Планирование проекта и делегирование

Прошлый урок был про одну задачу. Но в агентстве работа — это проекты на недели, с десятками задач и несколькими людьми. Делегирование на уровне проекта — это отдельный навык: решить заранее, где ИИ будет помогать, где — нет, и как сделать так, чтобы каждый участник не изобретал это заново. Разберём на примере небольшого проекта.

Карта делегирования

Возьмём типичный проект: сайт для небольшой компании, четыре недели, команда — менеджер, аналитик, дизайнер, разработчик, тестировщик. Разложим по этапам и для каждого спросим: что здесь отдаём модели, в каком режиме, что остаётся людям.

Сбор требований. Аналитик проводит интервью с клиентом. Само интервью — человек. Подготовка гайда с вопросами — дополнение: модель предлагает, аналитик отбирает. Расшифровка и превращение в список требований — автоматизация. Поиск пробелов и противоречий в требованиях — дополнение. Факты о бизнесе клиента — только из его слов и его площадок; если модель что-то «дополнила», это идёт в список вопросов, а не в документ.

Дизайн. Концепция и композиция — дизайнер. Тексты для интерфейса, варианты формулировок, состояния ошибок — автоматизация. Критика макета с позиции разных пользователей — дополнение. Проверка контраста — лучше скриптом, чем «на глаз» и чем мнением модели.

Разработка. Архитектурные решения — разработчик, возможно с обсуждением. Типовой код, тесты, рефакторинг по образцу — агентность через Claude Code с чёткими границами. Ревью — дополнение: модель первая читает дифф, человек — второй.

Тестирование. Чек-листы из ТЗ, тест-данные, генерация граничных случаев — автоматизация. Исследовательское тестирование и решение о готовности — человек.

Управление. Протоколы встреч, статусы по заметкам, планы — автоматизация с проверкой фактов. Разговоры с клиентом о сроках и деньгах — человек; модель — для репетиции и формулировок.

Записанная таким образом карта делегирования занимает полстраницы. Её ценность в том, что решения приняты один раз и всей командой, а не каждым по-своему в момент спешки.

Модель как партнёр по планированию

Есть соблазн просить модель «составь план проекта». Это плохое делегирование: у модели нет вашего опыта, вашей команды и вашего клиента. Но модель — хороший партнёр по планированию, если использовать её в режиме дополнения.

Что она делает хорошо:

• Находит пропущенные этапы. «Вот план из восьми пунктов. Чего в нём не хватает для проекта такого типа?» Она напомнит про миграцию данных, настройку аналитики, редиректы со старых адресов.
• Задаёт вопросы. «Задай мне десять вопросов, ответы на которые нужны, чтобы оценить этот проект». Часть вопросов вы уже знаете, часть — забыли задать клиенту.
• Проверяет зависимости. «Вот список задач. Какие из них нельзя начать, пока не сделаны другие?»
• Играет роль. «Ты — клиент, который увидит этот план. Что тебя в нём смутит?»

Чего она не делает: не знает реальную скорость вашей команды, не знает, что разработчик уходит в отпуск, не знает историю отношений с клиентом. Сроки, оценки и приоритеты — ваши.

Разовое и повторяющееся

При взгляде на проект целиком становится видно, что многие задачи повторяются: еженедельный статус, чек-лист регресса перед каждым релизом, проверка макета по одному списку критериев, шаблон постановки задачи разработчику. Для таких задач описание стоит написать один раз и переиспользовать.

Форма зависит от инструмента. В чате это может быть сохранённый шаблон промпта или проект с инструкциями. В Claude Code — файл CLAUDE.md с правилами проекта или навык (Skill) для конкретной операции. Разница принципиальная: разовый промпт живёт у одного человека в истории чата, а инструкция в проекте живёт у всей команды и улучшается по мере накопления ошибок.

Хороший признак зрелого делегирования — когда после каждой найденной ошибки ИИ команда не говорит «ну вот, опять», а дописывает одну строку в общую инструкцию, чтобы ошибка не повторилась.

Границы для агентов

Чем самостоятельнее ИИ, тем важнее заранее описать, чего он делать не должен. Для агентных задач на уровне проекта полезно зафиксировать:

• какие файлы и данные можно менять, а какие — нет;
• когда нужно остановиться и спросить (например, перед удалением, перед изменением схемы базы, перед отправкой чего-либо наружу);
• как проверять результат (какие тесты запускать, какие критерии считать провалом);
• сколько попыток допустимо, прежде чем вернуть задачу человеку.

Эти правила в Claude Code живут в CLAUDE.md; в других инструментах — в системных инструкциях. Они не только защищают от ущерба, но и повышают качество: агент, который знает, как проверить свою работу, чаще её проверяет.

Как понять, что делегирование работает

Несколько признаков, по которым видно, что карта делегирования принесла пользу, а не стала ещё одним документом.

Люди перестали задавать модели вопросы, на которые она не может знать ответ. Черновики приходят на ревью уже с пометками «проверено по источнику» и «нужно уточнить у клиента». Повторяющиеся задачи выполняются по общей инструкции, а не по памяти. И главное — время, сэкономленное на черновиках, тратится на проверку и на общение с клиентом, а не просто на большее количество черновиков.

→

Попробуйте сами

10–15 мин на рабочем месте

1. Возьмите текущий проект и составьте карту делегирования на полстраницы: этапы → что отдаём модели, в каком режиме → что остаётся людям. Покажите её команде и попросите поправить. Даже если карта неполная, разговор о ней стоит потраченных 15 минут.
2. Отдайте модели свой план проекта (без данных клиента) с просьбой: «Чего в этом плане не хватает? Какие зависимости между задачами я мог упустить?». Отметьте, какие из её замечаний оказались полезными, а какие — общими.
3. Найдите одну повторяющуюся задачу в проекте и напишите для неё инструкцию, которой мог бы воспользоваться коллега: контекст, что должно получиться, как проверить. Сохраните там, где её увидит команда.

Коротко

• Карта делегирования: для каждого этапа проекта — что отдаём модели, в каком режиме, что остаётся людям.
• Факты о клиенте — только из его слов и его площадок; «дополнения» модели — в список вопросов.
• Модель — партнёр по планированию (пропуски, вопросы, зависимости, роль клиента), а не автор плана.
• Повторяющиеся задачи описываем один раз: шаблон, проект с инструкциями, CLAUDE.md, навык.
• Для агентов заранее описываем границы: что менять нельзя, когда спросить, как проверять.
• Признак успеха: сэкономленное время уходит на проверку и клиента, а не на больше черновиков.