Нужен ли ПМу технический бэкграунд и как его нарабатывать: исповедь менеджера и результаты опроса разработчиков
Привет, VC. Меня зовут Марина Заботина, я аккаунт-директор в диджитал-агентстве Далее. Сегодня хочу поднять животрепещущую тему — зачем и как прокачивать технический бэкграунд проджект-менеджеру.
В статье рассмотрю:
- насколько техническая грамотность нужна для управления проектами, связанными с разработкой.
- с какими сложностями приходится сталкиваться, когда тех бэка нет.лайфхаки, чтобы стать бро для команды вместо того, чтобы получать косые взгляды в спину.
- приведу примеры из собственного опыта и конкретный план действий.
Пара ремарок:
Эту тему рассматриваю в контексте ведения проектов в заказной разработке: не только дизайн, контент, но и проекты интернет-магазинов, веб-приложений.
Роль проджекта на проекте заключается не только в управлении командой, но и в непосредственном общении с клиентом. Для клиента менеджер — основное контактное лицо. Это значит, ему нужно защищать решения команды, обосновывать выбор тех или иных технологий. А для этого — советоваться с разработчиками, и на каком-то уровне, но разбираться в теме.
Почему сложно без технической подкованности и на что влияет ее отсутствие
Я не раз наблюдала, как менеджеров, работавших до этого только с дизайном и контентом, перекидывали на разработку. И как быстро волосы их седели, глаза наполнялись слезами, а рот — новопасситом. Потому что без элементарных базовых знаний было не выжить.
Это случилось и со мной в начале менеджерского пути. Когда я впервые пришла на проект с разработкой, мне выпал хардовый уровень. Я вела проект, который лидирует технический директор. Сразу бинго: мегамозг, светило науки, Ferrari 250 GTO в мире IT, способен выучить любой язык программирования за несколько дней (и это не шутка).
Но в коммуникации человек этот был сложным: говорил только техническим языком и выжимками из логов. Так что я очень быстро перестала задавать вопросы по любой непонятной мне теме. То есть, по любой.
Казалось бы — что с того, что техдир не хочет с тобой общаться? Вы же не в друзья друг другу набиваетесь, а работаете. Но дело как раз в том, что нехватка взаимопонимания с техлидом, разработчиком или командой в целом влияет на проект.
Качественно передать информацию клиенту не удается. Объяснить можешь только контуры проекта и то, что тебе сказали, причем, с минимальным уровнем понимания. Если у клиента возникают вопросы — ответить на них часто не можешь. Нужно бежать к техлиду, а он, как мы помним, на вопросы отвечать не хочет. А если ответит, то понимания это не прибавит.
Клиент может почувствовать, что менеджер не очень подкован — страдает доверие. Команда видит, что ПМ в теме не разбирается — может ли он чем-то управлять? Такая ситуация продуктивности не прибавляет.
Подытожу. На что влияет отсутствие базовых технических знаний:
- не всегда понятно, к кому из команды идти с той или иной задачей: это для синиора или джуна/ а это вообще на фронт или на бэк?
- лишнее время проджекта, команды и клиента. Приходится адресовать даже базовые вопросы команде, вместо того, чтобы решать их самостоятельно.
- качество погружения в проект и качество коммуникации с командой и клиентом ниже.
- нет возможности фильтровать задачи и пожелания клиента по технической части, если они неосуществимы.
- самостоятельно оценить объем задачи сложно.
- неуверенность, страх, боль и слезы — в постоянном стрессе быть продуктивным и развиваться сложно.
Что говорят в интернетах
Чтобы удостовериться, что мое мнение — это не только мнение, а реальность, пришлось даже зайти в интернет. Еще в 2020 году на Хабре провели опрос, где выясняли, какого уровня должен быть технический бэкграунд у менеджера. 63% опрошенных ответили, что нужна общая техническая грамотность. В комментариях под тем опросом разгорелась довольно интересная дискуссия. Почитайте на досуге.
Данных опроса мне было недостаточно — требовались детали. Поэтому мы с нашей PR-командой провели опрос среди коллег (нас больше 320 человек), добавили к нему опрос в нашем ТГ-канале и запушили еще один опрос на Хабре и vc.ru.
У менеджеров мы узнавали, как они оценивают свой уровень технической грамотности, какие сложности видят в общении с разработчиками, как борются с трудностями. У разработчиков спрашивали, как влияет наличие или отсутствие этого самого бэкграунда на работу и готовы ли они помогать неокрепшим менеджерам превращаться в суровых технарей.
Чувствуют ли проджекты нехватку технических знаний
Опрос ПМов показал, что 100% тех, кто боится задавать вопросы разработчикам, оценили уровень своей технической подкованности как нулевой. Смелее себя чувствуют те, у кого есть базовая или продвинутая техническая грамотность.
А вот некоторые ответы менеджеров на вопрос о том, какие трудности у них возникают из-за недостатка технического бэкграунда:
А вот некоторые ответы менеджеров на вопрос о том, какие трудности у них возникают из-за недостатка технического бэкграунда:
В технически сложных задачах приходится долго разбираться и задавать вопросы разрабам, которые могут показаться им глупыми. Но это приходится делать.
Не всегда понимаю, что говорит разработчик.
Трудности с полноценной формулировкой задачи, некоторые важные для выполнения детали могут быть не учтены, не уточнены заранее у клиента.
Трудности в аргументации в разговоре с клиентом, особенно когда нужно обрабатывать возражения.
Основные сложности на моей стороне связаны с пониманием серверной инфраструктуры.
Мнение разработчиков про тех. бэкграунд менеджеров
Окей, вроде мои выводы подтвердились. Отсутствие технического бэкграунда влияет и на коммуникацию с командой, и на качество общения с клиентом.
А что по этому поводу думают сами разработчики? Мы спросили, чувствуют ли они разницу в работе с технически подкованным и нулевым менеджером. Подавляющее большинство (81,8%) ответило утвердительно.
Приведу ответы разработчиков на вопрос: «Можете рассказать, в чем вы видите разницу в общении с технически подкованным ПМ, если она есть?» В двух словах: разница в понимании.
Важен не столько технический бэкграунд, сколько понимание того, как всё работает. Если человек понимает, то он еще на самой ранней стадии даёт фидбек клиенту о нереалистичности, а не приходит с идеей, на которую получает ответ от технаря «это работает не так», отвлекая того по пустякам.
Технически подкованного менеджера очень сложно обмануть в оценке задач (объективно, а не то чтобы я пытался»).
Не нужно объяснять банальные вещи
В переводе задач с клиентского на разрабский; в фильтрации задач. Технически подкованный менеджер сам уточнит все необходимые моменты перед тем, как давать задачу разработчику
Те же разработчики ответили, что дает наличие технической базы менеджеру.
Выводы из опросов
Техническая подкованность важна. Без нее сложнее общаться и с клиентом, и с разработчиками. Приходится тратить больше времени на погружение в детали проекта. А если есть базовые знания — продуктивность растет, ресурсами легче управлять, обратную связь по задачам может дать сам менеджер, не отвлекая разработчиков.
Дополнительно к опросам мы провели мини-исследование по 50 вакансиям проджект-менеджеров в заказной разработке. В 39 из них технический бэкграунд нужен, в 4 требовалось еще и умение кодить, 7 компаний готовы взять на работу человека без базовых технических знаний и всему его научить.
То есть, становиться супер-профи не нужно. Но если у вас классные софты, и вы при этом способны вести осмысленный диалог с разработчиками — то будете у работодателя в топе. И, как ни крути, набирать базу придется. Даже агентства, готовые взять ПМ без базовых знаний, планируют ньюкамера обучать, следуя заветам товарища Ильича.
Как нарабатывать технический бэкграунд
Теперь, когда мои гипотезы подтвердились и мы пришли к тому, что техническая грамотность помогает делу и нервной системе менеджера, поговорим о том, как её нарабатывать и что этому может помешать.
Побороть страх
Как вы помните, боятся подходить к разработчикам с вопросами те, у кого нулевой технический бэкграунд. Почему так? Дело в том, что менеджера в начале его пути преследуют простые человеческие страхи. Страх показаться глупым, задавать вопросы, ответы на которые для других очевидны, и из-за этого столкнуться с негативом. Некоторые даже опасаются, что их уволят за профнепригодность. Да и синдром самозванца никто не отменял.
Что с этим делать? Во-первых, обращусь к результатам опроса.
100% опрошенных нами разработчиков готовы помогать менеджерам, если те приходят с вопросами.
А есть ли случаи, когда разработчики не хотят помогать менеджеру разбираться? Конечно, есть. Если менеджер не хочет погружаться и реально разбираться в теме, задает одни и те же вопросы, не запоминая ответы, не хочет учиться самостоятельно — помогать ему будут с меньшим желанием или не будут вовсе.
Итого — если вы правда хотите наработать технические знания, разработчики всегда готовы вам помочь.
Самостоятельно искать нужную информацию
Сначала изучите вопрос самостоятельно. Ищите базовые материалы по теме, читайте Хабр, идите на форумы. Основная задача — понять предметную область, по которой не хватает информации. Отлично помогает YouTube: запросы из разряда «разбор темы для чайников» действительно работают.
Где-то в мире живет индус, который уже разобрал вашу тему и выложил 20-ти минутный ролик с понятным разбором. И это не шутка.
Если у вас хороший уровень английского, изучайте зарубежные источники. В англоязычном интернете вы с большей вероятностью найдете объяснение необходимых вам нюансов, да и материалов по теме там, скорее всего, будет больше.
Выбирать правильное время для общения с разработчиками
Если к тех. лиду проекта идти страшно, найдите более лояльного товарища среди разрабов и обращайтесь к нему. Лайфхак — если у разработчика не хватает на вас времени, поймайте его во время обеда, перерыва на кофе или в курилке.
У разработчиков есть две фазы работы. Активная — когда они непосредственно работают над задачей, в это время переключаться на что-то другое для них нежелательно. И фаза осмысления — пошел выпить кофе, вроде за кодом не сидишь, но задачу обдумываешь. Эта вторая фаза — возможность для ПМов что-то выяснить, задать вопросы, обсудить задачу и способы ее решения. Вам полезно, а разработчику приятно видеть заинтересованность в его работе.
Учиться защищать мнение разработчиков перед клиентами
Стратегия, которая повысит уровень погруженности в технические детали и сделает вас настоящим бро в глазах разработчиков.
Для этого вам нужно хорошо разбираться в теме и задавать правильные вопросы. Правильные — значит те, которые связаны не с технологией в целом, а с ее применением на вашем проекте.
Когда клиент хочет фичу Х, а разработчик говорит, что это невозможно или возможно, но с нюансами, выясняйте, почему так и как это объяснить клиенту. Но не с тем, чтобы заставить его изменить мнение, а чтобы собрать аргументы для его защиты перед клиентом.
Для этого вам нужно разобраться в теме максимально. Поэтому задавайте им самое большое количество уточняющих вопросов, которые только возможно. Аргумент тут простой: «Если я это пойму, я смогу твое мнение защитить».
Преграды на пути
Схема получения драгоценных технических знаний не такая тривиальная, как кажется. Менеджеры, которые только начинают путь, сталкиваются с тремя ограничениями.
Ограниченность по времени
Мы работаем в условиях цейтнотов, сроков, многозадачности. Поток информации большой, нужно успевать его обрабатывать. Возможность выделить конкретное время на изучение тех. части выдается крайне редко.
Сложный язык
Большая часть информации о технологиях, которую вы встретите в интернете, написана техническим языком и для технарей. Когда языка не понимаешь, приходится гуглить не только про саму технологию, но и термины, которые используют для ее объяснения. Так, забив в поиске «Что такое DNS», через сутки можно обнаружить себя с трясущимися от кофе руками, в поту изучающим топологию сети.
Устаревание знаний
Пункт актуален не только для менеджеров, но и для всех в IT. Часто, когда заходишь читать про какую-то технологию, оказывается, что речь в статье про версию-прапрапрабабушку современной технологии. И кстати — она не поддерживается с 2011 года. Если вы на старте работы с проектом что-то изучили по конкретным темам, не факт, что через год, столкнувшись с похожим стэком, сможете разобраться в деталях. Возможно, технологии убегут далеко вперед.
Хорошая новость в том, что этих ограничений бояться не следует — достаточно о них знать. Так вы не станете вешать на себя дополнительную нагрузку и не будете расстраиваться, когда чего-то не успеваете или не понимаете. Как писала выше: общайтесь с командой.
Конечно, ролики на Youtube, статьи и Хабр помогут разобраться с базой, но только разработчик на вашем проекте сможет объяснить, что конкретно пошло не так или почему применить ту или иную технологию невозможно.
Советы и рекомендации
Если вы только встали на этот сложный путь, рекомендую следующее:
- Стараться погружаться в особенности проектов, использовать софт-скилы, чтобы наладить контакт с командой.
- Задавать вопросы разработчикам.
- Набирать теоретикал минимум на Хабре и Ютубе.
Мой личный топ тем для погружения в особенности разработки веб-проектов выглядит так:
- TCP/IP
- Клиент-серверная архитектура
- Фронтенд/бэкенд
- API
- Цикл разработки ПО
- GIT
В зависимости от специфики проектов, у каждого будет свой топ.
Если базовые знания уже есть, продолжайте развиваться:
- Не прекращайте задавать вопросы
- Учитесь защищать мнение разработчиков перед клиентом
- Попробуйте читать код
- Разбирайтесь в нюансах.
В финале делюсь глоссарием основных понятий, который собрала вместе с командой.
Глоссарий написан менеджерами для менеджеров. Так что очень надеюсь, что благодаря ему слез и нервов будет меньше, а уверенных ПМов — больше. А если кто-то захочет дополнить мой словарь другими полезными терминами — пишите в личку.
Где нас найти
Наш тг-канал: @daleedigital. Тут бывают новости, полезности для работы, вакансии и другой диджитал-движ.
Сайт: dalee.ru
Необразованный ПМ ( НПМ) - горе в диджитал-агентстве.
В любом агентстве.
НПМ, смог - не смог, но провёл переговоры с заказчиком.
После, НПМ, смог - не смог, донёс своё видение до разработчиков.
Разработчики реализовали то, что НПМ смог до них донести.
Закономерно - заказчик в шоке, он хотел совсем не это.
Опыт работы ПМ, и опыт общения с "ПМ" говорит об одном - нормальные ПМ - выходцы из разработчиков, или, как минимум, с профильным образованием, курсами, опытом работы.
Остальное - гарантированные проблемы с реализацией проектов, и даже разрывом отношений.
Олег, нам очень жаль, что вам пришлось столкнуться только с таким опытом.
Все когда-то с чего-то начинают. Мы стремимся развивать наших сотрудников и давать им те знания, которых они жаждут.
И, конечно, взять готового ПМ со всеми зананиями и скиллами — это круто, но в условиях рынка далеко не всегда возможно. Плюс в агентстве есть проекты для абсолютно разных компетенций, и это совершенно нормально, если ПМ из дизайнерских проектов захотел перейти на проекты по разработке или наоборот и т.д.