Данная статья является переводом материала, расположенного по ссылке.
Вы когда-нибудь встречали менеджера, довольного скоростью разработки? Лично я нет. Но иногда все гораздно хуже, чем просто скорость… мне доводилось слышать много воспитательных бесед с клиентами о работе разработчика — почему вы не можете писать код 8 часов к ряду и почему сидя и рассматривая стену или даже играя в настольный теннис, разработчик тоже может работать, потому что обдумывает решение задачи в этот момент. Однажды один из топ менеджеров зашел в мою комнату с криком: «Они не работают! Они сидят в интернете!!! Что мы можем с этим сделать?»
История
Итак, я расскажу вам историю о двух командах. Обе они работали над мобильным продуктом одинаковой сложности. Одна из команд упорно работала все время — 10-12 часов в день, часто работая в выходные дни. Каждый релиз для них был сражением — им почти всегда удавалось выкатывать его вовремя, но это было непросто, очень непросто. Каждый знал, как упорно они работают — было постоянное движение, и каждый мог понять, просто взглянув, что вся команда занята делом. Довольно часто у них были «критические блоки» перед релизом и вся команда собиралась для решения этой задачи. Вы могли увидеть их стоящими возле компьютера и что-то обсуждающими. Если им улыбалась удача — найденный фикс не приводил к возникновению новых багов, но иногда их была целая цепочка — одна проблема возникала за другой. Таким образом, они должны были работать всю ночь, чтобы подготовить билд к релизу.
Вторая команда была абсолютно другой — они начинали работать в 11 часов утра, а уходили домой в 6-7 вечера. Они тоже регулярно делали релизы и практически никогда не было задержек. Они много работали над архитектурой приложения, чтобы сделать ее понятной и лёгкой в поддержке. Архитектура не была идеальной, но они пытались ее улучшить. Они не были в панике перед релизом, разработчики могли более или менее предсказать сложности нового фунционала. Да, они также тратили много времени на юнит-тесты и интеграционные тесты. Они могли потратить половину спринта на рефакторинг. Были ли у них более легкие задачи, чем у предыдущей команды? Нет.
Как это выглядело со стороны менеджеров? Бьюсь об заклад, вы предложите что-то вроде «Первая команда усердно работает, вторая — нет.» Менеджеры даже пытались измерить «продуктивность», сравнивая показатели затраченных часов — первая команда постила почти в два раза больше рабочих часов в Jira. Итак, для всех было очевидно, что вторая команда очень ленивая.
Но что на счет результатов? Они были почти одинаковы для обеих команд — работающие приложения в продакшене, более менее счастливые клиенты) Я даже не скажу вам, что второе приложение работало лучше и содержало меньше багов (и это правда)
Итак, как понять, что ваши разработчики усердно работают
Эта история демонстрирует то, что нельзя судить о производительности команды по тому, насколько занятыми выглядят разработчики.
Лично я считаю, что настоящие разработчики должны быть ленивыми. Если они делают одну и ту же вещь дважды — они слишком ленивы повторять это, поэтому пытаются придумать, как автоматизировать этот процесс. Они ленивы, поэтому не могут позволить себе повторов — избавляются от них настолько, насколько возможно. Они всегда ищут более удобные и продуктивные варианты.
Итак, когда менджер жалуется «они смотрят видео на youtube в рабочее время», я обычно спрашаиваю его/ее — «Но почему это является проблемой? Вы не удовлетворены результатами команды?»
Вот небольшая инструкция для менеджеров проектов. Первое, определите, с чем есть проблемы.
Если нет проблем и ошибок в разработке, но вы чувствуете, что «это не правильно»:
- Невозможно писать код 8 часов в день. Вам нужно время хотя бы на обдумывание, потому что вы не печатная машинка — вы сперва должны решить что напечатать. Время на обдумывание иногда может занимать во много раз больше печатания.
- Что касается обдумывания — вы не можете думать 8 часов к ряду (И здесь я не имею ввиду мысли о предстоящем отпуске — лично я могу думать об этом весь день). Я имел ввиду «изобретать». Вам нужно время для придумывания идей. Вы не можете просто быть машиной-генератором идей. Поэтому всегда должен быть небольшой «пробел» в рабочем дне.
- Менеджеру проектов очень тяжело понять, как работает разработчик — для менеджера день состоит из прерываний, это «поток менеджера». Поток разработчика наоборт — непрерывен, когда вы загружаете всю информацию о задании себе в — переменные и их значения, объекты, связи и т.д. Вы должны держать все это в своей голове, чтобы писать код, в добавок к «модели» решения. Вы устаете от этого. Ваш хочет небольшой отдых. Это все равно что нести тяжелые коробки в течение нескольких часов — вам просто нужно отдохнуть. И вы выгружаете все из своего и открываете Reddit. И в этот момент заходить ваш менеджер и «Эй, почему ты не работаешь???»
- Прогресс. Вы не можете прогрессировать если все время загружены. У вас просто нет времени для изменений. Поэтому должно оставаться время дл этого — для экспериментов, для роста, для обучения
- Это не фабрика. Вы не можете судить о производительности, используя простые метрики вроде «количество выпущенных элементов». Все эти простые метрики, такие как количество строчек кода или «количество фич» за определенное время. Разработчики не дураки (к сожалению, они слишком умны) — когда вы начинаете измерять их — они взламывают вашу метрику. Единственный способ извлечь из этого пользу — задать метрику «успеха» — достижение каких-то командных целей, релизов, прибыли, счастливых клиентов. Нет с этим проблем? Значит нечего исправлять.
Есть ошибки в разработке
Попробуйте найти первопричины. Самый легкий способ — это сказать что разработчики ленивые. Даже если разработчик не работает… просто не работает в течение всего дня. Попытайтесь выяснить почему. Может потому что вы, как менеджеров проектов, делаете свою работу плохо: разработчик не заинтересован в проекте? Потому что все очень скучно? Потому что «нет смысла что-либо делать, я все равно буду виноват в конце концов»?
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это не сложно понять. Решение простое — вы их увольняете.
Итак, не пытайтесь изменить людей. Измените окружающую обстановку, измените управление, удалите препятствия. Будьте садовником — вы не можете сделать настоящий цветок своими руками, но вы можете вырастить его.
Автор: own
