Разработка ускорилась — заново изобрели планирование
За 10 лет у нас было много разных проектов, но сейчас мы работаем над реально инновационным. Делаем его небольшой командой специалистов. В продукте много связанных сущностей, интерфейсов и данных в активной разработке, а требования уточняются по ходу. При этом сроки жёсткие, а горизонт планирования короткий.
Если бы мы работали над проектом как раньше: фронтендеры, бэкендеры, тимлид, аналитик, менеджер + нейронки, то шли бы по длинному пайплайну из нарезанных задач. В нужный срок мы бы так не уложились.
Поэтому для проекта мы заново изобретаем планирование и используем подход AI SDLC. Его ключевой элемент — продакт-инженеры + экспертиза узких специалистов.
Например, инженер, с сильной экспертизой во фронте, но не шарящий за бэк, идёт к бэкендеру за детализацией на уровне текущей архитектуры.
Так как требования к лид тайму высокие, то с одной стороны надо делать больше задач под ключ, с другой стороны качественно планировать распределение взаимосвязанных задач.
В основе планирования здесь четыре группы факторов:
1. Требования и пользовательская ценность. Нужно так разбить и расположить задачи, чтобы каждый законченный блок давал пользу клиенту.
2. Технические зависимости. Данные, интерфейсы и API-контракты связывают разные части продукта. Нельзя независимо разрабатывать функции, которые зависят друг от друга или затрагивают одни и те же участки кода.
3. Владение кодом. На старте выгоднее отдавать доработку тому, кто уже погружён в конкретную часть продукта. Позже экспертизу можно распределять между командой, чтобы снижать бас-фактор.
4. Приоритеты и сроки. Нужно соотносить ценность задач с затратами, менять очерёдность и при необходимости резать скоуп ближайшего релиза.
Поверх этого есть ещё один слой — реальное состояние разработки. Какая-то задача заняла больше времени, другая закончилась раньше, третья заблокировала коллегу. Вчерашнее распределение уже не работает, и план нужно пересобирать.
Обычно весь этот контекст разделён между аналитиком, менеджером и тимлидом. Аналитик отвечает за продуктовую декомпозицию, менеджер — за приоритеты и соотношение выхлопа с затратами, тимлид — за технические зависимости и распределение задач с учётом владения кодом. Пока все синхронизируются, принятие решения растягивается.
Сначала я пытался уместить всю эту конструкцию в голове. Потом вспомнил собственную рекомендацию: не надо долго думать над чистым листом, сначала получи первую версию от нейронки.
Я передал Claude пользовательские истории с описаниями и критериями приёмки, код из всех активных веток и приоритеты ближайшего релиза.
За 4-5 итераций Claude собрал план разработки.
Сначала он прошёлся по всем пользовательским историям и сопоставил их описанный статус с тем, что реально есть в коде: что уже готово, что сделано частично, где пока стоят заглушки и что ещё предстоит реализовать.
Затем объединил истории в пакеты работ. Для каждого пакета указал:
— какую ценность он даёт пользователю; — какие истории в него входят; — что уже готово и что осталось сделать; — от каких контрактов, данных и элементов интерфейса он зависит; — кто из разработчиков лучше владеет нужными участками кода.
Также он предложил три варианта группировки задач: по пользовательским сценариям, разделам интерфейса и сущностям продукта. Я выбрал сценарный вариант.
Для него нейронка собрала отдельный граф зависимостей между пакетами: какой API-контракт или готовый элемент интерфейса одна часть команды должна передать другой. На этой же основе предложила, кому из разработчиков отдать каждый блок, и зафиксировала открытые вопросы, которые нужно разобрать с командой.
Буквально за полчаса получилась рабочая карта разработки. Документ можно актуализировать или пересобрать за пару запросов к ИИ.
Я вижу здесь тот же переход, который происходит с разработчиками. Для менеджера остаётся всё меньше зон, где он сам не может ничего сделать.
