На днях прислали в рабочую почту очередное ТЗ в 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»? С чем столкнулись? И имеет ли это вообще смысл?
