Итоги 4-го потока марафона «ТЗ за 7 шагов»: ключевые инсайты и эволюция методологии

Четвертый поток марафона по созданию технического задания с помощью ИИ завершается 10.02. Этот поток стал по-настоящему исследовательским: фокус сместился с вопроса «как делать?» на глубокое обсуждение «почему именно так?». Благодаря диалогу с практикующими аналитиками мы смогли выявить точки роста в методологии и зафиксировать конкретные улучшения для следующих потоков.

Ключевые темы обсуждения и запланированные изменения:

1. Графическая нотация: от единого стандарта — к инструментальной гибкости

Что обсуждали: 
Инструмент Graphviz, предложенный для построения контекстных диаграмм, оказался неидеален для всех. Участники отмечали недостаток визуальной наглядности в процессе правки и сложность быстрой итерации.
Что меняем в промтах: 
В следующих потоках мы добавляем альтернативные варианты на выбор: PlantUML (для любителей текстового описания) и Yed Graph Editor (для тех, кому важен интерактивный drag-and-drop).

Цель — повысить скорость и комфорт моделирования.

2. Четкое разделение логики: Use Cases, Интеграции, Utility-функции
Что обсуждали: 
Возникла важная дискуссия о природе функций. Стало очевидно, что не все требования стоит упаковывать в сценарии использования (Use Cases). Необходима предварительная классификация по цели:
- Действие, направленное на достижение цели конкретной роли пользователя (UC).
- Обеспечение обмена данными с внешними системами (Интеграция).
- Поддержка внутренних процессов или общие сервисные функции (Support/Utility).

Что меняем в промтах: 
вводим структурированное разделение:
-Пользов ательские Use Cases — строго для целей акторов.
- Интеграционные сценарии — выносим в отдельный промт внутри блока интеграции.
- Support/Utility функции — исключаем из Use Cases и описываем в соответствующем разделе. Это устранит путаницу и повысит логическую целостность документа.

3. Разделение ответственности: Функциональные и Нефункциональные требования

Что обсуждали: 
Обсудили дублирование измеримых параметров между ФТ и НФТ.

Что меняем в промтах: 
Четко разводим ответственность:
- В ФТ убираем количественные метрики. Акцент — на саму функцию, ее тип (UC/Utility/Support) и привязку к целям из Opportunity Canvas.
- В НФТ концентрируем все измеримые атрибуты качества.

4. Формирование Функциональной Архитектуры (ФА)

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

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

5. «Теория в один клик»
Что обсуждали: в процессе работы часто требовалось быстро освежить в памяти теоретические основы (например, правила построения контекстной диаграммы или классификацию НФТ.

Что дополняем: в тексты заданий напрямую интегрируем ссылки на соответствующие статьи из библиотеки Systems Education:
- НФТ и атрибуты качества
- Контекстная диаграмма

Что уже доработано «на лету»:
- Обновлены промты для проектирования модели данных с учетом рекомендаций по трем нормальным формам для реляционный БД
- Настроены проекты в Qwen для автоматизации обратной связи по всем 7 шагам марафона.
- Разработан и апробирован на учебном кейсе участника пилотный промт для описания Функциональной Архитектуры.

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

Следующий поток стартует в феврале — надеюсь успеть внести изменения в промты.
Если ваша цель — создавать четкие, структурированные и технологически выверенные ТЗ с помощью ИИ, присоединяйтесь!

5ый поток марафона c 18.02