– Думаю, что главным фактором, объясняющим отсутствие ответственности за свою работу, а я это так называю, было то, что мы не создали специального пространства, в котором одновременно находились бы все члены команды. Ни у кого из ребят не появилось чувство единения и общности действий. К сожалению, мы не обратили внимания на это условие Agile. А также на то, что стендапы должны проходить регулярно, в этом заложен важный смысл сонастройки всех действий членов команды. У нас же стендапы проходили не регулярно, а как придется.

Главное объяснение здесь такое: у участников проекта не было внутренней готовности работать в Agile, не было желания вникнуть во все правила SCRUM и принципы Agile. Не сформировалась сама ценность работы по-новому. Поэтому часто можно было услышать: «Я свою работу сделал, почему я еще должен что-то брать в работу со SCRUM-доски, когда мой коллега еще не справился с одной задачей, я лучше подожду». Это при том, что все хорошо понимали суть задачи, которую им предстоит решить и ее важность для компании.

Получилось, что нагрузка у всех была неравномерная. Кто-то делал больше, потому что лучше проникся новыми идеями менеджмента, а кто-то остался в старой парадигме подчиненных отношений. Несмотря на то, что все вошли в команду добровольно. Кроме одного парня, который был назначен руководством. И от него было больше всего проблем, конечно.

– А что дал лично тебе этот проект? Как ты изменилась?

– Я испытала разочарование от того, что мы не сделали так, как это должно было быть в идеале. Еще я поняла, что никогда не надо делать работу за других, им это вредит. Это мой личный урок для всей моей деятельности.

Но самое важное открытие для меня в том, что Agile надо осознать, принять, прожить и следовать в жизни. Правила – это одно, ими можно пренебрегать, а осознание – это другое, это так глубоко проникает в тебя, что ты уже не можешь свернуть с этого пути.

В Agile нельзя заставить работать людей, с ним надо подружиться.

<p>Уроки проекта Agile в компании G</p>

1. Смещение ролей в команде. С первого же вводного семинара по основам Agile стало понятно, что команда находится на этапе формирования и еще недостаточно развита, чтобы быть эффективной. Неусвоенные принципы Agile приводили к тому, что участники посчитали роль SCRUM-мастера ответственной за все результаты работы команды. Поэтому ребята просто «сдавали» свою работу SCRUM-мастеру и ожидали вердикта. Члены команды загрузили эту роль массой файлов и презентаций, пока консультанты не вмешались в этот искаженный процесс. В команде долгое время сохранялись отношения «из прошлой жизни»: я свою работу сдал SCRUM-мастеру, почему я должен еще что-то делать, пока не прошла проверка.

Изменение такого отношения проходило болезненно и по живому, в процессе работы над проектом корректировались роли и выстраивались взаимоотношения, основанные на доверии и взаимопомощи.

2. Высокая должность Владельца продукта. Эта роль была искажена тем, что ее выполнял топ-менеджер высшего звена и по привычке управлял работой команды в авторитарном стиле. С другой стороны, и сами ребята не воспринимали топ-менеджера как члена своей команды, а исключительно как руководителя, которому надо подчиняться. О доверии в таких условиях речи уже не было. Это привело к тому, что команда тяжело обретала самостоятельность и самоуправляемость с постоянной оглядкой на руководство.

3. Совмещение с основной работой. Руководители, в подразделениях которых трудились участники команды, не прониклись значимостью проекта CRM по многим причинам, часть из которых описана в интервью. Более того, не осознавая важность конечного продукта Agile-команды, руководители считали, что это только отвлекает их сотрудников от основных задач, поэтому увеличивали их загрузку. Это означало, что над проектом нередко приходилось работать в свободное время и в выходные дни, что быстро свело первоначальный энтузиазм на нет. Появилась усталость от проекта и желание быстрее его завершить.

4. Некорректно составлен бэклог продукта. Команда начала работать в таких условиях, когда конечный продукт не был востребован большинством руководителей компании G. А они-то как раз и были будущими потребителями и заказчиками. И именно в силу этого они не могли сформулировать четкую цель для команды, не могли создать образ конечного продукта. Его попросту не было. Команда с подачи одного топ-менеджера взяла в работу задачу адаптировать CRM к различным подразделениям, наполнить данными и научить всех работать в этой системе. Но не ожидала, что проект начнет разрастаться в геометрической прогрессии. После каждого спринта добавлялись все новые и новые вызовы, работы становилось все больше, а конечный результат никак не вырисовывался.

Перейти на страницу:

Все книги серии Проектный менеджмент

Нет соединения с сервером, попробуйте зайти чуть позже