Comments 27
Объявить тему выступления «десять ошибок», а рассказать о трёх.
Интересно было бы почитать, что вы успели сделать за полтора года, как пришли к нынешней точке.
Product Owner – это человек, отвечающий за разработку продукта. Статья в целом именно для РО, но спасибо за комментарий, я учту это в будущем
Что-то я так и не понял — вы скрам-мастер (человек, ведущий скрап, ретро и т.п.) или продакт оунер (человек, ответственный за судьбу развития продукта, а, соответственно, максимально погруженный в этот продукт, его прошлое, настоящее и будущее)? Это же вообще разные вещи, даже не особо-то пересекающиеся. Как вообще можно научиться быть PO — это же как научиться быть директором, при этом не зная директором чего ты будешь. Нереально, как по мне.
Я продукт оунер, не скрам мастер. Да, это абсалютно разные роли. Ни одной из них не возможно научиться, на мой взгляд. Это или есть или нет, и вы это или используете или нет.
Школа РО это не место где из любого сисадмина сделают РО:)
Это коучи( правда, крутых крайне мало) которые подробно рассказывают и разбирают все фреймворки, все сервисы, и инструменты, которых очень много.
Если провести аналогию- вы и так можете быть коммерческим директором какой-нибудь конторы, но зная например не просто основы РСБУ, а ещё и основы МСФО, аудита и управленки — вы всё ещё остаётесь коммерческим директором, но начинаете смотреть на управление совсем иначе и начинаете видеть больше, и скорее всего можете претендовать на место в компании побольше и получше.
У меня от этой статьи свитшот заискрился и смузи забулькал.
Начнем с того, что гибкие методологии не панацея, их применение далеко не всегда оправдано. В Аджайле, в частности, есть куча ролей, которые не являются непосредственно разработчиками. В правильно «настроенном» аджайле на подходящем проекте — это всё может прекрасно работать и оправдывать оверхед в виде дополнительной нагрузки на ФОТ. Иначе, все эти роли просто проедают бюджет без какого-либо существенного вклада в процесс.
Какой же «условный скрам-мастер» захочет допустить, что бы его смысл существования на проекте был подвергнут сомнению. И вот вся эта скам-кодла начинает представление в виде бурной деятельности: неуёмная инициативность, пропаганда методологий и инструментов, круглосуточное желание выслужится, статейки на профильных ресурсах, лайки и репосты по тематике…
Да, соглашусь, довольно много аджайл-бесполезных и дорогих людей, особенно кручей. И скрам мастеров тоже, найти правда крутого — большая редкость, и профиль такого спеца очень сложный, поэтому их мало. Но это не значит что его не надо искать.
Если у скрам-мастера стоит конкретный, влияющий на его ЗП, KPI на создание самоорганизованной команды, это работает, он ограничен во времени. Конкретно мой скрам-мастер уже сам старается уходить от команды разработки, только сама команда не хочет его отпускать т.к. Правда видит результаты его работы
Но это не значит что его не надо искать.
Если он нужен — его надо искать. Всё.
KPI на создание самоорганизованной команды
А какими метриками вы измеряете «саморганизованность команды»? (честно, интересно, без стёба)
только сама команда не хочет его отпускать т.к. Правда видит результаты его работы
А, разве команда обладает достаточной экспертизой для оценки эффективности скрам-мастера? Команда не посвящена в бюджет (да, они даже рейты друг друга обычно не знают), поэтому с точки зрения команды любой человек, хоть что то делающий будет полезен.
Вот про это я бы точно с удовольствием почитал.
<толсто>
А кем Вы работаете? И о какой технодичи идёт речь?
и в целом, учитывая перечисленный опыт, первый две ошибки очень удивляют.
и не понял почему инвесторы определяют метрики продукта.
попытка внедрения devops — а зачем вам тогда вообще scrum если вы никуда не выкатываете?
ну и 7 разрабов и 0 тестировщиков в команде — ммм… тут или опечатка или…
все в команде не знают что делают другие и им все равно? вы серьезно?
я надеюсь, что кто-то из BE все же были techlead или брал роль архитектора. Трудно поверить, что вот так без общего контроля, без тестирования вы начали пилить, там будет не 10 ошибок.
ну по тексту думаю понятно по комментам, использовать аббревиатуры PO, BE, FE не стоит — или уже пишите глоссарий в начале статью раз решили писать «по своему».
Если уж цикл статей, то список общий можно и в начале привести — он же уже известен? ))
Статью люди читают, чтобы получить законченный объем знаний, вы же PO — должны понимать, кто ваш клиент и что он ожидает, а не для себя пишите. Статья циклом самый сложный вариант, потому что тут уже пошла декомпозиция (если уж scrum — то это как итерация), и каждая статья должна быть законченной и нести фичевую ценность. Честно — лучше было лонгрид написать, минусов было бы меньше.
Не любят здесь PO, что поделать.
Суровых профессионалов в любой области мало, в том числе среди PO.
10 ошибок юного РО (часть I — три ошибки)