Нужны ли технические навыки менеджеру проектов?
На эту тему как на просторах украинских (ссылка 1, ссылка 2), так и зарубежных ресурсов (ссылка 3, ссылка 4) были написаны десятки статей, большинство из которых сводятся к общему выводу, что нет.
Менеджеру проектов (как и менеджеру в принципе) технические скиллы не нужны, т.к. менеджер свои задачи, как организовать работу команды должен решать за счет soft skills. И с этими утверждениями достаточно трудно поспорить.
Кто возразит, что умение слушать и слышать, проактивность, хорошая самоорганизация, коммуникабельность, гибкость и умение делегировать не помогут менеджеру проектов построить работу своей команды?
Мой личный, более чем
Но такая постановка вопроса устраивала не всех. Трое ученых 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. Для желающих: с самим исследованием можно ознакомиться здесь, почитать обзорную статью здесь.
