Керівництво менеджера як зрозуміти, що розробники дійсно працюють
Ви коли-небудь зустрічали менеджера, задоволеного швидкістю розробки? Особисто я ні. Але іноді все гораздно гірше, ніж просто швидкість ... мені доводилося чути багато виховних бесід з клієнтами про роботу розробника - чому ви не можете писати код 8 годині до ряду і чому сидячи і розглядаючи стіну або навіть граючи в настільний теніс, розробник теж може працювати, тому що обмірковує рішення задачі в цей момент. Одного разу один з топ менеджерів зайшов в мою кімнату з криком: «Вони не працюють! Вони сидять в інтернеті. Що ми можемо з цим зробити? »
Отже, я розповім вам історію про двох командах. Обидві вони працювали над мобільним продуктом однакової складності. Одна з команд завзято працювала весь час - 10-12 годин на день, часто працюючи в вихідні дні. Кожен реліз для них був боєм - їм майже завжди вдавалося викочувати його вчасно, але це було непросто, дуже непросто. Кожен знав, як наполегливо вони працюють - було постійний рух, і кожен міг зрозуміти, просто глянувши, що вся команда зайнята справою. Досить часто у них були «критичні блоки» перед релізом і вся команда збиралася для вирішення цього завдання. Ви могли побачити їх стоять біля комп'ютера і щось обговорюють. Якщо їм посміхалася удача - знайдений фікс щоб привести до виникнення нових багів, але іноді їх була ціла ланцюжок - одна проблема виникала за одною. Таким чином, вони повинні були працювати всю ніч, щоб підготувати білд до релізу.
Друга команда була абсолютно іншою - вони починали працювати о 11 годині ранку, а йшли додому в 6-7 вечора. Вони теж регулярно робили релізи та практично ніколи не було затримок. Вони багато працювали над архітектурою додатки, щоб зробити її зрозумілою і легкою в підтримці. Архітектура не була ідеальною, але вони намагалися її поліпшити. Вони не були в паніці перед релізом, розробники могли більш-менш передбачити складності нового фунціонала. Так, вони також витрачали багато часу на юніт-тести і інтеграційні тести. Вони могли витратити половину спринту на рефакторинг. Чи були у них легші завдання, ніж у попередньої команди? Ні.
Як це виглядало з боку менеджерів? Б'юся об заклад, ви запропонуєте щось на кшталт «Перша команда старанно працює, друга - ні.» Менеджери навіть намагалися виміряти «продуктивність», порівнюючи показники витрачених годин - перша команда постила майже в два рази більше робочих годин в Jira. Отже, для всіх було очевидно, що друга команда дуже лінива.
Але що на рахунок результатів? Вони були майже однакові для обох команд - працюючі додатки в продакшені, більш менш щасливі клієнти) Я навіть не скажу вам, що другий додаток працювало краще і містило менше багів (і це правда)
Отже, як зрозуміти, що ваші розробники старанно працюють
Ця історія демонструє те, що не можна судити про продуктивність команди по тому, наскільки зайнятими виглядають розробники.
Особисто я вважаю, що справжні розробники повинні бути ледачими. Якщо вони роблять одну і ту ж річ двічі - вони занадто ліниві повторювати це, тому намагаються придумати, як автоматизувати цей процес. Вони ліниві, тому не можуть дозволити собі повторів - позбавляються від них настільки, наскільки можливо. Вони завжди шукають більш зручні і продуктивні варіанти.
Ось невелика інструкція для менеджерів проектів. Перше, визначте, з чим є проблеми.
Якщо немає проблем і помилок в розробці, але ви відчуваєте, що «це не правильно»:
- Неможливо писати код 8 годин на день. Вам потрібен час хоча б на обдумування, тому що ви не друкарська машинка - ви спершу повинні вирішити що надрукувати. Час на обдумування іноді може займати в багато разів більше друкування.
- Що стосується обмірковування - ви не можете думати 8 годині до ряду (І тут я не маю на увазі думки про майбутню відпустку - особисто я можу думати про це весь день). Я мав на увазі «винаходити». Вам потрібен час для придумування ідей. Ви не можете просто бути машиною-генератором ідей. Тому завжди повинен бути невеликий «пробіл» у робочому дні.
- Менеджеру проектів дуже важко зрозуміти, як працює розробник - для менеджера день складається з переривань, це «потік менеджера». Потік розробника наоборт - безперервний, коли ви завантажуєте всю інформацію про завдання собі в мозок - змінні і їх значення, об'єкти, зв'язку і т.д. Ви повинні тримати все це в своїй голові, щоб писати код, в добавок до «моделі» рішення. Ви втомлюєтеся від цього. Ваш мозок хоче невеличкий перепочинок. Це все одно що нести важкі коробки протягом декількох годин - вам просто потрібно відпочити. І ви вивантажуєте все зі свого мозку і відкриваєте Reddit. І в цей момент заходити ваш менеджер і «Ей, чому ти не працюєш. »
- Прогрес. Ви не можете прогресувати якщо весь час завантажені. У вас просто немає часу для змін. Тому має залишатися час дл цього - для експериментів, для росту, для навчання
- Це не фабрика. Ви не можете судити про продуктивність, використовуючи прості метрики на кшталт «кількість випущених елементів». Всі ці прості метрики, такі як кількість рядків коду або «кількість фіч» за певний час. Розробники не дурні (на жаль, вони занадто розумні) - коли ви починаєте вимірювати їх - вони зламують вашу метрику. Єдиний спосіб отримати з цього користь - задати метрику «успіху» - досягнення якихось командних цілей, релізів, прибутку, щасливих клієнтів. Ні з цим проблем? Значить нічого виправляти.
Є помилки в розробці
Спробуйте знайти першопричини. Найлегший спосіб - це сказати що розробники ледачі. Навіть якщо розробник не працює ... просто не працює протягом всього дня. Спробуйте з'ясувати чому. Може тому що ви, як менеджерів проектів, робите свою роботу погано: розробник не зацікавлений в проекті? Тому що все дуже нудно? Тому що «немає сенсу що-небудь робити, я все одно буду винен в кінці кінців»?
Так, іноді вам трапляються розробники, які просто не хочуть працювати. Це не складно зрозуміти. Рішення просте - ви їх звільняєте.
Отже, не намагайтеся змінити людей. Змініть навколишнє оточення, змініть управління, видаліть перешкоди. Будьте садівником - ви не можете зробити справжню квітку своїми руками, але ви можете виростити його.