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