Комментарии 27
Сейчас могу читать код, вести осмысленную беседу с разработчиками
Это вам так кажется, скорее всего.
Просто разработчики вежливы и не говорят, как со стороны выглядит когда менеджер начинает вести беседу на технические темы.
Желательные хардовые навыки у ПМ
Sql и возможно другие
Использование rest api
Хорошее владение excel - vlookup
Grafana, kibana
Поверхностные понятия про кубер - dev/stage/prod
Поверхностные понятия о брокерах
ПМ только с софт-скилами, это как инженер конструктор без знаний сопромата. т.е. ошибки будут закладываться в проект ещё на стадии обсуждения, а выявляться только на стадии опытной эксплуатации.
И я еще заметила, что нет какого-то глоссария, который мог бы упростить жизнь менеджерам-джуниорам. Условно, документ или еще что-то, где были бы описаны базовые понятия. Его просто не существует в природе.
Control Objectives for Information and Related Technologies не существует в природе/
Постановка практически одного вопроса к ПМ-ам и разрабам сначала вывернута, а затем инвертирована по цветам... м.б. я чего-то не понял?
Фактически вы описываете функционал роли Системного Архитектора. Менеджер вообще другим занимается (планирование, риски, задачи). Если встает вопрос технического характера, он должен идти на консультацию к архитектору.
А если вы на встрече принимаете технические решение без валидации команды - горе, беда и не выстроенные процессы и косяк менеджера.
Лучше быть хорошим менеджером без тех. знаний, чем плохим техническим.
Вот тоже по мере чтения пришло понимание, что в буквы ПМ смешаны две разные роли:
1 Product Manager (Product Owner)
2 Project Manager
И в статье пожоже что есть попытка во вторую роль насаждать навыки первой, хотя они должны сосуществовать парой. А еще точнее, по одному продукту может быть и несколько проектов
Менеджер это руководитель. Руководитель не понимающий или не знающий технической составляющей - плохой руководитель. Либо будет требовать "пойди туда, не зная куда", либо грамотные подчинённые будут эксплуатировать низкую компетентность руководителя. И на самом деле это касается не только проектов технического характера, но и любой деятельности (Опыт участия в различных проектах в течение 30 лет)
Вопрос бессмысленный без контекста. Бывают разные структуры команд и компоновки ответственности по ролям в этих командах. Ниже попробую обобщить опыт, полученный за время работы над разными проектами и их обсуждения с коллегами
Есть определенный перечень критериев, на которые бы я порекомендовал обратить внимание в первую очередь при решении о балансе технических и управленческих навыков у проектного менеджера, в том числе (но не ограничиваясь):
Проект является развитием собственного продукта или контрактной разработкой?
Если речь идет о (длительной) контрактной разработке - стоимость ошибки, как правило, выше. Как следствие, требования к техническим навыкам должны расти, поскольку стоимость ошибок на этапах инициации и планирования проекта значительно выше, горизонт планирования также значительно выше
Если речь идет о проекте по развитию собственного продукта, технические навыки могут быть подвинуты на второй план, за счет того, что чаще для развития собственных продуктов используются итерационные подходы, что делает стоимость ошибки ниже
Предполагается ли хранение, обработка, передача информации, которая составляет коммерческую, государственную тайну, персональные данные, иную критическую информацию? Какие требования по безопасности предъявляются к результату проектной деятельности (информационной системе)?
Если речь идет о массивных информационных системах, которые оперируют вышеперечисленной информацией, на протяжении всего жизненного цикла проекта требуется отдавать себе полный отчет в соответствии требованиям информационной безопасности. Проектный менеджер без соответствующих навыков вряд-ли сможет даже сформировать соответствующую команду или оценить дополнительную стоимость за выполнение этих требований
Если речь идет о b2c приложениях, в которых в самом худшем случае могут фигурировать персональные данные, порог вхождения по техническим навыкам снижается, акцент в таких проектах делается на клиентоцентричность, повышение скорости реакции на изменения внешних условий и умение подстраиваться под них
Бюджет проекта и возможность закрыть такие роли, как: бизнес-аналитик, системный аналитик, архитектор, специалист по информационной безопасности, DevOps-инженер, TeamLead, TechLead отдельными специалистами:
Если речь идет о проектах масштаба (или финансирования) стартапа, то в обязанности проектного менеджера в основном и в первую очередь будут входить компетенции именно этих специалистов
Если речь идет о масштабных проектах с хорошим финансированием, то каждый член проектной команды будет выполнять собственную роль, и дополнительной нагрузки по непрофильным направлениям для проектного менедежра (скорее всего) не будет, что позволит снизить порог вхождения с точки зрения технических способностей
Количество провайдеров, с которыми требуется выполнить интеграцию, для достижения поставленной цели. Количество вендоров, с которыми нужно работать, для достижения поставленной цели:
Чем больше - тем выше техническая сложность - тем выше требования к проектному менеджеру, поскольку появляется большое количество зависимостей, для корректного планирования проектной деятельности с учетом которых требуются внушительные технические компетенции
И напротив, если проект является деятельностью одной (нескольких) in-house команд разработки, порог вхождения снижается
Предметная область. Тут все просто:
Решения "от программистов, для программистов" и аналогичные потребуют, конечно же, большей технической экспертизы
Напротив, максимально утилитарные в повседневной жизни решения (например, lifestyle-приложения) потребуют значительно более низкие технические компетенции
К сожалению, у меня не получилось дать бинарный ответ на ваш вопрос. Но надеюсь, что этим комментарием у меня получиться передать общий вектор мышления при собеседовании очередного проектного менеджера на ваш проект
Также, в завершение, хотелось бы напомнить, что проектная деятельность по определению (того жек pmbok) является уникальной, и к каждому проектну подход, в том числе и при сборе команды проекта, потребуется уникальный
Несомненно, технический бекграунд ПМ-у нужен, но без погружения в детали, на уровне общего понимания. Кто говорит что не надо, вероятно, живет в своем манямирке.
Кстати, технический бекграунд нужен и дизайнеру интерфейсов (поменьше, чем менеджеру, но хотя бы какой-то). А фронтендеру нужно хотя бы минимальное понимание дизайна (встречается редко и это большая проблема).
Дочитав до первой диаграммы, стало ясно, что менеджеры всегда будут говорить ДА клиенту, а особенно своему директору на планерках и даже если такой эффективный менеджер возьмет с собой технаря на встречу, чтобы «нарисовать 7 красных перпендикулярных линий, зелёным маркером» и получит от технаря «подсказку», что это невозможно, то его быстро приструнят и скажут не торопиться с выводами, а необходимо собрать бэкгранд по фидбэкам, и встретиться через месяц, чтобы наконец понять «прибить табличку или прикрутить её», а за это время пожл отчеты, отчеты и еще раз отчеты, чтобы статистика не проседала и красивые графики лежали у руководства, а пока забибикаем мозги разрабам или кому там, всякими митингами, совещаниями, спринтами и прочей фигнёй-показухой!
PS
А вообще такие эффективные менеджеры проектов напоминаю барышню из английского сериала «компьютерщики», когда обычного гуманитария-менеджера назначают на должность начальника IT отдела, к админам… итог ясен и предсказуем: тупо сидит и торгует лицом, а за нее решают вопросы системные администраторы… в итоге если косячит она - выгребают все… звезд так же не хватает, а по факту команда прекрасно продолжает работать, даже несмотря, что их начальник тупая как пробка и больше балласт, чем помощник или наставник… стоит задуматься точно нужны ПМ в таком количестве?!
Или все таки надо побольше… ну так человек 10 «прожектов» на один проект или на одного клиента))) ну а что, один отвечает за зеленые линии, другой за перпендикулярные, а третьи за котиков, тогда точно не надо иметь технические скиллы))) а вот разрабов-технарей можно и до одного человека довести - ОН ЖЕ ЭКСПЕРТ, ОН ЖЕ СПЕЦИАЛИСТ)))) и как раньше работали без ПМ в таких количествах - ума не приложу… тупее наверно только набрать толпу эйчаров в компанию из трех человек (а вдруг через 10 лет компания будет расширяться, а у нас уже целый отдел из десятка кадровиков есть))))
И еще добавлю, многие почему то приравнивают ПМ к руководителю… лично для меня руководитель=директор, который мне платит, а ПМ может быть менеджером… но тогда скажите мне нафиг мне «продакт менеджер» тогда, если есть «прожект менеджер»? Задача менеджера по продукту или непосредственно руководства компании (если оно общается с клиентом) получить наиболее полное ТЗ, далее технарь сразу или после анализа ТЗ выдаст, что, сколько и чего необходимо для решения задачи и уже выдаст на гора то и так, как необходимо с технической точки зрения отдать решение клиенту, но нет - лучше же наплодить кучу и одного менеджера, чтобы враг не догадался, а потом технарь передаст гуманитарию свои правки, гуманитарий клиенту свои фантазии и то в чем не разбирается но умно кивает гривой и благодаря сломанному телефону 100500 раз меняется ТЗ и хотелки, а по итогу выясняется, что многое уже в проекте обговорено, что изменить нельзя и будет так и никак иначе и вообще продукт уже продан задним числом и выпущен в продакшен без согласования с технарем, потому что ПМ лучше знает рынок и как графики красивые рисовать для директора и клиента, и вообще готовый продукт надо было отдать вчера, но когда клиент забирает продукт - выясняется, что заказчик мог бы подождать еще месяц и вообще вот ту фичу что прикрутили - она никому не впёрлась… ПМ молодец, он все графики рисовал и подсовывал директорам и клиенту, а разраб весь седой понимает, что надо уходить с галер)))
о тогда скажите мне нафиг мне «продакт менеджер» тогда, если есть «прожект менеджер»
Все очень просто
Продакт менеджетр - отвечает за "продукт" и за БИЗНЕС эффект его внедрения.
Преджет менеджер - отвечает за разработку и внедрение продукта согласно требований продак менеджера
Оба отвечают перед спонсором проекта, которые на все это безобразие дал денег и хочет получить отдачу.
Если, к примеру продукт вышел на рынок и провалился - люлей должен получить "продакт менеджер"
Если продукт вышел не в срок, либо он не соответствует тому, что просил "продакт" - люлей должен получить "проджект менеджер"
-----------------
Оба имеют полное право требовать работы от команды, но каждый в своей части. "Продакт" выносит требования, "проджект" контролирует процес.
Почему их два - тоже все просто. Разные скиллы.
"Продакт" - обычно бизнес человек, который может и чаще всего отвечает за разработку продукта. Обычно использует дизайнера себе в помощь и других продуктовиков
"Проджект" - чисто "внедряй". Сегодня один продукт, завтра вообще другой
благодарю кэп, но в чем разница между двумя менеджеров, думаю и так понятна... тут рассматривался вопрос не в контексте должностей, а в целом
и да, прожект - не всегда внедряй, как и продакт - не всегда отвечает за разработку продукта... но продакт может снять задачку с клиента, а вот рассказать про плюсы и минусы, проджект - не может, без помощи инженера...
по итогу, советую пересмотреть репризы и комические постановы про зеленые линии красным цветом и собрание, на котором решают прикрутить или прибить табличку
Так должно быть. Если где-то не так - два варианта. Либо это просто плохо, либо организация придумала свое ноу хау.
Как вы понимаете, есть миллион способов как сделать плохо, и один-два - как сделать хорошо
пока видел только эффективных менеджеров и рабов на галере, но почему то ни одного эффективного раба и ни одной галеры с менеджерами, в качестве гребцов... но если вы считаете, что продукт создает не инженер, а цифры на бирже или красивый график на столе директора, тогда не обижайтесь, когда вам бабка с семечками скажет, что сегодня у нее семечки стоят дороже, чем вчера, потому что биток подскачил)) примите, как реальность, которую сами же и создаете
но чтобы вы не думали, что я считаю, что менеджеры проектов не нужны - то вы ошибаетесь... чем больше команда, чем масштабней проект, в котором надо решить 100500 задач, тем нужнее ЗАМЫ на местах, потому что директор физически не успеет всех выслушать, но тогда неважно как мы назовем ТОПа, который отвечает за направление в развитии бизнеса... фин дир, начальник сервиса, производства или директора по общим вопросам))) главное, чтобы не ЗАМ-ЗАМАа по ЗАМам, а на деле - эффективный менеджер на теплом месте... лучше уж тогда пусть будут пафосные должности, типо: клининг-менеджеры, зато они все так же будут поддерживать чистоту на территории, кухне или где там вам нужно, как говорится, как не назови, а суть да дело не изменится)))) поэтому если вам так катастрофически хочется начальника группы, направления или производства - назвать ПМ, да хоть утюгом, главное что делать он будет то же самое))))
Продукт, точнее его идею, требования к нему создает именно "продакт менеджер". Если он конечно есть. Но там тоже часто бывают люди, которые вместо этого принимаются за реализацию всех фенечек мира, которые они 10 лет вынашивали в своей голове.
Команда уже его реализует в коде и не только.
Ключевое тут даже не то, кто там больше в колхозе работал, а то, кто пойдет на ковер, если продукт не принесет денег. Поэтому проще всего понять роль человека от его прямой ответственности.
Разрабочик в принципе не отвечает за бизнес эффект внедрения, его его код прошел все тесты.
так так так... "создает" продакт может только коричневого цвета в сортире))))) вы как бы мягкое с теплым не путайте! Спрос рождает предложения, а не наоборот слава богу))) и пока так - продакты ничего не создают и не надо гипербализировать... у хорошего продакта и без ваших - "создает", хватает дел! Это в первых, а в вторых обычно таких людей берут уже под готовый продукт, чтобы он, этот самый продакт менеджер, как раз не бегал с вопросами к инженеру "а как оно работает" и не вешал лапшу на уши клиенту, что "может еще кофе варить", а потом не создавал компании и рабам на галере доп. проблемы, типо "я уже продал функционал - варить кофе, так что сделай"))))) а продавал услуги или товар согласно ТЗ и возможностям этого самого продукта без всяких розовых пони, которые умеют варить кофе, но которые нах никому не вперлись.... ну и в третьих никто не создает продукт из воздуха, опять же есть СПРОС и тогда могут что то запилить, потому что уже есть потенциальный клиент и посему разрабу не надо знать есть выхлоп или нет... для этого как раз есть продажники, которые через свои наработанные базы клиентов находят заказы и по этим самым продажам можно уже строить графики, подсчитывать прибыль-убытки, ВСЕЕЕЕЕЕ дружище - не изобретайте вы велик... а то реально начинает звучать, как бред сумасшедшего, который пытается оправдать свою роль в большом организме, который вообще то и без ПМ спокойно существует, но вы упорно пытаетесь себе наверно, доказать что прожекты нужны, правда выглядит это, как сова натянутая на глобус...
ЗЫ
и как раньше самолеты, при совке строили... вот же недалекие - КБ открывали, а надо было просто эффективного менеджера притащить или 10, короче чем больше, тем хуже... наверно бы сейчас до сих пор самолеты были бы только на чертежах, зато графики красивенькие бы на столах лежали)))) ляяяяяпоооооотаааааа
Мне кажется, ответ на вопрос зависит от размера команды и структуры управления. ПМ может быть и на команду из 5 и из 50 человек. Чем меньше, тем больше вероятность, что нужны выше технические скилы. Важно чтобы команда понимала ПМа и ПМ понимал команду. Если ПМ сам собирает команду, то тут нужно выше базового. Если есть кто-то, вроде лида, кто установит связь между бизнесом и разработчиками, то базового достаточно.
Но базовый, думаю, необходим в любом случае.
Вы смешали продукта и проджекта
Вы смешали технические и хард-скиллы (например, навык планирования для ПМ - это хард-скилл)
Мне кажется пропущен важный момент, какие компетенции важны, а какие - не очень. Конечно если рассуждать о предмете с высоты полета астронафта
И еще ремарка: в этой статье фразы «технический бэкграунд ПМ», «техническая грамотность», «техническая подкованность» — синонимы.
то разницы наверное нет. А если приглядеться - то есть. И это очень странно :)
Что не нужно:
Технические скиллы, которые могут быть использованы для "подмены" кого-то из членов команды: писать код, писать тесты и т.д. Они бесполезны, так как ПМ все равно не может обладать ими даже на минимальном уровне, а даже если ими обладал когда-то - они давно устарели. Ну и самое главное, если допустим, что ПМ может сделать работу разработчика, тогда вопрос - а кто будет делать его? Да и применить их довольно таки сложно. Ну не делать же код ревью лично :) Поэтому смело забываем о своих тех. скилах и занимается управлением проекта. Если что, имею опыт перехода в ПМы после 10 лет архитектуры, а до того разработка ну и все такое :)
Что еще не нужно:
Точнее знать можно, но все равно не поможет. К примеру, вы можете знать http response status коды. Это конечно круто знать, что бывает ответ 404, ли 500, но вот дальше скорее всего будет анекдот про петьку и приборы, поэтому лучше это знать тихо для себя и не отсвечивать. Анекдот вот:
Летят Петька с Василием Иванычем в самолете:
— Петька, прибор?!
— Тридцать!
— Что — "тридцать"?
— А что — "прибор"?
Просто техническое знание обычно цепляет другое техническое знание, и мало просто знать 404. Поэтому если чего знаете - примите, что вам это кажется и радуйтесь, что если вы свое знание проявлили, вас не стали "колупать" дальше. Либо вы реально знаете, но тогда вопрос - а зачем применяете в роли ПМа?
Что нужно:
Хорошее знание SDLC вообще и в конкретной организации в частности. Иначе непонятно, чем вообще тогда ПМ может управлять. SDLC (software development life cycle) - это в том числе про взаимоотношения людей в команде, на каких условиях они передают "фишку" друг другу и что им надо для начала работ. Хотя уже тут, по опыту - народ откровенно сыпеться уже тут, или в лучшем случае следит и участвует в "понимании" процесс формально. По опыту - это из собеседований ПМов :)
Дальше идет очевидное направление, что еще очень желательно знать, чтобы не участовать формально. А именно, надо знать, какие артефакты создаются в процессе, из чего они состоят и что будет (либо может быть), если чего-то нет полностью или частично. В идеале вообще надо понимать, для кого тот или иной артефакт создается и как он дальше используется.
А вот дальше уже появляется более-менее относительно опциональная штука - понимать базовое устройство этих артефактов, чем они отличаются друг от друга и как это отличие можно использовать.
К примеру, тестовая среда. Это тоже артефакт и очень важный. Надо понимать, сколько их у нас, кто владелец каждой среды и зачем она нужна. В случае интеграционного проекта где заканчивается граница этой среды, и где начинается что-то еще, за которое могут отвечать совсем другие люди. Что-то возможно мы шарим с другими и это надо все время учитывать. Хотя были ПМы, которые на собеседовании на вопрос, что нужно QA для начала тестирования приложения, просто говорили, что нужно написать тесты и все.
Является ли это техническим бэкграундом ПМа? Думаю да. По сути, это технология (или набор технологий) производства софта, процессом которого так или иначе управляет ПМ. Если этим не владеть - взаимодействие с командой сведется к секретарским обязанностям и "торговле .балом" перед всеми. Ну можно еще добавлять какие-нибуть стандартные лозунги, типа "баги должны исправляться вовремя", "код нужно писать хорошо", "заказчик должен быть доволен"
Какой должен быть уровень технической грамотности у менеджера проектов?