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

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

Статья позитивная, но есть несколько нюансов.
  1. По ходу статьи складывается впечатление, что, простите, «все — п*?:%сы, я — Д'Артаньяр». То есть в компании без Вас было совсем плохо, а Вы пришли и поставили всё на правильные рельсы за 5 месяцев. Имхо, так не бывает и вы не раскрыли, кто ещё «виноват» в успешной смене процессов.
  2. Вы пишете, что Вы — Project Manager. Я, являясь сертифицированным Scrum Master-ом и работая уже более трёх лет в большой интернациональной команде по Scrum of Scrums (это когда внутри каждой команды Scrum + ежедневно проводятся Scrum-митинги между Scrum мастерами всех команд), не припомню, чтобы где-то в Scrum была роль Project Manager. Более того, PMP и CSM тренинги подразумевают во многом диаметрально противоположные подходы в управлении командами и планировании.

Позвольте прокоментировать.

1. Нигде и не сказано, что все, что делалось, делалась исключительно одним человеком. Собственно поэтому в статье и используется местоимение «мы».

2. А при чем тут PMP? К слову у Project Management Institute также есть сертификация по Agile. Но не суть. Если Project Manager ведет проект по PRINCE2 или имеет прочие сертификаты вроде M.S.P.M., то он уже не Project Manager? Говоря исключительно про описываемый кейс, то руководитель проекта был нужен для того, чтобы провести трансформацию к Scrum-у, а не работать как Scrum Master.
Спасибо за минус :)
«мы» встречается в тексте ровно 1 раз, зато через весь текст проходит «я», «мне» и все действия по изменению процесса как бы обезличены, то есть как будто всё делалось само собой, по вашему указанию. Возможно это просто я так воспринял данный текст. И мне кажется, что я догадываюсь в какой компании и на каком проекте это происходило :) Если я угадал — тогда Вам действительно удалось многое поменять в лучшую сторону, прошу прощения за несколько грубый стиль предыдущего комментария, не хотел ничего плохого в Ваш адрес сказать.
По поводу PM тоже согласен, дал маху. Для больших команд, а тем более для команд, которые меняют процесыы и переходят на Agile, нужен человек, который будет управлять этим процессом перехода. И по поводу роли PM в SCRUM нашёл замечательную статью и понял что я реально не прав: www.scrumalliance.org/community/articles/2012/january/implementing-scrum-how-does-the-project-manager-fi

P.S.
Удачи в Вашем начинании, и пусть у Вас всё получится.
А не расскажите, как переходили от Team-lead'ов к Product-owner'ам и Scrum-master'ам? Интересна статистика, кто из первой группы кем стал. И откуда набрали народ во вторую и третью группу?
Если правильно поняла вопрос, то:
— Team-lead-ов никуда не переводили. Однако их обязанности несколько изменились в сторону технической работы: код-ревью, архитектура решений, тренинги и воркошопы команде, интервью и т.п. Также, чтобы разрешить проблемы скопившегося технического долга, организовали технический бэклог, который поддерживался и приоритезировался лидами;
— Scrum master-ами становился кто-то из команды (разрабочик либо QA). Обязанности были стандартными и не расширялись отчетностями и проч менеджеровскими активностями, поэтому не отнимали много времени + была ротация. Ротация позволяла не обременять кого-то определенного скрам-мастерством=)
— Product-owner-ы были и до этого, только назывались бизнес-аналитиками. К их обязанностям добавились приоритезация бэклога и участие в Agile мероприятиях.
Судя по ответу вы все правильно поняли)

Насчет product-owner'ов. Только у них была/есть власть над приоритетами в бэк-логе? Или для изменения приоритета какой-нибудь задаче им нужно это согласовать с кем-то?
Нужно было согласовывать, так как ситуация была сложнее, чем просто желание/видение развития продукта. За каждой фичей стоял договор с клиентом, зачастую с какой-то датой или релизом. Поэтому приоритет мог быть поднят/понижен в рамках планирования роадмапа продукта.
Спасибо за ответы!
А еще, не расскажите, в какой стадии проект сейчас?

Особенно интересен прогресс в «модулизации проекта»
Проект развивается и растет. За время «после статьи» появилась команда сапорта, появился отдельный технический спринт. Что касается модулизации проектов, то процесс идет, хотя и медленно. Чтобы не останавливать разработку продукта, большие задачи уходят в техническую команду, которая не самая многочисленная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории