Определение продукта в LeSS. Часть 1.

Перевод оригинальной статьи Сезарио Рамоса.

Это первая часть серии блог-постов об определении продукта в LeSS.

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

Узкое определение продукта создает различного рода проблемы для продуктовой группы. Узкое определение продукта локально оптимизирует производительность команд за счет производительности группы. Системная диаграмма (CLD) ниже объясняет эту динамику. 

(См. Этот блог-пост для краткого обзора обозначения CLD.)

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

Устраните локальную оптимизацию узкого определения продукта

Часто используемое определение продукта – «что-то, что сделано для продажи». Продукт обеспечивает способ извлечения прибыли.

  • У продукта есть пользователи, люди;
  • Продукт предоставляет базовую функциональность, которая закрывает проблемы и отвечает потребностям пользователей;
  • Продукт имеет бизнес-модель, источники доходов, независимую прибыль и убыток (P&L) или возврат инвестиций (ROI).
  • Продукт разрабатывается и поддерживается системой людей, компонентов и процессов.

Определение продукта обуславливает, какие организационные элементы (люди, компоненты, процессы и системы) необходимы для разработки и запуска продукта. Если ваш продукт – «Ипотека», то Владельцем Продукта, вероятно, является человек из бизнеса, который понимает рынок. Бэклог Продукта может содержать такие элементы, как «Кредитные предложения для малого бизнеса», а пользователи, вероятно, будут клиентами, которые платят деньги. Ипотека – это широкое определение продукта, когда оно содержит все детали, необходимые для создания комплексного решения для конечного пользователя.

Как определить продукт?

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

Шаг 1 — Определите необходимые организационные элементы для разработки и поддержки продукта.

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

Типичные шаги для достижения этой цели:

  • Определите типичных внешних конечных пользователей для вашей группы.
  • Определите постоянные потребности, которые эти конечные пользователи хотят решить, или задачи, которые они должны выполнить.
  • Определите фичи для каждого из пользователей, которые они используют для удовлетворения потребностей или выполнения своей работы.
  • Определите каналы, через которые пользователи используют функции для удовлетворения своих потребностей/проблем и т. д. (Например, Браузер, Приложение, API, Connector или Helpdesk)
  • Затем, определите организационные элементы, которые вам необходимы для разработки фичи и удовлетворения пользователя. Сделайте это, изучая путь, как каждый элемент функциональности проходит через вашу организацию в руки клиента. Начните с каналов, проработайте компоненты, системы, людей и процессы до конца пользовательского пути.

Шаг 2 – Проясните источники доходов

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

На этом шаге задайте вопросы вопросы: “Производят ли идентифицированные организационные элементы продукт, который генерирует доход для организации? Или есть недостающие части для этого?”. Также неплохо найти ответы на следующие вопросы:

  • Как элементы вместе генерируют деньги? Например, может ли определение продукта иметь плату за использование? Продажа активов? Абонентская плата? Лицензирование? Если нет, что нужно добавить к определению продукта?
  • Имеет ли определение продукта независимый P&L? Если нет, то какие организационные элементы отсутствуют? 
  • Какие KPI можно назначить определению продукта? Например, можете ли вы назначить увеличение валового дохода? Увеличение новых клиентов? Удовлетворенность клиентов?

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

Определение продукта завершено?

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

С такой большой группой вы можете спросить себя: «Как я могу создать эффективные кросс-функциональные команды, которые включают все эти компетенции? В случае более чем десяти групп, мы рекомендуем организовать команды среди Области Ценностей  и содержать зависимости для каждой области.

Это тема моего следующего блога.

Работаем с ценностями в Скраме (часть 3)

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

Движок обратной связи

Известна латинская сентенция: Turbato melius capiuntur flumine pisces, что буквально означает «в мутной воде рыба ловится лучше». В одной из басен древнегреческого поэта Эзопа говорится о рыбаке, который мутил воду вокруг сетей, загоняя туда ослеплённую рыбу. Для поддержания ценностей нужна прозрачность и частые циклы обратной связи, чтобы команда понимала куда плывет. Поэтому Скрам-команды инспектируют и адаптируют ценности и взаимоотношения на Ретроспективе Спринта. 

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

  • Скрам-мастер дает каждому карточки: две зеленые и одну красную. 
  • Скрам-мастер просит написать обратную связь коллегам, опираясь на примеры конкретного поведения (вторая часть). Зеленая карточка — поведение, поддерживающее ценности, красная — нарушающее их. Обратная связь дается в формате ненасильственной коммуникации. Она может быть адресована как всей команде, так  и конкретному человеку. 
  • Карточки зачитываются по очереди, а Скрам-мастер фасилитирует открытый диалог, помогая команде высказываться без оценок, интерпретаций и обвинений. 

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

Читать далее «Работаем с ценностями в Скраме (часть 3)»

Работаем с ценностями в Скраме (часть 2)

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

Алгоритм формулирования ценностей

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

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

Для формулировки ценностей я использую алгоритм, позаимствованный в книге Culture Engine:

  • Формулировка ценностей (1-2 слова)
  • Определение и калибровка ценностей (несколько предложений)
  • “Я” формулировки конкретного поведения (несколько примеров).

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

Читать далее «Работаем с ценностями в Скраме (часть 2)»

Стабильные команды**

http://scrumbook.org.datasenter.no/images/StableTeams.jpg

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

✥ ✥ ✥ 

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

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

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

  • администрирования, чтобы отслеживать, над чем работают люди;
  • сниженной эффективности, так как командам нужно интегрировать нового участника (эффективно создавая новую команду), которому в свою очередь нужно узнавать о команде и продукте;
  • действия «закона Брукса» («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»).

Если команды формируются из пула ресурсов, утилизация ресурсов часто приводит к многозадачности, когда люди распределяются по нескольким командам и часто по нескольким продуктам. Добавьте к таким командам меняющиеся требования, и нестабильность становится просто невыносимой. Стабильные и нестабильные части системы должны быть сбалансированы, поэтому там нужно что-то изменить. Много лет эту задачу решали с помощью “заморозки” требований, чтобы постоянно меняющиеся ресурсы могли поставить продукт в прогнозируемый (хотя бы примерно) срок. Жесткая фиксация требований к продукту не позволяет учиться и игнорирует изменения, которые могут создать Наибольшую ценность, поэтому это не хорошее решение.

Поэтому:

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

Читать далее «Стабильные команды**»

Работаем с ценностями в Скраме (часть 1)

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

Дух игры

Ценности впервые были описаны в книге Кен Швабера и Майкла Биддла “Agile Software Development With Scrum” (2001). На вопрос “зачем ценности в Скраме?” у меня есть несколько ответов. Во первых, ценности определяют дух игры: культуру, незримую составляющую, маяки, на которые можно опереться в случае отсутствия полной ясности. Это этический и моральный кодекс Скрама. 

Описание фреймворка умещается на семнадцати страницах. Но оно не описывают все ситуации, с которыми столкнутся команды. Ценности похожи на принципы фэйр-плей в спорте.

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

Читать далее «Работаем с ценностями в Скраме (часть 1)»

Незаметный Скрам-Мастер*

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

✥ ✥ ✥

Во время Ежедневного Скрама участники Команды Разработки не обсуждают текущие вопросы друг с другом, а обращаются непосредственно к Скрам-Мастеру. Команда постоянно ожидает указаний или одобрения, прежде чем начать работу. То есть они не берут на себя ответственность за событие и не действуют как команда.

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

Поэтому:

Выполняя роль владельца Скрам-процесса, Скрам-Мастер должен убедиться, что команда берет на себя ответственность за Ежедневный Скрам.

Читать далее «Незаметный Скрам-Мастер*»

7 принципов упрощения организаций

Перевод оригинальной статьи Баса Водди и Крэйга Лармана.

Зачем компаниях Аджайл или LeSS? К сожалению, многие организации стремятся повысить эффективность отдельных людей и команд. Фокусируясь на отдельных активностях, “выхлопах” (outputs), скорости (velocity) и утилизации ресурсов, они не осознают, что это обычно приводит к снижению доставляемой ценности и адаптивности, удлинению циклов разработки фич для клиентов. LeSS нацелен не на локальные оптимизации (такие как рост персональной эффективности), а на оптимизацию организации для повышения ценности, доставляемой клиентам, и адаптивности —  скорости, с которой организация может менять направление разработки, опираясь на обучение.

Как же построить гибкую и адаптивную организацию? Упростив ее!

Читать далее «7 принципов упрощения организаций»

Вчерашняя погода*

http://scrumbook.org.datasenter.no/images/custom_text_shelter_14054-2.png

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

✥ ✥ ✥ 

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

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

В некоторых организациях на команды давят, требуя доставлять больше, чем они могут. Используя концепции «stretch goal» или «BHAG (Big Hairy Audacious Goal)», объем работ кажется захватывающим и привлекательным. Но подобные цели разрушают автономность команд и идут вразрез с подходом кайдзен (см. Кайдзен и Кайкаку).

Поэтому:

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

Читать далее «Вчерашняя погода*»

Повышайте Agility при помощи PBR

Уточнение Бэклога Продукта (PBR) в однокомандном Скраме не является официальным событием. В масштабированной разработке (LeSS, Nexus) комплексность продукта резко возрастает, и PBR становится обязательным каждый Спринт. В этой статье я объясню, как с помощью PBR повысить организационную гибкость (Agility) продуктовой группы.

Вопрос молодому Скрам-мастеру

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

Я спросил: «Какое событие Скрама ты бы хотела “отладить” в первую очередь: Планирование Спринта, Ежедневный Скрам или что-то еще?» Подумав, она ответила: «Планирование Спринта». Ответ логичный, ведь Планирование Спринта — первое событие в любом Спринте. Так ли очевиден ответ?

Читать далее «Повышайте Agility при помощи PBR»

Скрам-мастер — «менеджерская» роль

Перевод оригинальной статьи Гюнтера Верхейена.

В традиционной модели «менеджер» — это тот, кто занимает более высокое положение в иерархии.

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

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

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

Рассмотрим идею о том, что Скрам-мастер — это «менеджерская» роль.

В отличие от традиционного «менеждера», у Скрам-мастера нет формальной власти над Командой Разработки или работой. Скрам-мастер ведет управление через Скрам-процесс. В организации он отвечает за эффективность использования Скрама командами, отделами и организацией. Скрам-мастер отвечает за понимание и реализацию Скрама. Это настоящая менеджерская задача: с подотчетностью, сферой деятельности и ответственностью, но часто саму роль Скрам-мастера упускают из виду и игнорируют.

Скрам-мастер — это действительно менеджер, но не в традиционном смысле. Очевидно, что Скрам-мастер не управляет бюджетом, людьми, работой и задачами. За возврат инвестиций отвечают Владельцы Продуктов. Командами управляют сами собой. Однако для возникновения самоорганизации в Скраме нужны цели и границы. Скрам-мастер управляет границами, самоорганизации: использует таймбоксы для управления рисками и фокусом, кросс-функциональную коллаборацию, “готовые” к релизу результаты, валидированное обучение.

Скрам-процесс обеспечивает командам каркас для творчества и коллективного создания ценности. Он задает ритм и закладывает основу для открытий. Скрам-мастер управляет Скрам-процессом, задействуя различные сервисы. И в них, как в зеркале, отражается состояние Скрама в организации. Выгоды, получаемые от Скрама, зависят от качества сервисов, которые оказывает Скрам-мастер. Или это не так?

Читать далее «Скрам-мастер — «менеджерская» роль»