Как измерить эффективность и решать проблемы разработчиков, если у тебя их сто
Вопрос о том, как оценить эффективность процесса разработки существует столько же, сколько и сама разработка. Часто девелоперы могут придерживаться идеи, что нужно просто качественно писать код, а вот все эти оптимизации, митинги, трекинг активности и так далее — менеджерская блажь. Руководители же в свою очередь считают, что превыше всего — продукт и у нас тут вообще-то бизнес, а не клуб по интересам: так что без метрик обойтись невозможно. Но насколько вообще важны метрики?
В начале сентября мы провели митап для руководителей разработки и поговорили об этом с людьми из 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 в технологии и пр.) — пишите в личку. Запись получилась не очень качественной, поэтому выкладывать ее в паблик мы не стали:, но поделиться с теми, кому правда нужно, всегда готовы.
