Как избежать моих AI-ошибок в управлении discovery-проектами

Сейчас у меня в работе проект, который, кхм, на старте имел очень размытые очертания. А-ля CRM-система, но с омниканальным окном коммуникаций и прочими CAPA-мероприятими.
На одной из первых встреч бизнес-заказчик попросил: «Нужно, чтобы вся переписка с клиентом была в одном месте». Звучит логично и просто. Через две недели выяснилось, что для директора это означало двустороннюю интеграцию со всеми каналами связи, для руководителя отдела — историю касаний с подсчетом лимита, а для рядового менеджера — просто удобный интерфейс "единого окна", чтобы не переключаться между вкладками. Три разных требования, спрятанные в одном предложении. Мы это не поймали на старте — поймали через две недели, когда опросили всех будущих пользователей и часть работы пришлось переделывать.

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

Я руковожу несколькими параллельными IT-проектами разного стека. При таком объёме ручная проверка каждой формулировки на скрытые допущения физически не масштабируется.
Примерно год назад я начал системно встраивать Claude в discovery и работу с документацией — не как разовый эксперимент «пусть напишет текст», а как часть процесса.

Ниже — то, что реально изменилось, и три ошибки, которые я сам сначала совершал.

Первое, что я попробовал — дать AI сырую цитату (или концепцию) заказчика и попросить сформулировать требования. Результат выглядел отлично: связный, профессионально звучащий список ФТ и НФТ. Проблема вскрылась позже — часть пунктов оказалась логичными, правдоподобными… и полностью придуманными. AI заполнил пробелы там, где данных не было, потому что связный текст — это буквально то, что он умеет делать лучше всего.

Это самое опасное свойство таких инструментов в discovery: неточность не выглядит как неточность. Она выглядит как уверенно написанный документ.

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

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

Решение оказалось скучным, но эффективным: один раз сформулировать структуру документа (назначение модуля → роли пользователей → функциональные требования → сценарии → нефункциональные требования → открытые вопросы → зависимости) и переиспользовать её в каждом промпте, а не описывать заново.

Настоящая экономия времени здесь — не в скорости генерации текста. Она в том, что происходит, когда требования меняются (а они меняются почти на каждом проекте). Раньше это означало вручную пересобирать документ. Теперь — прогнать обновлённые вводные через тот же шаблон структуры и получить актуальную версию за считаные минуты.

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

Решение — отдельный шаг ревью: прогонять готовый документ через ещё один запрос, где AI уже не создаёт контент, а именно проверяет написанное на внутренние нестыковки между разделами. Это заняло лишние пять минут, но безупречно "причесало" документ

Ничего из этого не заменяет экспертизу PM. AI не отличит формально правильное требование от требования, которое реально решает бизнес-задачу заказчика — это по-прежнему моя работа. Хороший черновик требований, кстати, не тот, что закрывает всё гладко и без единого вопроса. Если AI не оставил ни одной пометки «требует уточнения» — это тревожный звоночек, что он (или я сам) что-то дофантазировали, а не то, что мы всё учли.

Больше всего в этом процессе изменилось не то, что документы стали появляться быстрее. А то, что при изменении требований — а в B2B-проектах они меняются почти всегда — пересборка документации перестала быть отдельной задачей на полдня. Discovery стало циклом, а не разовым событием в начале проекта.

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