Тёмная сторона Силы. Почему в продуктовой команде должен быть руководитель проекта

Недавно я перечитывал свою старую статью по управлению людьми, написанную около трёх лет назад. В тот момент я был начинающим руководителем проектов и «тёмная сторона силы» в управлении проектами казалась далёкой и нереальной.

Тогда в моей ответственности был заказной проект с чёткими требованиями, «моя» команда, которой я ставил задачи, защищал и оберегал от внешнего мира, расписание, которое я составлял и отстаивал в дискуссиях с руководством и заказчиком. С заказчиком, как и с руководством, я общался с позиции команды и отстаивал её интересы: чтобы сроки были достаточны, чтобы новые требования не появлялись «ниоткуда», чтобы претензии к качеству имели под собой реальные основы и так далее. Отношение с командой при этом было, на мой взгляд, близкое к идеалу. Конечно, встречались и конфликты и разногласия, но, в большинстве случаев, они разрешались мгновенно и безболезненно.

Через некоторое время я возглавил другой отдел. По сути, это была отдельная компания, которая занималась продуктовой разработкой компонентов для .NET и JavaScript. Соответственно, в сферу моих задач добавилось управление продуктом, а также курирование маркетологов и менеджеров по продажам. По сути, к моим обязанностям добавилась бизнес-составляющая.

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

В какой-то момент, оглянувшись назад, я ужаснулся тому, как сильно изменился мой стиль управления, и как сильно я стал похож на того мерзкого и непрофессионального ПМа, образ которого (со словами «и откуда только ТАКИЕ берутся») рисовал себе, когда только начинал работать.

Конечно же, мне это очень не понравилось (вообще, я люблю, когда меня любят и уважают ;). Соответственно, я решил обдумать почему так произошло, и что надо делать, чтобы не допускать дальнейшей «деградации».

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

Я решил проверить этот факт и уменьшил нагрузку, разбив команду так, чтобы во главе каждой группы стоял тимлид, которому я бы давал пачку задач с приоритетами и не следил за дальнейшей их судьбой до тех пор, пока специалист по тестированию не скажет «всё готово». Кроме того, я делегировал обучение сотрудников и сосредоточился на развитии и продвижении продуктов. Действительно, работы по постановке, конкретизации задач и контролю разработки стало значительно меньше. Но, тем не менее, это не сильно-то помогло «вернуться на светлую сторону».

Подумав ещё немного, я понял, чего не хватало в текущей ситуации. Не хватало ощущения единства с командой, которое могло продолжаться месяцами на заказной разработке.

Не хватало стойкого кредо любого руководителя проектов: я создаю то, что создаёт моя команда. Наоборот, не покидало чувство: команда делает мой продукт. Команда делает то, что мне нужно, что я запланировал. И, похоже, это и есть ключевой момент. Вся проблема в том, что я стал смотреть на команду со стороны бизнеса, в то время, как будучи ПМом был сам её частью.

Раньше управление людьми сводилось к постановке задач, мотивации, обучению и охране от внешнего воздействия. Теперь – к постановке задач, мотивации, обучению, найму, повышению зарплаты и т.д. Если внимательно приглядеться, отсутствует один важный фактор. Это охрана от внешнего воздействия. По сути, внешнее воздействие — это я сам!

Таким образом, проблемы бизнеса сразу спускаются в команду, минуя ПМа – тот самый щит, который отсеивает лишнее, структурирует поток задач, не даёт заказчикам на лету изменять приоритеты, перекраивать требования и делать всё прочее, что они (а теперь можно сказать и «мы») так любим делать.

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

P.S. Есть одна оговорка — хороший процесс может тоже неплохо защитить команду, однако это уже другая история.