Запрос «сделай CRM для компании» выглядит понятным, пока не начинается разработка. Внутри него скрываются пользователи, права, карточки клиентов, отчеты, уведомления и интеграции. Если поручить всё сразу, оценивать результат придется тоже целиком. Намного удобнее сначала выделить MVP: минимальную версию, на которой можно проверить один полезный рабочий сценарий.
Разберем подход на учебном примере: небольшому бизнесу нужно принимать заявки с сайта и передавать их менеджеру. Это не описание готового продукта или обещание сроков, а модель для планирования собственного проекта.
Начните с результата, а не со списка экранов
Первый вопрос: что пользователь должен суметь сделать после запуска? В нашем примере клиент отправляет заявку, сотрудник видит ее в списке и меняет статус. Администратор может понять, не потерялись ли обращения. Красивый дашборд без надежного сохранения заявки эту задачу не решает.
Сформулируйте один основной маршрут от начала до конца. Затем определите, что будет доказательством успеха: запись действительно появляется в базе, сохраняется после перезапуска, видна только авторизованному сотруднику. Так появляется основа приемки, а не просто перечень компонентов интерфейса.
Отделите обязательное от следующей версии
- Нужно для MVP: форма, проверка полей, сохранение, защищенный список заявок, смена статуса.
- Можно отложить: сложные отчеты, несколько отделов продаж, гибкий конструктор воронок, оформление писем.
- Нельзя забыть: обработку ошибок, ограничение доступа, резервное копирование и понятный способ запуска.
Минимальность относится к количеству функций, а не к безопасности данных. Если приложение принимает реальные контакты клиентов, нельзя считать общедоступный список заявок приемлемым упрощением. Для самого первого прототипа лучше использовать вымышленные данные и закрытое тестовое окружение.
Разбивайте работу на проверяемые этапы
Задача «сделать backend» слишком широка. Задача «создать файл модели заявки» слишком техническая: файл сам по себе не дает проверяемого результата. Хороший этап соединяет конкретное изменение с наблюдаемым поведением.
- Зафиксировать существующее окружение и команды запуска, проверить базовый тест.
- Добавить прием заявки с валидацией и сохранением в тестовой базе.
- Показать сохраненные заявки сотруднику с проверкой доступа.
- Добавить переходы между согласованными статусами.
- Проверить весь маршрут и подготовить запуск с резервной копией.
У этапов есть зависимости. Нельзя принимать список заявок исключительно на заранее нарисованных карточках: нужно проверить, что он показывает реальные записи предыдущего этапа. При этом визуальную часть можно прототипировать раньше, если явно отметить, что данные пока демонстрационные.
Шаблон одной задачи для Codex
Цель: добавить сохранение заявки из существующей формы.
Сначала изучи текущий обработчик и слой доступа к данным.
Поля: имя, телефон, комментарий.
Телефон обязателен; пустые значения отклоняются.
Используй существующие инструменты проекта.
Не меняй дизайн, авторизацию и соседние формы.
При ошибке записи нельзя показывать успешную отправку.
Добавь проверки успешного сохранения и отказа базы.
Готово: заявка сохраняется, ошибка видна пользователю,
проверки выполнены, изменения перечислены в отчете.
Публикация на рабочий сервер не входит в задачу.В таком запросе есть цель, границы и приемка. Названия файлов лучше добавить после знакомства с репозиторием, а не выдумывать заранее. Если код еще не существует, сначала попросите предложить небольшую структуру и перечислить спорные решения. Подробнее об ограничении правок есть в материале как правильно ставить задачи Codex.
Как понять, что этап получился слишком большим
Признаки: меняются несколько независимых пользовательских сценариев, результат нельзя проверить без незавершенных соседних частей, либо откат одного изменения отменяет сразу несколько полезных функций. В этом случае разделите задачу по поведению, а не по количеству файлов. Иногда три файла составляют большой риск, а двадцать небольших однотипных правок являются одной понятной операцией.
Отдельно отмечайте исследовательские задачи. Например, «проверить, предоставляет ли CRM нужное событие» не равно «реализовать интеграцию». Результатом исследования может быть ограничение API или необходимость другого подхода. Это нормальный итог, который должен изменить план до начала большой разработки.
Что сохранять между этапами
После приемки фиксируйте краткую сводку: что реализовано, какие проверки прошли, что осталось и какие решения приняты. Ссылки на файлы и тесты полезнее длинного пересказа диалога. Держите roadmap в репозитории, а повторяющиеся правила работы в AGENTS.md. Не нужно копировать туда весь журнал разработки.
Если обнаружилась новая потребность, добавьте ее в очередь, а не незаметно расширяйте текущую задачу. Иначе небольшой MVP снова превратится в проект без границ. Например, просьба «заодно подключить телефонию» может затронуть учетные записи, согласия, хранение записей и тарификацию внешнего сервиса.
Приемка MVP
Пройдите маршрут так, как его пройдет сотрудник: отправьте тестовую заявку, перезагрузите страницу, откройте запись, измените статус и снова войдите в систему. Проверьте отказ сервиса и отсутствие прав. Убедитесь, что есть инструкция запуска и восстановления. Рабочий сценарий важнее количества реализованных экранов.
Для управления задачами полезно задавать Codex конкретный контекст и ожидаемый результат; соответствующие возможности описаны в официальной документации по постановке задач. Саму последовательность этапов определяют требования вашего проекта, а не универсальный промпт.
Следующий шаг: составить архитектурное ТЗ. Если нужна помощь с MVP сайта или внутреннего инструмента, обсудим задачу: начнем с одного рабочего сценария и понятных условий приемки.
