Программисты делают бизнес

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