Нотатки по книзі «Як пасти котів», Рейнвотер
Одна з тез книги, яка мене сильно здивувала — про те, що тимлід — зовсім не обов'язково найдосвідченіший програміст у команді (взагалі, через специфіку нашої професії, будь-який програміст, не виключаючи тимліда, вважає себе найкращим) . У ролі тим-ліда є каверза: часто, посаду керівника пропонують за особливі заслуги в програмуванні, але навички, необхідні для цієї посади потрібні зовсім інші, і скоріше стосуються бізнесу, ніж програмування.
Нижче мій безсистемний перелік нотаток. Деякі з них – це цитати, деякі – мої інтерпретації та думки, що виникають під час читання.
- Не дивуйтеся, що ви почуваєтеся некомфортно в новій ролі. Відчуття комфорту з'явиться, мабуть, через 6 місяців або 12 місяців.
- Песики, що віддано дивляться в очі не потрібні. Потрібні хороші програмісти, незважаючи на всі їхні дивацтва.
- Важливі навички керівника – це наставництво, терпіння та проникливість.
- Елегантність – це досяжна досконалість.
- 70% вартості ПЗ - це супровід. Як наслідок, цим можна виправдати і тести, і елегантний код. З останнім, щоправда, є нюанси.
- Тім-ліду потрібно приділяти увагу коду, але намагатися мислити глобальніше.
- Варіант із «Днем керувати, увечері писати код» працює лише деякий час, але, зрештою, від цього втомлюєшся.
- Делегування – це дуже важливо
- Керівництво - це рутинні завдання керівника (контроль термінів тощо),
- лідерство — це вміння допомагати команді досягати більш високих результатів.
- Чим вища організованість, тим легше знаходити баланс між лідерством та керівництвом.
- Окрім самоорганізації потрібно ще допомагатикомпанії організовувати процеси, що стосуються розробки.
- Мета керівника – зробити успіх результатом рутинної роботи.
- У роботі з інформацією має бути система. Це стосується як робочого столу, так і інформації в цілому.
- Обов'язково слід писати код. Хоча б уночі.
- Найкраще, що може зробити керівник, — удосконалити себе.
- Вимагайте від своїх програмістів домагатися бездоганності. Якщо вони вважають, що це затягує час — нагадайте їм, що елегантність — це досконалість.
- Потрібно думати наперед про проблеми, які можуть забрати багато часу. Потрібно працювати на випередження.
- Для зустрічі з колективом вистачить раз на тиждень.
- 45 хвилин на нараду більш ніж достатньо.
- Варто планувати проміжні пункти, оскільки люди часто відкладають усе до останнього.
- Проектування, перш ніж технології.
- Робота вдома - чудово! Але рівень дисципліни в усіх різний. Обов'язково потрібно перевіряти і стежити за метриками роботи співробітників, яким дозволили попрацювати вдома.
- Варто почати писати списки завдань програмістам, і вже неможливо від цього відмовитися — всі чекатимуть нових завдань. Саме тому варто дуже уважно та серйозно підходити до цієї роботи.
- Бізнес: збирання інформації необхідної для координування програмних завдань.
- Специфікація: Системне відстеження очікуваних результатів. Одиниці виміру: проект, технологічна область, наприклад.
- Реалізація: прискіпливе виявлення всіх подробиць, що становлять очікуваний результат, поглиблений аналіз.
- Завдання керівника – організовувати виробництво ПЗ. Інформацію, яка цьому не допомагає, потрібно фільтрувати.
- Більшість «Термінових чудовихпрохання» розмивають фокус. На такі прохання потрібно відповідати, сказавши, що зараз дуже мало часу, але ти обов'язково з цим розберешся! Та й записувати це в чергу завдань, щоб не забути.
- Ваше головне завдання – випустити програмний продукт.
- Фокусуватися — отже, розставляти пріоритети серед тих відомостей, які претендують на значущість, і справді значимих відомостей.
- Потрібно виділяти час як програмування, і рішення адміністративних завдань.
- Спирайтеся на програмне забезпечення для управління проектами.
- Не варто постійно відволікатися на skype.
- З усією хитрістю та підступністю, важливо намагатися змусити співробітників концентруватися на своїй роботі.
- Потрібно формувати списки завдань на тиждень із пріоритетами та термінами завершення.
- Якщо розробники дісталися у спадок – дуже гарна ідея – запропонувати програмістам описати свої поточні завдання. Так можна дізнатися не лише про те, як керували розробниками раніше, про те, як хтось із них бачить свої обов'язки.