Все любят истории о сильных личностях. Про Туполева, Королёва, Стива Джобса, Сергея Брина, Марка Цукерберга. Про Нила Армстронга, который сделал «один маленький шаг для человека — и гигантский скачок для человечества». Про Юрия Гагарина, который первым полетел в космос.
Но и Луна, и космос покорялись не одиночкам. За этими шагами стояли инженеры, конструкторы, испытатели, техники, врачи, военные, диспетчеры — тысячи людей, чьих имён не было в главном заголовке.
Мы любим персонализировать успех и персонализировать вину. Но сложные системы, как и полёты в космос, не строятся одним человеком — и не рушатся из-за одного человека тоже.
В IT всё точно так же. Особенно когда речь заходит о «плохом ТЗ». Обычно разговор строится по простой схеме: аналитик плохо написал, разработчик пострадал, проект поехал вправо. Иногда наоборот — говорят, что ТЗ было нормальным, просто разработчик не задал правильные вопросы. В итоге спор снова сводится к поиску одного виноватого.
Но плохое ТЗ почти никогда не появляется в одиночку. Если оно попало в работу, прошло обсуждение, ревью, декомпозицию и ушло в разработку, значит это уже не история про один неудачный документ. Это история про процесс, в котором команда слишком поздно проверила общее понимание.
Потому что плохое ТЗ — это не просто слабый документ. Это след команды, которая где-то не договорилась, не уточнила, не поставила под сомнение, не остановилась вовремя и не задала себе главный вопрос: мы точно понимаем, что строим?
Где обычно ломается понимание
Проблема редко рождается в одной фразе. Обычно она проходит несколько этапов и на каждом становится чуть менее заметной.
Сначала бизнес описывает ожидание на языке результата:
«нужно быстрее заводить B2B-клиентов», «нужно автоматизировать онбординг», «нужно согласование условий и лимитов», «нужно передавать данные в ERP и биллинг».
Для бизнеса это понятные слова, потому что за ними стоит контекст: кто участвует в процессе, какие исключения бывают, какие решения уже приняты внутри компании, какие ограничения существуют в продажах, финансах, юридическом блоке и операционных системах.
Потом аналитик переводит это в требования. И здесь легко появляется первая потеря смысла. Часть контекста кажется очевидной, часть не проговаривается, часть формулируется слишком общо. Фраза «менеджер создаёт заявку на онбордингB2B-клиента» выглядит простой, пока не начинаешь разбирать, кто именно может её создать, что делать с дублем по ИНН, какие документы обязательны, кто видит кредитный лимит, можно ли менять коммерческие условия после согласования финансов, как хранить версии договора и что происходит, если ERP недоступна в момент активации клиента.
Затем требования уходят на ревью. Но если ревью превращается в чтение текста по диагонали, команда проверяет не будущую систему, а грамотность документа. Все вроде бы согласны, потому что в тексте нет явной ошибки. Но поведение системы всё ещё никто не прожил.
После этого разработчик начинает писать код — и именно код становится первой настоящей проверкой требований. В этот момент внезапно выясняется, что не хватает статусов заявки на онбординг, не описаны роли согласующих, непонятны правила изменения коммерческих условий, нет модели договора и пакета документов, не определены события интеграции с CRM, ERP и биллингом, не описаны ошибки, повторные попытки отправки запросов, аудит и поведение системы при частично выполненном процессе.
Самая опасная часть в том, что каждый участник команды может быть по-своему прав. Продажи думают о скорости подключения клиента. Финансы — о рисках и лимитах. Юристы — о версиях договора.
Разработка — о состояниях, транзакциях и интеграциях.
Так сложный B2B-процесс превращается в дорогую игру в угадайку. Не потому что кто-то специально сделал плохо, а потому что команда слишком поздно проверила общее понимание.
Практический разбор: от размытой заявки к общей модели
Компания продаёт B2B-клиентам продукт на индивидуальных условиях. Для каждого крупного клиента нужно провести онбординг, проверить контрагента, собрать документы, согласовать коммерческие условия, рассчитать кредитный лимит, подготовить договор, передать данные в ERP и биллинг, а потом открыть клиенту возможность делать заказы.
На первом обсуждении это часто звучит компактно: менеджер заводит клиента, система запускает согласования, после финального одобрения формируется договор и клиент становится активным. В ТЗ такую задачу легко записать одним абзацем: «реализовать процесс согласования B2B-клиента и коммерческих условий». Документ будет выглядеть солидно, но именно здесь обычно и рождается плохое ТЗ.
Проблемы начинаются не в коде, а в невидимых развилках. Кто может создать заявку: только менеджер, руководитель отдела продаж или партнёр через внешний портал? Что делать, если клиент с таким ИНН уже есть в CRM? Можно ли менять коммерческие условия после того, как их согласовала финансовая служба? Что важнее: решение риск-службы или ручное согласование директора? Должны ли юристы видеть кредитный лимит? Может ли согласование идти параллельно или только последовательно? Что делать, если ERP недоступна в момент финального одобрения?
Для продаж это один процесс: «быстро завести клиента». Для финансов — другой: «не открыть лимит без проверок». Для юристов — третий: «не потерять версию договора и основания согласования». Для разработки — четвёртый: «нужна модель состояний, права, транзакции, интеграции, ошибки и аудит». Если всё это не проговорить заранее, каждый участник будет считать свою картину очевидной.
На уровне текста такую неопределённость можно спрятать за фразой «реализовать согласование клиента». На уровне системы спрятать уже не получится. Появятся сущности: клиент, контрагент, заявка на онбординг, пакет документов, коммерческие условия, кредитный лимит, маршрут согласования, задача согласующего, решение, комментарий, версия договора, событие интеграции, уведомление, запись аудита. Появятся статусы: черновик, на проверке, на согласовании, возвращено на доработку, отклонено, одобрено, отправлено в ERP, ошибка интеграции, активировано. Появятся правила переходов, исключения и ответственность за каждое действие.
Вот здесь команда и должна остановиться не после начала разработки, а раньше. Хорошая практика — превратить размытую постановку в проверяемую модель будущей системы и прогнать через неё реальные сценарии бизнеса. Важно: это не личная лаборатория аналитика и не демонстрация «как AIнаписал систему». Это способ собрать вокруг одной модели бизнес, аналитику, разработку, тестирование и владельцев процесса.
Мы использовали Claude Code именно в этой роли: как инструмент, который помогает быстрее материализовать модель и сделать её предметом командного обсуждения. Главным героем остаётся не AI, а совместная проверка понимания. Инструмент только сокращает путь от разговора до работающего черновика, на котором уже видно, где требования расходятся с реальным поведением системы.
Смысл был не в том, чтобы аналитик внезапно стал разработчиком и начал писать production-код. Смысл был в другом: через рабочую модель мы раньше вынесли наружу скрытые противоречия требований и смогли обсуждать с заказчиком не абстрактный документ, а поведение будущей системы.
Мы сократили процесс до нескольких командных шагов.
Этап 1. Собрали общую картину процесса. Мы не начинали с просьбы «сделай сервис согласования». Сначала описали цель системы, участников процесса, роли, внешние системы, ограничения, основной бизнес-сценарий, известные исключения и границы первой версии. На этом шаге важно было не получить код, а договориться о языке: что такое клиент, заявка, лимит, договор, согласование, активация, ошибка интеграции.
Этап 2. Разложили ответственность между участниками. Мы отдельно проговорили, что в процессе важно для продаж, финансов, юристов, разработки, тестирования и эксплуатации. Продажи проверяли скорость и удобство сценария. Финансы — правила лимитов и рисков. Юристы — версии договора и основания решений. Разработка — статусы, транзакции, API и интеграции. Тестирование — исключения, ошибки, отмены, дубли и частично выполненные операции.
Этап 3. Построили проверочную модель. Через Claude Code собрали черновой backend-проект: предметные сущности, статусы, Pydantic-схемы, API-роуты, тестовые данные, mock-интеграции с CRM, ERP и биллингом, простую OpenAPI-документацию. Это была не production-разработка, а способ сделать требования видимыми. Когда есть модель данных, состояния и API, общие слова быстро превращаются в конкретные вопросы.
Этап 4. Провели командный прогон сценариев. На модели прошли не только «счастливый путь», но и спорные ситуации: дубль клиента по ИНН, возврат документов на доработку, отказ юриста, изменение скидки после согласования финансов, недоступность ERP, повторная отправка запроса, изменение лимита, просмотр audit trail. Именно здесь стало видно, какие требования конфликтуют между собой и какие решения надо принять до разработки.
Этап 5. Зафиксировали решения в ТЗ. После обсуждения мы обновили статусную модель, DTO, валидации, события интеграций, правила аудита и критерии приёмки. В документ попала не первая догадка аналитика, а результат командной проверки: глоссарий, роли, матрица прав, жизненный цикл заявки, сценарии и исключения, модель данных, API-контракты, интеграции, требования к аудиту и список открытых вопросов.
Такой формат меняет роль инструмента. Claude Code или похожий агентный сервис не заменяет аналитика, разработчика или ревью требований. Он помогает быстрее создать общий объект обсуждения. Команда перестаёт спорить только о формулировках и начинает проверять поведение: что происходит при отказе, кто видит данные, какое событие уходит во внешнюю систему, как восстанавливается процесс после ошибки.
Главная ценность такого подхода не в том, что кто-то быстро поднял черновой backend. Ценность в том, что команда раньше видит противоречия. Не тогда, когда разработчик уже написал половину логики, а тогда, когда изменить статус, поле, правило или интеграционный сценарий ещё дёшево.
Что меняется для команды
Такой подход полезен не только аналитику, потому что фокус остаётся не на инструменте, а на качестве общего понимания.
Бизнес получает не длинный документ, который сложно представить в работе, а модель процесса: вот заявка, вот проверка контрагента, вот согласование скидки, вот ошибка ERP, вот возврат на доработку. Заказчику проще спорить с конкретным поведением системы, чем с абзацем текста.
Разработчик получает ТЗ, в котором уже есть след предварительного проектирования: сущности, связи, статусы, ограничения, примеры входных и выходных данных, API-контракты и договорённости по интеграциям. Это не отменяет технического проектирования, но снимает часть неопределённости, которая обычно прилетает в разработку под видом «разберёмся по ходу».
Тестировщик подключается раньше и видит не только основной сценарий, но и исключения: отказ, дубль, отмену, повторную отправку, недоступность внешней системы, изменение данных после согласования. Это превращает ревью требований в подготовку будущих тест-кейсов, а не в формальное чтение документа.
Аналитик перестаёт быть человеком, который просто переносит слова бизнеса в файл. Он становится модератором общей модели: собирает разные картины процесса, показывает противоречия, фиксирует решения и помогает команде договориться о том, как система должна вести себя в реальности.
Важно, что речь не о конкретном стеке. В веб-разработке мы говорим про классы, DTO, API, таблицы, миграции и сервисы. В 1С это могут быть справочники, документы, регистры сведений, регистры накопления, обработки и роли. В мобильной разработке — экраны, состояния, локальное хранилище, синхронизация, offline-режим. Названия разные, но мышление одно: данные, связи, действия, ограничения, состояния и последствия.
Когда команда проходит этот путь до полноценной разработки, она меньше перекладывает неопределённость на следующий этап. Бизнес точнее формулирует ожидания. Аналитик видит системные разрывы. Разработчик заранее подсвечивает реализуемость. Тестировщик вытаскивает исключения. В итоге ТЗ становится не личным документом аналитика, а результатом совместной проверки будущей системы.
Практические принципы, которые помогают не производить плохое ТЗ
Первый принцип — проверять не только текст, но и поведение. Требование должно отвечать не только на вопрос «что должно быть», но и на вопрос «что система делает в конкретной ситуации».
Второй принцип — делать ревью требований командной процедурой. На ревью должны звучать разные вопросы: бизнесовые, технические, тестовые, интеграционные, юридические, эксплуатационные. Если документ прочитал только аналитик и один согласующий, это ещё не проверка общего понимания.
Третий принцип — разбирать сценарии вместе с исключениями. Основной путь почти всегда понятен. Настоящая сложность живёт в отказах, дублях, правах доступа, изменении статусов, отменах, сроках, ошибках и интеграциях.
Четвёртый принцип — раньше строить модель данных и состояний. Даже простая схема сущностей, статусов и переходов часто быстрее вскрывает противоречия, чем длинное обсуждение формулировок.
Пятый принцип — показывать заказчику не только документ, но и модель будущей системы. Это может быть прототип, схема, кликабельный макет, таблица состояний, диаграмма или черновой сервис, собранный с помощью Claude Code или похожего агентного инструмента. Важно не то, каким инструментом собрана модель, а то, что команда проверяет её поведение до разработки.
Шестой принцип — фиксировать решения и открытые вопросы явно. Если команда чего-то не знает, это не должно исчезать в воздухе. Лучше честный список неопределённостей, чем уверенный документ с замаскированными дырами.
Плохое ТЗ — это не приговор аналитику и не повод снова устраивать вечный спор между аналитиками, разработчиками и тестировщиками. Чаще это сигнал, что команда слишком поздно проверила общее понимание.
Хорошее ТЗ появляется там, где требования не только записывают, но и проживают. Где бизнес видит модель будущей системы до разработки. Где аналитик думает не только словами, но и сущностями, связями, статусами, DTO, базой данных, API, ограничениями и ошибками. Где разработчик и тестировщик подключаются не в момент, когда «всё уже согласовано», а тогда, когда ещё можно недорого поправить понимание.
«Один маленький шаг для человека — и гигантский скачок для человечества» звучит как фраза одного героя. Но за такими шагами всегда стоит команда
В IT, возможно, один из таких маленьких шагов — перестать относиться к ТЗ как к документу, который один человек передаёт другому. И начать относиться к нему как к результату совместной проверки будущей системы.
Инструменты вроде Claude Code могут помочь сделать эту проверку быстрее: собрать черновую модель, показать её заказчику, прогнать сложные сценарии и раньше найти противоречия. Но они не заменяют системный анализ и командную работу. Они просто дают команде возможность раньше увидеть то, что раньше всплывало слишком поздно.
И в этом, кажется, главный смысл. Не «AI пишет ТЗ», а команда раньше договаривается о том, что именно она строит. Для процесса это может выглядеть как небольшой сдвиг. Но для качества разработки — вполне может оказаться большим шагом вперёд.
Этот материал — не про то, что аналитик должен заменить разработчика, а про то, что требования должны перестать жить только в тексте. Когда команда раньше видит будущую систему, спорит не о формулировках, а о поведении, ролях, данных и исключениях — ТЗ становится не передачей ответственности, а результатом общего понимания. Над материалом работали: ведущий специалист Ильнур Садиков, младший специалист Энгель Адылев и старший специалист Айдан Казиханов.
ссылка на оригинал статьи https://habr.com/ru/articles/1048160/