Кейс: гибкий подход к программе лояльности и биллингу
Коротко Стартап резко изменил дорожную карту продукта, и аналитику пришлось планировать анализ двух новых функций, пока эксперты по более важной из них были недоступны. Описание ситуации через BACCM, выбор адаптивного подхода и сокращение границ при повторном проходе MoSCoW позволили команде поставить обе функции за пять спринтов.
По материалам: R. Leyton, кейс IIBA о гибком подходе (программа лояльности и биллинг), серия «How Do I Identify What Needs to Be Done», 2021; IIBA, Руководство BABOK® v3, Модель базовых понятий бизнес-анализа.
На этой странице
Эта страница своими словами пересказывает опубликованный кейс IIBA, автор которого — Райланд Лейтон (Ryland Leyton). Факты кейса принадлежат ему; раздел с уроками добавляет общую практику.
Контекст#
Стартап в сжатые сроки изменил дорожную карту продукта. Теперь требовались две новые независимые программные функции: программа лояльности для клиентов, у которой был более высокий приоритет, и функция самообслуживания.
На то, чтобы спланировать анализ, у аналитика было около 15 минут с владельцем продукта, техническим лидером и скрам-мастером. Всё определяли два ограничения: разработку нужно было начать быстро, а эксперты в предметной области по программе лояльности были недоступны ближайшие две недели.
Подход#
Аналитик описал ситуацию через шесть базовых понятий Модели базовых понятий бизнес-анализа (BACCM) из Руководства BABOK®: - Изменение: новые возможности для двух групп заинтересованных сторон. - Потребность: внутри компании — скорость и отсутствие лишних усилий; для клиентов — конкретные функции. - Решение: две независимые программные функции. - Заинтересованные стороны: управление продуктом, разработчики, клиенты, обучение, UX и поддержка. - Ценность: удержание клиентов и конкурентное преимущество. - Контекст: разработку нужно было начать быстро.
При такой картине естественным выбором стал адаптивный (ориентированный на изменения) подход только с той документацией, которая действительно нужна команде.
Что сделал аналитик#
- Выстроил очерёдность работ по доступности людей. Команда начала с функции самообслуживания, эксперты по которой были доступны, а исследование программы лояльности параллельно продолжалось. План охватывал шесть двухнедельных спринтов вперёд.
- Провёл семинар по MoSCoW с командой, чтобы распределить возможности программы лояльности по категориям Must, Should, Could и Won’t. При повторном рассмотрении около 30% пунктов из «Must» переместились в «Should».
- Сознательно сократил границы. Первый релиз должен был предложить одну стандартную программу лояльности вместо настраиваемой. По данным кейса, это сократило работу над программой лояльности примерно до двух-трёх спринтов вместо четырёх-шести.
- Подкрепил сокращение фактами. Интервью с несколькими клиентами показали схожие потребности, и это поддержало стандартный вариант.
Результат: обе функции были поставлены инкрементами за пять спринтов, то есть за десять недель.
Уроки, которые можно применить#
- Используйте BACCM как инструмент быстрой постановки задачи. Когда времени мало, быстрый проход по изменению, потребности, решению, заинтересованным сторонам, ценности и контексту даёт всем общую картину и показывает, чего вы ещё не знаете. Он помещается на одной странице и укладывается в одну короткую встречу.
- Планируйте с учётом людей, а не только приоритетов. Если эксперты по главному пункту недоступны, начните с работы, которую можно анализировать уже сейчас, а время ожидания используйте для изучения приоритетного пункта. Отразите эту зависимость в плане и назначьте дату, когда к ней вернуться.
- Проводите MoSCoW дважды. Первый проход обычно перегружает «Must». На втором проходе спросите о каждом пункте: можем ли мы выпустить релиз без него? Если да, это не Must.
- Сначала ищите стандартный вариант. Настраиваемость умножает трудозатраты. Спросите, закрывает ли один стандартный вариант потребности большинства клиентов в первом релизе; настройки можно добавить позже, если реальное использование покажет, что они нужны.
- Подкрепляйте сокращение границ данными от клиентов. Несколько коротких интервью с клиентами помогают отстоять сокращение гораздо лучше, чем мнения.
- Держите объём документации соразмерным. При адаптивном подходе документируйте то, что нужно команде для создания и тестирования инкремента, и немногим больше.
Как применить это в «Мастерской» (вымышленной сети веломастерских): допустим, владелец хочет сразу и онлайн-запись, и заказ запчастей с интеграцией с поставщиком, но ИТ-специалист поставщика две недели в отъезде. Аналитик начинает с записи, отправляет поставщику короткий список вопросов и проводит MoSCoW по заказу запчастей. Второй проход переносит «автоматический дозаказ» из Must в Should, и первый релиз предлагает ручной заказ через портал поставщика.
Источники#
- R. Leyton. Case studies “How Do I Identify What Needs to Be Done” (гибкий и каскадный подходы). IIBA, 2021. Гибкий подход: программа лояльности и биллинг.
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Модель базовых понятий бизнес-анализа (BACCM).