От клиентского интервью к требованиям услуги

После интервью у вас есть записи, цитаты и несколько страниц заметок. Клиенты просят «проще», «быстрее», «чтобы всё было в одном месте». Из этих слов ещё трудно составить услугу: непонятно, что именно делать, как проверить результат и где заканчивается работа.

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

Начните с одного повторяющегося затруднения

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

Не спешите делать вывод «Нужен личный кабинет». Сначала опишите наблюдаемое затруднение: перед выполнением правок человеку нужно собрать согласованный список и определить актуальную версию.

GDS рекомендует формулировать потребности через задачу пользователя, а не через заранее выбранное решение. Для коммерческого предложения это полезно тем, что оставляет возможность сравнить несколько способов: правила переписки, единый документ, настройку существующего инструмента или собственную программу.

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

Сохраните путь от факта к выводу

Разделите четыре вещи: что произошло, как вы это объясняете, что предлагаете сделать и как проверите полезность. Так будет видно, где заканчивается рассказ человека и начинается ваше проектное решение.

Например, участник сказал: «В пятницу внёс комментарии директора, а в понедельник узнал, что менеджер уже согласовал другую версию». Это наблюдение из его рассказа. Предположение о причине — отсутствие единого порядка согласования. Предлагаемое изменение — один ответственный собирает комментарии в определённом документе. Проверка — исполнитель получает однозначный список и не возвращается к уже отменённой версии.

1. Факт: в пятницу внёс комментарии директора, в понедельник узнал, что менеджер согласовал другую версию.
2. Объяснение: возможно, нет единого порядка согласования.
3. Изменение: один ответственный собирает комментарии в определённом документе.
4. Проверка: исполнитель получает однозначный список и не возвращается к отменённой версии.

Цепочка не доказывает, что изменение сработает.

GDS отдельно описывает переход от наблюдений к выводам и действиям при анализе исследования. Наша цепочка для небольшой услуги — практическая адаптация этого принципа. Она не доказывает, что выбранное изменение обязательно сработает.

Не нужно оформлять сложную систему ссылок. Достаточно кода интервью и короткой записи эпизода, чтобы при необходимости вернуться к основанию.

Не считайте частоту упоминания единственным приоритетом

Просьбу изменить цвет кнопки могут повторить несколько человек, а риск отправить конфиденциальный файл не тому адресату — назвать один. Важность не определяется одним количеством упоминаний.

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

В то же время редкая необычная история не должна автоматически расширять продукт для всех. Возможно, она описывает клиента, которому ваша первая версия пока не подходит. Тогда полезнее обозначить ограничение, чем обещать поддержку всех сценариев.

Сформулируйте проверяемый результат

«Упростим согласование» звучит приятно, но не объясняет, что изменится. Более конкретный результат: «Для выбранного типа заказа будет описан порядок передачи версии, сбора комментариев и подтверждения готовности».

Дальше нужно определить, что именно вы передаёте: схему процесса, настроенную папку, шаблон списка правок, инструкцию и пробное прохождение на одном заказе. Не все эти элементы обязательны. Выберите те, которые нужны для обещанного результата.

В NASA при подготовке требований обращают внимание на ясность и возможность проверки. Для небольшой услуги можно взять сам принцип, не перенося инженерную документацию целиком: у каждого существенного требования должен быть понятный способ убедиться, что оно выполнено.

Фраза «Участники больше никогда не запутаются» такой проверки не выдерживает. Вы не управляете всеми будущими действиями. А «Участники прошли учебный сценарий и нашли актуальную версию по инструкции» — наблюдаемое событие с ограниченной областью вывода.

Отделите обязательную основу от вариантов

Для первого предложения полезно составить короткий список: что нужно каждому подходящему клиенту, что выбирается по ситуации и что пока не входит.

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

Проверьте основу вопросом: сможет ли подходящий клиент получить обещанную пользу без дополнительных покупок, о которых заранее не знал?

Назовите необходимые действия клиента

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

Если эти действия не описаны, исполнитель может пообещать результат, на который не влияет. Например, настроить удобную систему можно, но заставить всех участников регулярно ею пользоваться одним фактом передачи файла нельзя.

Включите в предложение понятные условия: какие материалы нужны, кто участвует во встрече, что согласуется и как определяется дата старта. Это помогает клиенту оценить не только цену, но и собственное участие.

Не превращайте список обязанностей в защиту от любых претензий. Если без сложного участия заказчика услуга не приносит пользы, стоит пересмотреть сам способ выполнения.

Проверьте черновик предложения отдельно

Покажите короткое описание человеку с подходящей задачей. Попросите своими словами объяснить, что он получит, что должен подготовить и где заканчивается работа. Не исправляйте ответ сразу: сначала запишите непонимание.

Такая проверка выявляет неясность, но ещё не подтверждает спрос. Для проверки покупки нужны конкретные условия и возможность принять решение. Если люди хорошо понимают предложение, но не выбирают его, причины следует искать дальше.

Не просите участников утверждать каждую формулировку как соавторов продукта. Они помогают понять опыт и реакцию; ответственность за состав предложения остаётся у вас.

Сохраните первую версию и основания изменений

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

Если предложение меняется, сохраняйте причину. «Добавили короткую встречу, потому что в двух заказах участники не смогли начать по одной инструкции» полезнее, чем «Решили сделать пакет богаче».

Начать можно с одного интервью и одного требования. Возьмите важный эпизод, сформулируйте задачу, предложите ограниченный результат и укажите способ проверки. Когда такая связь понятна, предложение становится последовательным: вы можете объяснить, зачем в нём каждый элемент и на каком основании он появился.