Discovery и сбор требований

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

  1. Бизнес
  2. Процесс
  3. Данные
  4. Ограничения

9.1 Бизнес

С этих четырёх вопросов начинают, потому что от них зависит, будет ли проект вообще.

Какую проблему решаем? «Хотим стать эффективнее с помощью AI» — это не задача, а протокол о намерениях: конкретику пока никто не формулировал. В нормальном ответе слышна повторяющаяся потеря: менеджеры трижды в день переносят одни и те же данные заявки из почты в учётную систему, а оттуда в таблицу для отчёта.

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

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

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

9.2 Процесс

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

Кто делает эту работу сегодня? Нужны фамилия и должность. «Отдел логистики» вам ничего не покажет — покажет человек, у которого на втором мониторе открыт файл, не упомянутый ни в одном регламенте. Попросите полчаса рядом с ним; эти полчаса дадут больше, чем весь предыдущий блок.

Из каких шагов состоит работа? Пусть перечислят по порядку и вслух, а вы записывайте прямо при них. Каждое «ну тут по-разному» — это метка на полях: вернитесь и выясните, от чего именно по-разному.

Что делается руками? Отсюда и начинают автоматизацию, и сам заказчик это место обычно не называет. Назовут то, что раздражает. Дольше всего тянется, как правило, совсем другое, и про него вспоминают, только если спросить отдельно.

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

9.3 Данные

Задача понятна, процесс описан. Остаётся выяснить, из чего это строить.

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

Есть ли CRM, хранилище, база? Если ответ получается подсчётом, суммой или фильтром строк, это text2SQL. Почему эти два вопроса путают чаще всех остальных, объясняет пятая глава; на discovery достаточно помнить, что за ними стоят два разных проекта с разными сроками.

Есть ли база знаний и кто её ведёт? База без ответственного за пару лет накапливает столько взаимных противоречий, что поиск по ней перестаёт быть надёжным. Спрашивайте не только про наличие, но и про то, кто её правит и как часто.

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

Сопоставьте услышанное с пятой главой без самообмана. Документы — RAG, база — text2SQL. А если нет ни того ни другого, доставать не из чего и считать нечего, то первый проект вообще не про модель. Это наведение порядка в данных, и в коммерческом предложении так и стоит написать, не пряча эту работу за словом «внедрение».

9.4 Ограничения

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

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

Есть ли требования безопасности — сертификат, список согласованных поставщиков, внутренняя процедура допуска? Что за этим стоит на практике, разбирает седьмая глава. Задача discovery проще: узнать, что требования есть, и записать, кто за них отвечает, пока это ещё влезает в план.

Есть ли персональные данные? Фамилии, диагнозы, доходы — всё, что защищено законом. От их присутствия фраза «просто отправим в облачный API» меняет смысл, а иногда становится невыполнимой.

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

О чём говорит незакрытый пункт

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

  • Шаги процесса никто не перечислил по порядку. Рано говорить не только про агента, но и про workflow. Сначала описание, потом автоматизация.
  • Ни документов, ни CRM. RAG строить не из чего: проект начинается со сбора и разбора материала, а не с системы над ним.
  • У процесса нет хозяина. За результат никто не отвечает, а значит, покупать его тоже, скорее всего, некому.
  • В работе есть персональные данные. Вопрос про облако считайте открытым заново и вернитесь к нему прежде, чем назовёте архитектуру.
  • Ошибка стоит дорого, а проверяющего в цепочке нет. Человек в контуре — не опция, которую прикручивают потом. Он появляется на первом же наброске или не появляется вовсе.

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

Красные флаги

Красных флагов пока нет

Блок A — Бизнес

Конкретная повторяющаяся потеря: кто именно что теряет и как часто. «Хотим повысить эффективность с помощью AI» означает, что думать ещё не начинали.

Не тот, кто собрал встречу, а тот, с кого спрашивают результат и кто теряет что-то, если ничего не улучшится.

Спрашивайте, пока не прозвучит показатель и направление. Записывайте словами заказчика и отмечайте, кто согласился с этим вслух.

То значение, от которого предстоит двигаться. Без него улучшение нечем измерить и нечем защитить на приёмке.

Блок B — Процесс

Имя и должность. Отдел не покажет вам процесс — покажут те двое, кто каждый день его и выполняет.

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

Ищите копирование из окна в окно, сверку глазами и таблицу, про которую все знают, но в регламенте её нет.

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

Блок C — Данные

Не «есть ли где-то файлы», а есть ли корпус, за который кто-то отвечает и который кто-то поддерживает в актуальном состоянии.

Важно не наличие базы, а то, отвечает ли она на вопросы бизнеса без ручной доработки выгрузок.

Спрашивайте не только про наличие, но и про то, кто её правит и как часто. База, которую два года никто не трогал, противоречит сама себе.

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

Если права раздаются папками, а не документами, поиск отдаст содержимое любому, кто дотянулся до ассистента.

Блок D — Ограничения

Спрашивайте не мнение ИТ-директора, а то, что написано в действующих внутренних документах и в договорах с их собственными клиентами.

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

Считайте и то, что попадает в обращения случайно: фамилия в теле письма — тоже персональные данные, даже если поля для неё нет.

Список того, чего нельзя, у банка, клиники и рекламного агентства писали разные ведомства и по разным поводам.

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

Нужны имя и должность. «Проверять будет пользователь» означает, что не проверяет никто.

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