Обо всем понемногу и об Agile-позитиве

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

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

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

Так получилось, что я вышла и сразу же ретро, а на следующей день планирование и все это в 4-ёх командах сразу. Понятное дело, что это тяжело, но зато мы, наконец, договорились, что будем выращивать своих скрам-мастеров, потому что меня на всех не хватает. Даже собрались с этими самыми будущими мастерами и обсудили, кто с какой командой желает поработать. Получится у меня 2 команды, им каждому по 1. Я наконец-то разгружусь и у меня будет больше времени на остальные свои активности.

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

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

И в заключении – наш главный скептик, который препятствовал всякому Agile-движению, уходит. Это честно, груз с души, потому что работать со мной он не хотел. Когда стальные ребята уже побежали, организовались в команды, на daily собираются, в story point оценивают, он стоит сбоку и бухтит. Конечно, ему было тяжело быть одному. Но вылезти из своей этой роли ему не позволяло, видимо, собственное достоинство. Поэтому уходит. Сейчас на последнем планировании сидел молчал, уже даже не троллил и что-то рисовал в своей тетрадочке.

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

Позитивный Agile научил меня с позитивом относиться ко всему и искать хорошее даже в каких-то негативных моментах. Впереди меня ждет AgileConf 2017, встреча с прошлыми коллегами, Agile-митапы в Новосибирске, выступление на продуктовой тусе Сибири, обучение команд и еще много всего интересного. Это ли не прелесть 🙂

photo5393400543843559468
А это нас вчера выперли из всех переговорок и нам пришлось планироваться прямо в нашем open space))

 

 

 

Advertisements

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

Неделю назад мы учились с воскресенья по вторник. К нам приезжала Даша Рыжкова и читала тренинг 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

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

Ретро на пляже

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

Дальше хочется поделиться, как одновременно вывезти почти 30 человек вне офиса в рабочий день для плодотворной работы? Все-таки такие большие мероприятия я провожу не каждый день 🙂

  1. Определиться с целью мероприятия, ведь не все вопросы можно решить на свежем воздухе без возможности визуализации.
  2. Определиться с местом, убедиться, что погода будет благоволить. Мы выбрали пляж, потому что давно не выбирались туда всей командой. Неплохо съездить на местность перед окончательным выбором, понять, как сможем расположиться.
  3. Продумать как добираться, хватит ли машин или понадобится такси. Нам повезло, половина была на машинах, которая забрала вторую половину 🙂
  4. Выбрать день и время. Как показала практика, лучше проводить во второй половине дня, чтобы после мероприятия не пришлось возвращаться в офис. 
  5. Организовать перекус, особенно, если работаете больше 2-ух часов. У нас получилось 3 часа, закупили фрукты, печенье, взяли питье. Обязательно мешок под мусор, одноразовую посуду, салфетки не забыть!
  6. Организовать рабочие места. Сюда входят и письменные принадлежности, и пледы. У нас так получилось, что планшетов в офисе совсем не нашли, пришлось импровизировать и брать из дома детские книги формата А4, чтобы было удобно писать. А коллеги из продуктовой команды поделились 2-мя биванами 🙂
  7. Продумать agenda встречи. Это самое важное для продуктивной работы. Ведь ретроспектива – главная встреча скрам мастера, которую он должен организовать хорошо и чтобы был выхлоп.

О структуре ретро

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

Для киносценария надо заполнить:

  1. жанр фильма
  2. название фильма
  3. кто главный герой
  4. с какими трудностями сталкивается главный герой
  5. как он их решал или будет решать

Для отчета:

  • сколько из бюджета потрачено story point на фильм
  • сколько киноляпов (багов) допущено в результате
  • сколько было незапланированных сюжетных линий (задач)
  • удалось ли достичь целей съемки фильма (спринта)?

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

Снова на тренинг для скрам мастеров

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

#Пятница

Сегодня прошёл первый день тренинга для #Scrum мастеров. Полезно было ещё раз вспомнить все основы, зарядиться и задать вопросы. Но и новая информация тоже была.

IMG_02771
Так Саша рассказал про хитрости планирования и зачем декомпозировать задачи на более мелкие, чтобы влезали примерно в 1 человеко-день. Это делается не ради бюрократии или потому что кому-то так хочется. А ради следующего профита:

  1. Можно отдать в тестирование намного раньше и не грузить тестировщиков под конец спринта. Чем раньше мы обнаружим ошибку, тем дешевле ее исправлять.
  2. Можно работать над большой задачей вдвоём, а это ускорит разработку и проучите опыт командной работы 
  3. На #Dailyscrum есть что рассказывать
  4. Видя полную декомпозицию, понимаешь, где в задаче может что-то пойти не так и даёшь более полную оценку
  5. Можешь раньше доставлять кусочек фичи и уже давать ей пользоваться
    🙂

Кстати, было очень крутое задание на принципы #Agile. Угадайте, какие принципы #Agile нарушены в каждом кейсе? 1 кейс – 1 нарушенный принцип. Они везде разные 😉

#Суббота

Закончился второй день тренинга. Из инсайтов, о роли #Scrum мастера – это не только человек, который:

  1. Следит за соблюдением фреймворка
  2. Насаждает #Agile культуру
  3. Создаёт крутую команду

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

К инструментам, которые добавляют #Прозрачность, можно отнести:

  • sprint planning с декомпозированными задачами (об этом писала вчера)
  • daily scrum meeting, который позволяет составить всем вместе план на день и решить, как справляться с трудностями
  • burn down chart и kanban доска визуализируют процесс движения к цели спринта
  • #Velocity очень хитрая штука. Считаем по реально сделанным задачам. Не важно сколько ты набрал и запустил в прогресс. Важно, сколько ты реально можешь довести до конца, ведь только то, что готово ценно и можно использовать. Несделанные задачи отправляем на следующий спринт без переоценки! Наша задача в дальнейшем выравнивать скорость спринтов, чтобы не было перекосов. 
  • definition of done, дающий понимание что значит задача готова 
  • sprint goal, которую формулируем в виде ценности, а не в количестве разработанных фич 
  • И т.д.

А какие инструменты, из перечисленных выше, используете вы?

Кстати, на следующих выходных тоже буду учиться 🙂

Перезагрузка ретроспектив

Минутка самокритики: Друзья, времени катастрофически стало не хватать на блог, но я стараюсь не забивать. Мыслей, событий, результатов очень много, буду стараться  сюда помещать это. Недавно, кстати, подумывала перевести его на medium, чтобы осовремениться, но пока руки не доходят.

Ладно, сегодняшняя тема довольно банальная. Поговорим о перезагрузке ретроспектив. Как и водится – это главная встреча scrum мастера и он должен проводить их хорошо. Часто эти встречи не любят, проводят раз в полугодие и все такое.

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

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

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

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

Первая ретроспектива

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

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

Обычная фраза с командного ретро:

Команда не должна брать в работу непонятные и неполные задачи.

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

22955_regenbogenballНадо ли говорить, что я была не довольна такой ретроспективой? Сама ведь выбрала старый формат 🙂 Остальным вроде понравилось, потому что хоть кто-то начал фасилитировать встречи, не давать гудеть одновременно всем и передавать токен..

Следующие встречи

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

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

Люди пришли, расселись по 4-ём столам. Я выдала им флипчарты, маркеры, стикеры, клей, распечатанные задачи из Jira.

  • Попросила вспомнить цель своего спринта и зафиксировать на бумаге. Было интересно, вспомнят ли. Но все прекрасно держали ее в голове! Это была приятная неожиданность.
  • Попросила разделить все задачи на 2 кучки:
    1. Мы завершили задачу и она идет в релиз
    2. Что-то пошло не так и с задачей не справились
  • Посчитать количество выполненных story point по кучке #1 и зафиксировать на флипчарте. Это их командный маячок, сколько они реально доводят до конца и делают прироста к будущему продукту.
  • Попросила проанализировать, что помешало им выполнить задачки из кучки #2. Люди реально видели то, что им мешает и здраво формулировали. Фраз типа “луна была в тельце” нигде не появилось, что не может не радовать 🙂
    • Кстати, на этом этапе выяснилось, что у меня есть команда, которая абсолютно перевыполнила план и у нее не было этой кучки. Пришлось на ходу переориентироваться и просить ребят подумать над тем, а что им помогло в этом.
  • Когда все справились с вышеперечисленными задачами я попросила придумать, как они будут в следующий раз справляться с подобными проблемами. И… люди впали в ступор. Реально, они сидели и говорили мне с честными глазами, что ничего нельзя сделать, что проблема не на их стороне, что мы заложники ситуации и прочее прочее. Ведь к такому повороту событий жизнь их не готовила, а раньше они обсуждали только командные правила..

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

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

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

0_ab98c_5010f11d_XXL

И кстати, я прошла испытательный срок досрочно. Мне его закрывали со словами: “Чтобы ты от нас не сбежала”. Я считаю это довольно неплохим результатом и даже немного горжусь собой 🙂

Главная заповедь 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

Теперь:

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

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

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