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

Комментарии 27

Ошибка четыре
Объявить тему выступления «десять ошибок», а рассказать о трёх.

Интересно было бы почитать, что вы успели сделать за полтора года, как пришли к нынешней точке.
Все для того, чтобы вы оставались с нами. Ситком из 10 ошибок будет продолжен.
Эта группа статей именно про управление продуктом, цени рассказать про то что сделали и как пришли этому не было. Если этот вопрос интересен, то обязательно расскажу в будущих статьях
Что такое РО? У меня в голове только одно «Ростовская Область». Ничего другого придумать не могу.
Статус РидОнли, которое получит автор материала (:

Product Owner – это человек, отвечающий за разработку продукта. Статья в целом именно для РО, но спасибо за комментарий, я учту это в будущем

Вы меня еще больше озадачили… Я вот являюсь учредителем и директором маленькой компании, ну и программист там же — никогда не думал, что являюсь каким-то там РО.
Итеративный подход в создании продукта

Что-то я так и не понял — вы скрам-мастер (человек, ведущий скрап, ретро и т.п.) или продакт оунер (человек, ответственный за судьбу развития продукта, а, соответственно, максимально погруженный в этот продукт, его прошлое, настоящее и будущее)? Это же вообще разные вещи, даже не особо-то пересекающиеся. Как вообще можно научиться быть PO — это же как научиться быть директором, при этом не зная директором чего ты будешь. Нереально, как по мне.

Я продукт оунер, не скрам мастер. Да, это абсалютно разные роли. Ни одной из них не возможно научиться, на мой взгляд. Это или есть или нет, и вы это или используете или нет.
Школа РО это не место где из любого сисадмина сделают РО:)
Это коучи( правда, крутых крайне мало) которые подробно рассказывают и разбирают все фреймворки, все сервисы, и инструменты, которых очень много.


Если провести аналогию- вы и так можете быть коммерческим директором какой-нибудь конторы, но зная например не просто основы РСБУ, а ещё и основы МСФО, аудита и управленки — вы всё ещё остаётесь коммерческим директором, но начинаете смотреть на управление совсем иначе и начинаете видеть больше, и скорее всего можете претендовать на место в компании побольше и получше.

Я так и не понял РО это эр-о или пи-о.

У меня от этой статьи свитшот заискрился и смузи забулькал.

Смотрю на всё это, и а… ю: сколько же всяких посторонних людей паразитирует на ИТ.
А из чего именно вы сделали такие выводы?
На сколько это всё актуально в данном случае — я не знаю. Поэтому, говорю в целом. Конкретно автора топика паразитом не называл )))

Начнем с того, что гибкие методологии не панацея, их применение далеко не всегда оправдано. В Аджайле, в частности, есть куча ролей, которые не являются непосредственно разработчиками. В правильно «настроенном» аджайле на подходящем проекте — это всё может прекрасно работать и оправдывать оверхед в виде дополнительной нагрузки на ФОТ. Иначе, все эти роли просто проедают бюджет без какого-либо существенного вклада в процесс.
Какой же «условный скрам-мастер» захочет допустить, что бы его смысл существования на проекте был подвергнут сомнению. И вот вся эта скам-кодла начинает представление в виде бурной деятельности: неуёмная инициативность, пропаганда методологий и инструментов, круглосуточное желание выслужится, статейки на профильных ресурсах, лайки и репосты по тематике…

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


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

Но это не значит что его не надо искать.

Если он нужен — его надо искать. Всё.

KPI на создание самоорганизованной команды

А какими метриками вы измеряете «саморганизованность команды»? (честно, интересно, без стёба)

только сама команда не хочет его отпускать т.к. Правда видит результаты его работы

А, разве команда обладает достаточной экспертизой для оценки эффективности скрам-мастера? Команда не посвящена в бюджет (да, они даже рейты друг друга обычно не знают), поэтому с точки зрения команды любой человек, хоть что то делающий будет полезен.
Воу, а как вы этот KPI самоорганизации меряете? Что-то вроде «за полгода работы скрам мастера концентрация самоорганизованности в крови разработчиков выросла на 15% что подтверждается генетическими исследованиями а так же снижением средней продолжительности совещаний при неизменной производительности в строчках кода»?
Вот про это я бы точно с удовольствием почитал.
Человек поделился своим опытом, притом полезным, и по делу, а его сливают с «улюлюканьем» в комментариях. Очень грустно наблюдать такое на Хабре.
Это всё от зависти. Жалкие задроты потратили годы своей жизни на всякую технодрочь. Вместо того, что бы за 21 день пройти курсы и пойти в ИТ-менеджемент.
<толсто>
Автор описал свой опыт в ритейле и там явно не один год. Я занимался управлением проектами по разработке и внедрению и мне было бы очень интересно почитать продолжение.

А кем Вы работаете? И о какой технодичи идёт речь?

Не «технодичь», а «технодрочь». Это, как раз таки весь тот технический бэкенд, который и отличает свитчера с «вайтивайти» курсов от инженера.

Скромный ПМ, на совершенно заурядном аутсорс проекте.
Легко «вайтивайти», сложнее «выйтиизайти».
1.5 года и все еще новоиспеченный? довольно странно.
и в целом, учитывая перечисленный опыт, первый две ошибки очень удивляют.

и не понял почему инвесторы определяют метрики продукта.

попытка внедрения devops — а зачем вам тогда вообще scrum если вы никуда не выкатываете?

ну и 7 разрабов и 0 тестировщиков в команде — ммм… тут или опечатка или…

все в команде не знают что делают другие и им все равно? вы серьезно?
я надеюсь, что кто-то из BE все же были techlead или брал роль архитектора. Трудно поверить, что вот так без общего контроля, без тестирования вы начали пилить, там будет не 10 ошибок.

ну по тексту думаю понятно по комментам, использовать аббревиатуры PO, BE, FE не стоит — или уже пишите глоссарий в начале статью раз решили писать «по своему».
Если уж цикл статей, то список общий можно и в начале привести — он же уже известен? ))
Статью люди читают, чтобы получить законченный объем знаний, вы же PO — должны понимать, кто ваш клиент и что он ожидает, а не для себя пишите. Статья циклом самый сложный вариант, потому что тут уже пошла декомпозиция (если уж scrum — то это как итерация), и каждая статья должна быть законченной и нести фичевую ценность. Честно — лучше было лонгрид написать, минусов было бы меньше.
Автор, не отчаивайся.
Не любят здесь PO, что поделать.

Суровых профессионалов в любой области мало, в том числе среди PO.
ИМХО, вместо того что бы писать какие ошибки были допущенны, лучше попробуйте для начала сформулировать для начинающего продукт менеджера что такое продукт менеджер, что он делает и зачем он нужен. После этого окажется, что скрамы, канбаны, аджайлы тут вообще не при чем. Что собирать команду разработки вам не надо (и даже противопоказано), потому что не ваша задача и не в ваших компетенциях думать о том, что, кому и как писать. И возможно тогда большая часть ошибок отпадет сама собой, и появится осознание того, в какую сторону стоит развиваться, что бы быть успешным менеджером.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий