Практически любая компания сталкивается с проблемой оценки персонала. Весы всегда немного шатаются – качество выполненной работы или количество завершенных задач? И для ИТ-департамента этот вопрос стоит остро и решается каждой компанией немного по-своему. Сегодня мы хотим описать наш опыт построения системы оценки разработчиков, аналитиков и заказчиков, над которым мы продолжаем экспериментировать.
Зачем мы этим занялись?
Компания Альфа-Лизинг (дочка Альфа-Банка) за 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, мы не описываем.
А именно:
Если оцифровать данные и положить на график, то получится вот такой шестиугольник.
Чем больше площадь шестиугольника, тем комфортнее ИТ-специалисту у нас. Если где-то есть падения, то это сигнал обратить внимание и вместе с сотрудником поработать над этим самым падением.
Диаграмму мы можем построить в любом срезе (отдела, города, команды… и т.д.). График показывает изменения каждого сотрудника и департамента целиком.
Помогло: таким образом мы постарались рационализировать самую непригодную для этого часть жизни – ощущения. Теперь мы лучше понимаем, как меняется работа и наше отношение к ней, можем попытаться предсказать выгорание сотрудников и достаточно оперативно на него отреагировать, увидеть несовершенства системы оценки и распределения задач и внести соответствующие изменения и многое другое.
Многие компании пытаются собирать обратную связь, но далеко не все умеют с ней работать и менять свою работу в зависимости от ее результатов. Главный ориентир, который помогает нам не сбиться с пути и не тратить время впустую – это здравый смысл, который прочно стоит на понимании того, что мы коммерческая компания и наша главная цель – это заработать деньги. Да, ИТ-департамент напрямую не приносит прибыли, но от качества и скорости нашей работы зависят конечный результат.
Поэтому каждый раз, когда мы пытаемся улучшить себя или мир вокруг и натыкаемся на какую-то трудность, мы оцениваем – принесет или сэкономит это деньги компании? Казалось бы: если ответ положительный, мы все делаем правильно, если нет – нужно отпустить не жалеть о потраченном времени. Но не все так однобоко. Есть задачи, которые затратные и прямой прибыли прямо сейчас не принесут, но в дальнейшем могут оказать драматическое влияние на развитие компании.
Следующим нашим большим шагом будет разработка и внедрение материальной оценки каждой задачи, которая поступает в ИТ. Мы хотим приучить себя и других мыслить в доходах и расходах, но на это понадобится какое-то время.
Зачем мы этим занялись?
Компания Альфа-Лизинг (дочка Альфа-Банка) за 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, мы не описываем.
А именно:
- Насколько интересны задачи, которыми ты занимаешься?
- Насколько сложны задачи?
- Достаточно ли тебе обратной связи от руководителя?
- Оцени свою удовлетворенность в зп.
- Оцени отношения в команде.
- Оцени свое понимание влияния твоей ежедневной работы на успех компании.
Если оцифровать данные и положить на график, то получится вот такой шестиугольник.
Чем больше площадь шестиугольника, тем комфортнее ИТ-специалисту у нас. Если где-то есть падения, то это сигнал обратить внимание и вместе с сотрудником поработать над этим самым падением.
Диаграмму мы можем построить в любом срезе (отдела, города, команды… и т.д.). График показывает изменения каждого сотрудника и департамента целиком.
Помогло: таким образом мы постарались рационализировать самую непригодную для этого часть жизни – ощущения. Теперь мы лучше понимаем, как меняется работа и наше отношение к ней, можем попытаться предсказать выгорание сотрудников и достаточно оперативно на него отреагировать, увидеть несовершенства системы оценки и распределения задач и внести соответствующие изменения и многое другое.
Вывод
Многие компании пытаются собирать обратную связь, но далеко не все умеют с ней работать и менять свою работу в зависимости от ее результатов. Главный ориентир, который помогает нам не сбиться с пути и не тратить время впустую – это здравый смысл, который прочно стоит на понимании того, что мы коммерческая компания и наша главная цель – это заработать деньги. Да, ИТ-департамент напрямую не приносит прибыли, но от качества и скорости нашей работы зависят конечный результат.
Поэтому каждый раз, когда мы пытаемся улучшить себя или мир вокруг и натыкаемся на какую-то трудность, мы оцениваем – принесет или сэкономит это деньги компании? Казалось бы: если ответ положительный, мы все делаем правильно, если нет – нужно отпустить не жалеть о потраченном времени. Но не все так однобоко. Есть задачи, которые затратные и прямой прибыли прямо сейчас не принесут, но в дальнейшем могут оказать драматическое влияние на развитие компании.
Следующим нашим большим шагом будет разработка и внедрение материальной оценки каждой задачи, которая поступает в ИТ. Мы хотим приучить себя и других мыслить в доходах и расходах, но на это понадобится какое-то время.
