Вопрос о том, как оценить эффективность процесса разработки существует столько же, сколько и сама разработка. Часто девелоперы могут придерживаться идеи, что нужно просто качественно писать код, а вот все эти оптимизации, митинги, трекинг активности и так далее — менеджерская блажь. Руководители же в свою очередь считают, что превыше всего — продукт и у нас тут вообще-то бизнес, а не клуб по интересам: так что без метрик обойтись невозможно. Но насколько вообще важны метрики?
В начале сентября мы провели митап для руководителей разработки и поговорили об этом с людьми из Plesk, Avito, Додо Пиццы, Тинькова, Agima, ЦИАНа, Яндекс.Вертикалей, DocDoc — ну и про себя не забыли. Ниже — выжимка из того, о чем говорили наши гости.
Когда ты управляешь командой из пяти-десяти человек, вы становитесь согласованной боевой единицей, коллективом, в котором каждый знает каждого. Разработчики проводят вместе время, работают плечом к плечу и, зачастую, общаются и за пределами работы. Влиться в этот коллектив СТО не составляет труда: руководитель становится полноценным членом команды и имеет возможность напрямую общаться с каждым лично. Все конфликты, проблемы или трудности, с которыми может столкнуться команда, видны как на ладони, а между СТО и его подчиненными практически отсутствует административный барьер.
Управлять компактными командами в плане оценки ее эффективности намного проще: так как участников рабочего процесса не слишком много, то любые неэффективные решения или методы видны сразу же. Да и разработчики с легкостью идут на ��онтакт со своим старшим, потому что общаются с ним ежедневно.
Как только размер команды кратно увеличивается и составляет не 5-10, а 50-100 человек, ситуация кардинально меняется. Теперь руководитель не может лично общаться с каждым, и нам необходимы четкие и эффективные метрики.
Первое и самое очевидное решение — таск-менеджеры и анализ количества закрытых задач. JIRA и подобные инструменты могут дать определенный массив полезных данных. Например, анализ закрытых задач позволит выявить наличие каких-то проблем без личного общения с девелоперами.
Например, когда в DocDoc формировали метрики, то изначально остановились на целых семи показателях, но в итоге осталось только три:
Первая метрика — субъективная и сигнализировали о ситуации в коллективе и микроклимате в целом. Вторая и третья — относились напрямую к разработке и отражали важные на тот момент параметры: у многих команд были проблемы с соблюдением сроков.
Еще один канал получения информации — опросники, которых тоже не стоит чураться. Например, все команда разработки Skyeng состоят из распределенных сотрудников, и из-за разницы часовых поясов побеседовать лично с каждым сложно чисто физически. Для нас периодические опросы в онлайн-формате стали выходом. Они не занимают много времени, сотрудник может пройти их тогда, когда ему удобно, и для этого не надо резервировать слоты в календаре или переговорку в московском офисе.
Проблема в том, что разработчики не всегда вовремя рассказывают о том, что их тревожит. Эту информацию можно получить только при личном общении, так что у хорошего CTO должны быть организованы «приемные часы», а то и вовсе спланированы беседы со всеми тимлидами и разработчиками в подчинении. У любого разработчика должно быть право назначить встречу вышестоящему руководителю в обход собственного тимлида. Иначе вы столкнетесь с консервацией проблем и их замалчиванием.
Не важно, работаете вы в продуктовой или аутсорс-компании. У любой разработки всегда есть заказчик: внутренний или внешний. В каких-то компаниях он выражен явно, в каких-то — нет, но заказчик есть всегда.
Отзыв заказчика — достаточно важная информация, так как она может вскрыть проблемы, которые не видны изнутри, и посмотреть на процесс разработки со стороны. Если клиент полностью доволен и никаких замечаний по своему взаимодействию с разработчиками высказать не может, то на этом фронте все идет более-менее успешно и внутренние проблемы не выливаются за пределы коллектива.
С другой стороны возможен сценарий, когда, вроде бы, разработка движется, но по отзыву клиента больше похожа на бардак, нежели на создание продукта: срыв сроков, проблемы в коммуникации, некорректная трактовка ТЗ. Любое из подобных замечаний — серьезный повод для того, чтобы углубиться в процессы команды и выяснить, на самом ли деле все так. Если слова заказчика подтвердятся, то нужно иска��ь, что стало причиной проблем.
Результаты проверки могут быть неожиданными. Так, например, часть вопросов возникает по причине недостаточной мотивации сотрудников: любому человеку тяжело выкладываться ежедневно на все сто и при этом не получать каких-то поощрений за свой труд. И в этом случае не стоит путать «поощрение» с «компенсацией» (второе — это зарплата). В этом случае подойдет как материальная, так и нематериальная стимуляция: бонусы, премии, какие-то корпоративные мероприятия и фишки для сотрудников. Даже замена оборудования или выполнение «необязательных» просьб подчиненных может показать разработчикам, что их труд ценен и к ним прислушиваются. А это, в свою очередь, поднимет «боевой дух» и производительность.
Особенно внимательно в этой ситуации стоит отнестись к «опорным» сотрудникам, которые за счет собственных безумных усилий закрывают факапы других членов команды. Такие люди есть в любом коллективе и даже если в целом команда справляется хорошо, забывать о вкладе таких сотрудников не стоит. Потому что если они «перегорят», то все полетит в пропасть.
Главная мысль всех выступлений на тему метрик: правды можно добиться только в прямом разговоре. Метрики позволяют выявить какие-то проблемы на статистическом уровне, но важно помнить, что они показывают только последствия.
Метрики могут только показать сам факт наличия проблемы.
А вот в чем ее суть — нужно разбираться на местах. Разбираться через беседы, встречи, опросы, то есть через прямое взаимодействие с живыми людьми. А метрики покажут вам, где, когда и с кем нужно пообщаться, но не более того.
p.s. На митапе мнениями делились:
* Сергей Лысцев (Plesk);
* Егор Толстой (Avito);
* Александр Андронов (Додо Пицца);
* Андрей Шелёхин (Тиньков);
* Алексей Паршуков (Skyeng, ex-DocDoc);
* Андрей Рыжкин (Agima);
* Алексей Чеканов (ЦИАН);
* Данила Штань (Яндекс.Вертикали, ex-Tochka)
Спасибо им большое!
p.p.s. Если вам интересно послушать/посмотреть полную версию митапа (в нее также вошли вопросы финансовой мотивации, найма, уровня погруженности CTO в технологии и пр.) — пишите в личку. Запись получилась не очень качественной, поэтому выкладывать ее в паблик мы не стали: но поделиться с теми, кому правда нужно, всегда готовы.
В начале сентября мы провели митап для руководителей разработки и поговорили об этом с людьми из Plesk, Avito, Додо Пиццы, Тинькова, Agima, ЦИАНа, Яндекс.Вертикалей, DocDoc — ну и про себя не забыли. Ниже — выжимка из того, о чем говорили наши гости.
В малой команде метрики не так и важны
Когда ты управляешь командой из пяти-десяти человек, вы становитесь согласованной боевой единицей, коллективом, в котором каждый знает каждого. Разработчики проводят вместе время, работают плечом к плечу и, зачастую, общаются и за пределами работы. Влиться в этот коллектив СТО не составляет труда: руководитель становится полноценным членом команды и имеет возможность напрямую общаться с каждым лично. Все конфликты, проблемы или трудности, с которыми может столкнуться команда, видны как на ладони, а между СТО и его подчиненными практически отсутствует административный барьер.
Управлять компактными командами в плане оценки ее эффективности намного проще: так как участников рабочего процесса не слишком много, то любые неэффективные решения или методы видны сразу же. Да и разработчики с легкостью идут на ��онтакт со своим старшим, потому что общаются с ним ежедневно.
С сотней разработчиков все намного сложнее
Как только размер команды кратно увеличивается и составляет не 5-10, а 50-100 человек, ситуация кардинально меняется. Теперь руководитель не может лично общаться с каждым, и нам необходимы четкие и эффективные метрики.
Первое и самое очевидное решение — таск-менеджеры и анализ количества закрытых задач. JIRA и подобные инструменты могут дать определенный массив полезных данных. Например, анализ закрытых задач позволит выявить наличие каких-то проблем без личного общения с девелоперами.
Например, когда в DocDoc формировали метрики, то изначально остановились на целых семи показателях, но в итоге осталось только три:
- удобство/удовольствие от работы;
- соотношение обещанного и затраченного времени на задачу;
- время жизненного цикла задачи.
Первая метрика — субъективная и сигнализировали о ситуации в коллективе и микроклимате в целом. Вторая и третья — относились напрямую к разработке и отражали важные на тот момент параметры: у многих команд были проблемы с соблюдением сроков.
Еще один канал получения информации — опросники, которых тоже не стоит чураться. Например, все команда разработки Skyeng состоят из распределенных сотрудников, и из-за разницы часовых поясов побеседовать лично с каждым сложно чисто физически. Для нас периодические опросы в онлайн-формате стали выходом. Они не занимают много времени, сотрудник может пройти их тогда, когда ему удобно, и для этого не надо резервировать слоты в календаре или переговорку в московском офисе.
Проблема в том, что разработчики не всегда вовремя рассказывают о том, что их тревожит. Эту информацию можно получить только при личном общении, так что у хорошего CTO должны быть организованы «приемные часы», а то и вовсе спланированы беседы со всеми тимлидами и разработчиками в подчинении. У любого разработчика должно быть право назначить встречу вышестоящему руководителю в обход собственного тимлида. Иначе вы столкнетесь с консервацией проблем и их замалчиванием.
Общение с заказчиком
Не важно, работаете вы в продуктовой или аутсорс-компании. У любой разработки всегда есть заказчик: внутренний или внешний. В каких-то компаниях он выражен явно, в каких-то — нет, но заказчик есть всегда.
Отзыв заказчика — достаточно важная информация, так как она может вскрыть проблемы, которые не видны изнутри, и посмотреть на процесс разработки со стороны. Если клиент полностью доволен и никаких замечаний по своему взаимодействию с разработчиками высказать не может, то на этом фронте все идет более-менее успешно и внутренние проблемы не выливаются за пределы коллектива.
С другой стороны возможен сценарий, когда, вроде бы, разработка движется, но по отзыву клиента больше похожа на бардак, нежели на создание продукта: срыв сроков, проблемы в коммуникации, некорректная трактовка ТЗ. Любое из подобных замечаний — серьезный повод для того, чтобы углубиться в процессы команды и выяснить, на самом ли деле все так. Если слова заказчика подтвердятся, то нужно иска��ь, что стало причиной проблем.
Результаты проверки могут быть неожиданными. Так, например, часть вопросов возникает по причине недостаточной мотивации сотрудников: любому человеку тяжело выкладываться ежедневно на все сто и при этом не получать каких-то поощрений за свой труд. И в этом случае не стоит путать «поощрение» с «компенсацией» (второе — это зарплата). В этом случае подойдет как материальная, так и нематериальная стимуляция: бонусы, премии, какие-то корпоративные мероприятия и фишки для сотрудников. Даже замена оборудования или выполнение «необязательных» просьб подчиненных может показать разработчикам, что их труд ценен и к ним прислушиваются. А это, в свою очередь, поднимет «боевой дух» и производительность.
Особенно внимательно в этой ситуации стоит отнестись к «опорным» сотрудникам, которые за счет собственных безумных усилий закрывают факапы других членов команды. Такие люди есть в любом коллективе и даже если в целом команда справляется хорошо, забывать о вкладе таких сотрудников не стоит. Потому что если они «перегорят», то все полетит в пропасть.
В итоге: метрики бесполезны без общения с людьми
Главная мысль всех выступлений на тему метрик: правды можно добиться только в прямом разговоре. Метрики позволяют выявить какие-то проблемы на статистическом уровне, но важно помнить, что они показывают только последствия.
- Метрики не расскажут, что в команде завелся тролль, который отравляет обстановку в коллективе, или что рулить командой поставили зеленого пацана, который вообразил себя лучшим тимлидом из когда-либо живших на этой планете.
- Метрики не расскажут, что недавно внедренный инструмент не только причиняет боль всем разработчикам, но после последнего обновления еще и неэффективный во всех смыслах кусок чьего-то быдлокода.
- Метрики не расскажут, что на этапе коммуникации с клиентом и обсуждения ТЗ творится такой бардак, что команда вместо условного «трамвая» занялась созданием «троллейбуса из буханки хлеба».
Метрики могут только показать сам факт наличия проблемы.
А вот в чем ее суть — нужно разбираться на местах. Разбираться через беседы, встречи, опросы, то есть через прямое взаимодействие с живыми людьми. А метрики покажут вам, где, когда и с кем нужно пообщаться, но не более того.
p.s. На митапе мнениями делились:
* Сергей Лысцев (Plesk);
* Егор Толстой (Avito);
* Александр Андронов (Додо Пицца);
* Андрей Шелёхин (Тиньков);
* Алексей Паршуков (Skyeng, ex-DocDoc);
* Андрей Рыжкин (Agima);
* Алексей Чеканов (ЦИАН);
* Данила Штань (Яндекс.Вертикали, ex-Tochka)
Спасибо им большое!
p.p.s. Если вам интересно послушать/посмотреть полную версию митапа (в нее также вошли вопросы финансовой мотивации, найма, уровня погруженности CTO в технологии и пр.) — пишите в личку. Запись получилась не очень качественной, поэтому выкладывать ее в паблик мы не стали: но поделиться с теми, кому правда нужно, всегда готовы.
