Почему delivery всегда выигрывает по умолчанию
У delivery есть всё, что любит команда и любит менеджмент: видимый прогресс, закрытые задачи, растущий бёрндаун, ощущение движения. У discovery этого нет. Его результат — не строчки кода, а изменившееся понимание: чаще всего вывод, что задуманное делать не стоит или стоит иначе. Такой результат тяжело показать в отчёте и невозможно отпраздновать на демо.
Поэтому по умолчанию побеждает delivery. Команда получает идею — от основателя, от крупного клиента, из соседнего отдела — и немедленно переводит её в задачи. Вопрос «а точно ли это решает чью-то проблему» кажется замедлением, почти саботажем: все же и так заняты. В итоге организация оптимизирует скорость производства функций, а не скорость обучения. Это разные вещи, и вторая важнее.
Марти Каган формулирует жёстко: большинство продуктовых идей не работает, а те, что работают, требуют нескольких итераций. Если это правда — а эмпирика продуктовых команд её подтверждает, — то главный риск проекта не в том, что вы медленно строите. Он в том, что вы быстро и качественно построите не то.
Что именно проверяет discovery
Полезно разделять четыре риска, которые discovery снимает по очереди или параллельно. Каган называет их так: риск ценности (нужно ли это кому-то настолько, чтобы платить временем или деньгами), риск юзабилити (сможет ли человек этим воспользоваться), риск реализуемости (можем ли мы это построить в разумный срок) и риск жизнеспособности (укладывается ли решение в бизнес — экономику, право, поддержку, бренд).
Команды, которые «делают discovery», обычно закрывают только риск юзабилити: рисуют макеты и показывают их пользователям. Это самый комфортный из рисков, потому что он про интерфейс, а не про смысл. Настоящая же дыра почти всегда в риске ценности. Человек в интервью вежливо кивает на макет, но это не значит, что он бросит текущий способ решать свою задачу. Discovery существует прежде всего чтобы отличить вежливый интерес от реальной готовности менять поведение.
Проблема раньше решения
Базовое правило: пока вы не можете внятно, в одну-две фразы, описать проблему и того, у кого она болит, у вас нет права проектировать решение. Если формулировка звучит как «пользователям не хватает функции X» — это не проблема, это уже спрятанное решение. Проблема формулируется в терминах ситуации человека и его цели, а не в терминах вашего продукта.
Опасность решения-раньше-проблемы в том, что оно обесценивает всю последующую работу. Команда честно проводит интервью, но задаёт вопросы, подтверждающие уже принятое решение. Это классическая ловушка подтверждения: мы слышим то, что хотим услышать, потому что уже начали строить. Дисциплина discovery — во многом дисциплина задавать вопросы, ответы на которые способны нас остановить.
Отсюда практический критерий качества discovery: он должен уметь сказать «нет». Если исследование в вашей команде за год ни разу не привело к отмене инициативы, это не значит, что все идеи были верны. Это значит, что discovery работает как оформление уже принятых решений, а не как их проверка.
Как говорить с людьми, чтобы узнать правду
Интервью — основной инструмент, и он же чаще всего испорчен. Роб Фитцпатрик в «The Mom Test» описывает суть: спрашивать нужно о прошлом поведении, а не о будущих намерениях и не об оценке вашей идеи. «Купили бы вы такое?» — бесполезный вопрос, на него все врут из вежливости. «Расскажите, как вы решали эту задачу в последний раз, что делали, сколько это стоило?» — вопрос, на который врать незачем, потому что он про факты.
Поведение прошлого — единственный надёжный сигнал. Если человек уже тратил деньги, время или костыли на обход проблемы, проблема реальна. Если он лишь соглашается, что «да, было бы неплохо», перед вами не спрос, а вежливость. Хорошее discovery-интервью почти не упоминает ваш продукт: оно про жизнь собеседника до вас.
Discovery как непрерывный поток, а не фаза
Самая живучая ошибка — воспринимать discovery как этап перед разработкой: «две недели исследуем, потом полгода строим». Тереза Торрес противопоставляет этому continuous discovery — ритм, в котором команда контактирует с пользователями каждую неделю на протяжении всего цикла. Причина проста: рынок, поведение и ваше собственное понимание меняются, пока вы строите. Замороженное на старте знание устаревает к релизу.
Практически это значит встроить в неделю команды один-два коротких разговора, привязать каждую крупную задачу к явно записанному допущению и держать список этих допущений живым. Тогда delivery перестаёт быть прыжком в темноту и становится проверкой конкретных, названных ставок.
Discovery не противостоит delivery и не заменяет его. Он задаёт delivery направление. Команда, которая быстро строит без discovery, — это машина, эффективно едущая неизвестно куда. Discovery не делает машину медленнее. Он даёт ей руль.