Как измерить эффективность и решать проблемы разработчиков, если у тебя их сто

    Вопрос о том, как оценить эффективность процесса разработки существует столько же, сколько и сама разработка. Часто девелоперы могут придерживаться идеи, что нужно просто качественно писать код, а вот все эти оптимизации, митинги, трекинг активности и так далее — менеджерская блажь. Руководители же в свою очередь считают, что превыше всего — продукт и у нас тут вообще-то бизнес, а не клуб по интересам: так что без метрик обойтись невозможно. Но насколько вообще важны метрики?



    В начале сентября мы провели митап для руководителей разработки и поговорили об этом с людьми из Plesk, Avito, Додо Пиццы, Тинькова, Agima, ЦИАНа, Яндекс.Вертикалей, DocDoc — ну и про себя не забыли. Ниже — выжимка из того, о чем говорили наши гости.

    В малой команде метрики не так и важны


    Когда ты управляешь командой из пяти-десяти человек, вы становитесь согласованной боевой единицей, коллективом, в котором каждый знает каждого. Разработчики проводят вместе время, работают плечом к плечу и, зачастую, общаются и за пределами работы. Влиться в этот коллектив СТО не составляет труда: руководитель становится полноценным членом команды и имеет возможность напрямую общаться с каждым лично. Все конфликты, проблемы или трудности, с которыми может столкнуться команда, видны как на ладони, а между СТО и его подчиненными практически отсутствует административный барьер.

    Управлять компактными командами в плане оценки ее эффективности намного проще: так как участников рабочего процесса не слишком много, то любые неэффективные решения или методы видны сразу же. Да и разработчики с легкостью идут на контакт со своим старшим, потому что общаются с ним ежедневно.

    С сотней разработчиков все намного сложнее


    Как только размер команды кратно увеличивается и составляет не 5-10, а 50-100 человек, ситуация кардинально меняется. Теперь руководитель не может лично общаться с каждым, и нам необходимы четкие и эффективные метрики.

    Первое и самое очевидное решение — таск-менеджеры и анализ количества закрытых задач. JIRA и подобные инструменты могут дать определенный массив полезных данных. Например, анализ закрытых задач позволит выявить наличие каких-то проблем без личного общения с девелоперами.

    Например, когда в DocDoc формировали метрики, то изначально остановились на целых семи показателях, но в итоге осталось только три:

    1. удобство/удовольствие от работы;
    2. соотношение обещанного и затраченного времени на задачу;
    3. время жизненного цикла задачи.


    Первая метрика — субъективная и сигнализировали о ситуации в коллективе и микроклимате в целом. Вторая и третья — относились напрямую к разработке и отражали важные на тот момент параметры: у многих команд были проблемы с соблюдением сроков.

    Еще один канал получения информации — опросники, которых тоже не стоит чураться. Например, все команда разработки Skyeng состоят из распределенных сотрудников, и из-за разницы часовых поясов побеседовать лично с каждым сложно чисто физически. Для нас периодические опросы в онлайн-формате стали выходом. Они не занимают много времени, сотрудник может пройти их тогда, когда ему удобно, и для этого не надо резервировать слоты в календаре или переговорку в московском офисе.

    Проблема в том, что разработчики не всегда вовремя рассказывают о том, что их тревожит. Эту информацию можно получить только при личном общении, так что у хорошего CTO должны быть организованы «приемные часы», а то и вовсе спланированы беседы со всеми тимлидами и разработчиками в подчинении. У любого разработчика должно быть право назначить встречу вышестоящему руководителю в обход собственного тимлида. Иначе вы столкнетесь с консервацией проблем и их замалчиванием.

    Общение с заказчиком


    Не важно, работаете вы в продуктовой или аутсорс-компании. У любой разработки всегда есть заказчик: внутренний или внешний. В каких-то компаниях он выражен явно, в каких-то — нет, но заказчик есть всегда.

    Отзыв заказчика — достаточно важная информация, так как она может вскрыть проблемы, которые не видны изнутри, и посмотреть на процесс разработки со стороны. Если клиент полностью доволен и никаких замечаний по своему взаимодействию с разработчиками высказать не может, то на этом фронте все идет более-менее успешно и внутренние проблемы не выливаются за пределы коллектива.

    С другой стороны возможен сценарий, когда, вроде бы, разработка движется, но по отзыву клиента больше похожа на бардак, нежели на создание продукта: срыв сроков, проблемы в коммуникации, некорректная трактовка ТЗ. Любое из подобных замечаний — серьезный повод для того, чтобы углубиться в процессы команды и выяснить, на самом ли деле все так. Если слова заказчика подтвердятся, то нужно искать, что стало причиной проблем.

    Результаты проверки могут быть неожиданными. Так, например, часть вопросов возникает по причине недостаточной мотивации сотрудников: любому человеку тяжело выкладываться ежедневно на все сто и при этом не получать каких-то поощрений за свой труд. И в этом случае не стоит путать «поощрение» с «компенсацией» (второе — это зарплата). В этом случае подойдет как материальная, так и нематериальная стимуляция: бонусы, премии, какие-то корпоративные мероприятия и фишки для сотрудников. Даже замена оборудования или выполнение «необязательных» просьб подчиненных может показать разработчикам, что их труд ценен и к ним прислушиваются. А это, в свою очередь, поднимет «боевой дух» и производительность.

    Особенно внимательно в этой ситуации стоит отнестись к «опорным» сотрудникам, которые за счет собственных безумных усилий закрывают факапы других членов команды. Такие люди есть в любом коллективе и даже если в целом команда справляется хорошо, забывать о вкладе таких сотрудников не стоит. Потому что если они «перегорят», то все полетит в пропасть.

    В итоге: метрики бесполезны без общения с людьми


    Главная мысль всех выступлений на тему метрик: правды можно добиться только в прямом разговоре. Метрики позволяют выявить какие-то проблемы на статистическом уровне, но важно помнить, что они показывают только последствия.

    • Метрики не расскажут, что в команде завелся тролль, который отравляет обстановку в коллективе, или что рулить командой поставили зеленого пацана, который вообразил себя лучшим тимлидом из когда-либо живших на этой планете.
    • Метрики не расскажут, что недавно внедренный инструмент не только причиняет боль всем разработчикам, но после последнего обновления еще и неэффективный во всех смыслах кусок чьего-то быдлокода.
    • Метрики не расскажут, что на этапе коммуникации с клиентом и обсуждения ТЗ творится такой бардак, что команда вместо условного «трамвая» занялась созданием «троллейбуса из буханки хлеба».


    Метрики могут только показать сам факт наличия проблемы.

    А вот в чем ее суть — нужно разбираться на местах. Разбираться через беседы, встречи, опросы, то есть через прямое взаимодействие с живыми людьми. А метрики покажут вам, где, когда и с кем нужно пообщаться, но не более того.



    p.s. На митапе мнениями делились:

    * Сергей Лысцев (Plesk);
    * Егор Толстой (Avito);
    * Александр Андронов (Додо Пицца);
    * Андрей Шелёхин (Тиньков);
    * Алексей Паршуков (Skyeng, ex-DocDoc);
    * Андрей Рыжкин (Agima);
    * Алексей Чеканов (ЦИАН);
    * Данила Штань (Яндекс.Вертикали, ex-Tochka)

    Спасибо им большое!

    p.p.s. Если вам интересно послушать/посмотреть полную версию митапа (в нее также вошли вопросы финансовой мотивации, найма, уровня погруженности CTO в технологии и пр.) — пишите в личку. Запись получилась не очень качественной, поэтому выкладывать ее в паблик мы не стали: но поделиться с теми, кому правда нужно, всегда готовы.
    Skyeng
    295,75
    Компания
    Поделиться публикацией

    Комментарии 23

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Дмитрий, привет, а где-то встречали такое?
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Ага. Видел такое. Получается имитация бурной деятельности, спихивание ответственности на других (типа «у вас претензии к пуговицам есть?») и прочие прелести ввода KPI. :-)
              0
              Как только эти специальные люди начинают считать KPI программистов сидя в центральном офисе у PM «в полях» начинаются проблемы с командой проекта. Программисты очень не любят не понятных KPI, совещаний и прочих прелестей. Особенно когда их эффективность оценивает не понятно кто и не понятно как. Или уходят в другую крайность: формального достижения этих самих KPI без огонька и энтузиазма.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Это ни разу не эффективно. Т.к. появляется еще одно звено в цепочке ПМ-..-разработчик. Причем, как правило, для Вашего случая не связанного с ПМ и самими людьми, кого обсчитывает.
                  Я не спорю, что метрики нужны, но в статье правильно написано, что это не вершина мастерства, а один из инструментов. Причем не самый главный. И для каждого проекта (команды) они могут иметь свои особенности. О которых Ваш специальный человек узнает, только после скандала из-за недоплаченных премий сотрудникам. И то не факт.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    По хорошему можно оценить только эффективность команды, а не отдельного члена команды.
            0
            Как только размер команды кратно увеличивается и составляет не 5-10, а 50-100 человек
            а если сделать 10 команд, проблема решена?
              0
              Максим, именно проблему прямой регулярной коммуникации и обратной связи 1-на-1 для CTO, кажется, не решает — людей-то остается сотня, на какие группы их не дели. Конечно, у каждой группы будет свой лид, он будет больше знать о каждом, но руководитель всей разработки чуть отрезан остается.

              0
              Не могли бы вы более полно раскрыть принципы измерения метрик? Как померить удовольствие от работы?!
                0
                На сколько понял меряют не «удовольствие от работы», а проверяют есть ли какие-то проблемы.
                  0
                  Привет, спасибо за интересный вопрос — перекинули Алексею Паршукову, который рассказывал про такой опыт, ждем деталей
                  0
                  Фокус-группы можно проводить, например.
                    0
                    Программировать им когда?
                      0
                      Интересно, присылайте ссылку.
                        0
                        а как же классификация задач и подходящих под них программистов?
                        у всех есть свои плюсы и минусы и неэффективно раздавая задачи производительность будет никакой
                          0
                          А поясните мысль, пожалуйста, — круто, если на примере. Не до конца понятно, как вы видите такую классификацию
                            0
                            ну например, недалёкие, им можно давать простые задачи где надо, что-то добавить немного изменить или где много рутинной работы, что-то более сложное или если бага вдруг переходит в уровень сложных то такое им давать низя, скорее всего надо будет детально обьяснить как писать код с примерами, иногда такие учаться, а иногда вообще никак, но и для них работа найдётся

                            средненькие, которые не выдумывают новые подходы для решения задачи, а тупо делают по готовому шаблону, не особо задумываясь о будущем этого кода, делают обычно быстро если не возникает концептуальных вопросов

                            есть мегамозги которые делают довольно медленно по почти всегда очень хорошо, но может слишком сложно, им нужно давать сложные фичи и баги, но код надо ревьювить чтоб остальные тоже понимали что они натворили, и если совсем непонятно то пусть напишет попроще или обьяснит как с этим потом работать

                            и вот их всех надо как-то равномерно распределять между проэктами и задания давать подходящие по знаниям, а то будет неэффективно, одни могут заскучать другие обидеться если надо 10 раз подряд переделать, если же набирать только из одной категории, то получаем соответствующие минусы для этой категории, универсальных которые и умные и быстро делают там где надо и с рутинной работой готовы работать пока не встречал
                          0
                          Почему все так любят измерять эффективность разработчиков? Почему никто не измеряет эффективность менеджеров?
                            0
                            Привет, так одно не отрицает другого — для оценки качества менеджмента есть свои подходы, частично пересекающиеся: опросы, достижение результатов в рамках квартала/года и пр, опять же, вопрос верно выбранных метрик и зачем мы их вводим. Но, кажется, Хабр просто меньше ресурс о менеджменте, поэтому мы больше говорим здесь о командах разработки)
                              0
                              Как можно измерить того, чего нет? :-)

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое