Развитие, ориентированное на миссию

По мере роста компаний масштабирование разработки Agile-продуктов становится все сложнее. По мнению 52% респондентов 13th State of the Agile Report, различия между организационной культурой и ценностями Agile являются главным недостатком в их работе.

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

Эти абстрактные ценности трудно оценить и использовать. В организации внедрение эффективной стратегии по их использованию становится нетривиальной работой. Подход Mission Driven Development (MDD) вырос из стартапов средней стадии как альтернатива развитию такой культуры.

Масштабирование вызовов

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

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

Проблемы масштабирования традиционных гибких фреймворков

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

Традиционные Agile-фреймворки (XP, Scrum и Kanban) оптимизированы для работы на командном уровне, оставляя управленческие отношения практически без внимания. Чтобы заполнить этот пробел, возникла новая волна масштабируемых Agile-фреймворков, т. е. SAFe, LeSS, Scrum of Scrums, Nexus, DAD и т. д. Однако эти подходы требуют тщательного планирования для внедрения и усилий по управлению и поддержке.

Облегченный подход, платформа Mission Driven Development дает достаточно рекомендаций для реализации надежной структуры масштабирования разработки и использования ценностей Agile.

Основные элементы развития, ориентированного на миссию

Миссии

Отправной точкой является Mission Discovery. Бизнес-миссия требует времени и усилий и должна определить скрытую проблему, пространство для решения и желаемый бизнес-результат. Точно сформулированная миссия стимулирует мотивацию, способствует сотрудничеству и способствует исследованиям в более широких областях дизайна.

Отряды

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

6-недельный цикл

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

Буферный период

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

Важность 6-недельного цикла

Хотя шестинедельный период может показаться некоторым Agile-практикам большим, он имеет несколько важных преимуществ.

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

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

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

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

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

Реализация разработки, ориентированной на миссию

Возьмем, к примеру, стартап на промежуточной стадии, у которого есть продукт B2B, предлагающий оптимизацию ценообразования в сети, которая увеличивает доход клиента за счет использования приложений искусственного интеллекта. Бизнес недавно подписал новый раунд финансирования с целью консолидации в качестве соответствующего участника отрасли и увеличения доли рынка на 300%.

В этом сценарии есть несколько проблем разработки продукта:

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

В конце концов, чтобы избежать сложных фреймворков, компания решает применить фреймворк Mission Driven Development. В разработке, ориентированной на миссию, детали «последней мили» определяются каждой организацией. Основными элементами, которые необходимо определить, являются:

• Открытие миссии
• Структура миссии
• Сборка отряда
• Осмотр и адаптация
• Буферная итерация
• Планирование мощности

Миссия Открытие

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

Процесс обнаружения миссии проводится специально выделенными командами. Группа исследователей, возглавляемая менеджером по продукту, состоит из исследователей продукта, бизнес-аналитиков и дизайнеров. Когда существует несколько менеджеров по продуктам, они подчиняются директору по продукту (CPO), который обеспечивает общее видение продуктов, соответствие продуктов и глобальной стратегии компании, а также своевременную доставку.

Рекомендуемая отправная точка для обнаружения миссии — вызовы, проблемы или возможности. Например, начав с задачи, вы помогаете команде исследовать больше областей дизайна, что в конечном итоге расширяет возможности решения.

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

1. Проведение маркетинговых исследований и анализа конкурентов
2. Понимание проблемного пространства, в котором определяется миссия
3. Создание эскизов и прототипов низкой точности
4. Четкое определение масштаба миссии
5. Сбор отзывов и проверка клиентов

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

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

В качестве примера давайте возьмем такую ​​задачу: какие функции должны быть созданы на основе платформы, чтобы обеспечить убедительный пользовательский опыт? Только одна исследовательская группа во главе с менеджером по продукту может справиться с этой задачей.

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

После первоначального исследования рынка принимается решение о разработке новых функций. Функции-кандидаты для платформы:

• Сверхбыстрая переоценка
• Быстрый и отзывчивый интерфейс
• Интеллектуальные и продвинутые правила переоценки
• История переоценки и продаж

В целях исследования компания решает использовать подход «дизайн-спринт»: пятидневный процесс для ответов на критические вопросы бизнеса посредством проектирования, прототипирования и тестирования идей с пользователями. Процесс обнаружения запускается для каждой функции-кандидата, чтобы увидеть, какая из них создаст большую ценность для текущих и потенциальных клиентов. Главной функцией, выбранной для разработки, являются интеллектуальные и расширенные правила переоценки.

Структура миссии

Достижение четкого определения миссии — нетривиальная задача. Он должен отражать четкую бизнес-задачу и устанавливать границы ее результата, а также давать достаточно места для того, чтобы команды могли прийти к инновационному и эффективному решению. Четкая и четкая миссия:

• Четко формулирует бизнес-задачу, определяя и очерчивая проблемное пространство.
• Синтезирует всю информацию и идеи, обнаруженные на предыдущих этапах.
• Ссылки на желаемый бизнес-результат.
• Ориентирован на результат, четко указывающий на картину успеха миссии.
• Является реалистичным и достижимым в течение 6-недельного цикла.
• Достаточно узкий, чтобы гарантировать фокусировку, и достаточно широкий, чтобы избежать деталей.

В примере, после недели открытия, информация и отзывы пользователей были собраны и синтезированы.

Целевой пользователь: аналитики ценообразования клиентов.

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

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

Вывод: правила должны применяться в настраиваемых приоритетах и ​​при необходимости должны быть изменены.

Аналитики хотели бы легко видеть, какие правила применяются в определенное время для данного продукта.

Желаемый бизнес-результат: увеличение вовлеченности пользователей платформы на 25 %, измеряемое временем, проведенным на платформе.

Сборка отряда

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

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

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

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

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

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

Проверка и адаптация в рамках цикла

Коучи Agile должны постоянно поощрять прозрачность, проверку и адаптацию с помощью стандартных практик Agile.

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

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

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

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

1. Выпуск 1:
   • Пользовательский интерфейс новой функции правила
   • Ценовые правила конкурентов
2. Выпуск 2:
   • Правило срочности доставки
   • Общее правило порядка
   • Приоритеты правил
3. Выпуск 3:
   • Доступное правило инвентаря
   • Правило приложения визуализации
4. Выпуск 4:
   • Скидка для премиум клиентов

Релиз 3 согласован в качестве демо на четвертую неделю. Поскольку выпуски производились на протяжении всего цикла разработки, желаемый бизнес-результат (в данном случае вовлечение пользователей) следует отслеживать с момента начала цикла разработки. Графически прогресс можно было бы ожидать следующим образом:

Буферный период

Использование одной или двух недель в качестве буферного периода — это практика, воспроизводимая в реализациях Mission Driven Development, а также в других подходах к масштабированию, таких как SAFe.

В SAFe итерация инноваций и планирования выполняется в каждом цикле разработки. Он служит переключателем контекста, запуская процессы и действия по исследованию и инновациям, которые обычно не учитываются другими платформами, ориентированными на доставку. Примеры мероприятий, реализованных в эту буферную неделю:

• Окончательная интеграция решения . При развертывании ближе к концу 6-недельного цикла вполне вероятно, что интеграция, проверка, документация и проверка еще не завершены. Выделенное время помогает обеспечить эффективную и плавную интеграцию новых решений в существующие продукты.
• Планирование миссии и расстановка приоритетов . Миссии уточняются, классифицируются на маленькие или большие партии и расставляются по приоритетам для следующего цикла разработки. При определении приоритетов миссий некоторые компании организуют дни презентаций, во время которых компаниям представляются основные миссии, а затем — в духе сотрудничества — они переходят к следующему циклу разработки.
• Хакатоны . Хакатоны приобретают все большую популярность среди стартапов и компаний благодаря их способности стимулировать инновации, создавать сообщества и получать новые знания и навыки в увлекательной игровой форме. Результаты представляются другим и становятся кандидатами в журнал невыполненных задач.
• Разработка экспериментальных прототипов или сторонних проектов . Общепринятой практикой является предоставление инженерам и дизайнерам времени для работы над тем, что они решили, при условии, что они показывают проделанную работу в конце буферного времени.
• Инженерные работы . Обычно выполняются чисто инженерные работы, такие как развитие инфраструктуры, автоматизация тестирования, сокращение технического долга и миграция систем.
• Развитие новых навыков и знаний . Быстрый темп эволюции знаний заставляет разработчиков быть в курсе мировых тенденций. Буферное время подходит для проведения обучения на месте, сообществ практики и технологических семинаров, среди прочего.

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

Планирование мощности

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

Рекомендация здесь проста: всегда имейте смесь малых и больших партий. Небольшие партии — это миссии, которые, по оценкам, занимают 3-4 недели, а большие партии могут занять шесть недель и более.

Если небольшая группа завершила свою миссию к 3 или 4 неделе, согласованная демонстрация — это возможность оценить, следует ли группе продолжать работать над улучшением реализованного решения, помогать другой команде, выполнять новую миссию небольшими партиями или начинать. незапланированная работа.

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

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

Риски развития, ориентированного на миссию

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

Объем миссии

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

Чрезмерно амбициозная миссия может вызвать разочарование и беспокойство, что негативно скажется на эффективности отряда. С другой стороны, миссия без энтузиазма может вызвать демотивацию и скуку отряда. Таким образом, менталитет минимально жизнеспособного продукта должен оставаться постоянным в рамках.

Почему миссии

Надежные бизнес-миссии должны иметь всестороннее определение проблемного пространства и его связи с видением компании. Если эта взаимосвязь не ясна, ценная информация может быть утеряна из-за непонимания того, как решение проблем влияет на цели компании.

Водопад-ловушка

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

Эксплуатация продукта

Задачи эксплуатации продукта, такие как управление инфраструктурой, службами или компонентами мониторинга, не должны входить в компетенцию отрядов, поскольку они могут повлиять на скорость. Использование стандартов и методов разработки, таких как атомарный дизайн, снижает усилия по разработке и, следовательно, ускоряет масштабирование. Другой распространенной практикой в ​​этой структуре является центральная операционная группа, которая занимается инфраструктурой в дополнение к управлению операциями с продуктом и мониторингу.

6-недельный цикл как основа для близорукости

Некоторые сценарии не подходят для этой платформы. Это становится особенно актуальным при работе с большими и сложными системами, которые могут оказать огромное влияние на качество обслуживания клиентов, например, проекты НИОКР или миграция критически важных систем.

Облегченный вариант для масштабирования Agile

Масштабирование Agile, чтобы не отставать от темпов разработки продукта и роста компании, является скрытой проблемой для практиков Agile. В качестве недавно разработанного гибкого подхода платформа Mission Driven Development завоевала популярность среди компаний благодаря простоте использования и реализации. Структура MDD приводит в движение сквозной сквозной процесс разработки продукта, от открытия до доставки, который заполняет пробелы, присутствующие в традиционных структурах Agile. Разработка, управляемая миссией, может стать новым Scrum для растущих компаний.