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

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

РЫБА НА ДОСКЕ

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

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

image

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

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

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

Фото №2

image

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

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

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

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

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

Фото№3

image

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

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

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

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

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

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

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

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

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

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

Комментарии (8)


  1. i360u
    14.03.2017 15:07
    +2

    Главная проблема руководителей проекта — в непонимании того, что их роль — обеспечивать процесс а не напрягать окружающих задачами по обеспечению этого процесса. Любая методология будет принята легко, если не будет обременять исполнителя формальными телодвижениями, которые может брать на себя сам руководитель. Тех управленцев, которые считают, что их смысл заключается исключительно в делегировании задач — никто не любит. К примеру: нужно посчитать сколько времени ушло на определенные таски? — Зайди в трекер и посчитай, вместо того, чтобы заставлять писать отчеты разработчиков.


    1. DeBovuar
      14.03.2017 15:21
      -1

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


  1. vadim_ig
    14.03.2017 15:15
    +5

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


  1. knekrasov
    14.03.2017 15:16
    +6

    Так в чем глубокий смысл статьи? Инженеры плевались на митинги и абстрактные диаграммы, по поводу чего вы собрали новый митинг и нарисовали еще больше диаграмм?


    1. DeBovuar
      14.03.2017 15:59
      -1

      Программисты как раз весьма позитивно приняли мероприятие: для них — это бизнес-игра, которая прошла энергично и весело.


  1. stardust_kid
    14.03.2017 16:52

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


  1. a4k
    14.03.2017 17:42

    Ваша компания занимается аутсорсингом?


    1. DeBovuar
      14.03.2017 17:42

      нет