“Давайте заведём AI-агента, который будет помогать писать business requirements. Это же быстрее, дешевле и логично.”
Дальше началась обычная работа:
— Собрали первый вариант.
— Протестировали.
— Получили выход агента.
Посмотрели — “ну, в целом неплохо, но не то”.
— Запустили ещё раз.
Потом ещё.
Через какое-то время в команде начинают звучать знакомые фразы:
“нужно ещё чуть точнее сформулировать”
“видимо, модель слабовата”
“надо просто ещё пару итераций”
“ну, мы же в новом процессе, нормально, что не сразу”
Cнаружи всё выглядит как освоение нового инструмента. А по факту команда уже попала в ловушку: решение было принято до того, как его проверили:
1. Не был задан критерий “что считается хорошим результатом”.
Не в смысле общего “чтобы требования были качественными”, а в смысле минимально проверяемого:
— по каким признакам мы понимаем, что результат годится?
— где граница между “сырой, но полезный черновик” и “текст, который потом разрушит работу дальше по цепочке”?
2. Не был обсужден способ реализации.
То есть никто не ответил на вопрос: мы вообще каким способом решаем эту задачу?
Мы делаем:
— черновик для ускорения?
— полноценную замену части работы product manager?
— интерфейс между PM и командой?
Не были собраны варианты.
Вместо этого почти всегда берут один, самый очевидный ход.
“Пусть агент пишет BRD”
А потом долго допиливают его, как будто проблема в качестве исполнения.
🚫И этого хватает, чтобы команда уже пошла в ложный способ решения.
Как это выглядит в жизни через неделю?
Команда чувствует не ускорение, а странную вязкость. Вроде бы работы стало больше. Результатов — не особенно.
🚫Product manager раздражён, потому что теперь вместо “написать самому” он:
— перечитывает длинные, криво акцентированные тексты,
правит смысл,
— вычищает двусмысленности.
🚫Руководитель раздражён, потому что вместо обещанной скорости команда начинает:
— дольше согласовывать,
— чаще уточнять,
— больше переделывать.
Вместо — "какие есть варианты, как мы проверяем до запуска и подходит ли вообще это решение?"
❤Опыт даёт только первый ход. Дальше его нужно уметь проверять.
И именно здесь начинается новая развилка по квалификации: один человек продолжает “пробовать и подкручивать”, другой начинает проверять решение до запуска.
И через полгода между ними уже не просто разница в стиле работы. Там разница в уровне.
Это инженерная работа с решением.
Подключайтесь в чат участников семинара, забирайте чек-лист безошибочной работы или сразу оплачивайте, чтобы не пропустить его разбор online с наставником МИМ на семинаре 05 апреля, 11:30: @SystemsSchool_bot (→ Меню → Оплатить резидентуру / практикум / семинар → Семинар. Как перестать переделывать и начать управлять результатом в работе: через критерии, варианты и AI → Ссылка на чат)