Файл intent.md, который запускает процесс разработки программного обеспечения, может поступать различными путями. У человека возникает идея, заводится тикет или инцидент выявляется посредством оповещения (см. Этап 6: Поддержка).
Когда у человека возникает идея, он проводит мозговой штурм с Claude и создает прото-спецификацию в формате Markdown. В традиционном SDLC тот же человек должен затем убедить члена продуктовой команды оформить эту идею вместе с ним или от его имени.
Прото-спецификация, сгенерированная Claude, легко читаема человеком, находится под версионным контролем и сразу же готова к использованию на следующем этапе. Прото-спецификация сохраняется как intent.md.
Независимо от того, исходит ли намерение от триггера события или от человека, применяются одни и те же шаги: владелец продукта просматривает и корректирует intent.md, написанный агентом, прежде чем он будет закоммичен.
Что меняется
| Традиционный подход | AI-ориентированный подход |
|---|---|
| Идея проходит через записи бэклога, пользовательские истории, стори-поинты и встречи по уточнению, прежде чем кто-либо сможет начать действовать. Право собственности передается при каждой передаче, поэтому то, что доходит до инженерии, на несколько шагов отличается от того, что имел в виду инициатор. | Инициатор проводит мозговой штурм с Claude и записывает результат как intent.md — прото-спецификацию, сформулированную самим инициатором. Артефакт содержит информацию о том, что требуется, почему и при каких ограничениях. Повторяющиеся процессы кодируются с помощью навыков (skills). |
Начало работы
- Предварительные условия: Отсутствуют.
- Инфраструктура: Доступ к Claude для людей, не являющихся инженерами (claude.ai или Cowork); согласованный шаблон
intent.md; общее, контролируемое версиями хранилище для намерений (intent), за которым следит владелец продукта. Для одного продукта простейшим хранилищем является папкаintent/в репозитории продукта. Такая настройка позволяет хранить цепочку артефактов рядом с кодом, полученным из них. Выделенный репозиторий для намерений (intent repo) оправдывает накладные расходы только тогда, когда намерения охватывают множество репозиториев, а в монорепозитории это просто директория. Раздел «Устаревшие системы» в Этапе 3: Разработка описывает, как это хранилище соотносится с Jira или инструментом управления требованиями, который уже содержит записи.
Настройка этого является одноразовой задачей для команды платформы или инженеров. Член технической команды должен развернуть хранилище намерений (intent home) и решить, кто может в него записывать, поскольку многие участники будут из разных отделов организации.
Как только репозиторий создан, участникам без опыта работы с Git не нужно использовать Git напрямую. Вместо этого коннектор к системе контроля версий (например, GitHub) позволяет Claude коммитить Markdown-файлы от их имени с claude.ai или Cowork.
Как это реализовать
- Инициатор описывает проблему Claude своими словами. Инициатор может описать, что они не могут сделать сегодня, кого затрагивает идея, как выглядит улучшение или что выходит за рамки. Формальный язык не требуется.
- Проведите мозговой штурм, пока идея не станет конкретной. Claude задает вопросы, которые задал бы аналитик: объем (scope), пользователи, ограничения и как выглядит успех.
- Попросите Claude записать результат как
intent.md, используя шаблон организации, который может быть закодирован как skill, настроенный членом технической команды и утвержденный руководителем. Это может охватывать проблему, предлагаемый результат, затронутых пользователей и системы, ограничения и открытые вопросы. - Инициатор исправляет все, что Claude понял неправильно.
- Закоммитьте
intent.mdв общее хранилище. Автор и временная метка добавляются к записи, и владелец продукта подхватывает идею оттуда.
Как это выглядит
intent.md:
# Намерение: самообслуживание по статусу претензий Автор: Дж. Ортис (операции по претензиям). Статус: черновик. ## Проблема Клиенты звонят в контакт-центр, чтобы узнать статус своей претензии. Операторы тратят примерно треть времени звонка на запросы только о статусе. ## Предлагаемый результат Клиенты видят статус претензии, следующий шаг и ожидаемую дату на портале. ## Затронутые пользователи и системы Операторы по претензиям, команда портала, claims-core API. ## Ограничения Отсутствие новых PII в сессии портала. Только существующая аутентификация. ## Открытые вопросы Нужен ли доступ сторонним оценщикам ущерба?Вопросы управления
Доказательством является закоммиченный intent.md, который содержит автора, временную метку и полную историю ревизий. Он регистрируется в Git-истории хранилища намерений (intent home). Владелец продукта утверждает, а решение о принятии или отклонении, которое отправляет намерение на Этап 2: Проектирование, записывается как слияние (merge) или закрывающий обзор.
Как это измерить
- Опережающий индикатор: Время от первой беседы до закоммиченного
intent.md, считываемое из Git-истории хранилища намерений (intent home), которая фиксирует автора и временную метку. Ожидается, что это сократится с многонедельного цикла выявления и уточнения до нескольких часов. - Запаздывающий индикатор: Коэффициент выживаемости, или доля файлов
intent.md, которые владелец продукта принимает на Этап 2: Проектирование, а не закрывает. Решение о принятии или отклонении записывается как слияние (merge) артефакта или закрывающий обзор. Дополнительно подсчитайте изменения вintent.md, внесенные после первого коммитаspec.mdдля того же изменения.