Всем привет. Меня зовут Марина Заботина, работаю аккаунт-директором в диджитал-агентстве. У нас в штате 320 человек. Хочу поднять вроде бы простую, но холиварную тему о том, какой уровень технической грамотности должен быть у менеджера проектов (ПМ).
Конкретно у меня команда из нескольких менеджеров. Естественно, проекты попадаются разного калибра. И уровень у менеджеров тоже не одинаковый.
Когда я сама только начинала работу в качестве ПM, то у меня не было технического бэкграунда. Но постепенно смогла набрать его. Сейчас могу читать код, вести осмысленную беседу с разработчиками, знаю термины и понятия. На мой взгляд, к этому должен стремиться каждый менеджер, который имеет дело с проектами по разработке.
Мы с коллегами часто обсуждаем, как вообще менеджеру прокачивать этот скилл, куда бежать, насколько «хардовым» он должен быть. Стало интересно, что об этом думают в комьюнити сейчас.
Давайте сделаем несколько допущений:
Сейчас речь о менеджерах, работающих именно в заказной разработке;
Это менеджеры, у которых есть проекты по разработке, а не только по дизайну и/или контенту. То есть они могут вести проект какого-нибудь интранета или заниматься большими интернет-магазинами;
Менеджерам необходимо защищать решения перед клиентам и обосновывать выбор тех или иных технологий для проекта;
Соответственно, для этого менеджеры ходят к разработчикам и советуются с ними, прежде чем идти к клиенту.
И еще ремарка: в этой статье фразы «технический бэкграунд ПМ», «техническая грамотность», «техническая подкованность» — синонимы.
Какой должен быть уровень технической грамотности при таких вводных?
Прежде чем идти на Хабр, я провела внутри компании небольшой опрос по теме. Было два варианта опроса — один для менеджеров, другой — для разработчиков.
Что рассказали менеджеры
У менеджеров было интересно узнать, как они оценивают свой уровень технической грамотности, какие проблемы видят в общении с разработчиками.
А вот некоторые ответы менеджеров на вопрос о том, какие трудности у них возникают из-за недостатка технического бэкграунда:
В технически сложных задачах приходится долго разбираться и задавать вопросы разрабам, которые могут показаться им глупыми. Но это приходится делать.
Не всегда понимаю, что говорит разработчик
Трудности с полноценной формулировкой задачи, некоторые важные для выполнения детали могут быть не учтены, не уточнены заранее у клиента.
Трудности в аргументации в разговоре с клиентом, особенно когда нужно обрабатывать возражения.
Основные сложности на моей стороне связаны с пониманием серверной инфрастуктуры.
Несмотря на данные выше на рынке бытует мнение, и я с ним согласна, что технический бэкграунд для менеджера — сейчас скорее преимущество, чем мастхэв с точки зрения работодателей. Если посмотреть вакансии на ПМов, то в них редко встретишь требования в духе «Обязателен минимальный опыт работы с кодом» и т.п. Но если у вас классные софты, и вы при этом еще и можете вести осмысленный диалог с разработчиками — то у работодателя вы будете в топе.
Что рассказали разработчики
У разработчиков я выясняла, чувствуют ли они разницу при общении с менеджером с техническими знаниями и без. И считают ли они, что ПМ обязательно должен обладать техническим бэкграундом. Тут вышел интересный момент:
При этом на вопрос «Чувствуете ли вы разницу в качестве коммуникации с технически грамотным менеджером и с тем, у кого такого бэкграунда нет?» 80% ребят ответили, что да, чувствуют.
Вот некоторые ответы разработчиков на вопрос: можете рассказать в двух словах, в чем вы видите разницу в общении с технически подкованным ПМ, если она есть?
В двух словах: разница в понимании.
важен не сколько технический бэкграунд, сколько понимание того как всё работает. если человек понимает, то он еще на самой ранней стадии даёт фидбек клиенту о нереалистичности, а не приходит с идеей, на которую получает ответ от технаря «это работает не так», отвлекая того по пустякам
Технически подкованного менеджера очень сложно обмануть. в оценке задач (объективно, а не то что бы я пытался)
Ну и не нужно объяснять банальные вещи
В переводе задач с клиентского на разрабский; в фильтрации задач. Технически подкованный менеджер сам уточнит все необходимые моменты перед тем, как давать задачу разработчику.
А на вопрос о том, готовы ли они помогать менеджерам, если те приходят к ним с вопросами, почти все ответили «Да». Мы, менеджеры, очень ценим, когда разработчики просвещают нас и помогают лучше понимать какие-то процессы и термины.
Проблемы ПМов при погружении в технические детали
И еще момент — с техническим бэкграундом для ПМ есть одна большая проблема — мало материалов.
У нас есть Хабр, есть и другие форумы, есть ютуб и поисковая строка в гугл в конце концов. Но все равно большая часть технических материалов написана технарями для технарей. Менеджер же набирает новые знания с учетом двух условий:
Ограниченность по времени. Как правило, прилетает какой-то запрос от клиента или команды, где фигурирует незнакомая технология. Или термины. И нужно скорее разобраться, о чем идет речь.
Сложный язык для относительно быстрого усвоения материала. Это как раз про то, что пишут-то все эти материалы изначально не для менеджеров.
Устаревание знаний. Эта проблема не только для ПМов, но мы ее тоже ощущаем на своей шкуре.
И я еще заметила, что нет какого-то глоссария, который мог бы упростить жизнь менеджерам-джуниорам. Условно, документ или еще что-то, где были бы описаны базовые понятия. Его просто не существует в природе. Может, в отдельных компаниях есть что-то похожее, но в общем на рынке — нет. При этом в силу неопытности, джуны могут не уметь верно формулировать вопросы. А это, в свою очередь, бесит разработчиков.
Но такой глоссарий бы очень пригодился. Помню, что в свое время мне его очень не хватало. И вижу, как сегодня его все так же не хватает менее опытным коллегам.
А по итогу
Хочу спросить у уважаемых хабраюзеров: что вы обо всем этом думаете? Какой должен быть технический бэкграунд у менеджера проектов, если он сталкивается с проектами с разработкой?
Варианты:
Никакого. Менеджер может обходиться без технический знаний при условии развитых софтов.
Базовый уровень. Допустим, что базовым мы считаем уровень, при котором ПМ знает основные понятия, понимает, чем отличается один инструмент от другого и умеет верно формулировать вопросы разработчику.
Продвинутый уровень. Либо ПМ имеет профильное образование, либо за время работы самостоятельно погрузился в разработку. И теперь может на равных разговаривать с разработчиком и защищать решения перед клиентом без предварительных обсуждений с командой. В том смысле что он сам может подобрать аргументы.
За комментарии отдельная благодарность: всегда интересно читать мнения разработчиков и менеджеров по данному вопросу.
