Системный аналитик из крупной финансовой компании описал на Habr подход, при котором техническое задание перестаёт быть структурированным документом. В его компании ТЗ оформляют как связанные задачи в Jira, а Confluence используют только как базу знаний для локальных стандартов. Это избавляет от необходимости записывать одни и те же требования в двух местах и тратить время на громоздкие документы по старым образцам.
Однако у Jira, по словам автора, нет версионности задач, истории получения требований из переписки, истории правок и согласований, а также истории вложенных файлов. Нет и интеграции с каналами коммуникаций: аналитик получает требования из почты, мессенджеров, задач, файлов и ссылок, но единого места, где всё это собиралось бы в целостную картину, не существует. Доработать Jira под эти нужды означало бы переписать её целиком.
| Инструмент | Что даёт | Чего не хватает |
|---|---|---|
| Jira | Связанные задачи вместо документа | Версионности, истории правок и согласований, интеграции с каналами |
| Confluence | База знаний для локальных стандартов | Не используется как основное место для ТЗ |
| Obsidian | Связи между заметками | Командных согласований, версионности, корпоративных интеграций |
Поэтому автор предлагает специализированную информационную систему, в которой ТЗ собирается из требований, а не пишется как документ. Она должна интегрироваться с разными каналами получения документов, а сами документы разных типов — связываться между собой, иметь ссылку на источник, историю обсуждения и согласования. ТЗ в такой модели — не файл и не страница, а всегда актуальная выборка связанных документов.
Принцип связанных заметок не нов: Obsidian и подобные инструменты давно показали, что связи между записями работают лучше папок. Но это инструменты для одного человека. В них нет согласований, версионности и интеграции с корпоративными каналами. Как только в процессе появляется команда, утверждения и внешние источники, персональная вики перестаёт справляться.
С описанной системой аналитик перестанет делать работу технического писателя: ему не нужно будет переносить требования из переписки в ТЗ, потому что система забирает их из каналов и связывает. Разработчик получит всегда актуальное задание с прослеживаемой историей, бизнес — уверенность, что его требования не потерялись, а принятые решения сразу окажутся в ТЗ.
Но у такой модели есть обратная сторона. ТЗ перестаёт быть документом, который можно прочитать сверху вниз, и превращается в набор связанных карточек. Целостную картину из них человеку приходится собирать самому. Здесь нужен искусственный интеллект, который проходит по связям и показывает картину целиком, отвечает на вопросы по ней. А чтобы подключить его к системе, нужен стандартный протокол, например MCP.
Пока это не описание готового продукта, а постановка задачи. Автор не называет конкретных сроков, бюджетов или компаний, которые уже внедрили подобную систему. Тем не менее направление перекликается с общим трендом: инструменты для совместной работы всё чаще дополняют ИИ-слоем, который умеет отвечать на вопросы по корпоративным данным. Вопрос в том, насколько такой слой сможет заменить привычный документ и не создаст ли новых сложностей с согласованием и ответственностью за решения.
