Чем больше метрик, тем меньше контроля

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

Я Степан, delivery-менеджер Outlines Tech. Поделюсь кейсом, где новые метрики не сделали проект прозрачнее, какие ошибки руководства к этому привели и чем всё закончилось для меня.

Ввели новые метрики, потому что нужно было больше золота

Сначала расскажу, с чего всё началось. История произошла на одном из моих прошлых мест работы из сферы Insurance Tech. До меня там там изначально было несколько крупных проектов, где у каждого была отдельная команда из 12–15 человек и свой тимлид. Все работали удалённо.

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

Чтобы добавить прозрачности, ввели квартальные OKR, Objectives and Key Results. В них связали финансовые показатели проектов и time to market — время от начала работы над фичей с бэклога до её выхода в прод. Руководство рассчитывало увидеть, на каком этапе всё начинает буксовать и как задержки влияют на дополнительные продажи и оплату. 

После внедрения OKR компания изменила и структуру управления. Между тимлидами и руководством появились ИТ-менеджеры. Они должны были отвечать за финансовые показатели и координировать работу команд. Тут-то и появляюсь я в роли delivery. Меня наняли вести четыре команды, которые занимались проектами для двух крупных российских страховых компаний.

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

Для этого, по логике, нужно было видеть, как устроена работа, и иметь возможность на неё влиять. Мне не дали ни того ни другого. Объясню ниже, как всё было устроено.

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

У каждой команды был свой тимлид. Он управлял разработкой, общался с сотрудниками и контролировал выполнение задач. Я же как ИТ-менеджер отвечал перед руководителем проектного офиса за OKR и итоговые показатели.

Сотрудники работали в Jira заказчиков, но доступа к ней у меня не было. Данные для отчётов готовили тимлиды: сами собирали показатели, переносили их в Excel и присылали мне. На основе этих таблиц я отчитывался перед своим руководителем проектного офиса.

Например, если time to market рос, то я не мог открыть Jira, посмотреть историю задачи и сам разобраться почему так произошло. Приходилось обращаться к тому же тимлиду, который готовил отчёт. Получалось, что я видел итоговую цифру, но не видел, из чего она сложилась.

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

Получилась система, в которой ИТ-менеджер стал третьим колесом: я отвечал за показатели, но не мог ни проверить данные, ни полноценно повлиять на результат. Управление оставалось у тимлидов, а руководство оценивало проекты по подготовленным ими отчётам. А сотрудники поняли, как показывать в отчётах хороший результат, чтобы сохранять прежний порядок работы.

Только выиграли, или что пошло не так

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

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

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

Приведу аналогию с планом продаж. Допустим, продавцу поставили план на 200 тысяч. Он сделает 200–205, но не больше. Покажешь, условно, 250 — в следующий раз получишь ещё 15–20% плана сверху. Руководство решит, что ты можешь больше, и разовый максимум быстро превратится в новую норму. Короче, кто везёт, на том и едут.

Возник конфликт интересов. Мне было важно, чтобы фичи выходили вовремя, заказчик их принимал и платил без задержек. Тимлидам — чтобы команды закрывали внутренние показатели производительности. Эти результаты вроде как должны быть связаны, но на деле расходились.

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

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

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

В итоге метрики остались, а люди ушли — и из разработки, и из менеджмента. При этом бизнес так и не получил прозрачности, ради которой всё затевалось.

Из этой истории я вынес пять правил

1. Нужно понимать, зачем вообще нужна метрика. Какое решение мы примем, если показатель вырастет или упадёт? Если ответа нет, цифра превратится в очередную бездумную строку отчёта.

2. Метрика должна быть прозрачной. Ответственный за показатель должен видеть первичные данные, а не получать готовую таблицу от человека, чью работу оценивает.

3. Ответственность должна совпадать с полномочиями. Нельзя требовать что-то от менеджера, если он не может влиять на процесс, иначе он превращается в лишнее звено.

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

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

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

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

Надеюсь, моя история будет кому-то полезна. Спасибо, что прочитали до конца. Мой telegram.

А как метрики работают у вас? Приносят ли они больше пользы или вреда?