Шесть причин, почему вам нужно обращать больше внимания на Цель Спринта

Цель Спринта — важный компонент Скрама. Он похож на факел, который объединяет команду разработки и помогает ей двигаться во время Спринта. О Цели Спринта не слишком часто говорят, и этой статье я хочу раскрыть глубину этого элемента.

Цель Спринта

Для начала давайте заглянем в Скрам Гайд и посмотрим, как он описывает Цель Спринта:

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

Мы видим, что Цель Спринта «дает гибкость», «объединяет смыслом» и «служит основанием». Я попробую объяснить эти идеи и добавлю еще несколько важных замечаний.

Продолжение этой статьи »


Как жить, если Бэклог Продукта похож на винегрет

Я работаю с большим количеством организаций, которые учатся использовать Скрам, как инструмент для организационной гибкости. Недавно я заметил закономерность: если команда не может сформулировать Цель Спринта, нужно смотреть на их Бэклог Продукта. И, как правило, он похож на мое любимое блюдо, винегрет. Найти смысл в винегрете — непростая задача 🙂

Бэклог продукта

Со временем отдельные случаи превратились в паттерн и я осознал: Цель Спринта является одним из индикаторов здоровья Бэклога Продукта, потому что именно она объединяет смыслом элементы Бэклога Продукта и служит основанием для командной работы. Сам Бэклог Продукта ультимативно определяет успех продукта, это генеральный план для Скрам-команды.

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

Продолжение этой статьи »


Меняем мир к лучшему

Всем привет,

буквально несколько дней назад мы в очередной раз провели сертификационный тренинг Professional Scrum Master (PSM) в Москве. Было так здорово и нам удалось покрыть такое огромное количество материала, что в последний третий день передо мной встала проблема — НЕКУДА ВЕШАТЬ ФЛИП-ЧАРТЫ.

413701269

 

Предлагаю посмотреть несколько роликов с прошедшего тренинга:

  • Видео Скрам

  • Битва Спецификаций и Пользовательских Историй

  • Зефирная битва

  • Ball Point Game

  • Общее видео с тренинга

В Unusual Concepts прекрасная команда людей, у которых глаза «горят». Мы убеждены, что занимаемся не тренингами, не трансформационными изменениями в компаниях, не внедрением Аджайл мышления, Скрама, Канбана и т. д.

Мы — меняем мир к лучшему.

413707317


Планирование релизов

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

Как часто мы выпускаемся?

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

  • Ежеминутно и чаще (да-да, так бывает ;))
  • Ежедневно
  • Еженедельно
  • Ежемесячно
  • Ежеквартально
  • Один-два раза в год или реже

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

На каком этапе развития находится наш продукт?

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

Что происходит на рынке?

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

Полезности.

Для планирования на долгий срок (от месяца и больше) нам понадобится несколько очень полезных вещей:

  • Product Owner и глубокие знания о ваших пользователях
  • Карта историй (Story map) вашего продукта (мы любим http://storiesonboard.com)
  • Backlog с оценками
  • Шаблон кано-взвешивания (можете скачать)

Расскажем по порядку чем и как пользоваться.

Собираем инициативную группу.

Не делайте релизное планирование в одиночку! Даже если вы гениальный продуктовик на этом этапе важно участие ваших коллег и активное вовлечение руководства и прочих заинтересованных лиц. Соберите инициативную группу и предложите поработать над планированием релизов всем вместе. О чем вам предстоит поговорить на этой рабочей встрече?

Выбор фокуса.

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

Теперь из всего собранного нам нужно будет выделить топ 3-5 факторов приоритизации нового функционала продукта на ближайшие 3 месяца (в данном случае мы описываем квартальные релизы).

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

  1. Создании уникальных фич, которых нет ни у кого из конкурентов
  2. Создании фич, которые позволят увеличить продажи новым клиентам
  3. Создании фич, которые позволят сократить наши операционные расходы

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

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

Выбранные факторы для второго релиза могут быть такими:

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

Как вы, наверное, догадались второй релиз будет проходить у нас под кодовым названием: «Помогаем бэкофису».

Оцениваем фичи в бэклоге.

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

На картинке ниже, вы видите 5 элементов бэклога, которые оценены по параметрам из первого примера (уникальность, продажи, снижение расходов).

Backlog

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

Колонки

  • ID — идентификатор фичи (часто ссылка на номер тикета в jira, confluence, wiki, и тп)
  • Imp — Importance или важность (используется для ручного
  • Name — описание фичи
  • Estimate — оценка
  • Sales — фактор приоритизации 1
  • Uniqueness — фактор приоритизации 2
  • Cost reduction — фактор приоритизации 3
  • Total value — общая ценность фичи (высчитывается автоматически)
  • Value percent — доля от общей ценности всех фич (высчитывается автоматически)
  • Cost percent — доля от общей стоимости производства всех фич (высчитывается автоматически)
  • Priority — приоритет (высчитывается автоматически)
  • Exciter — Вау! фича (берется из кано-анализа)
  • Linear — Линейная фича (берется из кано-анализа)
  • Baseline — Базовая фича (берется из кано-анализа)

Все что нам осталось сделать это расставить цифры 0, 1 или 2 напротив точек пересечения названия каждой фичи и каждого из 3х факторов приоритизации. Делается это просто: задайте вопрос инициативной группе по отношению к каждой фиче: «Если мы сделаем эту фичу,  какой эффект она окажет на этот фактор приоритизации?»

  • Если ответ, не окажет никакого влияния, то ставите 0.
  • Если окажет небольшое позитивное влияние, то ставите 1.
  • И если окажет большое положительное влияние, то ставите 2.

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

А как вы делаете релизное планирование? Делимся в комментах…

 


Путешествие по Кеневину, часть 1

О чем вы узнаете в этой статье. Статья получилась длинная, поэтому я решил разделить ее на две части. В первой мы рассмотрим недавно обновленный Кеневин Фреймворк. Это один из самых популярных на данный момент sense-making фреймворков, который помогает понять мир и происходящее в нем. Затем мы поговорим об экспертах и рассмотрим самые типичные передвижения по фреймворку. Во второй части статьи, мы будем передвигаться по доменам Кеневина с помощью увлекательной командной игры “Путешествие по Кеневину”. Вас ожидают многочисленные фото и видео материалы, а также рисованные флип-чарты.

Кеневин Фреймворк. Мой коллега Сергей Дмитриев два года тому назад написал замечательный блог-пост о Кеневине. И в течение последних двух лет особо добавить было нечего, но совсем недавно создатель шотландец Дэйвид Сноуден обновил свою модель. Ко всему прочему, я хочу взглянуть на фреймворк под другим углом, добавить провокационные мысли знаменитого публициста и философа Нассима Талеба, а также модель Management 3.0 Юргена Апелло и рассмотреть наиболее частые переходы из домена в домен. Продолжение этой статьи »


Приоритезация портфеля проектов

image-1

Начав в прошлом году обсуждение по применению Kanban для управления портфелем проектов, мы обещали продолжить публикацию материалов на эту тему. Рассказывая на конференциях и обсуждая с коллегами вопросы, мы неоднократно останавливались на проблеме ПРИОРИТЕЗАЦИИ портфеля.

Что же интересует компании? Вопросы практически у всех одинаковые:

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

Сегодня мне хотелось бы рассказать о применении Serious Games для приоритезации  портфеля  проектов.  Итак, начнем.

Продолжение этой статьи »


Бизнес-дартс: управляем проверкой бизнес моделей

Работая над собственными проектами и проводя множество тренингов по управлению продуктами, мы часто получали обратную связь и натыкались сами, на то, что в инструментах под названием Business Model Canvas (Alex Osterwalder) и Lean Canvas (Ash Maurya), визуально, не очевидны связи указанных в полях данных, так как они расположены в разных частях таблицы, а также не понятно как работать с метриками, если поле одно, а метрики хочется придумать для сущностей в разных полях канваса.

И вот, перед одним из тренингов, мы улучили момент, и решили разобраться, как же можно переработать канвас так, чтобы его содержимое было более логичным визуально и позволяло эффективно работать с метриками. Погрузившись в тему с головой, стали приходить все новые вопросы и мысли: если business canvas придуман для действующего бизнеса, то почему бизнес должен переставать думать об актуальности проблем, которые он решает? Так ли важно unfair advantage в lean canvas? Так ли важно иметь поле key activities, если эти активности требуют вложений и все равно будут фигурировать в затратах (Cost structure)?
Продолжение этой статьи »


Смотрим в будущее (Grooming)

Недавно получил письмо от одного из участников моих тренингов следующего содержания:

Привет, Сергей! У меня короткий вопрос о Grooming-ах… В последнее время наши grooming встречи все больше и больше фокусируются на получении оценок к историям из беклога, однако, некоторые члены команды начинают сетовать по поводу того, что они хотели бы лучше понимать истории до того, как они начнут голосовать по поводу их оценок…

Продолжение этой статьи »