Как разобрать новую хотелку клиента в Codex
Новая просьба клиента часто выглядит безобидно: "а можно еще вот это?", "давайте добавим маленькую кнопку", "поменяем логику совсем чуть-чуть", "это же быстро". Проблема в том, что маленькая фраза может менять сроки, стоимость, структуру продукта, обязательства перед другими людьми и ожидания клиента.
Codex в такой ситуации не должен быть кнопкой "согласиться и сделать". Его полезнее поставить перед решением: дать ему просьбу клиента, текущий договоренный объем, сроки, список уже обещанного и попросить карту влияния. Тогда владелец проекта видит не только желание клиента, но и цену изменения.
В источниках по внедрению ИИ постоянно повторяется одна и та же мысль: проблема часто не в модели, а в культуре и процессе. Для маленькой команды это звучит проще: если каждую хотелку принимать на эмоциях, никакой агент не спасет. Codex нужен, чтобы перед согласием появилась проверяемая пауза.
Не отвечать сразу
Самый опасный ответ на новую просьбу - быстрый оптимизм. "Да, сделаем" приятно написать, но потом это становится обязательством. Перед ответом лучше попросить Codex разложить просьбу на последствия.
Главное:Новую хотелку клиента нужно сначала превратить в карту влияния. Codex собирает затронутые части, риски, вопросы и варианты ответа, но решение о согласии, сроках и цене остается у человека.
Рабочий запрос
Разбери новую просьбу клиента как карту влияния.
Вход:
- сообщение клиента;
- текущий объем работ;
- сроки;
- уже данные обещания;
- ограничения команды.
Верни:
- что клиент реально просит;
- какие части проекта это затрагивает;
- входит ли это в текущую договоренность;
- какие риски появляются;
- какие вопросы нужно уточнить;
- 3 варианта ответа клиенту;
- какое решение должен принять человек до обещания.| Что дать Codex | Что он возвращает | Что решает человек |
|---|---|---|
| сообщение клиента | что именно просят | принимать ли запрос в работу |
| текущий объем работ | что меняется | это входит в договоренность или нет |
| сроки и обещания | где появляется конфликт | можно ли двигать срок |
| ограничения команды | риск и стоимость | нужно ли менять цену |
| историю похожих просьб | варианты ответа | какой тон и позиция уместны |
После такого запроса Codex возвращает не финальное "да" или "нет", а материал для решения. Это особенно важно для не-программиста: ему не нужно понимать внутреннюю механику проекта до мелочей, но нужно видеть последствия.
Где граница
Codex может показать, что просьба затрагивает сроки, бюджет, старые обещания или качество. Но он не должен сам обещать клиенту новую цену, скидку, дату релиза или изменение договора. Это решение человека, потому что именно человек отвечает за отношения и обязательства.
В этом и есть практический must-have. Codex не заменяет владельца проекта. Он делает момент принятия решения более ясным: просьба видна, последствия видны, варианты ответа видны, а ответственность не растворяется в красивом тексте.
