Практические кейсы в работе аналитика с помощью искусственного интеллекта. Присоединяйся!
По вопросам и консультациям: @hellybel
Post #494
457

Итоги 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
Четвертый поток марафона по созданию технического задания с помощью ИИ завершается 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
- ❤ 7
- 🔥 4
- ⚡ 1















