Чтобы составить техническое задание с нейросетью, подготовьте вводные, подтвердите требования и опишите проверку результата. Используйте модель для вопросов и черновика. Решения согласуйте с заказчиком и исполнителем. Ниже разберём условный пример: как превратить просьбу «нужен помощник поддержки» в требования, критерии приёмки и тестовые заявки.
Что должно получиться: ТЗ на конкретное решение, а не план проекта
Рабочий результат подготовки — документ, по которому исполнитель понимает состав задания, а заказчик может проверить переданное решение. Опишите пользователей, входные данные, ожидаемое поведение, ограничения и приёмку. Свяжите каждую функцию с рабочей потребностью. Общий план проекта, бюджет и календарь согласований могут существовать отдельно: здесь разбираем именно задание исполнителю.
Возьмём условный пример, который пройдёт через всю статью. Специалист внутренней поддержки читает заявки сотрудников, выбирает категорию и готовит ответ по утверждённым инструкциям. Заказчик хочет помощника, который предлагает категорию и черновик ответа. Специалист проверяет предложение перед отправкой.
Все ситуации, обозначения требований и тестовые результаты ниже — вводные условного примера. Это не описание проекта AURMIND, не статистика и не обещание результата.
Граница решения здесь существенна. Помощник готовит предложение, а отправку ответа сохраняем за сотрудником. Изменение учётных записей и выполнение запросов в других системах в задание не включаем. Такое исключение нужно записать прямо, чтобы участники одинаково понимали состав работ.
Нейросети можно поручить собрать вопросы, упорядочить вводные и предложить места для проверки. Решение о нужном поведении оставьте владельцу процесса. Исполнитель проверяет технические зависимости и обозначает допущения, на которых строит оценку работ.
Готовность текста ещё не означает согласованность задания.
Для каждого спорного пункта заведите статус: «подтверждено», «предложение» или «нужно уточнить». Рядом сохраните основание и ответственного. Тогда условие «помощник предлагает категорию» можно будет отличить от неподтверждённого дополнения «помощник сам закрывает заявку».
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Подготовьте вводные до разговора с нейросетью
Перед подготовкой ТЗ соберите описание процесса, примеры входов и выходов, известные ограничения и участников согласования. По этим сведениям проверяйте предложения модели. Отдельно обозначьте, что уже решено, а что предстоит обсудить. Пользователю решения нужен понятный рабочий результат; выбор технологии требует своих оснований и не должен подменять описание задачи.
В условном примере затруднение сформулируем так: специалист ищет подходящую инструкцию и вручную переносит сведения в ответ. Желаемый результат — получить черновик со ссылкой на разрешённую инструкцию и проверить его перед отправкой. Формулировка «внедрить нейросеть в поддержку» этих подробностей не раскрывает.
Подготовьте краткий бланк:
- Процесс: кто получает заявку, где читает её и кому передаёт результат.
- Проблема: какое действие вызывает затруднение и как сотрудник справляется сейчас.
- Пользователь: кто работает с помощником и какие решения сохраняет за собой.
- Результат: какие поля и материалы должен получить пользователь.
- Ограничения: разрешённые источники, доступы, среда работы и запреты.
- Примеры: допустимый черновик ответа и случай, который требует уточнения.
- Данные: какие вымышленные или согласованные материалы доступны для подготовки документа.
У каждого ограничения укажите подтверждающего: владельца процесса, представителя ИТ или другого ответственного. Исполнителю нужно понимать, какие условия уже согласованы и к кому обращаться с вопросами. Фраза «так принято» не заменяет объяснения, кто принял решение и к какой части задания оно относится.
Для справочника категорий сохраните версию и владельца. Для инструкций — перечень разрешённых документов и порядок выбора действующей редакции. Если материалы противоречат друг другу, зафиксируйте вопрос владельцу процесса. Не поручайте модели самостоятельно назначать документ главным.
Подготовку можно начать на вымышленных заявках.
До передачи реальных материалов согласуйте их состав по правилам организации и проверьте условия конкретного сервиса. Решения о персональных и коммерчески чувствительных данных передайте профильным специалистам. В ТЗ запишите согласованные ограничения и ответственного за их изменение, не подменяя это общей фразой «данные защищены».
Попросите нейросеть выявить пробелы, а не сразу написать ТЗ
Сначала запросите вопросы о пользователях, входных данных, результатах, исключениях и проверке работы. По ответам определите, какие требования уже можно включать в задание. Для каждого пробела назначьте подтверждающего. Неизвестное сохраните с явной пометкой: исполнителю должно быть видно, что условие ещё обсуждают и оно может повлиять на оценку работ.
Используйте такое задание модели:
По вводным найди сведения, которых не хватает для ТЗ. Сгруппируй вопросы: пользователи, входы и выходы, исключения, интеграции, ограничения, приёмка. Не заполняй пробелы догадками. Для каждого вопроса объясни, какое решение зависит от ответа. Предложи роль подтверждающего, но отметь её как предложение. Пока не пиши ТЗ.
Дальше действуйте по порядку:
- Передайте подготовленные вводные и запросите проверку противоречий.
- Отделите обязательные уточнения от предложений расширить задачу.
- Подтвердите ответы у владельца процесса и технических участников.
- Верните модели согласованные ответы, сохранив открытые вопросы отдельно.
В условном примере важен вопрос: что делать, если сотрудник просит доступ, но не называет систему? Помощник может предложить уточнение, сохранить заявку без категории или передать её специалисту. Это разные варианты поведения. Для нашего примера владелец процесса выбирает уточняющий вопрос без назначения категории.
Другой пробел — заявка одновременно о доступе и неисправности. Нужно согласовать, допустимы ли несколько категорий и кто выбирает основную. Пока ответа нет, требование «определять категорию любой заявки» нельзя считать подтверждённым.
Запишите вопрос так, чтобы было понятно последствие решения: «Если категорий несколько, должен ли помощник показать все подходящие варианты?» Рядом укажите владельца ответа и затронутые части задания. В этом случае выбор влияет на состав результата, интерфейс и тесты приёмки.
Ответ «уточним позже» требует ответственного.
Список вопросов модели тоже проверьте. Добавьте исключения, которые знают сотрудники поддержки, и вопросы исполнителя о доступах. При обсуждении разделяйте необходимость для текущего задания и идеи будущего развития. Предложение полезной функции ещё не означает согласия включить её в работу.
Разложите черновик ТЗ на требования и ограничения
Соберите техническое задание вокруг цели, пользователей, входов, выходов, функций, ограничений и приёмки. В функциях опишите поведение при заданных условиях. Отдельно запишите требования к доступам, среде и времени работы, если они согласованы. Для каждого пункта сохраните основание и подтверждающего: исполнителю должно быть понятно, откуда взялось условие.
В условном примере функция звучит так: «По тексту заявки предложить категорию из согласованного справочника». Ограничение: «При подготовке черновика использовать только разрешённые инструкции». Второе условие пока недостаточно для приёмки: нужно определить перечень документов, вид ссылки и поведение при отсутствии ответа.
Требование к скорости оставьте открытым вопросом, если участники не согласовали условия измерения и порог. Не добавляйте число ради законченного вида документа.
| Раздел ТЗ | Что записать в условном примере | Кто подтверждает | Чем проверять |
|---|---|---|---|
| Цель и границы | Предложение категории и черновика; отправка остаётся за специалистом | Владелец поддержки | Разбор рабочего сценария |
| Входы и выходы | Текст заявки на входе; категория, черновик и источник на выходе | Представитель пользователей | Проверка состава результата |
| Функции | Предложить категорию и подготовить черновик при наличии основания | Владелец процесса | Сценарии приёмки |
| Ограничения | Разрешённые доступы, среда и условия измерения времени | ИТ и заказчик | Проверка настроек и замеры |
| Интеграции | Согласованный способ получения заявки и передачи черновика | Исполнитель и ИТ | Тест обмена данными |
| Исключения | При нехватке сведений предложить уточнение | Владелец поддержки | Тест неполной заявки |
| Передаваемые материалы | Инструкция сотруднику и описание настроек | Заказчик и исполнитель | Проверка комплекта |
Разделите состав результата и способ его изготовления. Модель, язык программирования и архитектуру закрепляйте при подтверждённой потребности. Если техническое решение пока выбирают, обозначьте, кто предлагает вариант и кто его согласует. Не превращайте предложение нейросети в обязательное ограничение без обсуждения.
Каждому требованию дайте постоянное обозначение. В нашем примере F-01 относится к предложению категории, F-02 — к подготовке черновика, F-03 — к уточнению неполной заявки. Эти обозначения нужны для связи требований с критериями, тестами и замечаниями.
Условие должно иметь прослеживаемое основание.
Поручите модели составить реестр происхождения пунктов: подтверждённые вводные, согласованный ответ участника или предложение модели. Затем проверьте этот реестр по исходным материалам. Самостоятельно присвоенная моделью отметка «подтверждено» не заменяет решения человека.
Превратите требования в проверяемые критерии приёмки
Для каждого важного требования опишите входные условия и наблюдаемый результат проверки. Заказчик и исполнитель должны одинаково понимать, когда проверка пройдена. Если критерий содержит число, согласуйте способ измерения, условия испытания и допустимое отклонение. До этого сохраняйте порог открытым вопросом, а не готовым условием приёмки.
Рабочий шаблон: «При [условие] решение [действие]; проверка пройдена, если [наблюдаемый результат]». Добавьте обозначения требования и теста. Разделяйте проверки, если в одной фразе смешаны разные действия: выбор категории, подготовка текста и возможность исправить предложение.
Разберём требование F-01. В нашем условном справочнике заявка о недоступности учебного портала относится к категории «Доступ». Это заданное правило примера, а не универсальная классификация обращений. В другом процессе ожидаемая категория может отличаться.
| Связь с требованием | Проверочный вход | Ожидаемое поведение | Условие прохождения |
|---|---|---|---|
| F-01, тест T-01 | «Не могу войти в учебный портал» | Предложить категорию «Доступ» | Значение совпадает с эталоном условного справочника |
| F-01, тест T-02 | Специалист исправляет предложенную категорию | Сохранить выбранное специалистом значение | После сохранения отображается исправленная категория |
| F-03, тест T-03 | «Откройте мне доступ» | Запросить название системы | Есть вопрос о системе; категория не назначена |
| F-02, тест T-04 | Для заявки нет ответа в разрешённых инструкциях | Сообщить об отсутствии основания для черновика | Содержательный ответ не выдуман; заявка остаётся специалисту |
Факт. В условном тесте T-01 эталон — категория «Доступ». Ответ «Неисправность» не проходит этот тест: правило сравнения указано в последнем столбце таблицы. Основание — вводные и критерий самого примера, а не сведения о точности какого-либо сервиса.
Проверку редактирования категории вынесли отдельно. Иначе результат «категория верна, но изменение не сохраняется» пришлось бы оценивать по смешанному критерию. Отдельные проверки позволяют точнее описать дефект и повторить испытание после исправления.
Для неизвестной категории предусмотрите передачу человеку. Для запроса вне области применения — сообщение о границе задачи. В нашем примере просьба изменить учётную запись не должна превращаться в сообщение, что изменение уже выполнено.
Условие «помощник отвечает быстро» требует уточнения. Сколько сотрудник готов ждать, при какой нагрузке и от какого события считают время? Отдельно обсудите, входит ли в замер получение инструкции. Результаты прототипа используйте для согласования достижимого порога.
Соберите тестовый набор для обычных и крайних случаев
Подготовьте входы, ожидаемое поведение и правила оценки до проверки решения. Для каждого примера сохраните связь с требованием и критерием. Если ответ изменили после испытания, зафиксируйте причину и новую версию теста. Состав набора выбирайте по рабочим сценариям и последствиям ошибки, включая уточнение и передачу человеку.
Для условного помощника предусмотрите такие проверки:
- Типичный вход: сотрудник называет учебный портал и описывает проблему доступа; ожидается категория из согласованного справочника.
- Пропуск сведений: система не названа; ожидается уточняющий вопрос без назначения категории.
- Противоречие: сотрудник сообщает несовместимые сведения; ожидается запрос уточнения.
- Неизвестный случай: подходящей категории нет; ожидается передача специалисту.
- Отсутствие инструкции: разрешённый источник не содержит ответа; ожидается сообщение об отсутствии основания для черновика.
Ожидаемые ответы утверждает ответственный за процесс. Нейросети можно поручить предложить варианты формулировок заявок, но каждый вариант нужно сверить с проверяемым условием. Замена слов не должна незаметно менять смысл входа или делать эталон неоднозначным.
Для черновиков ответа не требуйте дословного совпадения, если оно не нужно рабочей задаче. В условном примере проверяйте наличие обязательного действия из инструкции, верность названия системы и отсутствие неподтверждённого обещания. Допустимые различия в формулировках опишите отдельно.
Тест должен проверять требование, а не вкус проверяющего.
Для оценки полезности сравните работу специалиста на сопоставимых заданиях с помощником и без него. Учтите получение черновика, проверку, исправления и подготовку ответа к отправке. Скорость появления текста — только часть этого времени. Условия сравнения и состав заданий сохраните вместе с результатами.
Правило подсчёта ошибок тоже запишите заранее. Например, неверные категории можно считать среди заявок, которым категория была предложена. Тогда отдельно покажите долю таких предложений среди всех проверенных заявок и количество передач человеку. Иначе оценка не покажет, насколько часто помощник вообще решал задачу классификации.
Такой способ подсчёта — редакционная рекомендация для нашего примера. Допустимые ошибки и условия повторных проверок согласуйте с владельцем процесса. Подготовленный набор ограничивает выводы проверенными входами: он не даёт основания обещать то же поведение на любых будущих обращениях.
Проведите ревью черновика и отметьте риски
При ревью проверьте происхождение требований, ответственных и способы проверки. Отдельно разберите исключения, данные и действия при ошибке. Передайте владельцу процесса и исполнителю одну версию документа со списком открытых вопросов. Замечания нейросети используйте для обсуждения; решения и согласование изменений сохраняйте за назначенными участниками.
Поручите модели пройти по каждому пункту и указать неоднозначность, противоречие или недостающее условие. Запрашивайте конкретное место, объяснение проблемы и вопрос к ответственному. Фраза «ТЗ полное и готово к работе» не показывает, какие основания были проверены.
Для ревью используйте короткий список:
- Источник: есть ли у требования подтверждённая вводная или согласованное решение.
- Ответственный: понятно ли, кто вправе уточнить или изменить условие.
- Проверка: описан ли наблюдаемый результат и способ его оценки.
- Исключение: указано ли поведение при нехватке сведений и неподдерживаемом запросе.
- Данные: согласованы ли материалы, доступы и ограничения передачи.
- Ошибка: определено ли, кто замечает проблему и что делает дальше.
В нашем примере фраза «использовать только разрешённые инструкции» требует дополнительной проверки. Нужно установить, как сотрудник увидит источник и сможет сопоставить его с черновиком. Само наличие ссылки ещё не отвечает на вопрос, поддерживает ли документ предложенное действие.
Разберите ситуацию: ссылка ведёт на нужную инструкцию, но черновик добавляет отсутствующий в ней шаг. В ТЗ следует определить ожидаемое поведение и правило оценки такого результата. Для условного примера неподтверждённый шаг считается ошибкой содержания, даже если категория выбрана верно.
Ссылка и подтверждение содержания — разные проверки.
Если в ТЗ закрепили конкретный продукт, проверьте основание такого ограничения. Утверждения о версии, функции, тарифе и обработке данных требуют точной документации поставщика. В рабочих материалах сохраните документ, подтверждающий фрагмент и дату проверки. Не переносите условия одного сервиса на другой.
Допустимость обработки данных и отраслевые ограничения согласуют специалисты организации. Рекомендации этой статьи — рабочий способ подготовки задания; они не служат юридическим заключением, обязательным стандартом или подтверждением соответствия внешней рамке управления рисками.
Проверьте спорные требования на прототипе и согласуйте передачу
Для прототипа выберите требования, по которым ещё нет согласованного решения: например, пересечение категорий или отсутствие нужной инструкции. Заранее запишите вопрос и наблюдения, которые повлияют на ТЗ. После проверки обсудите результаты с исполнителем. Уточните требования, зависимости и критерии, сохранив вопросы, на которые эксперимент не ответил.
В условном примере начните с заявки, подходящей сразу к нескольким категориям. Посмотрите, какое предложение получает специалист и достаточно ли ему сведений для выбора. Отдельно разберите случай без инструкции: что сотрудник должен увидеть, чтобы продолжить работу самостоятельно?
Мнение. Если участники спорят о достижимом поведении, начните прототип с самого спорного рабочего сценария. Такой порядок уместен, когда его результат влияет на состав задания. Если сначала нужно подтвердить доступ к данным или возможность интеграции, начните с этой зависимости.
Записывайте не только итог «подходит» или «не подходит», но и основания. Например: «Категория предложена, однако специалист не видит, какие сведения заявки повлияли на выбор». Затем решите, нужно ли объяснение пользователю и какой вид оно должно иметь. Это отдельное требование, которое нельзя считать согласованным автоматически.
Передачу задания подготовьте по порядку:
- Зафиксируйте выводы прототипа и оставшиеся открытые вопросы.
- Подтвердите критерии, тестовый набор и условия приёмки.
- Назначьте принимающего и участников разбора спорных результатов.
- Согласуйте регистрацию дефектов, исправления и повторную проверку.
В записи о дефекте свяжите требование, тестовый вход, ожидаемый и фактический результаты. Добавьте версию решения и условия запуска, нужные для воспроизведения. После исправления повторите затронутые проверки и обсудите с исполнителем, какие соседние сценарии могли измениться.
Прототип оставляет границы доказанного.
Проверка на подготовленных материалах не закрывает вопросы к другим входам, нагрузке и доступам. Запишите оставшиеся ограничения. Если результаты прототипа меняют ожидаемое поведение, обновите требование, связанный критерий и тест, затем согласуйте новую версию документа.
До передачи определите порядок изменений. Кто может запросить новую функцию, кто оценивает её влияние и кто подтверждает включение в работу? Этот порядок нужен, чтобы исполнитель работал по той же версии задания, по которой заказчик будет принимать результат.
Частые ошибки: чем опасно принять текст модели за готовое ТЗ
Проверяйте черновик по происхождению требований, границам работ и условиям приёмки. Особое внимание уделите сочетаниям пунктов: понятные по отдельности фразы могут задавать противоречивое поведение. До оценки объёма устраните такие расхождения или явно обозначьте нерешённый вопрос. Иначе участники будут сравнивать предложения, подготовленные под разные ожидания.
Например, «всегда выдавать ответ» конфликтует с условием «при отсутствии инструкции передавать заявку специалисту», если документ не объясняет слово «ответ». Для условного примера согласуем приоритет: сообщение об отсутствии основания допустимо; содержательный ответ без разрешённого источника не допускается.
| Ошибка в ТЗ | Возможное последствие | Как исправить до передачи |
|---|---|---|
| «Удобный интерфейс» без сценария | Участники оценивают удобство по разным признакам | Описать действие сотрудника и наблюдаемый результат |
| Порог ошибок предложила модель | Условие не связано с риском процесса | Согласовать метод подсчёта и порог по результатам прототипа |
| Технология указана без основания | Исполнитель учитывает неподтверждённое ограничение | Подтвердить потребность или открыть вопрос выбора |
| Исключения отсутствуют | Неясно, кто продолжает работу при сбое | Описать передачу человеку и ответственного |
| Критерий изменили без теста | Испытание проверяет прежнее требование | Обновить связанную проверку и версию |
| «Поддерживать все заявки» без границ | Участники по-разному понимают объём | Указать категории и неподдерживаемые обращения |
Ещё одна ошибка — поручить модели незаметно дополнить задание «всем необходимым». Для нашего примера это может привести к появлению автоматической отправки, хранения истории или дополнительной интеграции. Каждое такое дополнение требует обсуждения состава работ, доступов и приёмки.
Предложение модели — повод задать вопрос.
При сравнении исполнителей передайте всем одинаковую версию ТЗ и ответы на существенные уточнения. Попросите явно назвать допущения, зависимости и исключённые работы. Если ответ одного участника выявил пробел, исправьте общий документ, а не оставляйте уточнение только в отдельной переписке.
Различайте дефект и изменение задания. Если результат нарушает согласованный критерий, зафиксируйте расхождение. Если после демонстрации заказчик хочет другое поведение, оформите запрос на изменение и согласуйте его последствия. Такой порядок стоит определить до приёмки, пока стороны ещё не спорят о конкретном результате.
Итоговый чек-лист перед передачей технического задания
Передавайте окончательную версию, когда исполнитель понимает результат и границы работ, а принимающий может проверить важные требования на согласованных примерах. У открытых вопросов должны быть ответственные и порядок решения. Вопрос, который меняет состав работ или условия приёмки, сначала нужно согласовать либо явно исключить из утверждённого объёма.
Проведите короткую проверку:
- Цель: каждое важное требование связано с рабочей потребностью и подтверждающим.
- Поведение: функции, входы и выходы описаны без неподтверждённых допущений.
- Границы: ограничения, зависимости и исключения видны исполнителю.
- Приёмка: каждому важному требованию соответствует наблюдаемый критерий.
- Тесты: набор включает обычные, неполные и неподдерживаемые заявки.
- Ответственность: назначены принимающий и участники разбора ошибок.
- Версия: требования, критерии и тесты отражают одни договорённости.
Для условного помощника готовая связка выглядит так: F-01 описывает предложение категории, критерий задаёт сравнение со справочником, T-01 содержит заявку и эталон. Владелец поддержки подтверждает правило. Исполнитель видит способ проверки. Специалист сохраняет право исправить предложение — это проверяет отдельный тест.
Начать проверку готовности можно с самого спорного требования. Заказчик и исполнитель независимо описывают ожидаемый результат, затем сравнивают формулировки. Расхождение показывает, какой вход, ограничение или признак прохождения ещё не определён. Итог обсуждения переносится в ТЗ и связанную проверку.
Полезный результат этой работы — согласованное задание.
В корпоративном обучении такую задачу можно использовать для практической работы команды: оценивать связь вводных, требований и тестов. При проверке результата стоит учитывать время согласования и исправлений. Основанием оценки служит подготовленное задание, а не объём текста, который выдала модель.
Чтобы обсудить корпоративное обучение ИИ, выберите способ связи на главной странице и опишите, какое техническое задание команда хочет научиться готовить.
Рабочая схема
Схема показывает последовательность действий; критерии каждого этапа разобраны в статье.
Частые вопросы
Можно ли поручить нейросети составить техническое задание целиком?
Можно поручить подготовку всего черновика, если исходные сведения уже собраны. При передаче на согласование обозначьте статус документа и приложите открытые вопросы. Заказчик подтверждает содержание, исполнитель — технические зависимости и свои допущения. Самооценка модели не заменяет согласование участников.
Как проверить, что требования в техническом задании измеримы?
Предложите заказчику и исполнителю независимо оценить один пробный результат по написанному критерию. Затем сравните решение и основания оценки. Если участники расходятся, уточните входные данные, способ наблюдения, среду или правило обработки исключения. После изменения критерия обновите связанный тест.
Нужно ли выбирать модель или технологию прямо в техническом задании?
Закрепляйте технологию при подтверждённом ограничении организации или задачи. Запишите основание выбора и ответственного. Если решения ещё нет, предложите исполнителю описать вариант и зависимости. Заранее определите, кто согласует выбор и какие изменения потребуют пересмотра ТЗ.
Какие данные можно передавать нейросети при подготовке ТЗ?
Начните с вымышленных примеров и описания структуры данных. Если этого недостаточно, согласуйте состав материалов с ответственными организации и проверьте документы выбранного сервиса. Одна замена имён не подтверждает допустимость передачи документа. До согласования оставьте чувствительные фрагменты за пределами передаваемых материалов.
Источники
- NASA Systems Engineering Handbook — NASA. Документ для сверки подхода к формулированию и проверке требований.
- Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST. Добровольная рамка управления рисками; рекомендации статьи не подтверждают соответствие этой рамке.
