Вы когда-нибудь встречали менеджера, довольного скоростью разработки? Лично я нет. Но иногда все гораздо хуже, чем просто скорость… мне доводилось слышать много воспитательных бесед с клиентами о работе разработчика — почему вы не можете писать код 8 часов кряду и почему сидя и рассматривая стену или даже играя в настольный теннис, разработчик тоже может работать, потому что обдумывает решение задачи в этот момент. Однажды один из топ менеджеров зашел в мою комнату с криком: «Они не работают! Они сидят в интернете!!! Что мы можем с этим сделать?»
История
Итак, я расскажу вам историю о двух командах. Обе они работали над мобильным продуктом одинаковой сложности. Одна из команд упорно работала все время — 10-12 часов в день, часто работая в выходные дни. Каждый релиз для них был сражением — им почти всегда удавалось выкатывать его вовремя, но это было непросто, очень непросто. Каждый знал, как упорно они работают — было постоянное движение, и каждый мог понять, просто взглянув, что вся команда занята делом. Довольно часто у них были «критические блоки» перед релизом и вся команда собиралась для решения этой задачи. Вы могли увидеть их стоящими возле компьютера и что-то обсуждающими. Если им улыбалась удача — найденный фикс не приводил к возникновению новых багов, но иногда их была целая цепочка — одна проблема возникала за другой. Таким образом, они должны были работать всю ночь, чтобы подготовить билд к релизу.
Вторая команда была абсолютно другой — они начинали работать в 11 часов утра, а уходили домой в 6-7 вечера. Они тоже регулярно делали релизы и практически никогда не было задержек. Они много работали над архитектурой приложения, чтобы сделать ее понятной и лёгкой в сопровождении. Архитектура не была идеальной, но они пытались ее улучшить. Они не были в панике перед релизом, разработчики могли более или менее предсказать сложности нового функционала. Да, они также тратили много времени на юнит-тесты и интеграционные тесты. Они могли потратить половину спринта на рефакторинг. Были ли у них более легкие задачи, чем у предыдущей команды? Нет.
Как это выглядело со стороны менеджеров? Бьюсь об заклад, вы предложите что-то вроде «Первая команда усердно работает, вторая — нет.» Менеджеры даже пытались измерить «продуктивность», сравнивая показатели затраченных часов — первая команда постила почти в два раза больше рабочих часов в Jira. Итак, для всех было очевидно, что вторая команда очень ленивая.
Но что на счет результатов? Они были почти одинаковы для обеих команд — работающие приложения в продакшене, более менее счастливые клиенты. Я даже не скажу вам, что второе приложение работало лучше и содержало меньше багов (и это правда)
Итак, как понять, что ваши разработчики усердно работают
Эта история демонстрирует то, что нельзя судить о производительности команды по тому, насколько занятыми выглядят разработчики.
Лично я считаю, что настоящие разработчики должны быть ленивыми. Если они делают одну и ту же вещь дважды — они слишком ленивы повторять это, поэтому пытаются придумать, как автоматизировать этот процесс. Они ленивы, поэтому не могут позволить себе повторов — избавляются от них настолько, насколько возможно. Они всегда ищут более удобные и продуктивные варианты.
Итак, когда менеджер жалуется «они смотрят видео на youtube в рабочее время», я обычно спрашиваю его/ее — «Но почему это является проблемой? Вы не удовлетворены результатами команды?».
Вот небольшая инструкция для менеджеров проектов. Первое, определите, с чем есть проблемы.
Если нет проблем и ошибок в разработке, но вы чувствуете, что «это не правильно»:
- Невозможно писать код 8 часов в день. Вам нужно время хотя бы на обдумывание, потому что вы не печатная машинка — вы сперва должны решить, что напечатать. Время на обдумывание иногда может занимать во много раз больше печатания.
- Что касается обдумывания — вы не можете думать по 8 часов в сутки без перерыва (И здесь я не имею ввиду мысли о предстоящем отпуске — лично я могу думать об этом весь день). Я имел ввиду «изобретать». Вам нужно время для придумывания идей. Вы не можете просто быть машиной-генератором идей. Поэтому всегда должен быть небольшой «пробел» в рабочем дне.
- Менеджеру проектов очень тяжело понять, как работает разработчик — для менеджера день состоит из прерываний, это «поток менеджера». Поток разработчика, наоборот — непрерывен, когда вы загружаете всю информацию о задании себе в мозг — переменные и их значения, объекты, связи и т.д. Вы должны держать все это в своей голове, чтобы писать код, в добавок к «модели» решения. Вы устаете от этого. Ваш мозг хочет небольшой отдых. Это все равно что нести тяжелые коробки в течение нескольких часов — вам просто нужно отдохнуть. И вы выгружаете все из своего мозга и открываете Reddit. И в этот момент заходить ваш менеджер и «Эй, почему ты не работаешь???»
- Прогресс. Вы не можете прогрессировать если все время загружены. У вас просто нет времени для изменений. Поэтому должно оставаться время дл этого — для экспериментов, для роста, для обучения
- Это не фабрика. Вы не можете судить о производительности, используя простые метрики вроде «количество выпущенных элементов». Все эти простые метрики, такие как количество строчек кода или «количество фич» за определенное время. Разработчики не дураки (к сожалению, они слишком умны) — когда вы начинаете измерять их — они взламывают вашу метрику. Единственный способ извлечь из этого пользу — задать метрику «успеха» — достижение каких-то командных целей, релизов, прибыли, счастливых клиентов. Нет с этим проблем? Значит нечего исправлять.
Есть ошибки в разработке
Попробуйте найти первопричины. Самый легкий способ — это сказать что разработчики ленивые. Даже если разработчик не работает… просто не работает в течение всего дня. Попытайтесь выяснить почему. Может потому что вы, как менеджер проектов, делаете свою работу плохо: разработчик не заинтересован в проекте? Потому что все очень скучно? Потому что «нет смысла что-либо делать, я все равно буду виноват в конце концов»?
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.
Итак, не пытайтесь изменить людей. Измените окружающую обстановку, измените управление, удалите препятствия. Будьте садовником — вы не можете сделать настоящий цветок своими руками, но вы можете вырастить его.
Комментарии (18)
Fasakhov
31.05.2015 22:01"… задать метрику «успеха» — достижение каких-то командных целей, релизов, прибыли, счастливых клиентов. Нет с этим проблем? Значит нечего исправлять."
Вот у менеджера по маркетингу, есть четкие измеряемые цели по привлечению новых клиентов по определенным рынкам, а у разработчиков такой цели нет. Можно неделю ждать от них когда сделают элементарный 301 редирект с одной страницы на другую. По опыту, проблемы в управлении всегда идут от собственников к менеджерам и уже потом к разработчикам. Как задали с самого начала генетический код корпоративной культуры, так с этим кодом и живет (или не живет) компания. Нужно писать статью «Руководство собственника». Менеджеры бывают и не причем в создавшихся проблемах. Пишу как менеджер.
tiny_squirrel
01.06.2015 05:34+1100% согласна про источники корпоративной культуры. К сожалению, ни разу не удалось убедить в этом собственников, все соглашались, что toxic культура присутствует, но не считали это корнем всех зол. А в итоге — система не функционирует, а корчится в попытках выжить.
У разработчиков и не должно быть цели привлечь новых клиентов, так же, как и задачи «успеха» бизнеса, тк они не собственники и просто не могут разделять то же стремление к успеху и отношение к бизнесу (мне категорически не нравится популярное отношение «давайте сделаем так, чтобы все себя вели как собственники, при этом будучи наемными сотрудниками»). Но, «работающий продукт», «чтобы никогда не сидеть в пятницу после 6 вечера из-за внезапного бага на продакшене» — вот это ближе к людям, это будет всем понятно :) Ну и, конечно, «светлое будущее» — глобальные цели, не слишком фантастические, чтобы быть недостижимыми, но достаточно вдохновляющие.
ncix
01.06.2015 16:37>>Менеджеры бывают и не причем в создавшихся проблемах. Пишу как менеджер.
Как удобно всегда на кого-то переложить ответственность.
own Автор
01.06.2015 22:48Частично с вами согласен. В моем случае менеджером является собственник, у которого есть опыт работы разработчиком. Но это скорее исключение. По поводу управления программистами и взаимодействия с начальством (собственником) рекомендую послушать выступления Григория bobuk Бакунова из Яндекса.
Shing
04.06.2015 14:11own сорри, но вы имхо не ответили на вопрос.
Так как понять, что разработчики действительно работают?
По достижению целей? Но одна цель будет легкой, другая наоборот недостижимой.
менеджер жалуется «они смотрят видео на youtube в рабочее время», я обычно спрашиваю его/ее — «Но почему это является проблемой? Вы не удовлетворены результатами команды?».
А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?
Единственный способ извлечь из этого пользу — задать метрику «успеха» — достижение каких-то командных целей, релизов, прибыли, счастливых клиентов. Нет с этим проблем? Значит нечего исправлять.
Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Или вы сводите все к интуиции и тому, что измерить это нереально?
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.
Но об этом ни слова.
p.s. ах, это перевод. но все равно, значит вы согласны наверно с данным материалом. интересны комментарии.Mirth
04.06.2015 15:52Не own, но отвечу.
А что если менеджер хочет ЕЩЕ больше результатов?
Его задача именно выжимать максимум из доступных ресурсов.
Оный максимум задаётся при проектировании технического задания и, зачастую, не находится в области компетенции менеджера. Действующих критериев оценки работы девелопера — всего три:
1. Соблюдение ТЗ
2. Нарекания от пользователя (количество и серьёзность проблем)
3. Нарекания от поддержки (аналогично)
Планку нужно выставить. Вы не описали как.
Очень просто: составить ТЗ.
суть развития в повышении планки.
Всё правильно. Поэтому специалисты, занимающиеся составлением ТЗ, учитывают не только пожелания заказчика продукта, но и результаты выполнения прошлых работы, а также сравнивают их со статистикой по отрасли.
Или вы сводите все к интуиции и тому, что измерить это нереально?
Я так понимаю, суть статьи — в том, что загрузка разработчика, видимая или фактическая, не может являться показателем эффективности его работы и поэтому подлежит регулированию только квалифицированными в области разработки управляющими. Если совсем просто: менеджер, управляющий разработчиками, должен быть специалистом не только в области менеджмента, но и в разработке.
own Автор
04.06.2015 17:00Shing Надеюсь, вы учли, что это перевод. Все, что написано ниже, мое личное мнение.
Чтобы правильно оценивать работу программистов, нужно самому иметь опыт в разработке. Есть еще человеческий фактор. Если у проджект менеджера нет своего репозитория (напр. на гитхабе), он не учавствует активно в жизни проекта (не делает коммитов, не приходит на код ревью), то наладить контакт с командой разработчиков и пользоваться авторитетом ему будет, мягко говоря, непросто. Очевидно, из-за этого бывают сложности в оценивании работы, срывы дедлайнов и т.д.
Поэтому всегда есть, что исправлять.
Можно что-то усовершенствовать, добавить новый функционал. Исправлять функционал, который работает, покрыт тестами, делает клиентов довольными… не имеет смысла.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Для этого существуют и давно применяются эстимейты, скрам, спринты и другие методологии.
tiny_squirrel
04.06.2015 21:55Попробую ответить. Статья, конечно, не задумывалась как полное и исчерпывающее руководство, тк, к сожалению, все очень зависит от конкретного случая и команды. Менеджмент в данном случае далек от теории и близок к практике. Скорее это протест против бездумного охаивания менеджерами «ленивых» разработчиков и попытка заставить из посмотреть на это с другой стороны: может быть проблемы и нет? может быть они и не ленивы вовсе, а у нас с целями что-то не так?
А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?
По целям) Выполняются? Значит все отлично. Не выполняются? Давайте разбираться. Как разбираться? Тут уже от ситуации зависит) Хотите выжать больше — меняйте цели. Ваша задача, как менеджера, создать для разработчиков своеобразный фреймворк, в котором они бы прекрасно существовали и пользовались свободой в его рамках. Вага задача — подкручивать его тут и там, чтобы все это достигало определнных целей. Это я сейчас говорю уже о несколько большем, чем «успех проекта», я говорю о компании. Если нам нужен успех проекта — это к ТЗ, как ответили выше.
Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Или вы сводите все к интуиции и тому, что измерить это нереально?
Как выставить планку и как создать такой фреймворк работы — пишут целые книги. Например, рекомендую — «Management 3.0» by Jurgen Appelo.
Предел максимальной эффективности — это тот, который вы можете достичь. Опытным путем. Пока все не сломается, например. Но нужна ли нам максимальная эффективность или производительность, например? Максимальная «утилизация ресурсов»? Максимизация утилизации ресурсов, например, снижает эффективность. Подняли производительность тут — соседние отделы захлебнулись результатами вашей деятельности.
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.
Были комментарии про то, что менеджер — не программист и не может понять, что программист соврал, запросив неделю на решение задачи, которая занимает час. Я программист, но я вела много проектов за рамками моих компетенций ( я не могу одновременно знать и Objective C и .Net и «что-то там еще про Scala»). Мне врали программисты. Это вскрывается. Нужно много общаться, нужно быть со своей командой, тогда прекрасно видно, кто чем занимается. Кто о чем говорит. Я всегда была менеджером «в полях», никогда не сидела в отдельном кабинете, всегда с командами. 80% моего времени — с командами. Тот же scrum — это изрядная потогонка для разработчиков, все на виду каждый день.
shamann
04.06.2015 16:44+1Позволю не согласится с выводом, что не надо изменять людей. На самом деле, развиваясь и обучаясь, человек ведь меняется. С позитивной точки зрения, хороший руководитель всё же меняет людей, его сотрудники растут, развиваются, становятся способными на большее. И вот для хорошего роста как раз и стоит создавать условия
«Меняй людей или меняй людей» — (развивай, мотивируй, обучай...) или (увольняй) нанимай других
Спасибо за отличный перевод.tiny_squirrel
04.06.2015 22:30Согласна. Изменения нужны, но, скорее, не мы меняем людей, а они сами меняются). А менеджеры создают условия, благоприятную среду. Вот так хороший менеджер и меняет людей: они меняются сами — у них просто не остается выбора. Например, если представить камень, который никак не хочет катиться вперед, лучше не продолжать его пинать (чтобы он поменялся и стал идеальным шаром), а чуть поменять рельеф — подрыть ямку перед ним, сдвинуть с места, переложить на бревна и катить :) Не лучший пример, тк камень и остался камнем, но, надеюсь, мысль понятна. «Пока враг рисует карты местности, мы меняем рельеф! Причем, вручную.» :)
Звучит как сказка, конечно, но по моим скромным эмпирическим данным — работает. И не забывайте расставаться с теми, кто выпадает из вашей культуры полностью. Для блага обоих.
antonzol
18.06.2015 13:46На самом деле действительно не ясно как понять работает разработчик или нет.
Но результат его работы осязаем (например рабочее приложение).
Главное правильно поставить задачу: что должно получиться в итоге.
Sergunka
Классаня статья. Увы на новом проекте попал в тим с двумя китайцами — которые имеют очень смутное представление о технологическом стеке и для чего нужны интеграционные тесты.
При слове рефакторинг — пучат глаза и похоже делают под себя. Основной аргумент против рефакторинга — а что если что-то перестанет работать и мы не заметим?
zharikovpro
> Основной аргумент против рефакторинга — а что если что-то перестанет работать и мы не заметим?
Ну без тестов при плохой архитектуре так оно и будет скорее всего :) Хотя если речь именно про «мы не заметим» — тут в некоторых случаях может спасти мониторинг логов и исключений.
own Автор
Имхо, без рефакторинга невозможно написание нового функционала. Чем дольше рефакторинг откладывается на потом, тем больше код превращается в лапшу, которую очень трудно поддерживать в дальнейшем. На более менее сложном проекте без тестов не обойтись. Они нужны не только, чтобы «заметить» что что-то сломалось, но и понять, как это исправить.
RouR
Т.е. если сейчас что-то не работает и они этого не замечают, то это ок? :) А при рефакторинге иногда такое можно выявить.