Comments 10
Известно, что в коде LLM творят зачастую лютую дичь, особенно если промпт пишется неспециалистом. Перенося на ТЗ, как мне, неспециалисту, можно понять, что результат - не лютая дичь? В отличие от кода, «запуск» ТЗ - это недели и месяцы работы на одну попытку.
Не_специалист не должен писать ТЗ. ИИ — это помощник для специалистов, который обеспечивает полноту и добавляет скорость. Давая задачу ИИ, аналитик должен быть в состоянии верифицировать и исправить ответ
Тогда было бы хорошо в разделе "Цель [статьи]" подчеркнуть, что описанный метод строго для аналитиков и не может использоваться как их замена.
Мне по работе и не только приходится достаточно часто писать ТЗ (а точнее - их более современные аналоги типа спецификаций/продуктовых требований/пользовательских историй), но я не являюсь именно специалистом-аналитиком. И в 95% случаев именно специалист-аналитик избыточен банально из-за ограниченности бюджетов.
Сейчас такого не увидел:
Эта статья — демонстрационный пример, иллюстрирующий пошаговую методику преобразования одной вымышленной бизнес-фразы заказчика в полноценное техническое задание (ТЗ) с помощью инструментов искусственного интеллекта (ИИ). В качестве исходной фразы для демонстрации выбрана бизнес-идея, приписываемая гипотетическому Сэму Альтману: «Помогите мне сделать GPT настолько незаметным, что люди перестанут бояться сингулярности».
Добрый день. Спасибо за интерес к моей статье. Для того чтобы писать ТЗ с помощью ИИ нужно уметь ТЗ писать самому и уметь оценить его качество. То есть нужно обладать навыком экспертной оценки написанного ТЗ другим аналитиком. Задача не в том чтобы ИИ писал ТЗ полностью за тебя, задача в том, чтобы ТЗ с твоими мыслями и идеями было дополнено качественно идеями от ИИ и структурировано в виде требований по заданному формату с учетом границ проекта.
Цель - ускорить свои возможности по написанию ТЗ, не выходя за границы проекта.
Следующая статья будет про написание кода по готовому ТЗ? Интересно было бы почитать, как разработчики относятся к артефактам, подготовленным с помощью ИИ. У нас в принципе с договоренностями по артефактам плохо, поэтому проверить не могу.
Добрый день. В статье разработана методика по написанию ТЗ, которая позволяет адаптировать промты к принятым в компании шаблонам артефактов. Промты адаптируются под необходимый формат вывода требований. То есть для разработчика структура и содержание артефакта, написанного с ИИ и без ИИ идентичны. Разработчик может даже не знать, что ТЗ написано с ИИ. В процессе разработки системный аналитик доводит артефакт до требуемого уровня детализации, в том числе по замечаниям от разработчиков и исправлению замечаний совместно с ИИ.
Про следующую статью пока не думала - возможно рассмотрю вашу идею.
ну у нас в компании не развита культура единообразных артефактов, поэтому работа аналитика заключается больше в том, чтобы вытащить требования и объяснить разработке в трех словах, что конкретно нужно сделать. Соответственно ИИ использую, чтобы он мне объяснил в пяти-шести словах, а дальше я уже разработчику сокращу до трех самостоятельно.
Поэтому у себя такой промтинг проверить не могу.
А почему нельзя попробовать внедрить типовые шаблоны для передачи хотя бы своих требований для разработчиков? Неужели каждый раз приходится формулировать по разной структуре?
есть типовые шаблоны для юзкейсов
отлично - значит можно использовать данную структуру описания в качестве шаблонов и создать промты на следующие артефакты:
- вывод реестра юзкейсов (с требуемым форматом кодировки каждого юзкейса)
- UML-диаграммы прцедента
- описание шагов юзкейса по шаблону с блоками, который у вас применим
За основу промтов можно взять заготовки промтов из статьи и прописать свои правила для вывода под ваши шаблоны.
Только обязательно на входе к промтам необходимо выдать в качестве вложения описания требований в произвольном, но в достаточном виде для погружения ИИ в задачу.
Далее сохранить данные промты в файлик (База промтов) и даже можно поделиться с коллегами будет :).
Как написать AI-ТЗ из одной фразы заказчика: пошаговая инструкция по методике SARD от идеи до спецификации требований