Что заставляет их нас так не любить проектных менеджеров, руководителей и скрам мастеров? Что лежит в глубине программистских душ и вырывается возгласами негодования в лучшем случае или жестким троллингом и саботажем в худшем.

Хотелось бы поделиться историей, которая не появилась бы, если бы не несколько случайных обстоятельств в одной и той же компании в одно и то же время. Так уж случилось, что новый руководитель проектов в одной весьма брутальной команде опытных программистов столкнулся с часто встречающейся проблемой скептического отношения к себе, к предлагаемым им практикам и к Agile “чудесам” в целом. Подобные сложности не были сюрпризом для прочих руководителей проектов, так как в том или ином виде проявлялись у всех. И так как все это случилось во времена внедрения аналитических инструментов в ретроспективы, то идея использования различных подходов в поиске корня проблемы казалась весьма актуальной. В целом тема отношения к проектным менеджерам временами поднимается в различных публикациях и постах, начиная с жалоб на фреймворки и нерадивых руководителей, мешающих эффективной работе; заканчивая неудачными внедрениями методологий и демотивирующими процессами. Итак, мы решили, что тема жизненная и определенно интересная.

РЫБА НА ДОСКЕ

В лучших традициях надо начинать с себя и в узком кругу ПМов мы решили отрефлексировать эту проблему. Консилиум решил что Диаграмма Исикавы подходит больше всего для анализа (ну мы же опытные, че) и в первом подходе к снаряду вписали все обязанности и задачи которые выполняются менеджером на проекте. Очень быстро места на доске перестало хватать, причины все не находились и скрепя сердце попытку не засчитали и все было выпилено под ноль. Так родилась рыба №2, при построении которой, фокус был на причины, которые могли привести к такому отношению (см. фото скелета ниже).

Фото №1 Скелет рыбы №2



Все полученные причины проранжировали по степени влияния на обсуждаемую проблему и вероятность/частоту ее возникновения.

И в лидеры попало следующее:

• Низкое понимание обязанностей скрам мастеров/проджект/программ менеджеров (далее просто руководитель проекта или РП) — 30 баллов
• Низкая видимость пользы, которую приносят РП-ов, нехватка kpi эффективности их работы для проекта или компании — 30 баллов
• Негативное отношение к тому, что руководители проектов “диктуют” как работать через выстраивание процессов — 18 баллов
• Низкое понимание/видимости пользы, которые приносят построенные процессы — 18 баллов
• Низкая видимость ежедневных обязанностей — 11 баллов

Фото №2



Усилия на устранение причин решили направить на самые важные пункты, 30-бальные.

На этом первый этап анализа был завершен. На следующую сессию анализа помимо непосредственно руководителей проектов пригласили несколько разработчиков, а инструмент анализа изменили на дерево текущей реальности.

Дерево текущей реальности (ДТР)

Негативные явления, связанные со скепсисом нашлись с легкостью. Не смотря на то, что с большей долей вероятности некоторые будут специфичны, приведем их полностью с описанием (фото №3 оранжевые стикеры):

• сваливание дополнительных обязанностей нехарактерных для РП (см. ниже);
• РП или секретарь? Негативное явление заключается в том, что как только инженерам нужно что-то обсудить, они просят РП забронировать митинг, соответство записать результаты их обсуждений. Как результат — РП теряет время из-за присутствия на многочисленных мероприятиях;
• саботаж митингов (от разведение демагогий до открытого сопротивления);
• пушинг со стороны Product Owners\Заказчика;
• сопротивление командой новым практикам;
• “плавали знаем” — отрицание практик так как уже использовали и результата не увидели;
• игнорирование просьб и задач.

Фото№3



С помощью наводящих вопросов постарались найти причинно-следственные связи. Таким образом появились дополнительные (синие) явления:

• Не понятны обязанности;
• Нет очевидности, что делает скрам мастер/РП в течении рабочего дня;
• Не у всех есть технический бэкграунд и это влияет на уровень доверия, так как может приводить к слабому пониманию технической стороны проекта;
• Не любовь к тому, что через процессы навязывают как работать;
• Разработчики не хотят отвлекаться от написания кода;
• Зачем они были нужны? Какая была цель найма РП и какие задачи они должны были решить.

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

Результаты анализа оказались весьма схожими с предыдущими и это навеяло сомнения, связанные с тем, что РП, присутствовавшие в прошлый раз, могли активно влиять на результаты этого обсуждения. Поэтому было решено организовать еще одну встречу, участниками которых были бы исключительно разработчики. Участие, естественно, добровольное. Инструментом анализа оставили дерево текущей реальности.

Как не удивительно пришло большее количество инженеров, чем предполагали и они с легкостью нашли негативные проявления, связанные со скепсисом к РП. Итак, было названо следующее:

• лидерство на проекте принадлежит не РП (существует некий иной формальный лидер);
• противостояние РП с менеджером продукта и неформальным лидером;
• команда против многих митингов, так как считает, что тратит время впустую;
• нет поддержки команды в выполнении задач;
• прошлый негативный опыт работы с РП на опыте прошлых компаний;
• троллинг руководителей проектов в команде;
• демотивация РП в работе

В ходе построения связей появились новые негативные явления, а именно:

• консерватизм людей;
• нет понимания, что и как это работает;
• нет метрик показывающих что что-то улучшилось или метрики необъективны (велосити в частности);
• нет видимой связи между действиями руководителей проектов и результатами на проекте (у команды). Т.е. если велосити выросло, релизы проектов стали происходить вовремя и т.п., то нет явной зависимости, что это произошло вследствие внесения практик РП-ов, ведь выполнение в итоге лежало на команде;
• не очевидна польза от нововведений по сравнению со временем затраченным на реализацию;
• не у всех РП есть технический бэкграунд и это влияет на уровень доверия.

Коренной проблемой оказалась нехватка объективных метрик, показывающих состояние на проекте после внедрения каких-либо фреймворков и/или практик. А после дружеского обсуждения для себя выяснили, что при внедрении какие-либо новшеств мы можем выглядеть как доктора, которые хмурятся на любые “глупые” вопросы пациента. Для себя решили, что ценность анализа и его результатов неоспорима, а открытая конструктивная дискуссия первый яркий прорыв в ее решении. Теперь для РП стало понятно направление при котором негативизм можно устранить (в нашем случае — внедрение метрик проекта Value stream mapping и эффективности проектов для наблюдений за проектам в целом), а для команды пришло осознание, что такая проблема есть и каковы ее причины.

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