[1/10] Как в цифрах показать бизнесу ценность своей команды?
[1/10] Как в цифрах показать бизнесу ценность своей команды?
Основано на реальных событиях. С целью соблюдения NDA некоторые детали в статье намеренно были изменены.
Как снег на голову
Однажды ко мне пришли и сказали, что в обозримой перспективе компании не хватит денег на оплату нынешней команды разработки. В мире стартапов срок, на который компании хватит имеющихся денег с учётом всех поступлений и расходов, называют «ранвеем» (runway). Так вот, наш runway составлял всего полтора года — и это в самом оптимистичном сценарии.
Шансы привлечь инвестиции с учётом политической и экономической обстановки были крайне низкими. Поэтому мне велели за два месяца сократить почти треть IT-отдела. В других отделах также планировались сокращения. Расчёт был на то, что снижение расходов позволит компании удержаться на ногах и платить зарплаты ещё 3–5 лет. За это время мы рассчитывали пережить кризис, закрепиться на рынке, нарастить выручку и, возможно, всё-таки найти способ привлечь инвестиции.
Всё это означало, что сократить предстоит почти 40 человек.
Сложно описать, что чувствуешь после таких новостей. Подобное для любого руководителя всегда как снег на голову. Несколько минут просто смотришь в одну точку, собираясь с силами и пытаясь осознать, сколько тяжёлых решений предстоит принять…
Стало понятно, что действовать придётся в режиме частичной неопределённости. Стратегия и планы компании на следующие 3–5 лет резко менялись. И в этих условиях предстояло ответить на вопросы:
Кого сокращать? И как не допустить, чтобы вместе с расходами мы не сократили шансы компании на выживание?
Только хорошей работы недостаточно
Тот эпизод отчётливо показал мне, насколько важно уметь не только хорошо делать свою работу, но и регулярно измерять её результат. А свою работу мы делали очень хорошо: отличная архитектура на современном стеке, чистый код, регулярные релизы, доступность сервиса выше 99,95%.
Бизнесу не особо важны общие показатели вроде количества задач, закрытых за спринт. Ему не важны и ваши внутренние технические метрики вроде процента покрытия кода тестами. Бизнесу нужно видеть, как эти показатели связаны с доходами и расходами, стоимостью привлечения клиента, сроками и затратами на проекты, вероятностью рисков и размером возможных потерь.
Например, доступность сервиса и выполнение SLA вполне могут интересовать бизнес. Ценность этих показателей можно объяснить через потери заказов при простоях, компенсации клиентам и риск оттока. Такой перевод нужен на любом уровне — от собственной работы и работы отдельных сотрудников до результатов команды, отдела или целой функции.
Когда доходы растут недостаточно быстро, а доступ к инвестициям осложняется, бизнесу приходится быстро адаптироваться и пересматривать расходы. Чтобы выправить операционную экономику, руководство должно понимать:
- какие затраты помогают зарабатывать;
- какие затраты защищают от возможных потерь;
- от каких затрат можно отказаться без существенного ущерба.
Под нож рискуют попасть даже хорошо работающие команды, чей вклад трудно объяснить за минуту и подкрепить цифрами.
Измеряем результат
Ниже я привожу лишь несколько основных метрик, отчётов, фреймворков и методологий, которые помогали лично мне принимать решения и защищать бюджет команды.
Деньги
Конечная цель большинства бизнесов — зарабатывать деньги. Даже в Гражданском кодексе предпринимательская деятельность определяется как деятельность, направленная на систематическое получение прибыли.
Компания всегда платит. Неважно, чем именно занимался конкретный сотрудник: разрабатывал новую фичу, чинил баг или просиживал штаны на совещании — компания заплатит ему за эти часы. Заплатит зарплату до вычета НДФЛ и страховые взносы, заплатит за ДМС и его рабочий MacBook Air, за рабочее место в офисе и за кофе с печеньками…
Для примера возьмём DevOps-инженера с зарплатой 3500 € в месяц «на руки». Если всё аккуратно посчитать, его полная стоимость для компании составит 90 000 € в год / 7500 € в месяц / 45 € в час.
Для понимания ситуации по компании в целом и по вашей команде в частности полезно разобраться в следующих отчётах и моделях:
- Profit and Loss Statement (P&L, PnL) — отчёт о доходах, расходах, прибыли или убытке за период. Ещё его называют отчётом о прибылях и убытках (ОПиУ).
- Бюджет доходов и расходов (БДР) — план доходов, расходов и прибыли на будущий период. Поможет понять, сколько вы планируете заработать в следующем году и какие расходы при этом сможете себе позволить.
- Бюджет фонда оплаты труда (ФОТ) — зарплаты, премии, надбавки, отпускные и прочие расходы на каждого сотрудника.
- Модель юнит-экономики — доходы, затраты и маржа на клиента, заказ или единицу продукта.
Зачастую ваша команда — лишь маленькая шестерёнка в большой компании: вы отвечаете за конкретную область, а полная финансовая картина вам недоступна. Мой опыт показывает, что часто достаточно проявить искреннюю заинтересованность и желание принимать решения с опорой на финансовые показатели. Я, например, всегда приходил к менеджеру продукта, владельцу продукта или даже CPO с просьбой:
«А покажи, сколько денег и как именно мы зарабатываем на наших IT-продуктах?»
И мы вместе на много часов с головой уходили в бесконечные отчёты. Ещё ни разу мне не отказали.
Но необязательно сразу разбираться во всех финансовых отчётах. Для начала достаточно хотя бы такого упрощённого представления:
Время
Сроки разработки и внедрения — ещё один ключевой показатель для бизнеса. Даже если вы предложите проект, позволяющий заработать миллионы долларов, но его реализация займёт слишком много лет, он, скорее всего, не получит зелёный свет. Поэтому важно учиться оценивать сроки реализации проектов.
Здесь помогут показатели и инструменты оценки:
- Time to Market (TTM) — время от появления идеи продукта до его выхода на рынок.
- Lead Time (LT) — время от момента, когда вы взяли обязательство сделать задачу, до её поставки.
- Story Points (SP) — относительная оценка трудоёмкости задачи с учётом её сложности и неопределённости.
Многие метрики хорошо работают только на масштабе: сначала нужно наработать статистику. Тогда при поступлении новой задачи вы сможете с некоторой вероятностью оценить срок её реализации.
Эффективность
Руководителю важно понимать, насколько эффективно работают отдельные сотрудники и команда в целом: какие результаты они получают и сколько времени и ресурсов на это уходит.
Здесь пригодятся:
- регулярные Performance Review и 1:1 с сотрудниками;
- матрица компетенций и ожидания от грейдов;
- OKR как показатель достижения целей и измеримых результатов;
- метрика Velocity для прогнозирования объёмов работы команды.
Чем закончилась история с сокращением?
Как же мы пережили то самое массовое сокращение в IT-отделе, о котором я писал в начале?
Для начала мы обсудили с руководством, какая именно у нас цель и какой план у компании. Я понимал общую проблему и слышал предлагаемый способ её решения — «уволить 40 человек», — но конкретные цели и планы компании оставались не до конца ясными.
Разбираемся с доходами и расходами
Несколько дней мы обсуждали ситуацию и вместе с финансовым директором разбирали финансовые отчёты. Затем говорили с HR-директором и даже с юристами. Пришлось быстро разобраться в ключевых метриках, структуре расходов компании, оценить стоимость сокращения сотрудника (а это 2–6 окладов). Затем вместе с командой менеджеров продукта мы объединили ключевые технические, продуктовые и финансовые метрики в общую картину, которая позволила принимать обоснованные решения. Это была самая насыщенная цифрами и таблицами неделя.
Мне удалось выяснить конкретную сумму, которую нужно сэкономить в следующем году, — 3,5 млн €. Более того, после более аккуратного расчёта расходов компании на IT требуемую сумму удалось снизить до 2,8 млн €: мы нашли несколько ошибок в бюджете ФОТ и расходах на инфраструктуру.
«Сэкономить 2,8 млн € за год» звучит гораздо конкретнее, чем «уволить 40 человек», — и даёт свободу в выборе решений.
Что помогло: отчёт P&L, бюджет ФОТ, прогноз расходов.
Режем расходы на инфраструктуру
Мы посмотрели на расходы на инфраструктуру и нашли в бэклоге несколько отличных вариантов их снижения. Задачи уже давно были подробно описаны, трудозатраты оценены, а экономия посчитана — они просто ждали своего часа, и вот он настал.
В итоге мы нашли способ сэкономить около 300 тысяч € в год. Пришлось, правда, отказаться от пары крупных, давно запланированных продуктовых экспериментов. Но в той ситуации мы согласовали это без проблем.
Что помогло: бэклог задач, отчёт P&L, прогноз расходов.
Режем план найма
Мы аккуратно собрали и перепроверили расходы на каждую команду: зарплаты с учётом плановых повышений, страховые взносы и дополнительные расходы компании на сотрудников (ДМС, обучение и т. п.). По динамике оценок Performance Review мы понимали, кому и когда в следующем году планируется повышение грейда и зарплаты.
Мы отказались от нескольких уже запланированных вакансий и тем самым значительно сократили расходы на следующий год. Перед этим ещё раз оценили реальную необходимость в найме и поняли, что закроем потребность за счёт перераспределения сотрудников, которые высвободятся после закрытия менее важных направлений.
Что помогло: бюджет ФОТ, план найма, план реорганизации.
Переходим на новую организационную структуру
Мы достаточно хорошо знали результаты работы каждого сотрудника в отделе. У нас были оценки трудоёмкости всех выполненных задач, пусть и в условных единицах. Регулярные Performance Review помогали видеть, кто хорошо справлялся со своей ролью, кто постоянно рос, а к чьей работе уже давно были вопросы. Мы буквально могли сравнивать сотрудников на одинаковых должностях между собой, даже из разных команд. Это давало основу для обсуждения кадровых решений.
Неделю мы рисовали и перерисовывали новую организационную структуру:
Большинство команд были продуктовыми, поэтому мы могли оценить выручку продуктов, над которыми они работали, и сопоставить её с расходами на разработку. Были и Research-команды, занимавшиеся в основном экспериментальными направлениями. По согласованию с CPO они стали первыми кандидатами на упразднение.
В итоге мы сократили 18 человек — более чем вдвое меньше, чем планировалось изначально. В несколько этапов полностью реорганизовали отдел разработки, стараясь максимально сохранить его производительность. Отказались от ненужного, закрыли убыточные направления и перераспределили ресурсы в те, что увеличивали выручку компании. Сократили сотрудников, к чьей работе уже были вопросы, а также роли, ставшие избыточными с учётом новых планов компании.
А самое главное — мы смогли защитить новую оргструктуру и новый бюджет ФОТ, потому что говорили и аргументировали решения на языке, понятном бизнесу.
Общие рекомендации
И напоследок дам ещё несколько общих рекомендаций.
Обменивайтесь данными с другими отделами
Говорите с финансистами, HR-специалистами, юристами, менеджерами продукта и коллегами из отдела продаж — выстраивайте систему обмена данными и обратной связи.
Скорее всего, вы хорошо понимаете трудоёмкость работ своего отдела, а они лучше вас разбираются в финансах, возможностях для роста и юридических рисках. Чтобы связать работу команды с результатами бизнеса, нужно действовать сообща: сверять расчёты, обсуждать допущения и обновлять прогнозы.
Необязательно сразу считать точно
Округляйте, начинайте с приблизительных оценок. Попытка сразу получить идеально точные цифры может обернуться большим объёмом сложной работы, которая на этом этапе не повлияет на решение. Улучшать расчёты и повышать их точность можно постепенно.
Начинайте с ключевых и базовых метрик, которые легко посчитать, и не переусложняйте раньше времени.
Рассматривайте три сценария
Стройте прогнозы как минимум для трёх сценариев развития событий:
🟢 Оптимистичный — все условия складываются благоприятно.
🟠 Базовый — наиболее реалистичный расчёт, основанный на текущих данных и обоснованных предположениях.
🔴 Пессимистичный — сроки разработки увеличиваются, расходы растут, а эффект оказывается ниже базового уровня.
Всё, что я писал выше, можно свести к одной таблице. Она не требует доступа к P&L и согласования с финансистами — для первой версии хватит того, что вы уже знаете о своей команде.
Шаг 1. Выпишите направления работы. Не задачи, а 5–7 крупных направлений, на которые уходит время команды: поддержка продукта, новые фичи, инфраструктура, внутренние инструменты, техдолг, интеграции.
Шаг 2. Посчитайте, сколько стоит каждое. Сколько человек в нём заняты и какую долю времени — умножьте на полную стоимость сотрудника. Помните пример с DevOps-инженером: 3500 € на руки превращаются в 7500 € в месяц для компании. Для первой прикидки возьмите зарплату на руки и умножьте на два — точность здесь пока не нужна.
Шаг 3. Ответьте на один вопрос по каждому направлению. Оно помогает компании зарабатывать, защищает от потерь — или без него можно обойтись?
Шаг 4. Переведите на язык бизнеса. Деньги — какую выручку приносит или экономит. Время — насколько ускоряет выход продукта. Риск — сколько компания потеряет, если это перестанет работать: простои, компенсации клиентам, отток.
В итоге по каждому направлению у вас должна получиться одна фраза:
«[Направление / команда] стоит компании [сумма] в год и [приносит / защищает / экономит] [эффект в деньгах, времени или риске]».
Что уже можно сделать на этой неделе:
Не откладывайте это до момента, когда к вам придут с цифрой, которую нужно сократить. Тогда будет уже поздно — вы окажетесь в той же ситуации, что и я в начале этой истории, только без недели на подготовку.
Желаю вам легко пережить эту ИТ-зиму, стать ещё мудрее и сильнее.
Котик Антон
Автор Telegram-канала I’m CTO, bitch, предприниматель, программист, ex-CTO. Руководил разработкой в Selectel, Dostavista и Borzo.
