Кейс управления проектами с применением альтернативных методов.
Автор Сергей Прыкин
Любому PM (Project Manager) приходилось сталкиваться с внутренними конфликтами в проекте. Фигурантами, провокаторами, манипуляторами могут выступать кто угодно – от заказчика, недовольного процессом решения задачи, до разработчика, который намеренно игнорирует рабочие встречи.
Часто в IT-команде есть «звездочки», обладающие исключительными компетенциями и полномочиями, чья токсичность считается нормой, но… является серьезным дестабилизирующим фактором. Еще встречаются откровенно слабые и неорганизованные сотрудники, коммерческие заказчики, которые лишь отдаленно представляют процесс разработки, но хотят его полностью контролировать.
Приведу несколько примеров:
Токсичный, но квалифицированный аналитик на встречах помимо сути проблемы выказывает пренебрежение другим ценным членам команды: «Вы слишком мало внимания уделяете проекту», «Вы не знаете, поэтому не говорите» и т.п. Деморализует? Еще бы! В моей практике были случаи, когда такие профессионалы доводили целый отдел до полного выжигания.
Слабый «игрок» команды, который не может справиться со своей частью работы в установленный срок или сообщить о проблеме вовремя руководителю проекта (например, о нехватке информации, доступов, инструментария, печенек в офисе). Как минимум – сорванный промежуточный дедлайн у всей команды. Как максимум – заваленный проект.
Коммерческий заказчик, который очень хочет контролировать (сроки, бюджет, риски и вообще «всечтоугодно») и регулярно абьюзит как промежуточных руководителей, так и отдельных игроков.
Проект превращается в «перетягивание каната», где результат «win-win» невозможен. Бывает, что обычная рабочая встреча проходит настолько неэффективно, что заказчик вообще не доверяет проект команде с негативным фоном.
Помимо токсичности есть и объективные причины для возникновения конфликтных ситуаций: конкурирующие приоритеты внутри команды, отсутствие полномочий, «тормозные» неотработанные процессы.
Что делать? Прибегать к популярной стратегии эскалаций - нажаловаться на всех и снять с себя ответственность. Или попробовать решить проблему эффективно, как случилось в нашем кейсе.
Почему не всё решается эскалацией?
Потому что часто проблема, как я уже писал выше, не в конкретном человеке, а в объективной причине, которую достаточно просто устранить. Бывает и в человеке – но, опять же, по объективной причине. И помогая ему справиться, мы получаем мотивированного игрока, готового тащить проект и команду вперед.
Руководитель проектов может регулировать процесс коммуникации без эскалаций, основной эффект которых – кратное повышение внутреннего напряжения в команде. Более того: настоящие руководители проектов Agile-PM не могут и не должны себе этого позволять, так как влияние их токсичности на команду максимально разрушительное. Вплоть до ее распада.
Я предпочитаю решать конфликты именно на уровне команд. Вот проверенные варианты:
Формулировать понятные цели проектов и регулярно их пересматривать, адаптируя к изменяющимся условиям. Отказаться от промежуточных приоритетов – нулевой, первый, второй, третий; низкий, средний, высокий. Реально работает – это выбор того, что действительно важно сейчас. По сути приоритетов должно быть два: обычный и важный. Сообщите членам команды, что делаем, а что нет. Это существенно упрощает всем жизнь.
Постоянная коммуникация с владельцами продуктов (и в обратную сторону – с командой). Я сделал вывод, что когда владельцы продукта понимают стратегическое направление разработки, то управляют бэклогом эффективнее. Важно своевременно, соблюдая договоренности, давать обратную связь всем участникам – КБ, заказчику, разработчикам, менеджерам продукта.
Постоянная аналитика процесса: где узкие места, где теряется время, какие действия не приносят пользы. Считаю, что членам команды нужно дать свободу определять, как лучше выполнять свою работу (а не заставлять следовать жестким инструкциям). Упрощение процессов снижает необходимость эскалаций и ускоряет успешный вывод на прод
В ходе данного кейса стратегия оправдала себя на все 100%.
В этом кейсе PM выступил как медиатор, главная задача которого – подсветить коммерческому заказчику и команде конечную цель и совместно с ними продумать и построить оптимальный путь для ее достижения (и придерживаться его!). Ведь, по сути, все участники проекта стремятся к успешному результату (к тому самому «win-win»).
Выводы. Что должен уметь PM?
В данном случае (как, впрочем, и во многих других) главной задачей PM было – выстроить рабочий процесс так, чтобы он завершился ожидаемо. Ожидаемо – это значит в срок, в рамках бюджета и с требуемым качеством. Чтобы все получилось, нужны те самые soft skills, о которых, как мне кажется, все мы немного подзабыли.
В частности, это:
- дивергентное мышление и умение применять нестандартные решения;
- обрабатывать огромные объемы информации (ей-богу, не каждому это дается быстро и легко);
- разнообразие навыков / опыта для подстройки под проект;
- грамотное выстраивание коммуникаций (цель – доверие команды и заказчика);
- конкретизировать хотелки (всех участников процесса);
- превентивно отслеживать риски, срывы, конфликты;
- навыки организации и управления встречами – максимум конструктива, минимум воды и критики.
Погружение в проект позволило минимизировать необходимость эскалаций, ускорить и упростить работу команды. Любое проявление токсичности – это явный или завуалированный запрос. Разобраться в нем и достичь согласия – тактика, которая показала максимальную эффективность и позволила успешно реализовать проект.
Готов ответить на ваши вопросы в комментариях.