Что стоит выяснить до первой строки кода

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

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

Определите решение, ради которого исследуете

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

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

Отдельно укажите ограничения своей команды. Если вы не готовы поддерживать десятки форматов документов, эта граница должна участвовать в выборе сегмента с самого начала. Иначе исследование найдёт привлекательный спрос на продукт, который компания пока не способна обслужить.

Разберите последний реальный эпизод

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

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

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

Пользователь, покупатель и согласующий могут быть разными людьми

В B2B-разборе AJTBD учитываются роли, внутренние согласования и барьеры внедрения. Одобрение ежедневного пользователя не означает, что покупка пройдёт остальные звенья.

Для нашего примера полезна простая карта. Закупщик готовит сравнение. Руководитель производства проверяет соответствие материалов. Финансовый директор утверждает расходы. IT определяет, какие документы можно передавать внешнему сервису. У каждого участника есть собственное условие согласия.

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

Разделите знание на три колонки

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

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

Согласуйте условия пилота до его запуска

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

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

Что передавать в разработку

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

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