Когда сложно быть «плохим парнем»

    Практически любая компания сталкивается с проблемой оценки персонала. Весы всегда немного шатаются – качество выполненной работы или количество завершенных задач? И для ИТ-департамента этот вопрос стоит остро и решается каждой компанией немного по-своему. Сегодня мы хотим описать наш опыт построения системы оценки разработчиков, аналитиков и заказчиков, над которым мы продолжаем экспериментировать.



    Зачем мы этим занялись?

    Компания Альфа-Лизинг (дочка Альфа-Банка) за 2017 год сильно выросла: размер бизнеса увеличился в 5,5 раз, общее количество сотрудников более чем в 2 раза, а ИТ-департамент разросся с 10 до 50 человек. При этом мы понимали, что в большой компании каждому нужны прозрачные и понятные KPI, которые мы либо придумаем сами, либо их навяжут нам извне.

    Чтобы не подстраиваться под чужую систему или адаптировать какую-то теоретическую формулу, пришлось создавать свою.

    Дано

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

    Так мы начали менять организационную структуру, расширяя область ответственности сотрудников. Больше не было одного специалиста, который отвечает, например, за сервера в Питере, и другого, который отвечает за сервера в Москве. Потребовалось какое-то время, но в целом идея о том, что мы в одной лодке, принялась командой спокойно. Потом, для задач поддержки бизнеса, мы наладили канбан, а для задач развития продуктов мы запустили SCRUM-команды. И если региональную сепарацию мы убрали, то возникла командная.

    Конечно, у SCRUM-команд было свое ретро, но для того, чтобы постоянно изменять процессы взаимодействия в разработке, мы сделали ретро на всю команду разработки через видеосвязь. Раз в месяц все разработчики и аналитики (кстати, отдельной роли тестировщика у нас специально нет) собираются и вместе обсуждают свои проблемы, но что самое главное – решают они тоже сообща, общим голосованием.

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

    Что сделали?


    ШАГ 1 – Публичный code review

    Чтобы наконец-то разобраться с качеством кода внутри компании, мы решили сделать двойную проверку для каждой задачи. Благодаря тому, что все разработчики у нас примерно одной квалификации, они могут сами стать как создателями кода, так и его проверяющими. Для того чтобы укрепить взаимодействие между офисами, проверку решили осуществлять силами двух специалистов – из Москвы и из Питера. Таким образом у нас получилось, что для того, чтобы выпустить задачу «в бой», она сначала должна пройти двойную проверку. Мы классифицировали замечания к коду. Всего у нас 7 классификаторов. Если есть замечания к коду, то они по фиксируются в нашем трекере, и задача уходит разработчику на исправление замечаний.

    Первые code review происходили публично. Все как в школе: написал код – вывел его на большой экран, и все его проверяют. Признаться честно, чтобы на такое решиться, нужно достаточно смелости и уверенности в своей работе. Но как-то нам удалось их провести, пусть с эмоциями и лишним «паром», но это стало первым большим камнем в фундаменте будущей системы.

    Помогло: в результате публичных code review нам удалось выработать «Стандарты хорошего кода», с которыми согласились все. Они немного меняются со временем, что абсолютно нормально. Главная цель – сделать проверку прозрачной, быстрой и объективной.

    В качестве бонуса даем ссылку на гениальный ролик про чистый код, который сильно мотивировал и повеселил нашу команду:


    ШАГ 2 – Новые роли и форма обратной связи

    Чистый код – это здорово, но на нем далеко не уедешь: ведь это всего одна из граней работы. После того как мы определились с правилами «чистописания» и оценками, нужно было переходить на следующий уровень и научиться доказывать, что работники мы тоже хорошие. Ситуация почти в каждой компании одинакова — ИТ-департаментом всегда кто-то из заказчиков недоволен: бизнес, маркетинг, юристы. Недовольство вещь неизмеримая, нет «недовольствомометра». Мы решили узнать, что именно думает заказчик о каждой конкретной выполненной разработчиком задаче.

    Как это происходит на примере: на доску вытягивается задача. Мы ее кратко обсуждаем и, если постановка задачи вызывает хоть малейшие сомнения или вопросы, она сначала идет на аналитика. Если задача очень простая, то аналитик к ней не привлекается. Но это не значит, что сам этап аналитики не выполнен. Нет. Разработчик по таким задачам аналитику проводит самостоятельно. Аналитик, в свою очередь, либо расшифровывает сложную задачу, либо декомпозирует ее, либо просто снимает с доски, если она вдруг потеряла актуальность.

    Если задача перешла в статус «Выполнено», мы решили спросить у заказчика, как ему было работать с конкретным разработчиком. В анкете всего 9,5 вопросов, которые позволяют нам оценить себя не только как профессионалов, но и как хороших работников и отдел, куда приятно обращаться. Если в задаче принял участие и аналитик, то мы спросили и аналитика, как ему работалось.

    Помогло: теперь у разработчика совсем не осталось возможности быть «плохим парнем» — мы делаем двойной code review, анализируем задачи, чтобы отбрасывать невозможные, и опрашиваем конкретных заказчиков и аналитиков, которые с ним работали. Успех этой системы в том, что ее не навязали извне, а создали вместе на общем голосовании. Поэтому никто не против такой всесторонней оценки.

    ШАГ 3 — Не останавливаться

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

    • Разработчик после задания заполняет анкету на Аналитика и Заказчика.
    • Заказчик на Аналитика и Разработчика.
    • Аналитик на Разработчика и Заказчика.

    В итоге у нас получилось очень много информации, которую нужно было сразу использовать и результаты этих анкет мы принялись оцифровывать. Чтобы вся затея не потеряла смысл, результаты обратной связи стали частью KPI аналитиков и разработчиков. Другими словами, часть их премии зависит от того, какую обратную связь они получают и насколько чистым будет поставленный с первого раза код.

    Единственный, кто вылетает из этой цепочки – это заказчик. Добавить в его KPI обратную связь от аналитика и разработчика не удалось, поэтому мы решили, что будем собирать фактуру и в конце года проведем итоги. В любом случае у нас будет повод для начала разговора и аргументы в пользу изменения ситуации в лучшую сторону. Этого часто не хватает для эффективной коммуникации.

    Помогло: этот шаг позволил нам восстановить баланс между всеми участниками процесса. Роль «плохого парня» стала максимально трудной.

    ШАГ 4 – А что ты чувствуешь?

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

    Чтобы избежать такой ситуации, мы общаемся с людьми. Обычная система обратной связи. В основе общения лежат 7 вопросов, 6 из которых оцифрованы. Мы просим каждого сотрудника оценить по 10-бальной шкале следующие параметры его самоощущения в организации. Причем определения мы даем только для 0 и 10. Что такое 5 или 7, мы не описываем.

    А именно:

    • Насколько интересны задачи, которыми ты занимаешься?
    • Насколько сложны задачи?
    • Достаточно ли тебе обратной связи от руководителя?
    • Оцени свою удовлетворенность в зп.
    • Оцени отношения в команде.
    • Оцени свое понимание влияния твоей ежедневной работы на успех компании.

    Если оцифровать данные и положить на график, то получится вот такой шестиугольник.



    Чем больше площадь шестиугольника, тем комфортнее ИТ-специалисту у нас. Если где-то есть падения, то это сигнал обратить внимание и вместе с сотрудником поработать над этим самым падением.

    Диаграмму мы можем построить в любом срезе (отдела, города, команды… и т.д.). График показывает изменения каждого сотрудника и департамента целиком.

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

    Вывод


    Многие компании пытаются собирать обратную связь, но далеко не все умеют с ней работать и менять свою работу в зависимости от ее результатов. Главный ориентир, который помогает нам не сбиться с пути и не тратить время впустую – это здравый смысл, который прочно стоит на понимании того, что мы коммерческая компания и наша главная цель – это заработать деньги. Да, ИТ-департамент напрямую не приносит прибыли, но от качества и скорости нашей работы зависят конечный результат.

    Поэтому каждый раз, когда мы пытаемся улучшить себя или мир вокруг и натыкаемся на какую-то трудность, мы оцениваем – принесет или сэкономит это деньги компании? Казалось бы: если ответ положительный, мы все делаем правильно, если нет – нужно отпустить не жалеть о потраченном времени. Но не все так однобоко. Есть задачи, которые затратные и прямой прибыли прямо сейчас не принесут, но в дальнейшем могут оказать драматическое влияние на развитие компании.

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

    Comments 12

      +1
      ШАГ 4 – А что ты чувствуешь?

      Главное, чтобы сотрудники видели, что их ответы действительно на что-то влияют. И если у сотрудника все становилось плохо, а потом резко выровнялось — возможно, что ему стало совсем все равно и он думает увольняться. Или на фоне "всех 7" сотрудник был замечен в разговорах о смене работы. За исключением таких нюансов — идея отличная.

        0
        Вы так написали «был замечен», будто это что-то крамольное :)
          0
          Мы стараемся найти равновесие между тем, что хочет сотрудник, и тем, что нужно компании. Часто именно в процессе таких встреч возникаю важные договоренности, которые мы стараемся выполнять. Причём, мы — это обе стороны: руководитель и сотрудник. Можем рассказать о конкретных примерах в следующей публикации.
          0
          А как у вас с KPI в отделах админов/девопсов/хелпдеска?
            0
            У Helpdesk основной kpi — это процент закрытых вовремя обращений. Каждое обращение проходит через руководителя группы поддержки. Руководитель оценивает категорию трудозатрат и направляет на инженера. Задача инженера — уложиться в категорию.

            У админов KPI — доступность сервисов. Мы только начали эту самую доступность релевантно измерять и корректно регистрировать простои сервиса. Точные цифры ещё будем корректировать, но основа измерений уже ясна.

            Касательно девопса – он еще не настолько развит, чтобы его измерять.
            +2
            1. Сколько времени обычно проходит от момента, когда программист отдал на ревью код и до момента когда ему поставили два аппрува?
            2. Как сильно вырос техдолг от введения такой системы?
            3. «Мы хотим приучить себя и других мыслить в доходах и расходах»: кто будет думать о качестве?
            4. «Мы просим каждого сотрудника оценить по 10-бальной шкале следующие параметры его самоощущения в организации.»: Ни в одной компании, где я работал, IT специалисты всех уровней не относились всерьез к таким анкетам. Вы верите их результатам?
              0
              1. Сколько времени обычно проходит от момента, когда программист отдал на ревью код и до момента когда ему поставили два аппрува?

              Не более суток.

              2. Как сильно вырос техдолг от введения такой системы?

              Не поверите, не вырос. Если смотреть долгосрочно, то скорее уменьшился, за счет повышения качества кода.

              3. «Мы хотим приучить себя и других мыслить в доходах и расходах»: кто будет думать о качестве?

              О качестве будет думать code review.

              4. «Мы просим каждого сотрудника оценить по 10-бальной шкале следующие параметры его самоощущения в организации.»: Ни в одной компании, где я работал, IT специалисты всех уровней не относились всерьез к таким анкетам. Вы верите их результатам?

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

              Вот и меня тоже интересует KPI админов и саппорта.

                0
                В анкете всего 9,5 вопросов

                А эти вопросы анкет на программиста и аналитика покажете?
                И как вы боретесь с эффектом «что оцениваем, то и получаем»?
                  0
                  Анкета выглядит примерно вот так:

                  1. Был ли разработчик заинтересован в решении вашей проблемы?
                  2. Были ли вам предложены варианты решения вашей задачи?
                  3. По факту реализации все ли требования, о которых вы договорились, учтены?
                  4. Вы бы порекомендовали этого разработчика другим коллегам нашей компании для реализации их задач?
                  5. В процессе реализации выдерживал ли разработчик данные вам обещания по сро кам?
                  6. В процессе реализации разработчик быстро отвечал на мои вопросы и вносил изменения в задачу на основе моих замечаний?
                  7. Разработчик предупреждал меня в случае простоя или в случае, когда ему срочно нужно было решать иные задачи?
                  8. По факту реализации понятно ли вам, как пользоваться новым функционалом?
                  9. Дополните вашу обратную связь в свободной форме
                  10. Как вы считаете, чего не хватает в этой форме обратной связи? Мы можем сделать ее лучше!


                  По второму вопросу – мы с ним боремся )
                  0

                  Отличная статья.
                  А есть ли защита от ложных ответов? Иногда легче сказать, что все хорошо, чем описывать проблему, особенно если отвечающий не верит в возможность её решения.
                  И разработчики, отвечая на неанонимный вопрос об их ощущениях от работы, будут давать более позитивные ответы. Они же не знают, кто, когда и как воспользуется этой информацией. Да и работает большинство недавно, что увеличивает неуверенность.
                  Мне кажется такая система модет очень быстро выродится, стать формальностью и постоянно обрастать костылями.

                    0
                    Хороший вопрос. Мы сами над этом все время думаем. Ничего идеального не бывает, особенно, если это касается людей. Люди – самая мощная адаптируемая система на нашей прекрасной планете. Люди ко всему привыкают и ко всему вырабатывают иммунитет. То, что работало сегодня, перестает работать завтра. У нас есть очень разные результаты (смотри скрин). Видно, что человеку некомфортно и что мы над этим работаем. Еще раз повторим, что это всего лишь инструмент, который работает здесь и сейчас. Очень может быть, что завтра мы его сильно переделаем. Может быть, что какой-то параметр перестанет быть важным и появится что-то новое….

                    Мы будем продолжать пробовать и меняться. Важно общение, важна заинтересованность в друг друге, важны изменения к лучшему и доверие. Серебряной пули нет, как нам бы этого ни хотелось. Но, если вы вдруг ее найдете, то не забудьте поделиться знанием ))

                  Only users with full accounts can post comments. Log in, please.