Как с помощью Data-Driven-подхода оценивать эффективность сотрудников и команд

Компания AGIMA работает в сфере заказной веб-разработки, и тут всё совсем не так, как при разработке IT-продукта. Маржинальность невелика и инвестиций мы не привлекаем, поэтому для стабильной работы, нам нужно быть сверх-эффективными в каждый момент времени.

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

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

Как и все, мы оцениваем рентабельность производства. Основной параметр на всех уровнях оценки — «усреднёнка». Это средняя рентабельность за 3 месяца (2 предыдущих и текущий). Все управленческие решения мы принимаем, опираясь на этот параметр, и это позволяет избежать ошибок, связанных со «скачками» доходов/расходов, которые могут быть весьма значительными при наличии долгих контрактов с нерегулярным закрытием.

Для анализа рентабельности по производственным подразделениям (в нашем случае это системная аналитика, прототипирование, дизайн, web-аналитика, frontend, backend, QA, информационная безопасность и менеджмент) нужно как-то поделить общие косвенные затраты (аренда офиса, административные расходы, HR, PR и т.д.).

Тут существует несколько подходов, мы выбрали распределение «по головам»: при таком подходе в каждое производственное подразделение падает объём косвенных, пропорциональный количеству штатных производственных единиц в этом подразделении.

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

Например, при размере косвенных на человека 150 тысяч, стоимость junior-разработчика с зарплатой 80 тысяч для подразделения будет лишь на 26% меньше, чем стоимость разработчика с зарплатой 160 тысяч (80+150 = 230, 160+150 = 310).

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

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

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

Этот уровень оценки возложен на руководителей проектов.

Изначально руководители проекта были замотивированы исключительно на объём без учёта рентабельности.

Казалось, что это хорошая схема, поскольку работала система сдержек и противовесов: руководитель проекта обеспечивает объём, а тимлид — рентабельность, но по факту возникали сложности :

• Менеджерам интересно продавать и делать нерентабельные задачи, в итоге тимлиду нужно реализовывать этот нерентабельный объём в ущерб своей мотивации или с потерей качества.
• Мы не видим рентабельность проектов в разрезе по разным департаментам.

Поэтому решили встроить и в мотивацию менеджера триггер по минимальной рентабельности проекта.

Как и раньше, базой для оценки эффективности менеджера является объём, но с оговоркой, что этот объём должен быть рентабелен.

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

Но визуализация данных для топов компании — не единственный итог углублённого анализа рентабельности производства.

Важнее то, что данные по рентабельности и объёму выработки доступны в виде дашбордов всем сотрудникам и ложатся в их мотивационные схемы, формируя бонусную часть зарплаты.

В нашей компании, например, у тимлида норма выработки устанавливается как ФОТ + налоги + косвенные + внутренние проектные затраты + внешние проектные затраты + норма прибыли.

С объёма сверх нормы выработки специалист получает бонус.

Бонус тимлида рассчитывается по следующей схеме:

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

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

Несмотря на очевидные преимущества, в процессе внедрения такой системы возникает большое количество сложностей:

• Много времени уходит на подсчёты (особенно поначалу, когда нет автоматизации).
• Система предполагает необходимость заставлять технарей быть экономистами (технари — это ещё полбеды, дизайнеры хотят заниматься ведением табличек ещё меньше!).
  
• Необходимость обеспечивать аккуратный тайм-трекинг для внутренних затрат.
  
• Нужно решить проблему правильного учёта разных типов проектов (Time & Materials, Выкуп, Fix price) путём введения поправочные коэффициентов.

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

Замер и контроль количественных показателей превращает управление командами и сотрудниками в подобие RPG-игры, в которой мы прокачиваем персонажа.

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

• Каждый сотрудник нацелен на хороший финансовый результат и имеет перед глазами дашборд для контроля показателей;

• Легко контролировать эффективность каждого сотрудника и принимать кадровые решения на основании данных;

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

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

Пара примеров:

• У вас длительный проект с регулярными фиксированными платежами от заказчика (выкуп команды). Числовые показатели на проекте стабильно хорошие (предположим, стоимость команды с косвенными и налогами = 1 млн. рублей, а клиент стабильно вам платит 1,5 млн.). Цифры говорят о том, что ничего не нужно предпринимать, но тут внезапно клиент разрывает контракт из-за накопившегося недовольства.

• На проекте сильный тимлид, но рентабельность проекта стабильно ниже целевой.

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

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

Качественными метриками я называю всё то, что нельзя измерить цифрами и нанести на график. Их можно и нужно ставить в KPI наряду с количественными.

Примеры качественных KPI для руководителя проектов:

• Пролонгация договора. В моменте на проекте всё хорошо, но клиент может не захотеть пролонгировать договор по ряду причин. Ставим эту задачу ему в KPI.

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

• Допродажи и диверсификация — важно стимулировать расширение объёмов и спектра оказываемых услуг в рамках одного бизнес-заказчика.

• Контроль команды — менеджеру необходимо контролировать рабочий климат: нужно проводить ряд мероприятий, чтобы команда сработалась и каждый эффективно выполнял свою работу.

Можно рассматривать каждого сотрудника как отдельный юнит и заниматься его мотивацией отдельно.

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

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

Есть два подхода к мотивации этих групп:

• Система сдержек-противовесов.
• Единые цели или командные KPI.

Если применять систему сдержек-противовесов, то цели в разрезе количественных и качественных KPI распределятся между производством и менеджментом примерно так.

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

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

Количественные:

• продажи;
• конверсия;
  
• количество скачиваний;
  
• рейтинг приложения;
  
• показатель отказов.
  

Качественные:

• сроки;
• качество кода;
  
• корректная архитектура.

Преимущества такого подхода:

• можно ставить команде в KPI показатели продукта (отдельному человеку их поставить нельзя, т к он не может единолично влиять на этот показатель, команда же полностью ответственна за продукт).

• команда работает сплочённо над общей целью, это положительно сказывается на мотивации и климате в коллективе.

Недостатки:

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

Недостаток можно нивелировать, если применять гибридную схему: ставить цели и отслеживать выполнение как по команде, так и по каждому её члену.

При установке качественных KPI важно руководствоваться принципами SMART-модели с пятью критериями:

• S – Specific (конкретность).
• M – Measurable (измеримость).
  
• А – Achievable (достижимость).
  
• R – Relevant (релевантность).
  
• T – Time bound (ограниченность по срокам).
  

Не буду останавливаться на них подробно, поскольку про это написано огромное количество литературы.

Но добавлю, что в дополнение к SMART-модели мы используем ещё два важных критерия — прозрачность и существенность.

Прозрачность. Важно, чтобы сотрудник в любой момент времени мог отследить, как выполнение его задачи влияет на общую картину по подразделению/компании и насколько в целом подразделение/компания справляется со своими KPI.

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

А если KPI выполняются — происходит пересмотр грейда и зарплаты, выплачиваются бонусы (которые зависят от показателей прибыли, не ограничены сверху и считаются по понятной и прозрачной формуле).

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

Делитесь в комментариях, как это происходит в ваших компаниях.