Бизнес-цели и согласованность: чего я долго не понимал как программист

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

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

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

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

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

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

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

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

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

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

Программист живёт на уровне 8 и иногда 7. Проблема не в этом - проблема в том, что уровни 7-8 начинают изобретать собственные цели, потому что настоящие им не показали. Так появляется «переписать на новый фреймворк» в качестве цели квартала.

Разница понятий, которые вечно путают:

Ключевое: у objective один primary KPI и один-два guardrail. Если KPI пять, команда оптимизирует тот, который проще сдвинуть.

Типичные цели по уровням

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

Уровень 1-2: Vision и Strategy

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

Стратегия же - это выбор из взаимоисключающих вариантов. Типичные:

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

Уровень 3: Objectives

Здесь появляются цифры, но ещё нет решений. Типичные группы:

Правило, которое экономит квартал: цель формулируется как изменение состояния клиента или бизнеса, а не как список работ. «Снизить возвраты» - цель. «Внедрить новую систему возвратов» - уже инициатива, и она уместна на уровне 6, а не 3.

Уровень 4: KPI и Target

Один objective - один primary KPI. Guardrail нужен всегда, потому что каждый KPI можно сдвинуть, сломав соседа:

Target - это порог и дата: «≤ 4% к 1 октября». Без даты цель бессрочная, а бессрочная цель не проигрывает, но и не выигрывает.

Уровень 5: Levers

Рычаг отвечает на вопрос «через какую механику». Полезно помнить, что рычагов у любого KPI конечное число, и их можно перечислить:

Именно на этом уровне живёт большинство «инженерных целей»: ускорить сборку, убрать легаси, поднять покрытие тестами. Это нормальные рычаги, но они не objectives. Если такой пункт стоит в списке целей квартала без ответа на вопрос «какой KPI сверху он двигает», то команда сама себе назначила цель - ровно то, о чём было выше.

Уровень 6-8: Initiatives, team outcomes, IC

Здесь формулировки становятся конкретными, и главное требование к ним - ссылка вверх:

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

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

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

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

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

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

Здесь мне очень помогла лекция Ильи Бирмана «Понимание задачи». Она про дизайнеров, но программист - тот же дизайнер, только его материал не пиксели, а система.

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

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

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

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

Этот пример показывает разницу между результатом, рычагом и гипотезой:

• результат - увеличить число участников;
• рычаг - убрать преграды;
• гипотеза - если убрать преграды, участников станет больше.

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

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

Понимание задачи надо ещё и записать. Не для формальности: пока пишешь, обнаруживаешь дыры, а клиент, читая, обнаруживает, что ты понял не то. Для программиста аналог - короткий design doc или описание в PR: контекст, гипотеза, что меряем, чем рискуем.

Где рвётся каскад

Последняя строка - персонально про меня прошлого. «Закрыл 12 тикетов» - это отчёт о том, что я был занят, а не о том, что что-то изменилось. Хорошая версия звучит иначе: «закрыл гипотезу H3 про блок условий на карточке товара, смотрим долю возвратов с причиной not as described через 14 дней».

Почему нельзя оптимизировать один рычаг

Отдельная ловушка: даже правильный KPI, взятый в одиночку, ломает соседей.

Бирман про это же: конверсию можно довести до 100%, если кнопка «купить» будет срабатывать сама. Только потом всё вернут.

Лечится это не микроменеджментом исполнителей, а связкой primary KPI + guardrails + общий обзор на уровнях 3-4. Если у команды поддержки KPI «время ответа», а у продукта «конверсия», и они не встречаются на одном ревью - они будут воевать, каждый будучи прав в своём слое.

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

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

Strategy: выигрываем за счёт доверия и низкой стоимости ошибок доставки,
          а не за счёт сырого охвата
  └─ Objective: снизить возвраты
      └─ KPI: return_rate = returned / paid за 30 дней, -15% за квартал
         Guardrail: CSAT (оценка удовлетворённости) не ниже среднего
                   за прошлый квартал: 4,6 из 5
          └─ 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-сигналы, а не на процент закрытых задач.
• Если не могу за одну фразу объяснить, какой уровень выше двигает моя работа, - иду спрашивать. Это не «лезть не в своё дело», это единственный способ не потратить квартал впустую.

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