Снова на тренинг для владельцев продуктов

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

photo5298693487014815775

#Воскресенье

Прошёл первый день тренинга. Из интересного эволюционный цикл владельца продукта.

Самая первая ступень – junior

  • Он способен приоритезировать backlog
  • Взять продуктовую гипотезу и проверить ее
  • Может общаться с командой
  • Переход на следующую ступень занимает, как правило, 3-6 месяцев

Следующая ступень – эксперт 

  • Он способен формулировать гипотезы и проверять их
  • Может сформировать набор экспериментов
  • Общается со стейкхолдерами (заинтересованными лицами)
  • Способен построить роадмап развития продукта
  • У него есть видение продукта
  • Получает бюджет по запросу
  • Переход в самый верх может занять больше 1 года 

Мини CEO 🤘

  • Распоряжается бюджетом самостоятельно
  • Нанимает себе людей 

photo5298693487014815774

И беда в том, что на рынке почти нет мини CEO. А если есть, то таких людей очень сложно удержать в рамках компании, чтобы они не ушли запускать что-нибудь своё. Компаниям приходится набирать junior и обучают их.

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

Если продукт большой и сложный, тем более не допускайте комитеты. Дробите его на кусочки и команды. Хорошее правило 1 владелец продукта – не более 3 команд. Иначе происходит расфокусировка.

#Понедельник

Во второй день обсуждали стейкхолдеров (заинтересованных лиц).

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

  • Будут те, кому ваш бизнес и продукт не все равно, а так же они могут оказать на него достаточное влияние. Выстраивайте с ними партнёрство. Помогайте друг другу, ведь это взаимовыгодно.
  • Есть те, кто оказывает высокое влияние, но вы им не интересны. Старайтесь перевести в предыдущий квадрант, особенно хорошо работает для внутренних стейкхолдеров, либо просто удовлетворять их потребности с наименьшими затратами. Пример внешнего такого стейкхолдера может быть ЦБ. 
  • Кто искренне интересуется, но не оказывает влияние – просто информируйте о ваших делах. 
  • Последний квадрант – не работайте с ними. Трата времени. 

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

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

#Вторник

Вчера был последний день обучения и он был огонь! 🔥🔥🔥

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

До этого мы узнали, что владельцы продуктов бывают трёх степеней крутости:

  1. Jinior
  2. Expert
  3. mini-CEO

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

Для начала, компания понимает, куда она плывёт и зачем. То есть, у неё есть цель, которую она преследует. Для того, чтобы ее достичь, мы формируем value streams, то есть определяем продукты, которые все вместе позволят достичь эту цель. А перед каждым продуктом, соответственно, ставим определенную задачу.

Дальше мы закрепляем за каждым продуктом человека, который будет его двигать вперёд – CPO (chief product officer).
Прорабатываем, сколько нам надо команд, чтобы этот продукт построить. Например, как на картинке, 3 штуки. За каждой командой, в данном случае, закреплён свой владелец продукта и у каждого свой #Backlog.
Если вспомнить эволюцию, то обязанности CPO стоит доверить владельцу уровня mini-CEO, потому что с командами ему будет скучно.

Scrum мастер может быть как один на value stream, так и несколько. Важно не забыть этого человека, потому что именно он будет помогать вашим командам выплывать из болота хаоса.

Чтобы наши владельцы гребли в одном направлении, с определённой периодичностью устраиваем им совместную с CPO встречу по синхронизации – PO synchronize.

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

Подобная организация работы очень популярна сейчас и многие знают ее под названием #Spotify фреймворк. Это проще, чем #SAFe, здесь команды могут работать не только по #Scrum, но и по #Kanban и т.д. Можно отдать выбор инструментария самим командам.

Советую к просмотру видео про инженерную культуру Spotify 🙂

Но как запустить это все безболезненно для компании? Есть несколько шагов:

  1. Запускаем пилотную команду с владельцем продукта и скрам мастером
    • обычно делаем эксперимент 3-4 месяцев
    • ставим амбициозную бизнес цель перед командой, но это не KPI, как правило, она недостижима, а команду мотивируют маленькие победы (успешные спринты, проверенные продуктовые гипотезы)
    • договариваемся о правилах игры на период пилота, как минимум, что никто не может быть уволен, потому будут взлеты и падения
  2. Строим вокруг команды value stream и собираем все косяки, которые могут быть в компании по межкомандному взаимодействию
  3. Масштабируем в рамках компании и достраиваем остальные value streams

Спасибо нашим тренерам за их терпение 🙂

Advertisements

Стратегия изменений. Часть 2.

Или как мы хотели разделиться на команды

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

Было: куча заказчиков, куча менеджеров, одна большая команда

Стало: 2 владелец продукта, 2 скрам мастера, одна большая команда

Изменилось, по-сути, немногое, но не все сразу. Итак, настало время раздербанить большую команду на кусочки. Человек очень много 48 штук. Продукт один, сложный и многоплатформенный.

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

В поисках лучших решений мы стали прибегать к поиску успешных кейсов у коллег по цеху, понятное дело нам надо масштабироваться. Конечно, если смотреть на них, как на одну большую команду из почти 59 человек, они обладают всеми компетенциями, чтобы сделать продукт. Но это мало управляемая толпа, получасовые daily scrum, шестичасовые планирования и неэффективные ретроспективы. Scrum of scrum не спасает, Nexus выглядит непривлекательно. Пока очень круто все учтено у Spotify, но их опыт неповторим, нужно строить что-то свое. Очевидным решением просятся feature teams, а дальше посмотрим.

component-vs-feature-teams.png.pagespeed.ce.NKNnxhQVFQ
Подробнее здесь

Как мы живем сейчас

1

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

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

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

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

Как будет

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

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

3В будущем хочется сделать мобильные команды кроссфункциональными тоже и прийти к одному баклогу. Но это реальность будет проверять мой план на прочность 🙂

 

Главная заповедь scrum мастера

Всем привет! У меня появилась небольшое правило и я хочу им поделиться с вами.

“Каждый день приносить пользу команде, даже если она небольшая”

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

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

Если не делать каждый день маленькую пользу для команд и работать с ними только от ретро к ретро, ничего никуда не сдвинется. Очень быстро все съедут на старые рельсы отсутствия ответственности, не желания работать и двигаться самостоятельно. Люди опять скажут, что ваш Scrum не работает и вообще Agile у нас всегда был 🙂

cf7f964d-dd75-4433-8ebd-6aaaafac3fe2PS: Название заметки у меня родилось в самом ее конце, когда я вспомнила как на тренинге для одной из команд, мы рисовали метафору скрам мастера. Одна команда команда изобразила осьминога, у которого одно щупальце выходило их храма Agile

 

 

Стратегия изменений. Часть 1

Очень вдохновилась тут заметками от Unusual Concept с интервью практикующих agile-коучей и scrum-мастеров. Особенно понравилось интервью с Лешей Пикулевым, и ответ на вопрос:

пикулев
Часть интервью с Лешей

Пытаюсь анализировать, как двигаюсь я. Многие шаги, которые они перечисляют в ответе на вопрос “Вас закинули к новой команде, ваши действия в первый месяц?“, я совершаю сама. Поэтому кажется, что на верном пути, ну и помню, что единственного верного пути нет 🙂

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

Как мы живем сейчас

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

6f81eda2-f26f-4984-b74a-c875487f8d89

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

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

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

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

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

Часть 1.

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

И вводим профессионального скрам-мастера – это я, конечно же, про себя 🙂

6f81eda2-f26f-4984-b74a-c875487f8d89

Теперь:

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

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

Но об этом в следующих сериях…

Заходя в новую компанию

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

Если большинство современных компаний уже отошли от водопада и страдают больше code and fix, то здесь его можно наблюдать в полной мере. В силу некоторых обстоятельств, называть компанию я не буду, но намекну, что это ИТ и финтех, с большой и сложной структурой команд и продуктов. Ну а кто в финтехе простой? 🙂

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

Первые шаги

  1. Познакомиться
    • С компанией. И здесь я имею ввиду не только свои команды, с которыми буду работать, а вообще со всеми, от которых у тебя могут быть внешние зависимости. Важно на первом этапе понять, сколько их может быть, кто из них более непонятный, кто идет на контакт, а кто нет. Сколько вообще здесь уровней иерархии и как ходит информация. Scrum ведь это про общение и взаимодействие.
    • С командой. Буду проводить первое ретро для них. Пока ретроспективы у них были раз в месяц и не привязаны к спринтам. Мы это исправим. На этой встрече я расскажу им о себе и чем буду заниматься. Потому что пока никто не понимает, кто я, зачем я здесь, но все уже меня так долго ждали 🙂
  2. Договориться со всеми, кто хочет завести в компании Scrum и Agile. Пока ты человек снаружи, тебе не все говорят, как есть на самом деле. Когда ты становишься человеком изнутри, делятся более охотно. Эта работа поможет мне лучше понять полный объем работ и то, как действительно обстоят дела. Историю Agile и Scrum в организации, ведь я не в первый раз слышу, что мы это уже делали 3 раза..
  3. Обучить. Рассказать об Agile, из чего состоит Scrum и в чем тонкости.

Что ждет дальше?

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

Сразу после обучения соберемся, обсудим как кто видит этот процесс и все вместе сделаем Impact Mapping трансформации. Подумаем над стратегией изменения.

В завершении хочу сказать, что это не идеальный план. Что наверняка более крутые Agile-коучи мне бы кучу всего еще посоветовали, но это мой путь, он не менее запутанный чем у вас 🙂

7 дней спустя

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

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

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

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

И кстати да, я понимаю, что как коучу мне еще расти и расти!

3 условия применимости scrum

Совсем недавно я сделала небольшой тренинг для одной команды. Как и везде, здесь есть явные евангелисты, благо хоть открытые 🙂 И на самой первой встрече, перед тем как рассказать про scrum, я собрала с них ожидания от тренинга. Одним из ожиданий у главного евангелиста было – “Какие 3 необходимых условия для внедрения/применимости scrum?”

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

Сразу оговорюсь, когда я упоминаю scrum, я за ним обязательно подразумеваю agile, а не голый фреймворк, поэтому все, что я скажу ниже, нужно воспринимать только через эту призму. Scrum без agile – деньги на ветер 🙂

Первое

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

Второе

Продукт, как мы знаем, невозможно сделать в одиночку. Нужна команда, но я здесь немного схитрю и в один пункт затолкаю два 🙂 Потому что просто команда условие необходимое, но недостаточное. Для настоящего успеха спец-операции нужна команда, разделяющая agile-принципы или хотя бы не сопротивляющаяся в 99% случаев, а готовая к изменениям.

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

Забегая немного вперед, все мы с рождения agile, просто со временем обрастаем кучей собственных убеждений, которые мешают нам это понимать 🙂

Третье

Вопрос: сколько нужно agile-коучей, чтобы вкрутить лампочку?

Ответ: ни одного, если нет поддержки сверху

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

Die_drei_Bogatyr

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

По итогам встречи

039

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

Ребята сказали, что нужно доверие, причем не внутри команды (оно уже есть), а сверху, чтобы руководство дало карт-бланш на все, что будет происходить в продуктовых командах.

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