На днях прислали в рабочую почту очередное ТЗ в Word на разработку, для комментирования и оценки реализации. При том что у нас есть корпоративный Confluence — мощнейшая система, как раз предназначенная для коллективной работы.
Не мне Вам рассказывать, что сегодня формулировать мысли в Word, при наличии Confluence‑подобных систем — очередной злостный антипаттерн. Confluence прекрасно справляется с описанием ТЗ сразу на веб‑страницах и позволяет всем заинтересованным участникам откомментировать любой абзац или слово онлайн, сразу получая уведомления на ответы. Затем можно экспортировать эту страницу в Word, если требуется.
Но почему многие до сих пор продолжают изначально использовать Word как основу для обмена информацией?
В целом, это был риторический вопрос, я и так знаю почему. В корпоративной бюрократической среде, ТЗ — это юридический документ, который обычно требует подписания для дальнейшей передачи на исполнение. Это действительно правильное взаимодействие между участниками, в правовом поле, не спорю. Но это НЕ означает, что ТЗ должно быть сразу сформировано в Word.
Я не понаслышке знаю процесс управления требованиями, поэтому, любой абзац или пункт ТЗ — это полноценное самостоятельное требование (если вы до сих пор пишите «тонны» сплошного текста в документе, без разбиения на детальные отдельные пункты, на которые можно сослаться — срочно погуглите методологии формирования «правильных» ТЗ, без этих знаний вы делаете больно всем участникам).
Идеально, когда ТЗ на стороне заказчика, готовится совместно с будущим исполнителем (если конечно речь не про конкурс). Урегулируются все спорные моменты, через долгие обсуждения и переписку. И спустя время (недели, месяцы или даже годы), на выходе имеем готовый PDF документ, отправляемый исполнителю для выполнения работ.
Что делает исполнитель дальше? Превращает каждый абзац этого PDF документа в соответствующие задачи своего трекера (Jira или любой другой инструмент). В лучшем случае, ему скинули исходный формат, в худшем, нанимает человека‑робота, который руками перепишет все требования сканированного PDF в трекер.
Примерно такой процесс:
Заказчик формирует ТЗ в Word -> Согласование -> Подписание -> Передача исполнителю -> Исполнитель вручную декомпозирует требования в трекер
Но даже Confluence - это по сути тот же документ, только веб-версия. А что если пойти дальше? Смотрим:
Заказчик сразу декомпозирует требования в трекере -> Обсуждение и согласование прямо в трекере -> Выгрузка в Word -> Подписание -> Передача исполнителю
Вместо утомительного обмена Word или веб‑документами, сразу формируется список требований, в специально предназначенной для этого системе, которые онлайн обсуждаются всеми участниками в виде комментариев (с соответствующими уведомлениями). Затем каждому требованию можно выставить соответствующий статус (принято, отклонено, невыполнимо и так далее). И как только окончательный список требований будет утверждён всеми участниками, исполнитель или заказчик жмёт кнопку Сформировать ТЗ и оно отправляется всем на подпись для юридического закрепления договорённостей. Естественно, каждый пункт итогового PDF имеет соответствующий системный идентификатор трекера, для проверки консистентности. В результате исполнитель сразу получает готовый подробный список требований у себя в трекере, а заказчик получает «правильное» ТЗ. Ну и оба имеют на руках утверждённый подписанный вариант документа.
В случае с конкурсными процедурами — тут вопрос. Изначально неизвестно кто будет исполнителем. Где формировать требования, если у заказчика нет трекера? И что делать если трекер есть, но нет возможности реализовать кнопку Сформировать ТЗ? Неужели сейчас нет какого‑то стандарта для формирования требований в едином формате? С выгрузкой в Word и в формате, доступном для загрузки во «внешние» популярные трекеры исполнителей. Может какой‑то SaaS, в виде стандарта?
В случае обмена ТЗ внутри корпоративного контура я не вижу юридических поводов для беспокойства. Трекер доступен сразу всем участникам, главное предусмотреть «фриз» от изменений номера и текста требований итогового списка, после утверждения. Можно ничего не выгружать из системы и не подписывать даже. В современных ИТ компаниях наверно ровно так и делают. Правда же?
Я пробовал реализовать методологию формирования требований самим заказчиком в старом добром Redmine, с последующей выгрузкой в готовый корпоративный Word документ ещё в далёком 2018, но «не сложилось, не срослось». Как‑то это было слишком инновационно и все крутили у виска. Но вот на дворе 2026 год и все до сих пор «страдают Word‑ом».
Признавайтесь, кто смог реализовать методологию «сначала требования, потом Word»? С чем столкнулись? И имеет ли это вообще смысл?
Комментарии (17)
achekalin
03.04.2026 10:23у нас есть корпоративный Confluence
Во-первых, не все заказчики знают об этом, во-вторых, в корпоративном Confluence могут работать пользователи "корпорации", а вовсе не внешние люди. Третье и четвертое тоже понятно: отвратительный редактор и вообще нелюбовь многих работать в этой поделке. Пятое скажу за себя: мне конфлю регулярно удается загнать в режим, когда он говорит, что записать изменения не может (хотя успешно их подгружает как черновик при следующем входе в режим правки документа) - и это не на одной инсталляции.
Итого: ворд тоже не идеал, но как редактор он на рынке лучший, как формирователь документа - тоже хорош. При это именно документом (в таком, "бытовом-юридическом", смысле) страницу на wiki (в конфле) называть язык не поднимается.
ilemusic Автор
03.04.2026 10:23Но сам по себе итоговый вордовский файл, каким бы он не был красивым на выходе - не используется по прямому назначению. Он разбивается на требования, затем из них либо формируют задачи в трекере или в Excel, с ними и работают. А ТЗ лежит где-то там, скучает.
achekalin
03.04.2026 10:23Ну так все верно, только и не в конфле он лежит. Деловая переписка - всё же не wiki.
Другое дело, что есть форматы и получше. И это тоже не wiki.
Кстати, конфля мне вечно мозг выносит своим очень необычным пониманием вставки из буфера с форматированием, а уж чтобы она еще и .md форматирование соизволила осилить. "Стандарт индустриии"! Там точно одно - слово "индус" в этой фразе.
zartarn
03.04.2026 10:23Потому что он будет именно документом с подписями и подшит к договору. А как с информацией из него уже будут работать дальше - это отдельная история.
GreyPhantom
03.04.2026 10:23многие до сих пор продолжают изначально использовать Word как основу для обмена информацией?
Да потому что "всегда так делали"... Не знаю как у Вас, а у нас текстовая заметка в Excel, таблица- в Word, и скриншот выборки из 1C- едва ли не норма... Когда владеют одним-двумя инструментами (и то на уровне "чтобы открыть файл- ткни сюда, сохранить- вот сюда")- заставить хотя бы попробовать что-то еще- практически невозможно, разве что через "боль "( когда просто не остается вариантов )
ilemusic Автор
03.04.2026 10:23Да всё ровно также и у нас. Я смог только пару человек "заразить конфлюеносм", остальные ну никак не идут туда. Ещё подсадил парочку на drawio (у нас он встроен в конфлюенс) вместо Visio. Вот и хотел послушать как другие живут, особенно "настоящие" современные ит компании.
gev
03.04.2026 10:23Да, хотя бы PDF :)
HardWrMan
03.04.2026 10:23Причём, их обоих (и doc/docx, и pdf) можно подписать. Иногда это решает.
ilemusic Автор
03.04.2026 10:23Видимо никто до конца не прочитал... :)
Я не предлагаю отказаться от Word и PDF, я рассматриваю замену процесса, когда вместо изначального составления текста в Word, требования формируются в какой-то веб-системе и обсуждаются там. И только потом из них формируется ИТОГОВЫЙ Word/PDF, который рассылается всем участникам на подпись.
Иначе, нельзя подписать то, что ещё не согласовано. Открываете ворд или пдф, а внутри написано - "нарисовать 7 красных линий, 2 из которых зелёные...". Ваши действия? Режим рецензирования? Или скриншотами в почту? Или цитатами? А если в переписке 15 участников? Чувствуете проблему?
HardWrMan
03.04.2026 10:23Открываете ворд или пдф, а внутри написано - "нарисовать 7 красных линий, 2 из которых зелёные...".
Но ведь Ворд это и есть самый крутой графический редактор! (С) шутки из 00х.
vmkazakoff
03.04.2026 10:23Вместо одной проприетарной системы артефакта которой можно, хотя бы, открыть ещё где-то (опенофис) вы предлагаете другую, которая наше и прибита гвоздями к серверу или вообще облаку??? Спасибо хоть не гуглдок. В реальности - ТЗ это текст, иногда схемы, иногда таблицы. С этим всем работает маркдаун. Который можно открыть примерно везде, даже если у вас только ssh доступ к консоли сервера на котором лежит файл, и то через vim получится прочитать.
Потом можно хоть куда конвертировать и как угодно распечатать. Подписать тоже можно без проблем.
Но конфлбенс? После такого количества прививок от облаков? Не понимаю.
ilemusic Автор
03.04.2026 10:23Я слышал, что в некоторых "команадах" действительно пишут тз в .md формате и хранят его в гитхабе. Для внесния изменений используют PR, и комментируют там же. Я так понял у вас ровно такая схема? Удобно? А заказчик тоже вносит изменения через PR?
Ни разу не пробовал, для меня наверно такой подход приемлем, но вот другие точно воспримут "в штыки", с учётом что даже конфлюенс "слишком сложен".
И md не убирает шаг, когда его всё равно будут конвертировать в список задач в трекере, на стороне исполнителя...
vmkazakoff
03.04.2026 10:23Удобно. Честно - очень. Код, требования, описание задач - все рядом. Ещё и версионируется. Декомпозиция тоже там, в отдельных файлах.
Отдельный бонус, опционально, ИИ очень хорошо подключается в режиме "вот файл требований, декомпозируй" или "вот декомпозиция, проверь логику найди проблемы и риски" и потом "вот подробное описание, действуй".
Но и без ИИ - хранение всех файлов в гит - это лучшее что может быть.
vmkazakoff
03.04.2026 10:23А. Ну и для людей которым не привычно - маркдаун примерно за нулевые усилия можно превратить в читабельный сайт с навигацией, кросс-сылками и всем остальным. Для тех кому не удобно редактировать в vim есть всякие редакторы типа обсидиан. Короче на самом деле это очень удобно, если капельку озадачиться и подготовить пространство. Ну мы же себе окружение для кодинга настраиваем, Дак почему бы для "документинга" этого не сделать?)
mrGroshev
03.04.2026 10:23Поддерживаю такой подход. Сколько времени теряется на то, чтобы перекидывать файл по почте, хранить мастер-версии, комментарии и т.д. Кроме того, в компаниях типа ГК, по методологии управления проектами рождаются ФТТ, потом ТЗ, потом ПР, а потом уже задачи в Jira (или аналогах). Всё это согласуется в системе документооборота, в которую вставляется файл Word — даже не текст. А если формируются замечания, то прикладывается ещё ексель с реестром учёта замечаний и версиями. Не забываем хранить все версии документов в специальной папке — вдруг придётся откатиться назад на n-м круге замечаний. Итог — 6 месяцев на согласование всего этого "добра" . И вишенка на торте: когда идёт подписание документов главным заказчиком или ЛПР, нужно подготовить слайды с образом результата и теми же задачами, и сходить пару раз «на поклон». Интересно, можно ли сломать привычные подходы в корпорациях?! Как вариант, первым шагом можно включать в курс "основы цифровой грамотности" при обучении топ- руководителей.
OlegZH
Было бы здорово все делать по уму, как Вы и пред(по)лагаете. Но Вам присылают файл, потому как файл — это реальный объект, который у Вас в руках, а система может накрыться медным тазом. РКН ввёл какое-то новое ограничение, и у Вас система "отвалилась" (например).
ilemusic Автор
Согласен. Сегодня это серъёзный аргумент. Можно тогда чуть модифицировать вывод: пришлите мне ссылку и файл :) Файл я сохраню, а комментировать буду по ссылке, если конечно она откроется...