В описание проекта добавили ещё одну роль, затем интеграцию. Цена осталась прежней. Где была граница работы, теперь трудно установить: стороны её толком не обсуждали.
Архитектура услуги нужна до таких разговоров. Покупателю предстоит понять, какой результат он получит, что потребуется от его команды и когда новая просьба изменит объём или цену.
Доказательства можно создавать в ходе исполнения. Порядок от исходного измерения до карточки для следующего покупателя, включая работу без публичного кейса, разобран в главе 9-1.
Из чего состоит надёжная услуга
Результат этапа. После него клиент лучше действует или принимает решение, а не просто получает ещё один документ в папку.
Процесс. Показывать каждую внутреннюю операцию не нужно. Покупатель должен понимать логику: какие данные входят, где принимаются решения, как проверяется качество и когда можно остановиться.
Границы. Что входит, чего нет, сколько итераций предусмотрено, какие подразделения участвуют и когда объём пересматривается. Граница не означает негибкость. Она помогает заранее согласовать ожидания от проекта.
Обязательства клиента. Доступ к людям и данным, сроки обратной связи, владелец решения, выполнение экспериментов. Если этого нет в договорённости, исполнитель молча забрал чужой риск.
Доказательства. Не парад известных логотипов, а свидетельства применимости: похожая ситуация, измеримый переход, образец мышления, пилот или рекомендация участника с нужным опытом.
Правила изменения и остановки. Новые данные появятся обязательно. Заранее договорись, что произойдёт, если гипотеза неверна, входные данные задержаны или продолжение потеряло смысл.
Подробное ТЗ тоже может скрывать неизвестное
Специалист превращает коммерческое предложение в техническое задание. Подробность создаёт ощущение порядка, хотя главное допущение всё ещё не проверено. Клиент начинает сравнивать функции. Качество пути к результату исчезает за перечнем работ.
Другая ошибка: оставить границы «по-человечески гибкими». Новые просьбы входят бесплатно, сроки едут, маржа усыхает. Клиент всё равно недоволен, потому что общего ожидания результата никто не создал.
Одна роль вместо растущего портала
В учебном случае команда продавала исследование и редизайн клиентского портала. По дороге в проект добавлялись роли и интеграции. Одна работа выросла вдвое, цена осталась прежней.
Услугу разделили на два результата. Первый этап давал согласованный сценарий для одной ключевой роли, прототип и решение о целесообразности разработки. Клиент предоставлял доступ к пяти пользователям, аналитику и владельца решения. Интеграции и визуальная система не входили. После проверки можно было остановиться, расширить исследование или заказать реализацию по новой оценке.
Вместо галереи экранов команда показывала историю похожего решения: какие допущения оказались неверными и как ранний прототип остановил лишнюю разработку. Один клиент отказался давать доступ пользователям. Продолжать на прежних условиях было нельзя: проверка сценария требовала участия этих людей.
На каком решении заканчивается этап
Чем больше неопределённости, тем опаснее продавать монолитный проект с жёстким обещанием. Разделяй путь на решения. Каждый этап уменьшает конкретную неопределённость и оставляет полезный результат, даже если продолжения не будет.
Но не дроби механически. «Сбор требований» сам по себе ценности не имеет, если после него клиент всё ещё не знает, что делать. Полезный этап заканчивается решением: выбрать сегмент, подтвердить процесс, утвердить приоритет или проверить техническую реализуемость.
Доказательство должно отвечать на риск. Клиент боится, что команда не поймёт предметную область: покажи способ погружения и похожий результат. Боится внедрения: красивый проект слабее данных об изменившемся поведении.
Проверь услугу до старта
Опиши услугу на одной странице:
- ситуацию и требуемое изменение;
- результат первого этапа;
- входные данные;
- логику процесса;
- контрольные решения;
- обязательства сторон;
- включённое и исключённое;
- критерий приёмки;
- условия пересмотра;
- доказательства для трёх главных рисков.
Проведи премортем: представь, что проект провалился. Назови пять вероятных причин и для каждой добавь входной критерий, контрольную точку или границу. Потом попроси коллегу сыграть покупателя и пересказать, что он получит, что должен дать и когда сможет остановиться.
До оплаты обе стороны одинаково описывают результат, логику, вклад клиента, исключения и правила изменения. Доказательства соответствуют рискам. Каждый этап заканчивается полезным решением.
Если при разборе обнаружилась зависимость, которой нет в договорённости, добавь её до обсуждения старта.