Имея в голове всего лишь абзац текста, заказчики часто хотели без технического описания сразу дать кому то задачу для ее выполнения.
В итоге мы решили проанализировать, какие поля в принципе нужны для составления ТЗ, получился вот такой минимально достаточный для начала набор.
Название проекта и описание позволяют агентам запустить в работу сценарий, где 5 ИИ-агентов изучают полученные данные, дополняют их недостающими и выдают техническое задание в виде одностраничного сайта. Для примера я просто нажму на шаблон «Интернет-магазин с доставкой», а название ТЗ вообще введу неосознанно. Итак, вот захотел я получить интернет-магазин, вообще напрочь забыв, что это такое и зачем он мне сдался и нужен.
Примерно за 90 секунд происходит формирование кусков документа, однако магия уже давно не в том, что несколько агентов работают над разными кусками, а в целом физическом, реальном и уже давно существующем процессе написания ТЗ вручную, когда осознаешь, как это делать руками и что нужно учесть. Нам еще стало интересно учитывать перспективные изобретательские фичи в ТЗ, те, до которых сам заказчик не додумается, но которые появятся в итоговом документе отдельным разделом для понимания и принятия / не принятия.
Итоговый документ представляет собой одностраничный веб-сайт, который можно при необходимости подкорректировать на свой вкус. В момент начала генерации в поле «Кастомный URL» можно ввести адрес страницы, если не охота получить стандартный URL, случайно сгенерированный скриптом.
Результат: Профессиональное ТЗ уровня enterprise, которое включает:
- Бизнес-анализ (JTBD, Kano, CJM)
- Исследование рынка (конкуренты, TAM/SAM/SOM)
- Техническую архитектуру (стек, API, инфраструктура)
- Анализ рисков (матрица, pre-mortem, edge cases)
- План реализации (дорожная карта, бюджет)
- Неочевидные инсайты (7-10 идей)
В ТЗ должны представляться некоторые параметры и метрики. Должно быть проработано понимание рынка (ведь иначе зачем начинать делать именно эти работы по этому ТЗ). Исполнитель должен ориентироваться на определенные показатели в процессе разработки.
Во введении и контексте можно заметить преимущества предлагаемого решения. В результат включен анализ рынка пользователей.
При разработке контента магазина стоит учитывать пользу, которую даешь покупателю. А она зависит и от самого IT-продукта, взаимосвязь стоит держать в голове и иметь в виду в ТЗ.
Также важно уметь планировать риски в процессе разработки продукта
План реализации пока пишет довольно сжато, но оценивает, как и какими средствами выполнить ТЗ.
В некоторых генерациях видится актуальной Kano-модель:
В сгенерированном ТЗ предлагается и техническая архитектура решения.
По результату генерации также предлагает неочевидные инсайты и слабые стороны в текущей версии ТЗ:
По результату ТЗ сразу видно приоритеты и пользовательские сценарии для разных видов пользователей:
Токены и лимиты
Сильным ограничением здесь является количество токенов для генерации, которое при использовании таких веб-ресурсов всегда ограничено если не владельцами аппаратной части, то коэффициентом онлайна вашего домашнего сервера с GPU. Очевидно, что лимиты предсказываются заведомым ограничением по количеству токенов, возможностью выбора самого типа ТЗ (короткое, расширенное, детализированное), а также можно выбрать модель, с которой генерация будет дешевле.
// Лимит токенов на ответ (зависит от модели) define(‘GIGACHAT_MAX_TOKENS’, [ ‘brief’ => 3000, ‘standard’ => 5000, ‘detailed’ => 8000 ]);
// Красивые названия моделей для отображения в отчёте define(‘GIGACHAT_MODEL_LABELS’, [ ‘GigaChat’ => ‘GigaChat Lite’, ‘GigaChat-Pro’ => ‘GigaChat Pro’, ‘GigaChat-Max’ => ‘GigaChat Max’ ]);
Чего еще не хватает
Проблема: ИИ-Эксперты работают с тем, что вы написали в форме. Но часто вы сами не знаете, чего хотите.
Пример: Вы написали «приложение для доставки еды». А на самом деле вам нужно только MVP для теста гипотезы, а не полноценная система.
Что должно быть: Эксперты должны задавать вопросы:
- «Какой у вас бюджет?»
- «Сколько пользователей планируете?»
- «Нужен ли вам мобильный или достаточно веба?»
2. Нет валидации противоречий
Проблема: Эксперты могут дать противоречивые результаты.
Пример:
- Бизнес-аналитик: «Нужна геймификация»
- Риск-менеджер: «Геймификация сложна в поддержке»
Что должно быть: Финальный эксперт (CTO) должен находить противоречия и разрешать их:
- «Геймификация нужна, но делаем только MVP-версию (бейджи, без лидербордов)»
3. Однократный вызов
Проблема: Каждый эксперт вызывается один раз. Если результат плохой, никто не переделывает.
Пример: Бизнес-аналитик выдал слабый анализ мотиваций → Архитектор спроектировал под плохой анализ → Всё ТЗ криво.
Что должно быть: Итерации:
- Эксперт 1 выдал результат
- Эксперт 5 проверил: «Слишком поверхностно, переделай»
- Эксперт 1 переделал
- Эксперт 5 проверил снова
4. Нет проверки на реалистичность
Проблема: Эксперты могут предложить нереалистичные вещи.
Пример: Архитектор предложил «использовать Kubernetes, Istio, Kafka» для приложения с 100 пользователями. Это оверинжиниринг.
Что должно быть: Эксперт по бюджету должен сказать: «Это слишком дорого, давай проще».
5. Нет персонализации под контекст
Проблема: Все эксперты работают по одним и тем же промптам, независимо от типа проекта.
Пример: Для B2B SaaS и для мобильной игры нужны разные методологии:
- B2B SaaS → фокус на ROI, интеграции, безопасность
- Мобильная игра → фокус на retention, монетизация, виральность
Что должно быть: Разные наборы промптов для разных типов проектов.
Промежуточный итог
Таким образом, первый шаг закончился неплохим результатом, позволяет получить много информации, о которой мы бы сами в процессе составления могли не подумать. Однако процесс генерации ТЗ действительно может быть отдельной задачей определенной группы инженеров, которые хотят довести до ума все его внутренние процессы и развести процесс создания документа до проблемы с затратами в более чем 100000+ токенов.
Итоговое ТЗ можно посмотреть по ссылке: https://genervis.ru/tz/6a47726f84359.php
Отличный материал