Бизнес-цели и согласованность: чего я долго не понимал как программист
Почти двадцать лет я пишу код и только в последние годы у меня сложилась картинка того, зачем он пишется. Не «какую фичу просили», а какое изменение в бизнесе она должна произвести и как мы поймём, что произвела.
Это неловко признавать. Но, кажется, это норма для отрасли.
Почему технарь не видит бизнес-цель
В большой компании между стратегией и тикетом стоит слоёный пирог из ролей: CPO, продакт, продакт-оунер, бизнес-аналитик, проджект, тимлид, скрам-мастер. Каждый слой пережёвывает контекст и передаёт вниз всё более конкретную формулировку.
Это работает. И это же ломает понимание: к разработчику приезжает уже готовый тикет с макетом и acceptance criteria. Ни одного вопроса задавать не надо - всё разжёвано. Отличный DX, нулевая связь с реальностью.
Дальше происходят три вещи:
- Ты начинаешь считать своей целью выход, а не результат: закрытые тикеты, смерженные PR, story points. Всё измеримо, всё зелёное, влияния на бизнес - ноль.
- Ты не можешь оспорить задачу по существу. Только «это дорого» или «это грязный хак». Спор про архитектуру вместо спора про гипотезу.
- Когда попадаешь в маленькую компанию или в свой проект, где слоёв нет, оказывается, что навыка формулировать задачу у тебя не было никогда. Его за тебя делали другие люди.
Меня к пониманию притащил не менеджмент, а свой продукт: когда некому передать «а зачем», приходится отвечать самому.
Каскад: восемь уровней
Самое полезное, что я для себя нарисовал - это лестница. Каждый нижний уровень существует только для того, чтобы двигать верхний. Если связь не объясняется одной фразой, уровень лишний или расфокусирован.
| # | Уровень | Вопрос уровня | Горизонт | Типичные роли в компании |
|---|---|---|---|---|
| 1 | Vision / Mission | Зачем мы вообще? | 5+ лет | Основатели, CEO, совет директоров |
| 2 | Strategy | Где и за счёт чего выигрываем? | 1-3 года | CEO, CPO, руководители функций |
| 3 | Objectives | Что должно измениться в цифрах? | год / квартал | Руководители бизнеса и продукта, владельцы направлений |
| 4 | KPI + Target | Как узнаем, что достигли? | тот же период | Владелец цели, product/data/finance-лиды |
| 5 | Levers (рычаги) | Через какую механику двигаем KPI? | квартал | Продакт, маркетинг/sales/operations-лиды, техлид |
| 6 | Initiatives | Какой проект тянет рычаг? | недели-месяцы | Продакт-оунер, бизнес-аналитик, проджект, техлид, дизайнер |
| 7 | Team outcomes | Какой вклад команды? | спринт / месяц | Тимлид, скрам-мастер, команда |
| 8 | IC work | Что конкретно делаю я на этой неделе? | дни | IC: программист, дизайнер, аналитик и другие специалисты |
Программист живёт на уровне 8 и иногда 7. Проблема не в этом - проблема в том, что уровни 7-8 начинают изобретать собственные цели, потому что настоящие им не показали. Так появляется «переписать на новый фреймворк» в качестве цели квартала.
Разница понятий, которые вечно путают:
| Понятие | Что это | Пример |
|---|---|---|
| Objective | желаемое состояние | снизить возвраты |
| KPI | чем меряем прогресс | return rate % |
| Target | порог успеха | ≤ 4% к 1 октября |
| Metric | любая измеряемая величина | клики по блоку «гарантия» |
| Guardrail | что нельзя сломать по пути | CSAT не падает |
Ключевое: у objective один primary KPI и один-два guardrail. Если KPI пять, команда оптимизирует тот, который проще сдвинуть.
Типичные цели по уровням
Ниже - шпаргалка того, как звучат цели на каждом этаже. Она нужна не чтобы выбрать «правильную» цель из списка, а чтобы: (а) узнавать язык уровня и (б) ловить подмену, когда сверху спускают формулировку нижнего уровня («сделайте нам мобильное приложение» - это инициатива, а не цель).
Уровень 1-2: Vision и Strategy
Vision не измеряется, и это нормально: его задача - задать рамку, внутри которой отказ от возможностей выглядит логично, а не как трусость. Проверка простая: если под vision подходит любая компания в отрасли, это не vision, а слоган.
Стратегия же - это выбор из взаимоисключающих вариантов. Типичные:
| Тип стратегии | Звучит как | Что из неё следует вниз |
|---|---|---|
| Лидерство по издержкам | выигрываем ценой и себестоимостью | цели про юнит-экономику, автоматизацию, self-serve |
| Дифференциация продуктом | выигрываем качеством и доверием | цели про удержание, NPS, качество данных |
| Нишевый фокус | выигрываем в одном сегменте, остальных не берём | цели про долю в сегменте, а не про общий рост |
| Дистрибуция и скорость | выигрываем каналом и темпом входа | цели про партнёрства, time-to-market |
| Платформа и экосистема | выигрываем тем, что на нас строят другие | цели про интеграции, API-адопшн |
| Движение вверх по рынку | уходим из SMB в enterprise | цели про средний контракт, безопасность, комплаенс |
| Смена модели монетизации | лицензии в подписку, разовые в recurring | цели про долю recurring-выручки |
Признак, что стратегии нет: годовой список вида «растём, улучшаем качество, выходим в новые сегменты, снижаем издержки, ускоряем разработку» - всё сразу и ни от чего не отказались.
Уровень 3: Objectives
Здесь появляются цифры, но ещё нет решений. Типичные группы:
| Группа | Типичные цели | Кто обычно владеет |
|---|---|---|
| Рост | привлечь новых клиентов, войти в сегмент/гео, поднять выручку | CEO, CRO, продакт |
| Удержание | снизить отток, вернуть спящих, поднять повторные покупки | продакт, retention/CRM |
| Монетизация | поднять средний чек, долю платящих, апсейл | продакт, монетизация, sales |
| Юнит-экономика | снизить CAC, поднять LTV/CAC, вывести сегмент в плюс | финансы, маркетинг |
| Активация | довести нового пользователя до ценности | продакт, онбординг |
| Эффективность | снизить стоимость обслуживания клиента, ручной труд | operations, поддержка, платформа |
| Доверие и риск | снизить возвраты, инциденты, фрод, штрафы | продукт, поддержка, безопасность |
| Люди | удержать ключевых, сократить время найма | HR, руководители |
Правило, которое экономит квартал: цель формулируется как изменение состояния клиента или бизнеса, а не как список работ. «Снизить возвраты» - цель. «Внедрить новую систему возвратов» - уже инициатива, и она уместна на уровне 6, а не 3.
Уровень 4: KPI и Target
Один objective - один primary KPI. Guardrail нужен всегда, потому что каждый KPI можно сдвинуть, сломав соседа:
| Objective | Primary KPI | Типичный guardrail |
|---|---|---|
| Снизить отток | месячный churn / NRR | не терять выручку на скидках |
| Поднять активацию | доля дошедших до ключевого действия за 7 дней | нагрузка на поддержку не растёт |
| Поднять средний чек | AOV / ARPU | конверсия не падает |
| Снизить возвраты | return rate за 30 дней | CSAT не ниже baseline |
| Снизить стоимость обслуживания | cost per ticket | время решения не растёт |
| Ускорить поставку | lead time до прода | частота инцидентов не растёт |
Target - это порог и дата: «≤ 4% к 1 октября». Без даты цель бессрочная, а бессрочная цель не проигрывает, но и не выигрывает.
Уровень 5: Levers
Рычаг отвечает на вопрос «через какую механику». Полезно помнить, что рычагов у любого KPI конечное число, и их можно перечислить:
| KPI | Рычаги |
|---|---|
| Выручка | трафик, конверсия, средний чек, частота покупок, цена |
| Отток | онбординг, ощущаемая ценность, качество поддержки, цена/упаковка, миграция на годовые планы |
| CAC | микс каналов, качество лидов, конверсия воронки продаж, реферальность |
| Возвраты | ожидания до покупки, точность данных о товаре, качество логистики, качество самого товара |
| Стоимость поддержки | самообслуживание, устранение причин обращений, автоматизация, шаблоны |
Именно на этом уровне живёт большинство «инженерных целей»: ускорить сборку, убрать легаси, поднять покрытие тестами. Это нормальные рычаги, но они не objectives. Если такой пункт стоит в списке целей квартала без ответа на вопрос «какой KPI сверху он двигает», то команда сама себе назначила цель - ровно то, о чём было выше.
Уровень 6-8: Initiatives, team outcomes, IC
Здесь формулировки становятся конкретными, и главное требование к ним - ссылка вверх:
| Уровень | Хорошая формулировка | Плохая формулировка |
|---|---|---|
| Initiative | блок условий на карточке и в чекауте, тянет рычаг «ожидания до оплаты» | редизайн карточки товара |
| Team outcome | доля причин возврата «other» ниже 15% за две недели | закрыть эпик к концу спринта |
| IC work | схема reason_code и дашборд, чтобы измерить гипотезу H3 | закрыл 12 тикетов |
Тест из четырёх вопросов
Прежде чем взять задачу, я теперь спрашиваю:
- Какой уровень выше она двигает? Назови KPI или инициативу.
- Как мы через 2-4 недели поймём, что двигается? (leading indicator, не выручка через год)
- Чем нельзя жертвовать? (guardrail)
- Что мы не делаем, потому что взяли это?
Если ответов нет - это не задача из каскада, это пункт из чьего-то списка желаний. Иногда это нормально (техдолг, эксперимент, обучение), но тогда так и надо назвать, а не притворяться, что мы двигаем бизнес.
Четвёртый вопрос самый неприятный и самый честный. Стратегия - это в первую очередь отказ от альтернатив. Если отказа нет, стратегии тоже нет.
Программист - тоже дизайнер
Здесь мне очень помогла лекция Ильи Бирмана «Понимание задачи». Она про дизайнеров, но программист - тот же дизайнер, только его материал не пиксели, а система.
Главный тезис: дизайнеры формулируют задачу на языке дизайна - «сделать удобнее», «убрать лишний шаг», «современный сайт». Это не задача, потому что у неё нет решения: подойдёт любое. Обсуждать по существу нечего, поэтому разговор скатывается к «подвинуть логотип» и «добавить красненького».
Программисты делают ровно то же самое, только словарь другой: «убрать легаси», «перейти на микросервисы», «поднять покрытие тестами», «ускорить сборку». Проверка та же - если подходит любое решение, задача сформулирована неверно.
Мой любимый пример из лекции: Бирман пришёл к клиенту, продающему электронные журналы, и по привычке хотел убрать регистрацию - все же знают, что регистрация это барьер. А регистрация у них была шагом воронки: сначала берут почту, потом телефон, потом звонят человеку и продают подписку под то, что он реально читал. Убрать её значило сломать бизнес-модель. Спасло только то, что клиент не дал.
Бирман приводит ещё один, отдельный пример - с онлайн-тестами. Он сформулировал задачу так: «увеличить число участников онлайн-тестов, сняв преграды к участию». Команда объяснила пользу тестов, упростила оплату и прохождение, придумала способы привлечь людей и вернуть их на сайт. Проект запустили, но он провалился: посетителей почти не было. Команда решала не ту проблему. Сначала нужно было спросить: «Откуда возьмутся люди и почему они вообще придут на этот сайт?»
Этот пример показывает разницу между результатом, рычагом и гипотезой:
- результат - увеличить число участников;
- рычаг - убрать преграды;
- гипотеза - если убрать преграды, участников станет больше.
Результат был понятен, но гипотезу о причине никто не проверил. Поэтому в задаче нужно указывать не только желаемый результат, но и проверяемую гипотезу: что именно должно его сдвинуть и как мы это поймём.
И третье, что я оттуда забрал: «увеличить прибыль» - не бизнес-задача. Если бы предприниматель умел ставить себе такую задачу, он бы её просто решил. У него в голове набор гипотез: открыть второй ресторан, сменить повара, запустить акцию. Твоя работа - понять, в какую именно гипотезу он поверил и почему.
Понимание задачи надо ещё и записать. Не для формальности: пока пишешь, обнаруживаешь дыры, а клиент, читая, обнаруживает, что ты понял не то. Для программиста аналог - короткий design doc или описание в PR: контекст, гипотеза, что меряем, чем рискуем.
Где рвётся каскад
| Стык | Симптом |
|---|---|
| Strategy ↔ Objectives | десяток годовых целей, ни от чего не отказались |
| Objectives ↔ KPI | цели словами, без формулы, без владельца |
| KPI ↔ Levers | vanity-метрики: охваты, число фич |
| Levers ↔ Initiatives | «делаем проекты», но какой рычаг тянем - неизвестно |
| Initiatives ↔ Team | дизайн и разработка изобретают свои цели |
| Team ↔ IC | отчёт про активность (story points, число PR) вместо вклада |
Последняя строка - персонально про меня прошлого. «Закрыл 12 тикетов» - это отчёт о том, что я был занят, а не о том, что что-то изменилось. Хорошая версия звучит иначе: «закрыл гипотезу H3 про блок условий на карточке товара, смотрим долю возвратов с причиной not as described через 14 дней».
Почему нельзя оптимизировать один рычаг
Отдельная ловушка: даже правильный KPI, взятый в одиночку, ломает соседей.
| Оптимизируем только | Что ломается |
|---|---|
| Охват | мусорный трафик, конверсия падает |
| Конверсию | агрессивный UX, растут возвраты и нагрузка на поддержку |
| Средний чек | падает конверсия, появляется ощущение впаривания |
| Скорость поддержки | падает качество ответов |
| Скорость разработки | инциденты и скрытый долг |
Бирман про это же: конверсию можно довести до 100%, если кнопка «купить» будет срабатывать сама. Только потом всё вернут.
Лечится это не микроменеджментом исполнителей, а связкой primary KPI + guardrails + общий обзор на уровнях 3-4. Если у команды поддержки KPI «время ответа», а у продукта «конверсия», и они не встречаются на одном ревью - они будут воевать, каждый будучи прав в своём слое.
Как это выглядит целиком
Сквозной пример, чтобы не оставалось абстракции:
Strategy: выигрываем за счёт доверия и низкой стоимости ошибок доставки,
а не за счёт сырого охвата
└─ Objective: снизить возвраты
└─ KPI: return_rate = returned / paid за 30 дней, -15% за квартал
Guardrail: CSAT не ниже baseline
└─ Lever: ожидания клиента до оплаты
└─ Initiative: блок условий на карточке товара и в чекауте
├─ Design: понятно «что получу и когда»
├─ Eng: точные данные о наличии и сроках,
│ структурированные причины возврата, A/B
└─ Support: единая таксономия причин
И мой кусок как инженера на неделю:
- Задача: схема
reason_code+ фиче-флаг + дашборд - Ссылка вверх: двигает KPI return_rate через инициативу «блок условий»
- DoD: события пишутся минимум для 95% возвращённых заказов
- Leading signal: доля причины «other» ниже 15% за две недели
- Non-goal: не трогаем сам процесс возврата в этом квартале
И критерий убийства: если leading-сигналы зелёные три недели, а return_rate не двигается - неверна гипотеза, а не исполнение. Меняем инициативу, а не давим на людей «сделайте ещё красивее».
Что я поменял у себя
- Не начинаю с задач. Начинаю с уровней 2-4: во что мы верим и чем меряем.
- Держу мало: 1-3 цели на квартал, один primary KPI на цель, 1-2 значимых треда в работе.
- Любую входящую идею сначала кладу на уровень: это стратегия, цель, рычаг, инициатива или уже задача? Половина идей после этого оказывается рычагами в бэклоге, а не приоритетом.
- В ревью смотрю на KPI и leading-сигналы, а не на процент закрытых задач.
- Если не могу за одну фразу объяснить, какой уровень выше двигает моя работа, - иду спрашивать. Это не «лезть не в своё дело», это единственный способ не потратить квартал впустую.
Слои ролей в больших компаниях придуманы, чтобы разгрузить технаря. Побочный эффект - технарь разучивается задавать вопрос «зачем». Вопрос стоит дешевле, чем квартал работы в неверную сторону.