Практически каждая компания сталкивается с проблемой оценки персонала.
Чаша весов всегда немного склоняется – качество выполненной работы или количество выполненных задач? А для ИТ-подразделения этот вопрос стоит остро и решается каждой компанией немного по-своему.
Сегодня мы хотим описать наш опыт построения системы оценки разработчиков, аналитиков и заказчиков, с которой мы продолжаем экспериментировать.
Зачем мы это делаем?
Компания «Альфа-Лизинг» (дочерняя компания Альфа-Банка) в 2017 году значительно выросла: размер бизнеса увеличился в 5,5 раза, общая численность сотрудников увеличилась более чем в два раза, а ИТ-подразделение выросло с 10 до 50 человек.
При этом мы понимали, что в крупной компании всем нужны прозрачные и понятные KPI, которые мы либо придумываем сами, либо они нам будут навязаны извне.
Чтобы не подстраиваться под чужую систему и не адаптировать какую-то теоретическую формулу, мне пришлось создать свою.
Данный Что у нас было в самом начале: исторически ИТ-команда была разделена на два офиса — Санкт-Петербург и Москва.
С одной стороны, им необходимо регулярно взаимодействовать друг с другом, но с другой, любая непонятная ситуация делит коллектив на два если не враждующих лагеря, где ответственность всегда на стороне «соседей», то просто отказывающихся от взаимодействия.
понимать друг друга.
Поэтому первое, что нужно было сделать, чтобы привести это уравнение к единому знаменателю, — это убрать границы ответственности и сделать ее общей для всех.
Поэтому мы начали менять организационную структуру, расширяя зону ответственности сотрудников.
Больше не было одного специалиста, который отвечал бы, например, за сервера в Питере, и другого, который отвечал бы за серверы в Москве.
Это заняло некоторое время, но в целом мысль о том, что мы находимся в одной лодке, команда восприняла спокойно.
Затем для задач поддержки бизнеса мы настроили канбан, а для задач разработки продукта запустили SCRUM-команды.
И если мы убрали региональное разделение, то появилось командное.
Конечно, у SCRUM-команд было свое ретро, но чтобы постоянно менять процессы взаимодействия в разработке, мы сделали ретро для всей команды разработки по видеосвязи.
Раз в месяц все разработчики и аналитики (кстати, у нас специально нет отдельной роли тестировщика) собираются вместе и вместе обсуждают свои проблемы, но самое главное — решают они тоже сообща, общим голосованием.
Эти встречи вскоре стали толчком к созданию системы оценивания.
Вопрос качества кода регулярно поднимался на ретро-мероприятиях.
Если системы нет, а есть отдельные «хорошие» ребята, которые борются за качество кода, то их инициатива рассылать выложенные в репозитории примеры «какашек» коллегам вызывала раздражение или насмешки.
Что ты сделал?
ШАГ 1 – Проверка общедоступного кода Чтобы окончательно понять качество кода внутри компании, мы решили перепроверить каждую задачу.Благодаря тому, что все наши разработчики имеют примерно одинаковую квалификацию, они сами могут стать как создателями кода, так и рецензентами кода.
Чтобы усилить взаимодействие между офисами, проверку решили провести два специалиста – из Москвы и из Санкт-Петербурга.
Таким образом, оказалось, что для того, чтобы выпустить задачу в бой, она должна сначала пройти двойную проверку.
У нас есть категории комментариев к коду.
Всего у нас есть 7 классификаторов.
Если к коду есть комментарии, они фиксируются в нашем трекере, и задача исправить комментарии переходит к разработчику.
Первые проверки кода прошли публично.
Это как в школе: написал код, выложил на большой экран, и все его проверяют. Честно говоря, чтобы решиться на это, нужно достаточно смелости и уверенности в своей работе.
Но каким-то образом нам удалось их провести, пусть и с эмоциями и слишком большим накалом, но это стало первым большим камнем в фундамент будущей системы.
Это помогло: в результате публичных проверок кода мы смогли разработать «Стандарты хорошего кода», с которыми все согласились.
Они со временем немного меняются, и это совершенно нормально.
Основная цель — сделать проверку прозрачной, быстрой и объективной.
В качестве бонуса мы предоставляем ссылку на блестящее видео о чистом коде, которое очень мотивировало и развеселило нашу команду: ШАГ 2 – Новые роли и форма обратной связи Чистый код — это здорово, но далеко с ним вы не продвинетесь: в конце концов, это всего лишь один аспект работы.
После того, как мы определились с правилами «чистоты» и оценками, нам пришлось перейти на следующий уровень и научиться доказывать, что мы тоже хорошие работники.
Ситуация практически в каждой компании одинаковая — кто-то из заказчиков всегда недоволен ИТ-отделом: бизнесом, маркетингом, юристами.
Неудовлетворенность – вещь неизмеримая; «измерителя неудовлетворенности» не существует. Мы решили узнать, что именно думает заказчик о каждой конкретной задаче, которую выполняет разработчик.
Как это происходит на примере: на доске нарисовано задание.
Мы кратко обсуждаем ее и, если постановка проблемы вызывает хоть малейшие сомнения или вопросы, она сначала передается аналитику.
Если задача очень простая, то аналитик ею не занимается.
Но это не значит, что сам этап аналитики не пройден.
Нет. Аналитику по таким задачам разработчик проводит самостоятельно.
Аналитик, в свою очередь, либо расшифровывает сложную проблему, либо декомпозирует ее, либо просто убирает с доски, если она вдруг потеряла свою актуальность.
Если задача переходила в статус «Выполнено», мы решали поинтересоваться у заказчика, как ему работать с конкретным разработчиком.
Анкета содержит всего 9,5 вопросов, которые позволяют оценить себя не только как профессионалов, но и как хороших сотрудников и отдел, с которым приятно работать.
Если в задании принимал участие и аналитик, то мы спрашивали аналитика, как это у него получилось.
Помогло : Теперь у разработчика больше нет возможности быть «плохим парнем» — мы делаем двойной ревью кода, анализируем задачи, чтобы отбросить невыполнимые, и опрашиваем конкретных заказчиков и аналитиков, которые с ним работали.
Успех этой системы в том, что она не была навязана извне, а создана совместно, путем всеобщего голосования.
Поэтому никто не против такой комплексной оценки.
ШАГ 3 – Не останавливайтесь В какой-то момент мы подумали, что не нужно останавливаться на достигнутом и можно собрать обратную связь от всех участников цепочки, а именно:
- После выполнения задания разработчик заполняет анкету для Аналитика и Заказчика.
- Заказчик для аналитика и разработчика.
- Аналитик для разработчиков и заказчиков.
Другими словами, часть их бонуса зависит от того, какую обратную связь они получают и насколько чистым является код, который они доставляют с первого раза.
Единственный, кто выпадает из этой цепочки, — это заказчик.
Добавить в его KPI обратную связь от аналитика и разработчика не удалось, поэтому мы решили, что соберем счет и подведем его итоги в конце года.
В любом случае у нас будет повод завязать разговор и аргументы в пользу изменения ситуации к лучшему.
Зачастую этого недостаточно для эффективного общения.
Это помогло: этот шаг позволил восстановить баланс между всеми участниками процесса.
Роль «плохого парня» стала максимально сложной.
ШАГ 4 – Что вы чувствуете? Теперь у нас есть идеальная «система», которая на цифрах и фактах доказывает, что мы правильно понимаем задачи, пишем хороший код и умеем общаться с другими отделами.
Пришло время заглянуть в себя, чтобы убедиться, что мы счастливы.
Глобальной статистики о том, насколько счастливы или несчастны люди в своих организациях, не существует. Очень распространенная ситуация: человек, чувствуя, что что-то не так, не пытается это проанализировать, копит недовольство, а затем просто уходит. Чтобы избежать такой ситуации, мы общаемся с людьми.
Нормальная система обратной связи.
Общение основано на 7 вопросах, 6 из которых оцифрованы.
Мы просим каждого сотрудника оценить следующие параметры своего самоощущения в организации по 10-балльной шкале.
При этом мы даем определения только для 0 и 10. Мы не описываем, что такое 5 или 7. А именно:
- Насколько интересны задачи, которые вы выполняете?
- Насколько сложны задачи?
- Достаточно ли для вас обратной связи от вашего менеджера?
- Оцените свою удовлетворенность зарплатой.
- Оцените взаимоотношения в команде.
- Оцените свое понимание влияния вашей повседневной работы на успех компании.
Чем больше площадь шестиугольника, тем комфортнее с нами ИТ-специалисту.
Если где-то есть падения, то это сигнал обратить внимание и поработать вместе с сотрудником над этим самым падением.
Мы можем построить диаграмму в любом разделе (отдел, город, команда.
и т.д.).
На графике показаны изменения по каждому сотруднику и всему отделу.
Помогло: Таким образом мы попытались рационализировать самую неподходящую часть жизни – ощущения.
Теперь мы лучше понимаем, как меняется работа и наше отношение к ней, можем попытаться спрогнозировать выгорание сотрудников и достаточно быстро отреагировать на него, увидеть несовершенства в системе оценки и распределения задач и внести соответствующие изменения и многое другое.
Заключение
Многие компании пытаются собирать обратную связь, но не все умеют с ней работать и менять свою работу в зависимости от ее результатов.Главным ориентиром, который помогает нам не сбиться с пути и не потерять время, является здравый смысл, который прочно основан на понимании того, что мы коммерческая компания и наша главная цель – зарабатывать деньги.
Да, ИТ-отдел не приносит прибыли напрямую, но от качества и скорости нашей работы зависит конечный результат. Поэтому каждый раз, когда мы пытаемся улучшить себя или окружающий мир и сталкиваемся с какими-то трудностями, мы оцениваем, принесет ли это компании деньги или сэкономит? Казалось бы: если ответ положительный, значит, мы все делаем правильно, если нет, нужно отпустить ситуацию и не жалеть о потраченном времени.
Но не все так однобоко.
Есть задачи, которые затратны и не принесут прямой прибыли прямо сейчас, но в будущем могут оказать кардинальное влияние на развитие компании.
Нашим следующим большим шагом будет разработка и реализация ощутимой оценки каждой задачи, входящей в сферу ИТ.
Мы хотим научить себя и других мыслить категориями доходов и расходов, но это займет некоторое время.
Теги: #Альфа-Банк #Управление персоналом #HR #оценка сотрудников #Управление персоналом
-
Поддержка Протокола Ipv6
19 Oct, 24 -
Необычный Кулер
19 Oct, 24
