Как ИИ меняет правила игры в управлении проектами разработки ПО

Долгие годы мы управляли проектами, как и большинство других руководителей с сертификатами PMP — следовали модели Time & Materials (T&M).

Процесс начинался с чернового описания объема работ. Создавалась иерархическая структура работ (Work Breakdown Structure/WBS) для распределения задач и, оценки трудозатрат. Но с появлением ИИ-ассистентов и их использованием для кодинга назрел вопрос замены WBS в управлении проектами, поскольку такой подход потерял гибкость и в некоторых случаях даже стал мешать.

В поисках чего-то более подходящего мы открыли для себя иерархическую структуру ценности (Value Breakdown Structure/VBS) и концепцию функциональных срезов (Functional Slices).

После перехода компании от устаревшей модели «Иерархическая структура ценности + Иерархическая структура работ + Традиционная разработка» к современному фреймворку «Иерархическая структура ценности + Функциональные срезы + Разработка с помощью ИИ», адаптации подхода для контрактов Time & Materials и использовании его в реальных проектах, мы решили поделиться своими наблюдениями. Вот, что из этого вышло.

Традиционная разработка ПО с VBS и WBS

Как мы работали раньше

В традиционной модели T&M мы совмещали две структуры:

• Иерархическая структура ценности (VBS, она же ИСЦ) — это стратегическая декомпозиция проекта на значимые для заинтересованных сторон результаты. Она нужна для согласования целей с клиентом и высокоуровневого планирования. Это получался своеобразный «артефакт» планирования, который фиксировался на ранних этапах и редко обновлялся. Обратная связь поступала поздно, а корректировка курса обходилась дорого;
• Иерархическая структура работ (WBS, она же ИСР, она же Структура декомпозиции работ) представляет собой декомпозицию функций на задачи уровня компонентов. ИСР была нашей коммерческой основой, определяющей оценку трудозатрат и отслеживание прогресса.

При разработке новых функций ПО мы следовали такому плану:

1. Детализация со стороны БА. Бизнес-аналитик детализирует модуль, разбивает его на функции и создает задачи в Jira;
2. Создание иерархической структуры работ. Руководитель проекта и техлид разбивают каждую задачу на мелкие подзадачи, оценивают часы и выстраивают зависимости;
3. Ручная разработка. Разработчики параллельно выполняют задачи (при этом накладные расходы на интеграцию регулярно добавляли к оценкам 20-30%).

Почему старый подход перестал работать с приходом ИИ

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

• Диспропорция гранулярности задач. ИСР, созданная для ручного написания кода, разбивает работу на фрагменты, рассчитанные на рабочий день разработчика. ИИ справляется с такими фрагментами за минуты;
• Нестабильные метрики производительности. Задача, оцененная в 10 дней, может быть выполнена за 2, а другая похожая задача может занять 5 дней из-за непредсказуемости ИИ. Наши почасовые метрики скорости стали нестабильными. Клиенты начали спрашивать, почему мы не можем делать все с одинаковой скоростью;
• Миграция «узких мест». В Jira разработка отображалась «зеленой» (реализовано с опережением графика), но общие сроки проекта пропорционально не сокращались. Это было вызвано тем, что «узкие места» смещались в области спецификации, интеграции и валидации — те зоны, которые модель ИСР не отслеживала должным образом;
• Административные накладные расходы. Пока мы создавали десятки мелких задач для работы, с которой ИИ справлялся за минуты, руководители проектов тратили время на поддержание иерархической структуры работ, нежели на управление ценностью для клиента;
• Кризис традиционных моделей оценки. Исторические почасовые данные стали ненадежными. Мы больше не могли предсказывать сроки проекта на основе оценок трудозатрат на уровне компонентов, поскольку влияние ИИ было неравномерным для разных типов задач;
• Размытие коммерческой прозрачности. Клиенты видели подробные почасовые оценки, но эти часы больше не отражали реального распределения усилий.

Разработка ПО с использованием ИИ сместила ограничения с написания кода на принятие решений, валидацию и согласование. Иерархическая структура работ, созданная для управления трудозатратами, по мере ускорения реализации начала препятствовать результатам и прозрачности.

Рекомендуем прочитать Порхай как бабочка, жаль как пчела: Как гибкий бюджет меняет мнение о разработке продукта

Новый подход к управлению проектами от XB Software: VBS с функциональными срезами и поддержкой со стороны ИИ

Наш новый подход сохраняет стратегическую ясность иерархической структуры ценности, но заменяет иерархическую структуру работ функциональными срезами («слайсами») в качестве основной единицы реализации. Это позволяет перейти от управления работой к управлению потоком ценности.

Что такое функциональный срез в разработке ПО?

Функциональный срез (Functional Slice) — это законченный, сквозной элемент функциональности, с которым взаимодействует пользователь и который приносит измеримую ценность. Он обладает следующими характеристиками:

• Вертикально интегрирован. Проходит через пользовательский интерфейс, бизнес-логику и уровни данных без скрытых интеграционных работ между слоями;
• Обладает самостоятельной ценностью. Можно продемонстрировать и, при необходимости, развернуть отдельно;
• Имеет ограничения. Есть четкие критерии готовности, обычно рассчитан на 1-3 дня разработки с использованием ИИ;
• Может быть протестирован. Позволяет заинтересованным сторонам проверить работу функции сразу после ее разработки.

Как меняются VBS, декомпозиция и исполнение?

Стратегический уровень (VBS/ИСЦ)

Вместо неизменного обещания ценности в будущем, иерархическая структура ценности превращается в реальный бэклог с постоянно меняющимися приоритетами. Это больше не контракт, который необходимо выполнить, а гипотеза, проверяемая каждые несколько дней.

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

Ценность реализуется инкрементально с первой недели, несоответствия выявляются за считанные дни при минимальных затратах, а главным вопросом, определяющим бэклог, становится «Какую ценность нам стоит поставить следующей?» вместо «Какую ценность мы обещали поставить к концу срока?»

Тактический уровень (Декомпозиция)

Единица декомпозиции меняется с фрагментов работы (задач ИСР) на единицы ценности (функциональные срезы). Таким образом, вместо набора горизонтальных компонентов, результаты работы превращаются в вертикально завершенные функции, с которыми пользователь уже может взаимодействовать.

Разработка (Исполнение)

С традиционного написания кода на уровне компонентов процесс разработки меняется на реализацию с помощью ИИ на уровне срезов. Разработчики пишут меньше строк кода вручную. Их роль сводится к управлению ИИ-ассистентов, проверке сгенерированного кода, сквозной интеграции срезов и валидации результатов.

Применение нового подхода «VBS + срезы + разработка с помощью ИИ» на практике

Определение и оценка функциональных срезов

Детализация смещается с задач на срезы. Бизнес-аналитик определяет поставляемую единицу ценности с четкими критериями согласования (готовыми для ИИ), дизайн-референсами и нефункциональными требованиями. Руководитель проекта проверяет их на соответствие иерархической структуре ценности. Тестировщик и техлид оценивают реализуемость, согласованность и целостность.

Давайте рассмотрим в качестве примера, как задача “Обеспечить безопасный онбординг клиентов” решалась бы старым и новым методами:

• Старый подход: 7 задач, всего 10 дней (форма регистрации, схема базы данных, интеграция со Stripe, подтверждение по электронной почте, документация API, уведомление администратора, время на интеграцию и тестирование);
• Новый подход: 3 функциональных среза, всего 4.5-6 дней (создание и подтверждение учетной записи, настройка оплаты, ьастер онбординга).

Оценка сроков разработки ПО смещается с человеко-часов на дни на реализацию среза. Теперь мы прогнозируем, используя дни на срез, и производим следующий расчет

Оценка среза = Традиционная оценка пользовательской истории × Эффективность ИИ × Издержки на исследование × Фактор опыта

• Традиционная оценка пользовательской истории: сколько времени занял бы этот объем работы при ручной разработке;
• Эффективность ИИ: насколько использование искусственного интеллекта в разработке ускоряет этот конкретный тип работы (варьируется от 0.6x для задач, подходящих для ИИ, до 1.2x для задач, требующих серьезной экспертной оценки от человека);
• Издержки на исследование: время, необходимое для проверки результатов работы ИИ, исправления проблем, созданных ИИ, и устранения неопределенности в требованиях;
• Фактор опыта: насколько уверенно разработчик владеет ИИ-инструментами.

Мы продолжаем отслеживать фактические часы на каждый срез для обеспечения прозрачности T&M, но прогнозирование опирается на пропускную способность срезов, которые становятся гораздо более стабильной метрикой.

Рекомендуем прочитать Не просто инструкция: Как Проектный регламент помогает командам успешно доводить проекты до конца

Управление потоком срезов

Jira становится менеджером потока срезов. Наш рабочий процесс был переработан с учетом новых реалий при сохранении прозрачности для T&M:

• Эпики: Представляют элементы иерархической структуры ценности;
• Истории: Представляют функциональные срезы;
• Задачи на срез ограничены тремя типами (Спецификация и дизайн; ИИ-реализация; Валидация и тестирование). Мы не разбиваем задачу “ИИ-реализация” на компонентные подзадачи. Отслеживаются только фактические часы работы бизнес-аналитика, UI/UX-дизайнера, разработчика и тестировщика. Клиенты видят соотношение готовых и оставшихся срезов, фактические часы на срез и тенденции пропускной способности.

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

• Перед каждым демо мы просматриваем ИСЦ вместе с клиентом, чтобы подтвердить приоритеты;
• После каждого демо мы собираем обратную связь и сразу же корректируем ИСЦ;
• Каждые 1-2 недели ИСЦ дорабатывается на основе полученного опыта.

Запросы на изменения обрабатываются на уровне срезов. Нам больше не нужно переоценивать десятки задач из иерархической структуры работ. Новая функция приложения превращается в 1-3 новых среза, которые мы добавляем в бэклог иерархической структуры ценности. Модификация означает пересмотр или разделение затронутых срезов, а удаление из объема работ — просто их удаление.

Пример: После просмотра демо клиент запрашивает реализацию функционала “Вход через соцсети”.

Прогнозирование переключается с трудозатрат на пропускную способность. Раньше: “У нас осталось 200 часов, а скорость нашей команды составляет 100 часов в неделю, поэтому мы закончим через 2 недели”. Проблема заключалась в том, что из-за нестабильности ИИ почасовая оценка скорости была ненадежной.

Теперь: “У нас осталось 12 срезов. Пропускная способность составляет 4-5 срезов в неделю. Мы закончим работу через 2.5-3 недели, при этом каждый срез будет демонстрироваться по мере готовности”. Часы по-прежнему учитываются в отчетах, но горизонт планирования определяется пропускной способностью срезов.

Адаптация процессов и ролей

Вместо спринтов с фиксированными сроками Agile-практики ориентируются на поставку на основе потока. Когда срезы приносят ценность за считанные дни, фиксированные двухнедельные Scrum-спринты теряют свой первоначальный смысл.

В новом подходе спринты становятся условными контейнерами для работы, а не циклами поставки. Если срез занимает меньше 3 дней — отлично! Клиент видит работающее ПО, когда оно готово, а не в привязке к фиксированной календарной дате.

Новые роли в разработке ПО. Каждая роль меняет ориентир с управления действиями на контроль потока ценности:

Заключение: от управления затратами труда к управлению потоками ценности

В эпоху разработки с помощью ИИ главный вопрос заключается в том, как быстро компании смогут перестроить свои модели управления, чтобы в полной мере использовать потенциал искусственного интеллекта.

В нашем подходе Иерархическая структура ценности (ИСЦ) становится живым бэклогом, приоритеты в котором пересматриваются после каждого демо в соответствии с обратной связью от заинтересованных сторон. Мы декомпозируем ценность на готовые срезы, измеряем пропускную способность и передаем работающее ПО каждые несколько дней.

Если вы готовы отказаться от почасовых отчетов и хотите регулярно получать работающее ПО, свяжитесь с нами, чтобы внедрить современный фреймворк на вашем следующем проекте.