Escaping the Build Trap, глава 2: Ограничения системы обмена ценностью

Главная мысль: на обмен ценностью давят ограничения с двух сторон. Ограничения клиента мы не контролируем. Свои ограничения компания контролирует полностью, но часто сама настраивает их на output, а не на outcome.

Ограничения на стороне клиента

На клиентов влияет то, что вокруг них:

• сообщество, семья, друзья;
• технологии, которые есть на рынке сейчас.

Поэтому желания и потребности клиентов меняются. Меняются и способы их закрыть. Компания не может управлять этим. Она может только лучше это понимать.

Ограничения на стороне бизнеса

Чтобы получить максимум ценности, компании нужны правильные:

• люди;
• процессы;
• политики;
• стратегия;
• культура.

Эти ограничения компания контролирует сама. Если они слишком жёсткие, ценность теряют обе стороны.

Пример: нет времени на итерации

Многие компании работают по жёсткому процессу и графику. Места для экспериментов нет.

Автор задаёт продактам на тренингах два вопроса:

Вопрос	Типичный ответ
Кто возвращался и улучшал последнюю выпущенную фичу?	Руку поднимают 15–20%
Как вы знаете, что выпущенное было успешным?	«Успели к дедлайну», «код без багов»

Это компания, настроенная на output.

Output и outcome

	Output	Outcome
Что это	То, что мы производим	Что происходит после выпуска
Примеры	Число фич и релизов, скорость команды	Проблема клиента решена
Легко посчитать?	Да	Сложнее
Где ценность	Нет	Да, для бизнеса и клиента

Признаки компании в режиме output:

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

Многие компании не видят вреда. Они просто не измеряют outcome. Так они теряют стратегию и попадают в build trap.

Что нужно изменить

1. Перестать оценивать команды по числу фич.
2. Определить, что такое ценность, и измерять её.
3. Хвалить команды за outcome для бизнеса и пользователей.
4. Строить продукты, которые ведут к этим результатам.

Ключевые термины

Термин	Значение
Output	Измеримый продукт работы: фичи, релизы, velocity
Outcome	Результат для клиента и бизнеса после выпуска
Constraint	Ограничение, которое влияет на обмен ценностью
Velocity	Скорость команды разработки, мера output

Что это значит на практике

• Закрытый тикет и зелёный dbt build — это output. Outcome — когда аналитик или бизнес принял решение на ваших данных.
• После релиза витрины вернитесь к ней через 2–4 недели. Проверьте, кто её использует и какие вопросы остались.
• Предложите продакту метрику успеха для фичи до разработки. Заложите нужные события в трекинг и в пайплайн заранее.
• Если ваша команда отчитывается числом моделей или пайплайнов, добавьте в отчёт метрики использования: запросы к таблицам, просмотры дашбордов.
• Разговор с пользователями данных — не потеря времени. Это часть работы.

Вопросы для самопроверки

1. Какие ограничения на стороне клиента нельзя контролировать?
2. Какие пять ограничений бизнес контролирует сам?
3. Как понять, что компания настроена на output?
4. Как вы сейчас проверяете, что выпущенная работа была успешной?

Предыдущая: 1. Обмен ценностью. Следующая: 3. Проекты, продукты и сервисы.