Согласование только выглядит как разговор. На самом деле это алгоритм диспетчеризации трафика между людьми: есть список открытых вопросов, есть список адресатов, есть правило, кому какой вопрос направить, и есть момент, когда всё сошлось. Человек делает эту работу давно и плохо — просто раньше её некому было отдать. Дальше — конструкция из нескольких агентов, которая гоняет согласование по проекту без вас.
Какие потери закрывает контур согласования
Вспомните, где ваш проект простоял последний месяц. Скорее всего, не в редакторе кода. Он простоял в переписке: три человека понимают scope по-разному, четвёртый не отвечает, а пятый уверен, что вопрос закрыли на созвоне в апреле. Пока согласование остаётся неформальным жанром, платите вы за него в нескольких местах сразу.
Уточнения живут в мессенджерах. Вась спросил, Вась ответил, оба довольны, в системе учёта ноль следов. Меняется исполнитель — контекст испаряется целиком, потому что он никогда и не был зафиксирован: лежал в чьей-то ленте сообщений между мемом и стикером.
Дальше — матричная структура. Формально решение принимают все, фактически не принимает никто. Каждый искренне считает, что уже высказался, и ждёт, что кто-то другой соберёт эти высказывания в решение. Собирает обычно тот, кому больше всех надо. Часто это вы.
И молчание. ЛПР не отвечает неделями, срок горит, инструмента давления нет — не будешь же долбить директора по производству каждое утро в личку. Тут и начинается самое дорогое: всю картину разночтений держите в голове вы, потому что больше её никто не держит. Вы становитесь единственной точкой отказа проекта, а ваша квалификация уходит на роль ходячей CRM для чужих мнений.
Что нужно приготовить на входе
Прежде чем ставить агента, разложите согласование на детали, которыми он будет оперировать.
Проектная информация. Постановки, спеки, договорённости, ограничения — всё, что уже зафиксировано. Это базовая «библия» проекта, из которой агент будет черпать контекст.
Пробелы трёх сортов. Чего не хватает, что сделано наполовину и что противоречит другому куску той же документации. Разночтение — самый вредный сорт. Оно не выглядит как дырка, оно выглядит как готовый текст, под которым две стороны понимают разное.
Люди. Они не равнозначны. У каждого своя позиция в оргструктуре, свой круг вопросов, по которым он вообще имеет право отвечать, и свой стиль разговора. С одним — официальное письмо на «вы». С другим — сообщение в мессенджер на «ты» и по делу.
Каналы. Почта, звонок, переписка, голосовые. Их обычно и считают препятствием для автоматизации. Хотя каналы — это транспорт, и от логики согласования они отделяются полностью.
Архитектура: один агент ищет дыры, второй долбит людей
Ставите агента, которому даёте три инструмента: проектную информацию, перечень вопросов и роутер-классификатор — кому какие вопросы можно задавать, с указанием позиции в оргструктуре и шаблончиком психопрофиля.
Шаг 1. Вычёсывание пробелов
Агент стартует и сканирует проект на пробелы, недоработки и разночтения. Каждое фиксирует как open_question — не «заметку в чате», не «надо бы уточнить», а запись с идентификатором, которую можно посчитать. У согласования появилось число, которое либо ноль, либо не ноль.
Шаг 2. Роутинг вопросов
Второй агент долбит адресатов. По почте: «Здравствуйте, Иван Иванович, нужно ваше решение по вопросу X до пятницы, иначе блокируется задача Y». В телегу: «Вась, привет, чё вот тут за ерунда написана, разъясни?» Смысл вопроса один, но канал, тон и степень формальности выбираются по адресату — роутер знает и позицию, и психопрофиль.
Шаг 3. Дозировка
Можно задавать по одному вопросу, можно кучей — это ручка, которую крутят под конкретного человека. Ответы принимаются письмами, текстом, голосовыми: каналы коммуникации абстрагированы от агента, ему всё равно, в каком виде пришёл смысл.
Шаг 4. Обработка очереди
Ответы встают в очередь на обработку, и агент их разбирает:
| Ситуация | Действие агента |
|---|---|
| Ответ однозначен | close_question, фиксация, внесение изменений в проект |
| Ответ противоречит ранее зафиксированному | Резолв по старшинству в оргструктуре |
| Ответ не укладывается в память проекта | reopen_question, адресация интересантам заново |
Шаг 5. Критерии выхода
Выхода из этой мясорубки два: счётчик открытых вопросов спустился к нулю либо агент упёрся в критическое противоречие и эскалирует на человека. Не «мы вроде всё обсудили» — счётчик.
Где эта штука ломается
Ниже — основные режимы отказа такого контура.
Спам вопросами. Вывалите на человека всё, что нашёл агент, — он вас проигнорирует, и правильно сделает. Пробелы надо приоритизировать, а количество вопросов за раунд ограничивать настройкой, а не энтузиазмом.
Универсальные вопросы. Без управляемого контекста проекта агент спрашивает вообще-обо-всём, и адресат так же абстрактно отвечает. Лечится слоями контекста: базовая «библия» проекта, корпус документов, граф связанных задач — из них под каждый вопрос собирается контекст-пак. Generic-режим годится как осознанный запасной вариант, но не как поведение по умолчанию.
Молчание. Адресат не отвечает — известный отказ контура, а не форс-мажор. Бесконечный вежливый пинг не помогает; помогает правило: N раундов, потом эскалация на владельца продукта и блокировка движения дальше.
Жаргон. Агент, пишущий заказчику на языке спеки, закончит диалог на первом письме. Наружу — бизнес-язык. Ссылки на источники («библия», раздел NFR, номер соседней задачи) уходят во внутренний лог для аудита, а не в тело сообщения человеку.
Расхождение источников правды. Спека говорит одно, вики — другое. Выбирать «который поновее» автоматически нельзя: приоритет источника задаётся явно, а само расхождение — повод для эскалации, не для тихого решения агентом.
Оговорка про статус сборки
Машину согласования стейкхолдеров целиком я описываю как архитектурный замысел, а не как работающий у клиента прод. Собран он при этом не из воздуха — соседние контуры у меня уже сделаны руками. Clarify gate в Jira: агент находит пробелы, задаёт вопросы по осям, держит лимит раундов и не пускает задачу дальше без внятных критериев приёмки; код лежит открытым. И стенд, где агенты двух независимых организаций согласуют интеграционную спеку между собой, без людей в цикле обсуждения, — тоже открытый репозиторий, с транскриптом переговоров и получившимся контрактом. Эксперимент я намеренно остановил на полпути, это PoC, а не продукт. Каждый кусок механики проверен отдельно. Не хватает сборки в одну машину.
«Иван Иванычи с ботами разговаривать не будут»
Возражение звучит примерно так: не будут ваши Иван Иванычи общаться с агентами, с ними надо в баньке лично париться, оффлайн, под водочку, вот там и согласовывается.
У меня на это два ответа.
Первый — технический. Роутер направляет вопрос в удобный получателю канал: кому письмо, кому звонок, кому сообщение в мессенджере, кому голосовое. С нужным тоном, нужной дистанцией, формулировкой под конкретного человека. Как общение с ботом это не читается — читается как внимательный коллега, который спрашивает по существу и не по десять раз. Сопротивление вызывает ведь не машина, а неуместность: сухой корпоративный текст там, где ждали человеческого, и панибратство там, где ждали формы. Для этого роутер и нужен.
Второй ответ — неудобный. Париться в бане с голопузым заказчиком или запрограммировать ему агентов — ваш личный выбор. Работают оба варианта, у обоих своя цена: один платится вашим временем, здоровьем и выходными, второй — инженерной работой, которую делаешь один раз и переиспользуешь на следующем проекте. Выбирайте осознанно. А если вы этот выбор уже просрали и у вас нет ни бани, ни агентов — мне тут нечем помочь.
Личные отношения со стейкхолдерами не заменяют процесс согласования. Они его проталкивают там, где процесса нет. Когда процесс есть, отношения перестают быть несущей конструкцией — и становятся тем, чем должны быть.
Измеримые эффекты на проекте
Согласование становится измеримым: не «мы в стадии уточнений», а счётчик открытых вопросов, скорость их закрытия и список тех, кто держит очередь. Эти метрики можно вынести в статус-репорт и использовать при пересчёте сроков.
Вы перестаёте быть единственным носителем разночтений. Всё, что жило у вас в голове и в трёх чатах, лежит в системе — с идентификаторами, ответами и авторством. Смена исполнителя перестаёт быть катастрофой.
Схема тянет многосторонние истории. В Askona согласование множества владельцев и контрактов было отдельным слоем работы, и результат мерился снижением количества ручных согласований на каждое изменение. Там же мы собирали демостенд с агентами заказчика и подрядчика, согласующими интеграционную спецификацию между собой. Когда сторон больше двух, ручное согласование растёт по числу пар — и человеческая пропускная способность кончается раньше, чем проект.
Эскалация получает полный контекст. Агент упирается в критическое противоречие и передаёт его человеку с полным контекстом: вот вопрос, вот два несовместимых ответа, вот кто их дал. Человек тратит время на решение, а не на выяснение, кто что имел в виду.
Согласование можно описать как маршрутизацию вопросов и решений
Узкое место большинства проектов — не разработка, а сведение людей в одну точку. Работа эта устроена как машина: пробел, вопрос, адресат, канал, ответ, конфликт, эскалация, счётчик. Если процесс раньше держался на личных договорённостях, это не значит, что его нельзя формализовать.
Личные связи никуда не денутся, они полезны. Но когда за согласование отвечает контур, а не ваша память и ваша печень, освобождается время на проектные решения — вместо работы телефонной станцией между людьми, которые не разговаривают друг с другом.