MVP и экономика ошибки или как я продолжаю занудствовать в пятницу ночью
Сразу хочу обозначить свою позицию. Весь мой текст ниже — не про обесценивание проделанной Кириллом и его командой работы. Он про корректную квалификацию управленческого уровня кейса и различие ролей. Вопрос не в том, «правильно» или «неправильно» действовала команда. Вопрос — на каком уровне ответственности находилось решение.
После уточнения кейса автором рамка выглядит так:
- заказчик пришел с уже сформированной гипотезой;
- бюджет и сроки были предварительно определены;
- задача — реализовать продукт;
- подрядчик настоял на MVP вместо полной разработки;
- MVP позволил сократить масштаб инвестиций.
Это понятная логика. А вот дальше давайте разберемся в различиях уровней.
Три модели реакции на «готовое решение»
Когда заказчик приходит с уже сформулированной функцией, у подрядчика есть три возможные модели поведения (исключая, собственно, отказ):
A. Реализовать полностью. Работа строго внутри гипотезы.
B. Ограничить масштаб через MVP. Проверить гипотезу с меньшими инвестициями.
C. Переопределить постановку задачи. Разобрать проблему до уровня потребности, отделить решение (с которым пришел заказчик) от реальной задачи, уточнить гипотезу до начала разработки.
В кейсе Кирилла и его ребят реализован вариант B.
Он снижает стоимость ошибки. Он не снижает ее вероятность. Мы с этим определились еще в моем ответе на оригинальный пост, Кирилл также придерживается такой точки зрения (исходя из его ответа на мой ответ, простите за тавтологию), и здесь разногласий нет.
Экономика неопределенности
Любой проект живет в двух типах риска:
- Риск направления — гипотеза может быть неверной.
- Риск масштаба — объем инвестиций может быть избыточным.
MVP работает со вторым типом. Аналитика работает с первым.
В рассматриваемой истории гипотеза оказалась слабой. MVP позволил ограничить ее масштабирование.
Но сама гипотеза не была пересобрана до старта разработки.
Decision rights × Risk exposure × Capital allocation
Чтобы точнее квалифицировать уровень, можно посмотреть на этот кейс через три управленческих параметра:
Decision rights
Кто имел право пересобрать исходную постановку?
Из описания следует, что подрядчик действовал в рамках гипотезы заказчика.
Risk exposure
Кто нес стратегический риск неверного направления?
Заказчик.
Подрядчик управлял только масштабом инвестиционного риска.
Capital allocation
Кто определял распределение капитала между альтернативными сценариями?
В кейсе капитал перераспределялся уже после обнаружения ошибки, а не до ее проверки через аналитическую декомпозицию.
Это и определяет уровень — управление капиталом после выявления слабости гипотезы, а не до ее масштабирования.
Модель C: переопределение постановки задачи
Здесь кроется важный момент, который я бы хотел отдельно подчеркнуть.
Переопределить постановку задачи — это не «прочитать лекцию клиенту о методологии». Это не конфликт и не торможение проекта.
Это отдельный коммерческий периметр.
Модель C открывает широкий простор для подрядчика:
- продать фазу discovery;
- провести проблемные интервью;
- сделать картирование сценариев;
- уточнить бизнес-цели;
- пересобрать гипотезу;
- расширить контракт за счет аналитического блока.
Это не идеализм ради торжества методологии. Это управляемая и зрелая коммерческая модель работы.
И именно здесь подрядчик может перейти с уровня «исполнителя с дисциплиной» на уровень полноценного «архитектора решения», к которому клиенты будут возвращаться.
Где проходит граница зрелости
Тактический подрядчик:
- снижает масштаб ошибки;
- управляет бюджетным риском;
- аккуратно работает внутри гипотезы.
Стратегический подрядчик:
- влияет на формулировку проблемы;
- снижает вероятность стратегической ошибки;
- управляет направлением инвестиций до кода.
В кейсе продемонстрирован первый уровень.
Да, это лучше, чем реализация без проверки. Но это не пересбор архитектуры решения.
Итоговая квалификация
Кейс однозначно демонстрирует нам:
- дисциплинированное ограничение инвестиций;
- корректное использование MVP;
- зрелое понимание, что гипотезы нужно проверять.
Кейс не демонстрирует нам:
- работу с вероятностью стратегической ошибки;
- влияние на decision rights;
- управление капиталом до этапа разработки.
Именно это различие и является предметом обсуждения, по-крайней мере с моей стороны.
P.S. Кирилл, прошу прощения, что задержался с ответом. Нашел время собрать мысли по вашему ответу только в пятницу ночью. Спасибо за ваш ответ. Всегда приятно вести диалог с хорошим собеседником.