Как стать автором
Обновить

10 ошибок юного PO (заключение)

Время на прочтение3 мин
Количество просмотров4.4K
И теперь 3 главных ошибки. Если их совершать снова и снова, боюсь, что из юного PO можно перейти в роль бывшего PO. Начало тут и тут.


8. Увольнять из dev team никого нельзя
Иначе вся команда будет демотивирована

Да, в классике жанра скрам-команда самоорганизованная, а ты сидишь на «троне» и приоритизируешь беклог. Как бы не так) 

В реальности самоорганизованная команда не боится обсудить проблемы, честно озвучить другому участнику команды, что «вообще-то мы тут не поболтать собрались». К примеру, если в команде появился человек — прокрастинатор, на ретро все это обсудили, поняли, что «так дело не пойдет» и  со словами "This is Sparta"… попрощались с ним. (Даже не знаю, как дальше работать в такой команде :) 

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

Хочу рассказать про два случая из своей практики. У нашей команды есть 2 крутых примера. 

  • Пример первый. Вынужденный. разработчик принимал участие в планировании, обсуждал фичи, поддерживал, грумил, а потом мог сказать: «Ребят, у меня обучение на 2 месяца». Возвращался, все опять по кругу. Но сама команда ничего не могла ему сказать, не хотела и молчала, и часть работ останавливалась, вся команда тянула эти запланированные задачи и, конечно, многое не успевала. Я долго за этим наблюдала, разговаривала с разработчиком, в итоге мы с ним попрощались. И ничего со здоровьем команды не случилось, все сказали: «Да, верное решение, но вообще хорошо бы принимать такие решения всей командой» (доросли :)). 
  • Пример второй. Положительный.  Разработчик страдал от прокрастинации, совершенно не ясно, чем занимался. Но на ретро команда сказала, что так не годится, описали плюсы и минусы человека из их же команды. И знаете что? Мы поняли, что просто не понимали друг друга. Разработчик начал работать по-другому, он много успевает, качественнее пишет. То есть ретро хватило. Так что просветление команды иногда тоже наступают, если есть хороший скрам-мастер, который поможет начать говорить.

9. Любое дело надо довести до конца

Нет, не любое. И  вообще крайне редкое дело нужно доводить до конца в продуктовой разработке. Разумеется если тот самый конец верно определен :) 

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

Многие начинающие PO переживают, что ни одну свою задумку (epic) не сделал «от и до», это чувство заставляет брать задачи, которые принесут мало ценности, но потратят много ресурсов, клиент тем временем будет страдать от проблемы, которую ты мог бы быстро и просто решить. 

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

Такой путь будет работать сам собой, если задачи имеют точно описанные user story, нарисую как это выглядит: 



10. Работай и бойся потерять работу

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

Пример. Наша команда полгода просидела без серверов для продукта, потому что „такие правила — все тут ждут сервера по 6 месяцев“, стоят они как Ferrari F60 America, а облачные хостинги запрещены. Ок, ждем — сервер под столом не так уж плох.

Рискни, попробуй. Не вышло? Пробуй еще! Или у тебя выйдет не строить бетонную стену или получится сломать, или самое ужасное, что может случиться — ты узнаешь, что снести ее действительно невозможно. Но по пути ты максимально узнаешь контекст проблемы, найдешь больше вариантов решений. Да, скорее всего ты кого-то сильно разозлишь своими попытками сломать то, что сломать нельзя. Никто не накажет тебя за попытку сделать все возможное для продукта и компании, и уже тем более не уволят :) первые раза три — точно. На четвертый — возможно, но зато ты сделал все, что мог. 

Кстати, сейчас мы хостимся в облаке, и разворачиваем виртуальные машины за 1 минуту в том количестве, в котором посчитаем нужным. И я все еще тут работаю :)
Теги:
Хабы:
Всего голосов 15: ↑11 и ↓4+7
Комментарии26

Публикации

Информация

Сайт
www.gpnbonus.ru
Дата регистрации
Дата основания
1995
Численность
Неизвестно
Местоположение
Россия

Истории