Техническое задание, написанное как документ в Confluence или Word, устаревает быстрее, чем его успевают согласовать. Одно и то же требование расползается по нескольким файлам, шаблон диктует структуру, которая уже не совпадает с реальностью, а каждая правка тянет за собой синхронные изменения в связанных разделах. Опыт системного аналитика в крупной финансовой компании показывает, что от такого формата можно отказаться: требования оформляют как связанные задачи в Jira, и это снимает дублирование и устаревающие шаблоны.
Jira закрывает часть проблемы, но не всю. У неё нет версионности задач, истории получения требований из переписки, истории правок и согласований, а также интеграции с каналами коммуникаций, откуда аналитик берёт требования. Доработать её под эти задачи означало бы переписать систему целиком.
Поэтому речь идёт о специализированной системе, где ТЗ не пишется, а собирается из требований: документы разных типов связаны между собой, хранят ссылку на источник, историю обсуждения и согласования, а само ТЗ становится всегда актуальной выборкой. Плата за это - потеря линейности: вместо документа получается набор карточек. Собрать из них целостную картину и ответить на вопросы помогает ИИ, подключённый через стандартный протокол вроде MCP.
Почему ТЗ в Confluence и Word перестаёт работать
Документный формат рассчитан на то, что требования меняются редко и предсказуемо. Как только продукт начинает развиваться быстрее графика согласований, документ превращается в снимок устаревшей картины: он описывает систему, которой уже нет. Confluence и Word хорошо хранят текст, но ничего не знают о связях между требованиями, поэтому каждая правка живёт своей жизнью.
Дублирование требований и устаревающие шаблоны
Одно требование редко существует в одном месте. Формулировка попадает в основной текст ТЗ, повторяется в приложении с интеграциями, всплывает в описании API, дублируется в письме от бизнес-заказчика и в комментарии к задаче. Чем больше копий, тем выше шанс, что часть из них останется в старой редакции.
Шаблон добавляет вторую проблему. Готовый каркас задаёт разделы, и аналитик заполняет их по инерции: появляются блоки-заглушки, которые копируются из проекта в проект. Шаблон фиксирует структуру, а содержание и контекст меняются. Постепенно форма начинает управлять смыслом, а не наоборот.
В крупной финансовой компании цена такой рассинхронизации выше, чем в продуктовой команде из пяти человек: требования проходят согласования, на них опираются разработка, тестирование и аудит. Поэтому от документа как единственного носителя требований там отказываются.
Переход к связанным задачам в Jira: что это даёт
Альтернатива, которая работает на практике: ТЗ оформляют как связанные задачи в Jira, а не как документ в Confluence или Word. Каждое требование становится отдельной задачей с идентификатором, исполнителем и статусом, а связи между задачами заменяют разделы документа. Изменение требования - это правка одной задачи плюс при необходимости новый тип связи, а не переписывание всего файла.
Что это даёт конкретно:
- уходит дублирование: формулировка существует в одном месте, остальные ссылаются на неё;
- устаревающие шаблоны теряют власть над структурой: набор задач собирается под конкретную фичу, а не под форму;
- статус требования виден сразу: в работе, на согласовании, отклонено;
- обсуждение остаётся рядом с требованием, а не в отдельной ветке почты.
Jira закрывает дублирование и шаблоны, но не закрывает версионность, согласования и коммуникации. Ограничение упирается в класс инструмента: трекер задач проектировался для управления работой, а не для ведения требований как связанной сущности.
Чего не хватает Jira: версионность, история требований и согласования
Список ограничений короткий, и каждое из них рушит идею ТЗ как живой выборки:
- нет версионности задач;
- нет истории получения требований из переписки;
- нет истории правок и согласований;
- нет интеграции с каналами коммуникаций, откуда аналитик получает требования.
Версионность задач и история правок
Задача в Jira хранит текущее состояние. Поле меняется на новое, старое значение остаётся только в журнале изменений и в лучшем случае доступно как комментарий. Для рабочего процесса этого хватает, для требований нет.
Требованию нужна версия: как оно формулировалось на момент согласования, что изменилось после, кто внёс правку и на каком основании. Когда через полгода тестирование находит расхождение с реализацией, вопрос звучит не «что написано сейчас», а «что утвердили и когда это перестало совпадать». Без версий и истории правок восстановить цепочку нельзя, а согласование теряет привязку к конкретной редакции текста.
История получения требований из переписки
Значительная часть требований приходит не из формального интервью, а из обсуждений: переписки с заказчиком, тредов в корпоративном мессенджере, комментариев на созвоне. Там же остаются уточнения, причины отказов и договорённости об исключениях. Jira эту историю не хранит: в задаче оказывается итоговая формулировка, а контекст, из которого она выросла, теряется.
В специализированной системе требование сохраняет ссылку на источник. Это меняет работу с неоднозначностями: вместо спора о том, кто что имел в виду, открывается исходное сообщение с датой и автором.
Интеграция с каналами коммуникаций
Требования живут в тех каналах, где общается команда, а Jira живёт отдельно. Переносить обсуждение внутрь задач неудобно, а синхронизировать вручную - значит терять часть сообщений. Собрать каналы коммуникаций и трекер в одну точку уже получается у MCP-связок: в разборе полного цикла тестирования в одном терминале показано, как Confluence, трекер задач, база данных, чат и репозиторий подключаются к одному агенту, который читает контекст из каждого источника.
Переписать Jira так, чтобы она держала версии требований, хранила переписку и тянула данные из мессенджеров, означало бы сделать другой продукт. Из этого вырастает идея отдельной системы, заточенной под требования.
Специализированная система: ТЗ как выборка связанных документов
Принцип простой: ТЗ не пишется как структурированный документ, а собирается из требований. Система хранит не файл, а набор связанных сущностей, и документ нужного типа формируется как выборка из них.
Как устроена связка документов и требований
Документы разных типов связываются между собой: требование ссылается на источник, из которого пришло, на смежные требования, на решение о согласовании. Каждая сущность хранит ссылку на источник, историю обсуждения и историю согласований. Формулировка не дублируется: она существует один раз, а в ТЗ попадает ссылкой.
Само ТЗ становится всегда актуальной выборкой связанных документов. Изменилось требование - изменилась выборка, без ручной синхронизации разделов. Границы задаются не шаблоном, а правилом отбора: например, все согласованные требования по конкретному продукту за период. Это концепция, а не готовый продукт, который можно купить и поставить.
Чем это отличается от Obsidian и персональных вики
Принцип связанных заметок известен по Obsidian: заметки ссылаются друг на друга, обратные ссылки показывают контекст, граф связей помогает увидеть структуру. Идея та же, но персональные вики не дают согласований, версионности и корпоративных интеграций.
Разница в корпоративных требованиях:
- согласование: у требования есть роли, подписи и статус, у заметки в личном хранилище их нет;
- версионность: нужно знать, какая редакция утверждена и что изменилось после;
- права доступа: разные документы видны разным людям, а финансовая компания без этого не работает;
- интеграции: данные приходят из трекера, мессенджеров, систем документации и внутренних API.
Obsidian хорош как личный инструмент и как источник идеи, но корпоративный контур на нём не построить.
Обратная сторона: ТЗ теряет линейность
У подхода есть честный минус. Линейный документ несёт повествование: читатель идёт от контекста к требованиям и видит логику целиком. Выборка из карточек такого повествования не даёт. Требования существуют как набор связанных элементов, и целостная картина складывается только в голове читателя, который прошёл по связям.
Для нового участника это тяжелее, чем прочитать ТЗ на двадцать страниц. Для аудита и для ответов на вопросы вида «что изменится для клиента, если мы отключим этот сервис» набор карточек тоже неудобен: ответ размазан по десяткам сущностей. Собрать из них связный ответ может ИИ, подключённый через стандартный протокол вроде MCP.
Зачем здесь ИИ и как его подключать через MCP
ИИ в такой системе решает две задачи: собирает из разрозненных карточек целостную картину и отвечает на вопросы по связям. Агент проходит по ссылкам, подтягивает источники, учитывает историю согласований и формирует ответ, который человек проверяет. Без стандартного интерфейса к данным каждый такой сценарий пришлось бы писать под конкретную систему.
MCP как стандартный протокол для подключения ИИ к корпоративным системам
Model Context Protocol описывает, как ИИ-агент обращается к внешним данным и инструментам. Протокол вырос из инициативы Anthropic и получил поддержку Linux Foundation, а решает он проблему M×N: без общего стандарта каждую связку «модель + система» приходится делать отдельно, с ним сервер описывает свои возможности один раз и подключается к любому совместимому клиенту. Архитектура, экосистема готовых серверов и быстрый старт разобраны в материале про MCP как универсальный протокол подключения ИИ-агентов к инструментам.
Для ТЗ как выборки это означает предсказуемый доступ агента к требованиям, источникам и согласованиям: вместо выгрузок и ручной сборки контекста сервер отдаёт агенту нужные сущности по запросу. Тот же протокол меняет модель взаимодействия с продуктом: запрос формулируется намерением, а не навигацией по интерфейсу, о чём подробно сказано в статье про MCP как новый интерфейс продукта.
Пример подключения: Microsoft 365 Copilot и MCP-сервер
Рабочая схема выглядит так: декларативный агент Microsoft 365 Copilot плюс удалённый сервер MCP, подключённый через соединитель Copilot Studio. В примере Fluix агент обращается к серверу MCP двумя запросами: GET /.well-known/mcp/schema для обнаружения средств без авторизации и POST /mcp для вызова средства с маркером OAuth Bearer, который выпускает Fluix. Данные остаются в собственном API Fluix: сервер MCP работает как слой доступа, а не как копия базы.
Перенести схему на требования можно по той же логике: MCP-сервер отдаёт агенту требования, источники и статусы согласований, а агент формирует из них ответ или черновик ТЗ. Это не единственный способ подключения, но он показывает, что связка «корпоративная система + внешний ИИ-агент» строится на стандартных запросах и токенах, а не на самодельных мостах.
Как проверять MCP-сценарии, чтобы не сломать процесс
Связку нейросети, MCP и автоматизации стоит проверять как последовательность отдельных этапов, а не как одну «магическую» кнопку. Порядок такой: зафиксировать исходный запрос, подготовить ограниченный набор данных, посмотреть, какой ответ формируется, и только в конце решать, нужен ли следующий шаг с изменением в учётной системе.
Отдельно запишите, какие данные сценарий должен получить и что ему запрещено менять. Это правило снимает большую часть рисков: агент, которому разрешено читать требования и историю согласований, не должен иметь возможности править согласованные документы.
Ручная точка подтверждения нужна там, где результат нельзя сверить с исходником. Ответ агента, собранный из карточек, стоит показать человеку до того, как он уйдёт в работу. Такой же принцип лежит в основе методологии Agent-Ops 0.4.0: ИИ предлагает, человек утверждает, а детерминированный исполнитель применяет только допущенные действия.
Проверку удобно вести на тестовых данных, сохраняя неудачные варианты и причины правок: через месяц именно эти записи объяснят, почему сценарий настроен так, а не иначе. Минимальная таблица для проверки MCP-сценария:
| Вход | Действие | Ожидаемый результат | Фактический результат | Ручная проверка |
|---|---|---|---|---|
| Запрос «покажи требования по продукту X» | Агент вызывает средство чтения связанных требований | Список требований со ссылками на источники | Сверить состав с утверждённой выборкой | |
| Запрос по записи без изменения данных | Агент возвращает поля номер, дата, контрагент, сумма, сомнения | Если значение отсутствует или неоднозначно, в поле сомнений стоит «нужно проверить» | Проверить, что агент не менял данные в учётной системе |
Полезно держать в голове ещё одно соображение про объём данных: отправлять в большую модель весь массив требований с историей обсуждений незачем. Фильтрация, удаление дублей и поиск нужных фрагментов перед обращением к модели снижают стоимость ответа и уменьшают шум, из-за которого агент цепляется за нерелевантные карточки.
Кому подходит подход и с чего начать
Подход рассчитан на команды, где требований много, они часто меняются и проходят согласования: банки, страховые, крупные внутренние платформы. Там, где ТЗ пишется раз в год для небольшой доработки, связанные карточки и MCP-сервер дадут больше накладных расходов, чем пользы. Универсальной заменой Jira и Confluence концепция тоже не выступает: трекер задач и вики остаются частью процесса, меняется роль документа.
Проверить идею можно ограниченным пилотом:
- Зафиксировать исходный запрос: какую именно задачу решает выборка требований.
- Подготовить ограниченный набор данных: десяток связанных требований с источниками и историей согласований.
- Проверить ответы агента на тестовых примерах, включая записи с неполными данными.
- Сохранить неудачные варианты и причины правок.
- Решить, нужен ли следующий шаг с изменением в учётной системе, и только потом выдавать агенту права на запись.
Если после пилота ответы агента сходятся с исходниками и человек тратит меньше времени на сбор контекста, подход стоит расширять. Если приходится перепроверять каждую ссылку вручную, значит данные в системе связаны недостаточно плотно, и начинать нужно с модели связей, а не с ИИ.