И теперь 3 главных ошибки. Если их совершать снова и снова, боюсь, что из юного PO можно перейти в роль бывшего PO. Начало тут и тут.
8. Увольнять из dev team никого нельзя
Иначе вся команда будет демотивирована
В реальности самоорганизованная команда не боится обсудить проблемы, честно озвучить другому участнику команды, что «вообще-то мы тут не поболтать собрались». К примеру, если в команде появился человек — прокрастинатор, на ретро все это обсудили, поняли, что «так дело не пойдет» и со словами "This is Sparta"… попрощались с ним. (Даже не знаю, как дальше работать в такой команде :)
РО — он менеджер, владелец бюджета, и, соответственно, если он совсем не погружается в дела «самоорганизованной» команды и не следит за ее «здоровьем», маловероятно, что подобная история закончится хорошо. Вы с командой попробовали разное, но не помогает? Тогда увольнение, предупреждение и все в этом духе — твоя зона ответственности. Хоть лучшие практики и говорят о том, что такие решения должны приниматься командой, крайне мало из них дорастает до такого психологического уровня взаимодействия.
Хочу рассказать про два случая из своей практики. У нашей команды есть 2 крутых примера.
9. Любое дело надо довести до конца
Нет, не любое. И вообще крайне редкое дело нужно доводить до конца в продуктовой разработке. Разумеется если тот самый конец верно определен :)
Например, вы придумали фичу, погрумили ее, она живёт в воображении, прототип прекрасен, а ещё у нее вон та кнопочка синяя с белой каёмочкой. К счастью существует спасительное mvp, которое не позволит тебе сделать совсем лишнее. Клиент будет получать в первую очередь самое необходимое, а только после — что-то нужное, потом дополнительное и только когда-нибудь что-то для души.
Многие начинающие PO переживают, что ни одну свою задумку (epic) не сделал «от и до», это чувство заставляет брать задачи, которые принесут мало ценности, но потратят много ресурсов, клиент тем временем будет страдать от проблемы, которую ты мог бы быстро и просто решить.
Такой путь будет работать сам собой, если задачи имеют точно описанные user story, нарисую как это выглядит:
10. Работай и бойся потерять работу
Приходишь в новую компанию/запускаешь стартап, но при этом ты работаешь и принимаешь решения по опыту прошлого. В новых реалиях обязательно найдутся люди/правила/мнения, которые расскажут тебе, что тут «так нельзя», а вот «так не принято», а «это слово вообще не произноси. Подобное становится искусственным ограничением для продукта, оно зачастую основано лишь на домыслах, субъективных мнениях и страхе других людей. Но ты этого не знаешь, и строишь вокруг своего продукта бетонные стены, которые ему же и не дают развиваться.
Пример. Наша команда полгода просидела без серверов для продукта, потому что „такие правила — все тут ждут сервера по 6 месяцев“, стоят они как Ferrari F60 America, а облачные хостинги запрещены. Ок, ждем — сервер под столом не так уж плох.
Рискни, попробуй. Не вышло? Пробуй еще! Или у тебя выйдет не строить бетонную стену или получится сломать, или самое ужасное, что может случиться — ты узнаешь, что снести ее действительно невозможно. Но по пути ты максимально узнаешь контекст проблемы, найдешь больше вариантов решений. Да, скорее всего ты кого-то сильно разозлишь своими попытками сломать то, что сломать нельзя. Никто не накажет тебя за попытку сделать все возможное для продукта и компании, и уже тем более не уволят :) первые раза три — точно. На четвертый — возможно, но зато ты сделал все, что мог.
Кстати, сейчас мы хостимся в облаке, и разворачиваем виртуальные машины за 1 минуту в том количестве, в котором посчитаем нужным. И я все еще тут работаю :)
8. Увольнять из dev team никого нельзя
Иначе вся команда будет демотивирована
Да, в классике жанра скрам-команда самоорганизованная, а ты сидишь на «троне» и приоритизируешь беклог. Как бы не так)
В реальности самоорганизованная команда не боится обсудить проблемы, честно озвучить другому участнику команды, что «вообще-то мы тут не поболтать собрались». К примеру, если в команде появился человек — прокрастинатор, на ретро все это обсудили, поняли, что «так дело не пойдет» и со словами "This is Sparta"… попрощались с ним. (Даже не знаю, как дальше работать в такой команде :)
РО — он менеджер, владелец бюджета, и, соответственно, если он совсем не погружается в дела «самоорганизованной» команды и не следит за ее «здоровьем», маловероятно, что подобная история закончится хорошо. Вы с командой попробовали разное, но не помогает? Тогда увольнение, предупреждение и все в этом духе — твоя зона ответственности. Хоть лучшие практики и говорят о том, что такие решения должны приниматься командой, крайне мало из них дорастает до такого психологического уровня взаимодействия.
Хочу рассказать про два случая из своей практики. У нашей команды есть 2 крутых примера.
- Пример первый. Вынужденный. разработчик принимал участие в планировании, обсуждал фичи, поддерживал, грумил, а потом мог сказать: «Ребят, у меня обучение на 2 месяца». Возвращался, все опять по кругу. Но сама команда ничего не могла ему сказать, не хотела и молчала, и часть работ останавливалась, вся команда тянула эти запланированные задачи и, конечно, многое не успевала. Я долго за этим наблюдала, разговаривала с разработчиком, в итоге мы с ним попрощались. И ничего со здоровьем команды не случилось, все сказали: «Да, верное решение, но вообще хорошо бы принимать такие решения всей командой» (доросли :)).
- Пример второй. Положительный. Разработчик страдал от прокрастинации, совершенно не ясно, чем занимался. Но на ретро команда сказала, что так не годится, описали плюсы и минусы человека из их же команды. И знаете что? Мы поняли, что просто не понимали друг друга. Разработчик начал работать по-другому, он много успевает, качественнее пишет. То есть ретро хватило. Так что просветление команды иногда тоже наступают, если есть хороший скрам-мастер, который поможет начать говорить.
9. Любое дело надо довести до конца
Нет, не любое. И вообще крайне редкое дело нужно доводить до конца в продуктовой разработке. Разумеется если тот самый конец верно определен :)
Например, вы придумали фичу, погрумили ее, она живёт в воображении, прототип прекрасен, а ещё у нее вон та кнопочка синяя с белой каёмочкой. К счастью существует спасительное mvp, которое не позволит тебе сделать совсем лишнее. Клиент будет получать в первую очередь самое необходимое, а только после — что-то нужное, потом дополнительное и только когда-нибудь что-то для души.
Многие начинающие PO переживают, что ни одну свою задумку (epic) не сделал «от и до», это чувство заставляет брать задачи, которые принесут мало ценности, но потратят много ресурсов, клиент тем временем будет страдать от проблемы, которую ты мог бы быстро и просто решить.
Выключить перфекциониста и чувство прекрасного на время. Настанет момент, когда клиент будет достаточно удовлетворен, и можно будет заняться всеми задачами в конце беклога (правда, сама ещё не была на этой стадии развития продукта, но осознание этого помогает с легкостью принимать решения).
Такой путь будет работать сам собой, если задачи имеют точно описанные user story, нарисую как это выглядит:
10. Работай и бойся потерять работу
Приходишь в новую компанию/запускаешь стартап, но при этом ты работаешь и принимаешь решения по опыту прошлого. В новых реалиях обязательно найдутся люди/правила/мнения, которые расскажут тебе, что тут «так нельзя», а вот «так не принято», а «это слово вообще не произноси. Подобное становится искусственным ограничением для продукта, оно зачастую основано лишь на домыслах, субъективных мнениях и страхе других людей. Но ты этого не знаешь, и строишь вокруг своего продукта бетонные стены, которые ему же и не дают развиваться.
Пример. Наша команда полгода просидела без серверов для продукта, потому что „такие правила — все тут ждут сервера по 6 месяцев“, стоят они как Ferrari F60 America, а облачные хостинги запрещены. Ок, ждем — сервер под столом не так уж плох.
Рискни, попробуй. Не вышло? Пробуй еще! Или у тебя выйдет не строить бетонную стену или получится сломать, или самое ужасное, что может случиться — ты узнаешь, что снести ее действительно невозможно. Но по пути ты максимально узнаешь контекст проблемы, найдешь больше вариантов решений. Да, скорее всего ты кого-то сильно разозлишь своими попытками сломать то, что сломать нельзя. Никто не накажет тебя за попытку сделать все возможное для продукта и компании, и уже тем более не уволят :) первые раза три — точно. На четвертый — возможно, но зато ты сделал все, что мог.
Кстати, сейчас мы хостимся в облаке, и разворачиваем виртуальные машины за 1 минуту в том количестве, в котором посчитаем нужным. И я все еще тут работаю :)