Пока мы писали эту статью, пользователи нашумевшего iPhone Duo успели раскритиковать его в сети. Крупнейший американский техноблогер протестировал новинку, но в итоге решил вернуться к предыдущей модели смартфона якобы из-за отсутствия привычного функционала.
Ни одна компания не застрахована от неоднозначной реакции пользователей на свой продукт. Поэтому и существует Agile-планирование, которое помогает быстро реагировать на внутренние и внешние изменения, корректировать план работ, чтобы не тратить ресурсы зря. Обо всём этом и расскажем далее.
Что такое Agile-планирование
Agile-планирование — это подход в управлении проектами, который подразумевает, что команда определяет цель, подробно планирует ближайшую работу и уточняет следующие шаги по данным и обратной связи. Так можно проверить гипотезу небольшим запуском и решить, во что вкладывать время дальше.
Agile применяют в контексте сильно изменчивого и непредсказуемого окружения: создаваемые новые услуги и продукты могут быть не приняты потребителями, текущие услуги и продукты начинают терять клиентуру и поэтому требуют трансформации и т. п.
Поэтому ответ на третий вопрос в Agile другой: необходим план-трансформер гипотез по достижению цели, который можно относительно легко регулярно пересобирать. И прогресс по плану мы будем оценивать не количеством заранее спланированных задач, а оценкой степени достижения цели
Но и это ещё не всё. Agile-планирование нужно, если используешь ИИ-агентов для ускорения работы команд. В противном случае рискуешь слить бюджеты на результат, который не соответствует ожиданиям.
✔️ Понимание текущего состояния — выверенные корпоративные данные
✔️ Цель с чётким измерителем её достижения. Наиболее популярен подход OKR (Objectives and Key Results) — «цели и ключевые результаты»
✔️ Легко пересобираемый план чётко сформулированных гипотез с ограничениями по бюджету — фиксированные ресурсы на фиксированный срок и встречи по перепланированию
Только в таком случае ИИ-агент без вмешательства человека сможет выполнить задачу, после этого — оценить степень достижения цели и, может быть, модифицировать задачу и попробовать всё снова. Возможно, вам кажется это сказкой, но это уже наша действительность
👀 Как масштабироваться в кризис
Дарим гайд по избавлению от микроменеджмента без потери качества →На каких горизонтах планируют работу по Agile
Майк Кон, основоположник методологии Agile, выделяет шесть основных уровней Agile-планирования: стратегия компании, портфель, продукт, релиз, спринт и день. Эта модель называется Planning Onion (слои гибкого планирования).
🧅 Onion (луковица) — это метафора и означает, что с каждым слоем планирования уровень неопределённости снижается. Чем ближе работа по времени, тем подробнее план.
Стратегия задаёт направление компании, а портфель связывает работу над разными проектами. Ниже рассмотрим следующие четыре уровня, которые относятся к развитию одного продукта.
| 👀 Горизонт планирования | ✏️ Что фиксируют | 🔍 Насколько подробно планируют | ⏰ Когда пересматривают |
|---|---|---|---|
| Продукт — визуализируют на дорожной карте | Цели развития, ожидаемые результаты и ключевые возможности | На уровне крупных изменений, без подробного разбора задач | В назначенные даты или при изменении продукта, появлении новых данных о поведении пользователей |
| Релиз | Ожидаемый результат, предполагаемый объём работы и ориентиры по срокам | До уровня пользовательских историй (User Story) и зависимостей между ними | При очередном планировании итерации и изменениях объёма, возможностей команды или условий |
| Спринт | Цель спринта, выбранные элементы продуктового бэклога и план их выполнения | Достаточно подробно для ежедневной проверки прогресса | План пересматривают на протяжении всего спринта |
| День | Ближайшие действия для достижения цели спринта, координацию работы и препятствия | До конкретных действий на ближайший рабочий день | На Daily Scrum и при необходимости в течение дня |
Что подготовить до составления плана
Составили базовый чек-лист подготовительных действий, без которых невозможно составить гибкий план.
А ещё важно, чтобы каждый участник рабочего процесса понимал, как устроена методология Agile, и осознавал свои роли и обязанности. Помимо этого есть и другие препятствия, которые лучше преодолеть заранее.
Поэтому до перехода к Agile-планированию я бы рекомендовал сформировать продуктовые кросс-функциональные команды, определить измеримые бизнес-цели и создать культуру, в которой руководители управляют результатами, а не контролируют выполнение каждого действия
Как составить Agile-план: от цели до ближайших задач
Разберём пошагово составление Agile-плана на примере работы небольшой и условной команды сервиса онлайн-записи к специалистам. Его разработчики используют фреймворк Scrum и делят работу на спринты.
Шаг 1: сформулируй цель и критерий результата
Ещё до планирования команда выяснила, что только 40% новых пользователей завершают запись к специалистам. Поэтому ключевая цель на ближайший квартал — увеличить долю этого показателя до 55% к концу года.
| ❌ Размытая формулировка цели | ✅ Хорошая формулировка цели |
|---|---|
| Увеличить количество завершённых записей к специалистам | Увеличить долю новых пользователей, которые завершили запись к специалистам после начала оформления заявки, с 40% до 55% к 31 декабря 2026 года |
Цели и ключевые показатели, информацию по проекту и продукту, аналитику, гипотезы, критерии приёмки и крупные этапы работ лучше фиксировать в документе Базы знаний Weeek и расшарить доступ коллегам. Так ничего не потеряется и информация будет доступна всем.
Шаг 2: составь дорожную карту с приоритетами и контрольными вехами
Подготовительный этап также помог сформулировать три гипотезы, почему пользователи прерывают оформление записи: из-за лишних полей в форме, сомнений при выборе специалиста и потому что отвлекаются и забывают вернуться. Каждая гипотеза — это этап работ, который позже мы разделим на задачи.
Сначала команда проверит короткую форму: для теста она уберёт два необязательных поля. Следующие гипотезы будут тестировать в зависимости от результатов предыдущих. Перед созданием дорожной карты лучше зафиксировать вводные данные в документе.
📍 Веха — это контрольная точка, на которой команда проверяет гипотезу и решает, стоит ли переходить к следующим. В нашем случае это решение оставить короткую форму для записи, продолжать тестировать препятствия или выделить ещё дополнительное время на сбор результатов.
Далее визуализируем дорожную карту проверки гипотез на ближайший квартал с помощью диаграммы Ганта Weeek.
Шаг 3: уточни задачи на ближайший спринт с учётом доступностей команды
До планирования команда уже согласовала бюджеты и добавила в бэклог продукта «Запустить тест короткой формы» и две другие гипотезы. В описании первой указано, что должно работать к запуску: часть новых пользователей увидит форму без полей «Фамилия» и «Комментарий», остальные — прежнюю. В обеих версиях команда сможет посчитать, сколько пользователей начали оформление и сколько — завершили, чтобы потом сравнить результаты.
Элементы в бэклоге продукта (в нашем случае — тестирование гипотез) оценивают в Story Points — относительных единицах, которые показывают сложность, усилия, время и возможные риски при выполнении задачи. Единица измерения может быть любой, главное, чтобы всем участникам процесса было понятно, что она означает. На скриншоте выше разработчики оценили сторипойнты в 3 балла по своей шкале — будем считать, что это означает среднюю трудоёмкость. Один балл — это оценка эталонной задачи, понятной всем в команде.
На планировании спринта команда согласует его цель — запустить проверку короткой формы и начать собирать данные о завершении записи. Обсудив объём с владельцем продукта, разработчики выбирают эту работу из бэклога в спринт. Затем разбивают её на шаги: готовят короткую форму, настраивают распределение пользователей и сбор данных, проверяют запись в обеих версиях и запускают тест.
Шаг 4: договорись о проверке результатов и следующем пересмотре плана
До начала работы команда договаривается, что нужно проверить перед запуском теста, как оценить результаты и сколько времени нужно, чтобы их собрать. Для короткой формы нужно подтвердить, что сервис сохраняет обязательные данные, создаёт запись и отправляет подтверждение.
Для проверки результата команда случайно распределяет новых пользователей между двумя формами, когда они начинают оформление. Затем сравнивает долю получивших подтверждение за одинаковое время после начала записи.
На обзоре спринта (Sprint Planning) команда показывает заинтересованным сторонам, как работает тест, и обсуждает первые данные, если они уже есть. Если информации недостаточно, то решение по готовой форме откладывается до тех пор, пока не будет ясна полная картина. Если по результатам видно, что стоит проверить другое препятствие, то нужно пересмотреть бэклог продукта.
Как и когда обновлять план
Возвращайся к плану после проверки результата или раньше, если изменилось что-то, от чего зависит ближайшая работа: тест дал неожиданный результат, задержалась связанная задача или у команды стало меньше времени. Схема ниже поможет тебе сориентироваться.
Сначала разберись, что произошло и как это влияет на цель. Например, перед запуском теста команда замечает, что в короткой форме аналитика не учитывает подтверждённые записи. Цель прежняя — увеличить долю завершивших запись. Меняется порядок работы: сначала нужно исправить ошибку со сбором данных, иначе сравнение двух форм будет искажено. Если изменения могут повлиять на цель, обсуди её пересмотр с владельцем продукта.
Затем пересчитай объём и сроки. Оцени, сколько времени займёт исправление, помещается ли оно в текущий план, или договорись, какие задачи можно отложить. Если сдвигается запуск теста короткой формы, уточни и дату сравнения результатов. Проверь, есть ли этапы, которые зависят от этого решения.
В Scrum разработчики уточняют ближайший план на Daily Scrum. Объём работ текущего спринта можно пересогласовать, сохраняя цель и качество. Если цель спринта потеряла актуальность, отменить его может только владелец продукта.
Обнови план после решения. За обновление бэклога продукта отвечает владелец продукта, а бэклог спринта — ответственность разработчиков. Если сдвинулись вехи или изменилась очерёдность проверок, то это также стоит отразить на дорожной карте.
Пример Agile-планирования для команды
Ещё один пример использования Agile-планирования для команд, которые внедряют ИИ-агентов, чтобы автоматизировать процессы и ускорить разработку.
В начале двухнедельной итерации команда определяет наиболее перспективные гипотезы, оценивает доступные ресурсы и договаривается о результате, которого хочет достичь, а ИИ-агенты помогают анализировать обратную связь клиентов, исследовать данные, формировать варианты решений, писать код и готовить тесты
Люди распределяют задачи между собой и агентами, проверяют результаты их работы, обеспечивают необходимый контекст и контролируют соблюдение установленных ограничений
В течение итерации команда отслеживает метрики и при необходимости меняет приоритеты, а в конце проводит сессию демонстрации результатов, на которой анализирует полученные данные и принимает решения о дальнейших действиях
Таким образом, команда планирует уже не столько загрузку отдельных специалистов, сколько достижение бизнес-эффекта с использованием совокупных возможностей людей и ИИ-агентов
Частые вопросы об Agile-планировании
