В одной крупной финансовой компании, где я работал системным аналитиком, технические задания оформляют не в Confluence и не в Word, а как связанные задачи в Jira. Это очень удобно, так как не приходится записывать и обновлять одни и те же требования в двух местах (Confluence/Word и Jira) и тратить время на написание громоздких и часто устаревающих структурированных ТЗ по старым образцам. Confluence в этой компании используется как база знаний в основном для хранения локальных стандартов.
Но в Jira все же нет версионности задач, истории получения требований из переписки, истории правок и согласований, истории вложенных файлов.
В Jira также нет интеграции с каналами коммуникаций. Системный аналитик получает требования отовсюду: почта, мессенджер, комментарии в задачах, файлы, ссылки. Единого места, где это собиралось бы в целостную картину, нет.
Доработать Jira так, чтобы все это учесть, означало бы переписать ее целиком.
Поэтому нужна специализированная информационная система, в которой ТЗ собирается из требований, а не пишется как структурированный документ. Она должна интегрироваться с разными каналами получения документов. Документы разных типов в ней должны связываться между собой, иметь ссылку на источник, историю обсуждения и согласования. ТЗ должно быть не файлом или страницей, а всегда актуальной выборкой связанных документов.
Принцип связанных заметок не нов. Obsidian и подобные инструменты давно показали, что связи между записями работают лучше папок. Но это инструменты для одного человека. В них нет согласований, версионности и интеграции с корпоративными каналами. Как только в процессе появляется команда, утверждения и внешние источники, персональная вики перестает справляться.
С описанной здесь системой аналитик перестанет делать работу технического писателя, потому что ему не нужно будет переносить требования из переписки в ТЗ, ведь система забирает их из каналов и связывает. Разработчик будет иметь всегда актуальное задание с прослеживаемой историей, бизнес получит уверенность, что его требования не потерялись. Принятые решения сразу окажутся в ТЗ.
Но у такой модели есть обратная сторона. ТЗ перестает быть документом, который можно прочитать сверху вниз, и превращается в набор связанных карточек, целостную картину из которых человеку приходится собирать самому. Здесь нужен искусственный интеллект, который проходит по связям и показывает картину целиком, отвечает на вопросы по ней. А чтобы подключить его к системе, нужен стандартный протокол, например MCP.
Комментарии (28)
FM12
13.09.2026 18:43А почему вы пишете, что в Jira нет версионности задач ?
Да, и важный момент, который является плюсом классического ТЗ - его можно закрепить при обсуждении с заказчиком - его можно версионировать как описание системы на конкретный момент времени.
А вообще в свое время поиск подходящей RMS меня привел к Archimate / Archi - как к более комплексному подходу с возможностью поддержания сложной системы связей между разными уровнями требований и в связи между техническими и функциональными требованиями, целями/задачами бизнеса, инфраструктурными ограничениями и возможностями и др ;-)
SergeyProkhorenko Автор
13.09.2026 18:43Версионироваь можно не только "классическое ТЗ", но и каждую задачу или их набор.
FM12
13.09.2026 18:43Это понятно.
Только в том-то и смысл ТЗ, что версионируется набор - в рамках которого есть тоже итерации по каждому требованию.
Просто реализовывать можно в конкретный момент времени только конкретную версию ТЗ.
Иначе это не ТЗ, а реально просто гибкая разработка с беклогом...
И ТЗ тогда сжимается до ЧТЗ под каждую конкретную задачу.
А разработка в целом происходит эволюционным путем - методом проб и ошибок и др - без попыток охватить картину в целом.
В общем ведение пунктов ТЗ в виде задач - идея не новая, но достаточно костыльная - особенно в случаях, когда есть нефункциональные требования и, фактически, во всех задачах они будут превращаться в чек-лист того, что нужно проверить / учесть разработчику при реализации конкретной фичи.
Ну и ТЗ - это в т.ч. первичное описание целевой архитектуры - хотя бы требований к ней...
ЗЫ: и если уж совсем быть строгими - после ТЗ идет техпроект, техпаспорт и т.п.
Но это для систем, которые внедряются в критичный прод - например, связанный с производством, ТЭК и т.п., где цена ошибки/просчета слишком высока, чтобы работать без предварительного ТЗ и понимания критериев приемки работы.
Chemist_modeler
13.09.2026 18:43Хорошо вам живется - вам требования поступают от заказчика так, что их можно извлечь из каких-то документов... завидую. Подозреваю, что делаете вы стотысяченадцатую вариацию а-ля кастомизация 1С. Тоже нужная вещь, не спорю. Но подозреваю, что жить таким проектам осталось не слишком долго. Если ИИ может правильно изалечь требования, то и сделать сам проект он, вероятно, тоже сможет без помощи кожаной прокладки... могу, впрочем, ошибаться в сроках - возможно, остались не месяцы, а еще годы.
Но как быть с теми проектами, в которых заказчик сам толком не понимает, что именно ему нужно? Вы можете ьесклнечно созваниваться и переписываться или встречаться лично, но в итоге формулируете ТЗ - вы сами, и придумываете его - по сути тоже сами, вытаскивая из заказчика не тоебования, а "хотелки". Их реализация - быть может, и возможна, за триллиард или чуть меньше, но заказчик этим доволен не будет. Ваша работа - понять, чего заказчику реально не хватает такого, что ваша команда способна для него сделать. Думабю, подобные заказы еще кпкое-то время поживут, прежде чем ИИ научится их делать. Возможно, это время и немаленькое, типа лет ста... могу, опять же, ошибаться в сроках.
С такими заказами как быть?
FM12
13.09.2026 18:43э... я нигде не писал, что требования поступают от заказчика в готовом виде..
Обычно заказчик приходит с проблемой, а не с требованиями - и даже не с пониманием, что ему нужно - новая система, или и.б. просто нужно людей обучить работать с текущими инструментами, или вообще просто это проблема процесса, а не ИТ.
Но закреплять требования по итогам обследования и работы аналитиков нужно с заказчиком - потому что иначе в какой-то момент возникнет вопрос, что работа должна быть оплачена, результаты приняты, бюджеты потрачены... и у заказчика должно быть понимание - на что и с каким выхлопом
Меня еще в институте учили, что ТЗ ВСЕГДА пишет исполнитель :)
Но заказчик формулирует заказ
FM12
13.09.2026 18:43Вы пока слишком оптимистичны в отношении ИИ.
Да, сейчас можно, теоретически, написать даже достаточно сложную систему, особенно используя SDD-подход.
Но, надо понимать, что это просто очередной шаг эволюции.
Когда-то программы писали на машинном языке или Асме - и представители бизнеса/ученые/инженеры отдавали свои алгоритмы/модели на бумаге бородатым дядькам или тетям, которые их забивали в перфокарты и запускали в мейнфреймы, а потом делали длинные распечатки с результатами.
Потом появились специалисты на стыке бизнеса/науки/аналитики и программирования - потому что в итоге появились языки верхнего уровня. Но все равно приходилось осваивать уже работу с этими инструментами.
А сейчас ИИ пишет код. При этом, все прекрасно понимаю, что как на языке верхнего уровня уже не написать так элегантно, как на асме, так и на ИИ вы получите код не просто не оптимальный - а заполненный определенным процентом нейрослопа.
Но, в любом случае, как только система становится проще обычной утилитки - встает необходимость управления ТЗ и применения SDD.
Ну и эффект "самоопыления" никто не отменял - ИИ вам не предложит нового решения - он просто "выровняет" вас с рынком.
Условно - ну, вот подскажет, что есть класс систем RMS, расскажет про мировой опыт и сделает проект "на уровне" который уже достигнут - но ничего нового он не предложит - потому что этого нигде еще нет.
Человеческое творчество - это не подбрасывание игральных костей - это сложный процесс, в котором есть даже детерменизм - только просчитать его также бесполезно пока что, как смоделировать поведение атомов в кусочке сахара, растворяемом в чаеChemist_modeler
13.09.2026 18:43Спасибо, что откликнулись.
Про творчество - в смысле, недоступное ИИ, который просто подровняет и всё, - имхо, один из мифов, которому жить осталось совсем недолго. ИИ уже способен находить новые решения, кои мы с вами далеко не всегда видим в силу нашей, человеческой, инерции мышления. К примеру, полноценное научное открытие - которое в т.ч. противоречит общепринятым концепциям и трактовкам и дает новое понимание физики явлений - отнюдь не дело следующего века. Причем для этого даже не нужна супер-интеллектуальная модель. Не лумаю, что разработка бизнес-софта концептуально сложнее.
Качество нейрокода - тоже вещь не то чтобы постоянная. Сравните сегодня и год назад... просто сравните. Шахматисты десяток лет назад тоже считали столетия, пока компьютер научится их обыгрывать, а фотографы - пока цифровая матрица сравняется с пленочной по пикселям. Качественный скачок, хотим мы того или нет, уже произошел.
Еще один распространенный миф - про ограничения платформ. Типа, на экселе невозможно написать нормальную программу, там лаже классов нормальных нет (кстати, про "ненормальные", которые там таки есть, многие суперспецы и не слыхали, как и про много чего еще). Дело часто бывает не в платформе, а в зарплате, которую шотовы платить разработчику.
Я про другое хотел сказать - про то, что уже сейчас неплохо бы подумать о том, какие проблемы нам придется решать лет через несколько, когда ИИ "скушает" очередной пласт человеческих работ, на этот раз в области программирования, - и как улучшить то, что еще после этого останется нашим белковым собратьям.
Кино не уничтожило театр и книги, а смартфон не уничтожил зеркалки - но театральному артисту и профессиональному фотографу сегодня надо делать не то же самое, что полста лет назад.
Какие именно задачи придется решать завтра тем, кто сегодня делает бизнес-софт? Где главное "узкое место" в таких задачах? Как его "расшить"? Сегодня это может казаться чем-то не слишком важным, а завтра - может оказаться единственным, что спасет профессию от вымирания...
FM12
13.09.2026 18:43С технологиями уходит рутина и остается творчество.
Это показывают и примеры новостей с так называемыми "открытиями ИИ". По факту там речь идет о том, что ИИ перебирал все возможные варианты, что ест-но человек сделать не может с такой же скоростью (пример - Мендеелеев перепробовал кучу вариантов в течении длительного времени, пока ему не "приснилась" итоговая таблица элементов).
Узким местом становится уже человек, который должен успевать обрабатывать те результаты, которые выдает ему ИИ и принимать решение - классический пример - кодревью кода ИИ. Иначе у нас все превратится в ваб-ливинг - когда все делает ИИ - и работает, и принимает работы... и живет :).
и тогда "скрипач не нужен".
И возникает вопрос - а нужен ли тогда ИИ?
Тут еще вторая западня - прогресс ИИ будет влечь за собой регресс людей. И в итоге остается опасность самоопыления ИИ с постепенной деградацией - уже и ИИ и людей... как говорится "будешь как Великий Нехочуха".
Но, думаю появятся люди, которые уйдут в Зеон и будут делать все "руками", думать сами, читать книги и др.Как не убил ширпотреб штучного производства в XIX веке. Да, луддиты побастовали - но мир не остановился. Просто оставшиеся мастера стали цениться выше и доступны узкому кругу.
Только если бы все было так просто - при чтении аналитических отчетов от ИИ не возникало бы каждый раз ощущение общения со смоляным чучелком.
Ключевое, что отличает человека - это не только явные знания, но и опыт, воспоминания, ощущения - все, что связано с физическим миром.
Не даром "мысль изреченная - есть ложь" - внутренний мир (неявные знания) человека намного богаче и сложнее, чем он может это описать.
И пока все неявные знания не будут переведены в явные - ИИ будет уступать.
Это как с "отвернувшимися" у Лю Цисиня в "Темном лесе".
ИИ сможет приблизиться к человеку, когда он получить возможность полноценной физической жизни, с полным спектром переживаний...
Вопрос только - нужен ли нам такой гомункул ?
А с т.з. экспериментов - да, если дать ИИ самому проводить физические эксперименты - он сможет методом подбора найти новые составы веществ, технологии производства и др... правда есть при этом вероятность, что он "сожрет" кучу материи на неудачные опыты... как сейчас сжигает кучу энергии на неудачные генерации и нейрослопы.
И, к слову, пока что даже в программировании, ИИ не может полностью самостоятельно дать себе обратную связь и сыграть за всю команду разработки, сам провести нужные эксперименты и др - все равно пока требуется наличие того, кто первично отстраивает систему.
Я бы воспринимал ИИ как очень активного студента, который прочитал кучу книг и впитал в себя все теоретические знания.
Чем он отличается от студента - студент такой объем забудет сразу после сессии - потому что нет подкрепления. А ИИ запомнит все - и полезное, и бесполезное - но без эмоционально, механистически.
А человек запоминает только через практику, через применение знаний в своих действиях - причем. желательно. в ближайшие несколько суток.
FM12
13.09.2026 18:43ЗЫ: вот про 1С обидно было... :-)
пусть в меня кинут камень, но уровень большинства программистов 1С мне с трудом позволяет назвать их ИТ-специалистами/программистами/проектировщиками...
Очень редко на рынке 1С-разработчиков встречаются грамотные команды - и причиной тому сама платформа, которая загоняет в некие рамки и сажает в свою песочницу.
Примерно как программирование на учебных языках типа "Кумир".
Поэтому сравнивать мою работу с примерами на 1С я бы не стал :-)
FM12
13.09.2026 18:43А вообще то, что вы описываете под ТЗ в Jira - это по сути бэклог.
Просто по правилам большинства гибких методологий:
1) задача не берется в текущую работу, пока ее не уточнили (это как раз этап формализации требований аналитиками)
2) допустима иерархия задач (те же "эпики" в скраме)
FM12
13.09.2026 18:43да, еще немного "не раскрыта тема сисек" с т.з. того, что вы понимаете под требованиями.
На вскидку есть как минимум такие варианты:
1) что должно быть
2) как должно быть учтено
И вот требования вида "что" хорошо укладываются в задач...
А вот требования "как" - должны соблюдаться при выполнении всего проекта и с т.з. использования трекера - это будут постоянно активные задачи, которые будут просто висеть в общей помойке задач и никак не "жить", не влиять на другие задачи и др.
Пример задачи "как" - "интерфейс должен соответствовать требованиям стайл-гайда...", "все модули должны работать на Java не ниже версии..." и т.п. - причем это могут быть и функциональные и нефункциональные требования
olku
13.09.2026 18:43Можете разделить Что делать (продукт заказчика), Как делать (технология исполнителя), и заменить Порядок (таск трекер) на Ожидание (релизы)
FM12
13.09.2026 18:43ну, тогда вот и получится, что одно и то же требование как задача в Jira будет висеть все релизы незакрытая....
в общем это все попытка натянуть трекер задач на RMS, хотя при этом от таск-трекера вообще берется по факту то, что он содержит в себе БД :-)
Elbrus128
13.09.2026 18:43Это очень удобно, когда ТЗ не документ, а компиляция из живых ссылок!!!
Заходите в п. 1 и читаете: "кнопка должна быть синяя по центру".
Сделали и идёте сдавать. А вам говорят: "Ты — плохой ушлеёпок! Что написано в ТЗ?"
Открываете все вместе, а там: "Кнопка должна быть красной слева".
Просто, пока вы писали синюю кнопку требования уже раза три переделали. ТЗ же
должно быть не файлом или страницей, а всегда актуальной выборкой связанных документов.
Очень удобно иметь динамичное ТЗ. Так можно получить квалификационное звание RTD (Real Time Developer, Программист реального масштаба времени).
Это особое искусство!
Такой не станет переделывать кнопку на красную. Он знает систему глубже!..
Он ждет. И... когда в требовании п. 1 снова появляется СИНЯЯ кнопка, он бежит сдавать работу. То, что она должна быть справа — не беда.По пути в лифте поправит.
Заехала на др. элементы интерфейса?
Это ушлёпки из др. команд не прочитали прекрасное динамичное ТЗ из ссылок!
Справа по п. 1 должна быть именно эта синяя кнопка.
В др. пунктах тоже все должно быть справа?
Это потому, что каждое требование пишут разные люди в своем собственном отделе. А в ТЗ они собираются по ссылкам. Нам не нужны какие-то аналитики, постановщики, архитекторы, которые будут читать весь документ, являться его автором и отвечать за его целостность и непротиворечивость.
Я сдаю работу по п. 1 только! Вот, её и принимайте!!!
SergeyProkhorenko Автор
13.09.2026 18:43А разве монолитное ТЗ избавлено от внезапных правок? Правки должны согласовываться заказчиком с исполнителем и реализовываться в дополнительное время за отдельную плату, и тогда не будет проблем. А форма ТЗ не имеет к этому отношения. В статье нет ничего про то, что "не нужны какие-то аналитики, постановщики, архитекторы, которые будут читать весь документ, являться его автором и отвечать за его целостность и непротиворечивость". Это Вы от себя добавили.
Elbrus128
13.09.2026 18:43Правки должны согласовываться заказчиком с исполнителем и реализовываться в дополнительное время за отдельную плату, и тогда не будет проблем.
Хм-м-м... Сергей, а как же тогда автособирающееся ТЗ из требований, которые куча разных людей пишут себе по своим делам, не держа в голове, что это одновременно будет и пункт ТЗ?
Эта фраза в вашем ответе, на мой скромный взгляд, прямо противоречит тому, что вы написали в вашем длинном запросе о помощи, изначально:… нужна… система, в которой ТЗ собирается из требований, а не пишется как структурированный документ.
Документы разных типов в ней должны связываться между собой, иметь ссылку на источник, историю обсуждения и согласования.
ТЗ должно быть не файлом или страницей, а всегда актуальной выборкой связанных документов.
… аналитик перестанет делать работу технического писателя, потому что ему не нужно будет переносить требования из переписки в ТЗ, ведь система забирает их из каналов и связывает.
Или я неправильно понял?!
Должна искомая гипотетическая система сама генерировать ТЗ или не должна, и у ТЗ тогда будет конкретный автор (коллектив авторов с ответственным руководителем), который его создает на основе каких-то других документов и отвечает за его содержимое?
suburg
13.09.2026 18:43Самый неудобный формат ТЗ с которым я работал, это как раз RMS. Куча утверждений "Система ДОЛЖНА...", из которых каждый человек по разному синтезирует что же именно надо сделать. Не считая описания требований в задачах, что на мой взгляд вообще неприемлемо.
Наиболее удобно для меня иметь описание системы ДО, описание система ПОСЛЕ и дельту между ними.
Описание системы ДО в моей картине мира это обязательный артефакт. Руками надо либо внести правки и превратить ДО в ПОСЛЕ (и силами ИИ описать дельту), либо описать дельту и силами ИИ получить ПОСЛЕ.
Плюс минус это можно делать в Конфлюенсе или другой вики через версии страниц (понятно что не идеально), можно в гите.
SergeyProkhorenko Автор
13.09.2026 18:43Видимо, Вы работали без системного аналитика, который должен отвечать за целостность и непротиворечивость ТЗ. Безусловно, версионность ТЗ - это обязательное требованние. Ну и согласование изменений, а также уведомления об изменениях.
FM12
13.09.2026 18:43ну, в случае новой системы не будет "ДО" - и ТЗ в итоге будет содержать полный набор требований вида "должен/должна" и т.п.
suburg
13.09.2026 18:43Это редкий вырожденный случай
Система создаётся один раз, и дорабатывается потом 10 лет.
В любой итеративной модели прямо "с нуля" только первая итерация. Потом уже появляется ДО.
Это кстати одна из проблем теории - хорошее ТЗ на новую систему и хорошее ТЗ на доработку системы несколько разные. Про это почему то редко пишут, и постоянно ориентируются на новую систему.
ToxaBes
Такая система называется RMS (Requirements Management System) и ее реализаций великое множество: DOORS Next, Jama, Polarion ALM, Helix и тд.
Наиболее близкой системой к тому что вы описали является Doorstop.
SergeyProkhorenko Автор
Спасибо, про RMS и Doorstop не знал, посмотрю. Формально это тот же класс, и Doorstop ближе всего по духу, потому что требования в нем живут рядом с работой, а не в отдельном хранилище.
Но RMS, включая Doorstop, управляют требованиями, которые уже сформулированы и помещены в систему. Моя идея в другом. Я предлагаю не создавать еще одно дублирующее хранилище документации, а собирать ТЗ из того, что и так происходит в задачах, переписке и согласованиях. Не нужно писать требование в RMS, оно уже есть в процессе, нужно только связать и показать.
Doorstop хранит требования в репозитории, а значит предполагает, что аналитик работает с гитом. Аналитики, в отличие от разработчиков, с гитом, как правило, не работают, и это не их зона ответственности. Иначе им пришлось бы освоить ветки, конфликты, merge, pull request, а это серьезные навыки, которые от аналитиков не требуются. Кроме того, в документации много нетекстовой информации (таблицы, диаграммы). Аналитик – не разработчик, и это нормально. Поэтому идея “документация как код (в git)” и не получила широкого распространения.
Моя идея несколько отличается от RMS. Плоская модель вместо дерева, а также извлечение из каналов вместо ручного ввода. Но главное даже не это. Не нужно дублировать задачи Jira в Confluence или Word. Требование живет в задаче, со связями, историей и согласованием. ТЗ становится выборкой таких задач, а не отдельным документом, который надо писать и поддерживать.
ToxaBes
Я вам перечислил аналоги только чтобы вы могли посмотреть и позаимствовать подходящие идеи чтобы улучшить ваше решение.
ilyxak
Освоить гит - дело пары недель.
Не стоит так строго разделять "зоны ответственности" (это, кстати, не совсем они. Это скилл в чистом виде) - чем ближе аналитик к разработке тем лучше для всех в конечном итоге. Так думаю.
Наши аналитики вполне справляются, кстати, и новые проекты ведут в гите.
mishenkovks
Дело не в гите а в том что
Пожелания должны быть связаны с требованиями
Требования с задачами
Задачами с тестированием
И когда заказчик говорит что надо поменять вот это пожелание сразу видно что править и что может сломать
FM12
как уже ранее писал - с т.з. создания именно модели требований - попробуйте Archimate / Archi.
В т.ч. вот неплохой в принципе пример использования в статье с Хабра:
https://habr.com/ru/companies/axenix/articles/1038916/