Нужны ли технические навыки менеджеру проектов?

На эту тему как на просторах украинских (ссылка 1, ссылка 2), так и зарубежных ресурсов (ссылка 3, ссылка 4) были написаны десятки статей, большинство из которых сводятся к общему выводу, что нет.

Менеджеру проектов (как и менеджеру в принципе) технические скиллы не нужны, т.к. менеджер свои задачи, как организовать работу команды должен решать за счет soft skills. И с этими утверждениями достаточно трудно поспорить.

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

Мой личный, более чем 7-ти летний опыт управления проектами и командами проектов говорит тоже самое. Не имея технического бэкграунда, мне удавалось, как мне скромно кажется, достаточно успешно управлять и обеспечить delivery проектов и программ различного масштаба. Хотя теории и совсем чуть-чуть практики разработки ПО я все же учился.

Но такая постановка вопроса устраивала не всех. Трое ученых Benjamin Artz University of Wisconsin, Amanda H. Goodall City, University of London и Andrew J. Oswald The University of Warwick решили проверить, каким образом технические умения менеджера влияют на сотрудников.

В частности 35 тыс. респондентам из Соединенных Штатов и Великобритании задали ряд вопросов, чтобы узнать:
— Может ли их менеджер в случае необходимость делать их работу?
— Вырос ли менеджер из специалистов внутри компании?
— Какой уровень технических компетенций менеджера с точки зрения работника?

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

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

А уже о том, как от удовлетворенности зависит продуктивность, вам расскажет любой HR (хотя если хотите можете более детально изучить данный вопрос самостоятельно).

Хотя само исследование было опубликовано в 2015 году, многие украинские (и не только) IT-компании пришли к похожему выводу эмпирическим путем, что и привело к достаточно большому количеству менеджеров проектов с опытом разработки.

Если вернуться к моей истории, то бывшему бизнес-аналитику и менеджеру изучать технические вещи было достаточно сложно, т.к. не всегда знаешь, в каком направлении двигаться. Один достаточно длинный период времени, когда я руководил проектной командой, которая разрабатывала десктопные приложения на С++ для работы с 3D-графикой, то по сути шутки ради подписался на блог Microsoft по разработке ISO стандарта C++. Разработчики в команде были весьма и весьма опытные и за развитием языка (С++) следили, безусловно, более внимательно и с более практическим интересом.

В результате иногда появлялись такие вот диалоги:

Я: Ребята слышали, в пул-реквестах нового стандарта появился «[cpp.concat] In example code comment, remove unnecessary line break and format code as code». Наконец-то.
Разработчик: А что это значит, ты знаешь?
Я (с довольным выражением лица): Ну конечно, теперь будет удобней делать конкатенацию строк.
Разработчик (с ехидным выражением лица): И как именно?
Я: Э-э-э-э.

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

Если говорить более серьезно, то можно вспомнить множество примеров, когда определенные технические знания или их нехватка приводила к более прозаичным ситуациям и диалогам:

— Как можно решить задачу?
— Вот так.
— А по времени?
— 3 дня.
— Как-то многовато. А какие есть еще варианты?
— Еще вот так вот, но там куча проблем: ....
— Ну ок, делаем.

Рассказы о таких диалогах слышал от многих менеджеров (бывших аналитиков, тестировщиков).

Все кажется логичным. В менеджеры ты обычно попадаешь:
— как ex-аналитик (логика мышления, коммуникабельность, структурированное мышление, технические знания и т.д.);
— как ex-разработчик (логика мышления, коммуникабельность, структурированное мышление, технические знания и т.д.).

Далее у каждого свой путь, поддерживать сильные стороны и дорабатывать слабые.

Что делать менеджерам не умеющим писать код?

Я со своей стороны призываю безусловно не пренебрегать развитием soft-skills, как раз потому, что именно за счет этих навыков менеджер и может выполнять свою работу, принося ценность в работу команды, но и не пренебрегать как минимум обзорным изучением технических аспектов разработки.

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

Когда после очередной оценки проекта стало понятно, что ручное регрессионное тестирование опять выросло по объемам и срокам, то всей команде была поставлена цель сократить его как минимум до объемов первого проекта. На обсуждениях того, как этого достичь, часть идей звучали уже и с моей стороны (кстати, базировались на уже практически классической «Continuous Delivery» Джеза Хамбла).

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

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

Также хотел бы порекомендовать несколько замечательных книг, которые помогут быстрее разобраться в технических аспектах современной разработки:
— Test Driven Development: By Example: Kent Beck;
— Release management Best practice handbook by Gerard Blokdijk;
— Product Release Planning: Methods, Tools and Applications by Guenther Ruhe;
— Continuous Delivery: by Jez Humble;
— The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology by Gene Kim;
— Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) by Michael T. Nygard;
— The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim;
— The Art of Monitoring Book by James Turnbull.

Заранее отвечая на потенциальные комментарии, сам прочитал не все, каюсь, но все есть в моем плане для чтения.

P.S. Для желающих: с самим исследованием можно ознакомиться здесь, почитать обзорную статью здесь.