Нужна система, в которой ТЗ собирается из требований, а не пишется как структурированный документ

В одной крупной финансовой компании, где я работал системным аналитиком, технические задания оформляют не в Confluence и не в Word, а как связанные задачи в Jira. Это очень удобно, так как не приходится записывать и обновлять одни и те же требования в двух местах (Confluence/Word и Jira) и тратить время на написание громоздких и часто устаревающих структурированных ТЗ по старым образцам. Confluence в этой компании используется как база знаний в основном для хранения локальных стандартов.

Но в Jira все же нет версионности задач, истории получения требований из переписки, истории правок и согласований, истории вложенных файлов.

В Jira также нет интеграции с каналами коммуникаций. Системный аналитик получает требования отовсюду: почта, мессенджер, комментарии в задачах, файлы, ссылки. Единого места, где это собиралось бы в целостную картину, нет.

Доработать Jira так, чтобы все это учесть, означало бы переписать ее целиком.

Поэтому нужна специализированная информационная система, в которой ТЗ собирается из требований, а не пишется как структурированный документ. Она должна интегрироваться с разными каналами получения документов. Документы разных типов в ней должны связываться между собой, иметь ссылку на источник, историю обсуждения и согласования. ТЗ должно быть не файлом или страницей, а всегда актуальной выборкой связанных документов.

Принцип связанных заметок не нов. Obsidian и подобные инструменты давно показали, что связи между записями работают лучше папок. Но это инструменты для одного человека. В них нет согласований, версионности и интеграции с корпоративными каналами. Как только в процессе появляется команда, утверждения и внешние источники, персональная вики перестает справляться.

С описанной здесь системой аналитик перестанет делать работу технического писателя, потому что ему не нужно будет переносить требования из переписки в ТЗ, ведь система забирает их из каналов и связывает. Разработчик будет иметь всегда актуальное задание с прослеживаемой историей, бизнес получит уверенность, что его требования не потерялись. Принятые решения сразу окажутся в ТЗ.

Но у такой модели есть обратная сторона. ТЗ перестает быть документом, который можно прочитать сверху вниз, и превращается в набор связанных карточек, целостную картину из которых человеку приходится собирать самому. Здесь нужен искусственный интеллект, который проходит по связям и показывает картину целиком, отвечает на вопросы по ней. А чтобы подключить его к системе, нужен стандартный протокол, например MCP.