Нужен ли ПМу технический бэкграунд и как его нарабатывать: исповедь менеджера и результаты опроса разработчиков

Привет, VC. Меня зовут Марина Заботина, я аккаунт-директор в диджитал-агентстве Далее. Сегодня хочу поднять животрепещущую тему — зачем и как прокачивать технический бэкграунд проджект-менеджеру.

В статье рассмотрю:

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

Пара ремарок:

• Эту тему рассматриваю в контексте ведения проектов в заказной разработке: не только дизайн, контент, но и проекты интернет-магазинов, веб-приложений.

• Роль проджекта на проекте заключается не только в управлении командой, но и в непосредственном общении с клиентом. Для клиента менеджер — основное контактное лицо. Это значит, ему нужно защищать решения команды, обосновывать выбор тех или иных технологий. А для этого — советоваться с разработчиками, и на каком-то уровне, но разбираться в теме.

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

Это случилось и со мной в начале менеджерского пути. Когда я впервые пришла на проект с разработкой, мне выпал хардовый уровень. Я вела проект, который лидирует технический директор. Сразу бинго: мегамозг, светило науки, Ferrari 250 GTO в мире IT, способен выучить любой язык программирования за несколько дней (и это не шутка).

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

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

Качественно передать информацию клиенту не удается. Объяснить можешь только контуры проекта и то, что тебе сказали, причем, с минимальным уровнем понимания. Если у клиента возникают вопросы — ответить на них часто не можешь. Нужно бежать к техлиду, а он, как мы помним, на вопросы отвечать не хочет. А если ответит, то понимания это не прибавит.

Подытожу. На что влияет отсутствие базовых технических знаний:

• не всегда понятно, к кому из команды идти с той или иной задачей: это для синиора или джуна/ а это вообще на фронт или на бэк?
• лишнее время проджекта, команды и клиента. Приходится адресовать даже базовые вопросы команде, вместо того, чтобы решать их самостоятельно.
• качество погружения в проект и качество коммуникации с командой и клиентом ниже.
• нет возможности фильтровать задачи и пожелания клиента по технической части, если они неосуществимы.
• самостоятельно оценить объем задачи сложно.
• неуверенность, страх, боль и слезы — в постоянном стрессе быть продуктивным и развиваться сложно.

Чтобы удостовериться, что мое мнение — это не только мнение, а реальность, пришлось даже зайти в интернет. Еще в 2020 году на Хабре провели опрос, где выясняли, какого уровня должен быть технический бэкграунд у менеджера. 63% опрошенных ответили, что нужна общая техническая грамотность. В комментариях под тем опросом разгорелась довольно интересная дискуссия. Почитайте на досуге.

Данных опроса мне было недостаточно — требовались детали. Поэтому мы с нашей PR-командой провели опрос среди коллег (нас больше 320 человек), добавили к нему опрос в нашем ТГ-канале и запушили еще один опрос на Хабре и vc.ru.

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

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

А вот некоторые ответы менеджеров на вопрос о том, какие трудности у них возникают из-за недостатка технического бэкграунда:

А вот некоторые ответы менеджеров на вопрос о том, какие трудности у них возникают из-за недостатка технического бэкграунда:

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

А что по этому поводу думают сами разработчики? Мы спросили, чувствуют ли они разницу в работе с технически подкованным и нулевым менеджером. Подавляющее большинство (81,8%) ответило утвердительно.

Приведу ответы разработчиков на вопрос: «Можете рассказать, в чем вы видите разницу в общении с технически подкованным ПМ, если она есть?» В двух словах: разница в понимании.

Те же разработчики ответили, что дает наличие технической базы менеджеру.

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

Дополнительно к опросам мы провели мини-исследование по 50 вакансиям проджект-менеджеров в заказной разработке. В 39 из них технический бэкграунд нужен, в 4 требовалось еще и умение кодить, 7 компаний готовы взять на работу человека без базовых технических знаний и всему его научить.

То есть, становиться супер-профи не нужно. Но если у вас классные софты, и вы при этом способны вести осмысленный диалог с разработчиками — то будете у работодателя в топе. И, как ни крути, набирать базу придется. Даже агентства, готовые взять ПМ без базовых знаний, планируют ньюкамера обучать, следуя заветам товарища Ильича.

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

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

Что с этим делать? Во-первых, обращусь к результатам опроса.

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

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

Сначала изучите вопрос самостоятельно. Ищите базовые материалы по теме, читайте Хабр, идите на форумы. Основная задача — понять предметную область, по которой не хватает информации. Отлично помогает YouTube: запросы из разряда «разбор темы для чайников» действительно работают.

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

Если к тех. лиду проекта идти страшно, найдите более лояльного товарища среди разрабов и обращайтесь к нему. Лайфхак — если у разработчика не хватает на вас времени, поймайте его во время обеда, перерыва на кофе или в курилке.

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

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

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

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

Схема получения драгоценных технических знаний не такая тривиальная, как кажется. Менеджеры, которые только начинают путь, сталкиваются с тремя ограничениями.

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

Большая часть информации о технологиях, которую вы встретите в интернете, написана техническим языком и для технарей. Когда языка не понимаешь, приходится гуглить не только про саму технологию, но и термины, которые используют для ее объяснения. Так, забив в поиске «Что такое DNS», через сутки можно обнаружить себя с трясущимися от кофе руками, в поту изучающим топологию сети.

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

Хорошая новость в том, что этих ограничений бояться не следует — достаточно о них знать. Так вы не станете вешать на себя дополнительную нагрузку и не будете расстраиваться, когда чего-то не успеваете или не понимаете. Как писала выше: общайтесь с командой.

Если вы только встали на этот сложный путь, рекомендую следующее:

• Стараться погружаться в особенности проектов, использовать софт-скилы, чтобы наладить контакт с командой.
• Задавать вопросы разработчикам.
• Набирать теоретикал минимум на Хабре и Ютубе.

Мой личный топ тем для погружения в особенности разработки веб-проектов выглядит так:

• TCP/IP
• Клиент-серверная архитектура
• Фронтенд/бэкенд
• API
• Цикл разработки ПО
• GIT

В зависимости от специфики проектов, у каждого будет свой топ.

Если базовые знания уже есть, продолжайте развиваться:

• Не прекращайте задавать вопросы
• Учитесь защищать мнение разработчиков перед клиентом
• Попробуйте читать код
• Разбирайтесь в нюансах.

Глоссарий написан менеджерами для менеджеров. Так что очень надеюсь, что благодаря ему слез и нервов будет меньше, а уверенных ПМов — больше. А если кто-то захочет дополнить мой словарь другими полезными терминами — пишите в личку.

Наш тг-канал: @daleedigital. Тут бывают новости, полезности для работы, вакансии и другой диджитал-движ.

Сайт: dalee.ru