Практика системного аналитика
Между постановкой и влитым merge request нет ни одной точки, где кто-то обязан сверить одно с другим. Контур разомкнут — и расхождение копится молча.
Проблема
Постановка и реализация расходятся всегда. Не потому, что кто-то плохо работает, а потому, что это разные тексты, написанные разными людьми в разное время, и никто не обязан регулярно сверять один с другим.
Требование живёт в спецификации, задача — в трекере, реализация — в коде, следствия — в схеме данных. Чтобы увидеть противоречие, надо держать всё это открытым одновременно и делать это регулярно. Вручную так не работает никто: слишком дорого по времени, чтобы делать постоянно, и слишком поздно, когда наконец делаешь.
Сплошным — то, что работает и обкатано на реальном проекте. Пунктиром — замыкание контура: запуск сверки по закрытым за неделю задачам и возврат расхождения автору постановки. Это то, что предлагается собрать и померить в пилоте.
Звено 1 — производство
Работает, обкатано
Процесс разложен на роли, каждая со своей зоной ответственности и своими критериями. Смысл разделения в том, что типовые замечания архитектора и лида аналитики ловятся раньше согласования. Один проход модели по всему сразу этого не даёт — он даёт средний по больнице текст без явных провалов и без явной глубины.
Звено 2 — сверка
Работает, измерено
Не чат-бот, который пишет текст, а связка коннекторов с правилами: что читать, в каком порядке, что считать расхождением, что показать человеку и в какой момент остановиться и спросить.
На одном сервисе в проекте крупного заказчика:
Сверка запускалась человеком по решению — то есть ровно тогда, когда кто-то заподозрил неладное. Ценность есть, но она разовая: между заходами контур снова разомкнут.
Звено 3 — замыкание
Предлагается собрать в пилоте
Плейбук с еженедельным запуском: берутся задачи, закрытые с прошлого прогона, по ним поднимаются требования, из которых эти задачи выросли, и сверяются с тем, что реально влито. Сверяется не вся документация, а только затронутая — поэтому процедура остаётся дешёвой и может со временем стать ежедневной.
Как это устроено
Модель подключается не к чату, а к рабочему контуру: читает те же системы, что и аналитик, но все сразу.
| Источник | Что даёт |
|---|---|
| Confluence, Jira | Спецификации, задачи, история версий и диффы страниц, поиск по CQL и JQL |
| Git | Исходники, конфиги, ветки и merge request — сверка постановки с тем, что написано |
| PostgreSQL | Структура схемы: таблицы, типы, ключи, ограничения |
| HTTP к API | Вызов метода на стенде: контракт из спецификации против фактического поведения |
| Figma | Макеты, структура фреймов, токены — вход для UI-спецификаций |
| Браузерный агент | Системы, у которых нет API |
Подключение к базе ограничено структурой. Содержимое строк методу не нужно ни на одной стадии: сверка работает со схемой, а не с данными. Это не осторожность, а свойство задачи — и оно снимает половину вопросов на входе.
Ничего не записывается без подтверждения: сначала план, что и куда будет записано, затем подтверждение человеком, затем запись одним батчем. Модель уверенно ошибается в доменных деталях, и цена такой ошибки в постановке выше, чем экономия от автоматической записи. Ответственность за результат остаётся на аналитике.
Границы
Что я предлагаю
Настройка контура под конкретный стек. Регламент и плейбук в письменном виде. Разбор двух-трёх реальных задач вместе с аналитиками. Три-четыре еженедельных прогона с замером.
На выходе — процесс, который живёт без меня, и цифры, по которым принимается решение о масштабировании.