---
title: "Бизнес-цели и согласованность: чего я долго не понимал как программист"
date: 2026-08-17T12:00:00
tags: [управление, бизнес, kpi, дизайн, карьера]
description: "Каскад целей от стратегии до тикета, почему в больших компаниях программист его не видит, и как проверить, что твоя задача вообще кому-то нужна."
---

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

Это неловко признавать. Но, кажется, это норма для отрасли.

![Каскад целей от вершины до ноутбука](img/business-goals-cascade.jpg)

<!--truncate-->

## Почему технарь не видит бизнес-цель

В большой компании между стратегией и тикетом стоит слоёный пирог из ролей: CPO, продакт, продакт-оунер, бизнес-аналитик, проджект, тимлид, скрам-мастер. Каждый слой пережёвывает контекст и передаёт вниз всё более конкретную формулировку.

Это работает. И это же ломает понимание: к разработчику приезжает уже готовый тикет с макетом и acceptance criteria. Ни одного вопроса задавать не надо - всё разжёвано. Отличный DX, нулевая связь с реальностью.

Дальше происходят три вещи:

1. Ты начинаешь считать своей целью **выход**, а не **результат**: закрытые тикеты, смерженные PR, story points. Всё измеримо, всё зелёное, влияния на бизнес - ноль.
2. Ты не можешь оспорить задачу по существу. Только «это дорого» или «это грязный хак». Спор про архитектуру вместо спора про гипотезу.
3. Когда попадаешь в маленькую компанию или в свой проект, где слоёв нет, оказывается, что навыка формулировать задачу у тебя не было никогда. Его за тебя делали другие люди.

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

## Каскад: восемь уровней

Самое полезное, что я для себя нарисовал - это лестница. Каждый нижний уровень существует **только** для того, чтобы двигать верхний. Если связь не объясняется одной фразой, уровень лишний или расфокусирован.

| # | Уровень | Вопрос уровня | Горизонт | Типичные роли в компании |
| --- | --- | --- | --- | --- |
| 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 тикетов |

## Тест из четырёх вопросов

Прежде чем взять задачу, я теперь спрашиваю:

1. Какой уровень выше она двигает? Назови KPI или инициативу.
2. Как мы через 2-4 недели поймём, что двигается? (leading indicator, не выручка через год)
3. Чем нельзя жертвовать? (guardrail)
4. Что мы **не** делаем, потому что взяли это?

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

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

## Программист - тоже дизайнер

Здесь мне очень помогла [лекция Ильи Бирмана «Понимание задачи»](https://www.youtube.com/watch?v=PbnbwkoCQOE). Она про дизайнеров, но программист - тот же дизайнер, только его материал не пиксели, а система.

Главный тезис: дизайнеры формулируют задачу **на языке дизайна** - «сделать удобнее», «убрать лишний шаг», «современный сайт». Это не задача, потому что у неё нет решения: подойдёт любое. Обсуждать по существу нечего, поэтому разговор скатывается к «подвинуть логотип» и «добавить красненького».

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

Мой любимый пример из лекции: Бирман пришёл к клиенту, продающему электронные журналы, и по привычке хотел убрать регистрацию - все же знают, что регистрация это барьер. А регистрация у них была **шагом воронки**: сначала берут почту, потом телефон, потом звонят человеку и продают подписку под то, что он реально читал. Убрать её значило сломать бизнес-модель. Спасло только то, что клиент не дал.

Это не продолжение истории про электронные журналы, а другой пример из лекции - из раздела, где Бирман разбирает письменное «понимание задачи». В проекте с онлайн-тестами он записал задачу на языке бизнеса: «увеличить число участников онлайн-тестов, сняв преграды к участию». В документе среди решений были объяснение пользы теста, помощь с оплатой и прохождением, а также способы привлечь людей и вернуть их на сайт. Всё это команда сделала, проект запустили, за работу получили деньги. Но проект провалился: на сайт почти никто не приходил. Получается, проблема была не в том, что посетителям мешало пройти тест, а в том, что посетителей почти не было. Бирман не проверил исходное предположение и не спросил: «Откуда возьмутся люди и почему они вообще придут на этот сайт?» Здесь важно различать результат, рычаг и гипотезу: «увеличить число участников» - результат; «снять преграды» - предполагаемый рычаг; «если снять преграды, участников станет больше» - гипотеза. Задача была сформулирована на языке бизнеса, но гипотеза о причине не была проверена. Нужен не только желаемый результат, но и проверяемая гипотеза о том, что именно его сдвинет.

И третье, что я оттуда забрал: «увеличить прибыль» - не бизнес-задача. Если бы предприниматель умел ставить себе такую задачу, он бы её просто решил. У него в голове набор гипотез: открыть второй ресторан, сменить повара, запустить акцию. Твоя работа - понять, **в какую именно гипотезу он поверил и почему**.

Понимание задачи надо ещё и записать. Не для формальности: пока пишешь, обнаруживаешь дыры, а клиент, читая, обнаруживает, что ты понял не то. Для программиста аналог - короткий 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 «время ответа», а у продукта «конверсия», и они не встречаются на одном ревью - они будут воевать, каждый будучи прав в своём слое.

## Как это выглядит целиком

Сквозной пример, чтобы не оставалось абстракции:

```text
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-сигналы, а не на процент закрытых задач.
- Если не могу за одну фразу объяснить, какой уровень выше двигает моя работа, - иду спрашивать. Это не «лезть не в своё дело», это единственный способ не потратить квартал впустую.

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