×

Нужны ли технические навыки менеджеру проектов?

На эту тему как на просторах украинских (ссылка 1, ссылка 2), так и зарубежных ресурсов (ссылка 3, ссылка 4) были написаны десятки статей, большинство из которых сводятся к общему выводу, что нет.

Менеджеру проектов (как и менеджеру в принципе) технические скиллы не нужны, т.к. менеджер свои задачи, как организовать работу команды должен решать за счет soft skills. И с этими утверждениями достаточно трудно поспорить.

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

Мой личный, более чем 7-ти летний опыт управления проектами и командами проектов говорит тоже самое. Не имея технического бэкграунда, мне удавалось, как мне скромно кажется, достаточно успешно управлять и обеспечить delivery проектов и программ различного масштаба. Хотя теории и совсем чуть-чуть практики разработки ПО я все же учился.

Но такая постановка вопроса устраивала не всех. Трое ученых 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. Для желающих: с самим исследованием можно ознакомиться здесь, почитать обзорную статью здесь.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Хочу обратиться к ребятам, которым повезло не встречать технически слабых или в целом слабых проектных менеджеров. Вы даже не представляете, насколько вам повезло!

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

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

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

Но главное веселье начинается тогда, когда коммуникация с клиентом происходит только через такого менеджера. Вы просто не сможете получить нужные ответы на все необходимые вопросы. Вам придется догадываться, что и как нужно сделать. Потом такой менеджер обязательно найдёт виноватых. Это делать они почему-то умеют.

Менеджер проектов — это прежде всего человек, отвечающий за правильную организацию процессов и взаимодействие между ними. Технический бэкграунд несомненно полезен, но не обязателен. То есть высококомпетентный менеджер проектов (именно менеджер) без тех. навыков намного более полезен, чем средний менеджер выросший из программистов. Здесь идет речь об IT, а если сегодня менеджер работает над IT-проектом, завтра над строительным, а после завтра над аэрокосмическим? Ему нужно уметь кодить, строить и самолетостроение знать? Нет, ему нужно быть профессиональным менеджером проектов и только.

126 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Тама кто-то соплей напускал и сообщения удалили, так что отвечаю тут:

Viktor, я с вами согласен. Но не кажется ли вам, что вы пишите не о ПМ, а о лидере или как сейчас принято по-современному-модному — product owner. Эти люди нужны и их роль и вклад в общее дело понятен, важен, востребован и очень уважаем. Но они не имеют ничего, повторю еще раз, абсолютно ничего общего с ПМ. для меня проблема ПМ состоит не в том, что они бесполезны — фиг бы с ним. А с тем — что они губительны для молодых и неокрепших!

Однозначно потрібно, хоча б мати якесь уявлення, так як складні задачі можуть здаватись необізнаним людям простими і наоборот прості сладними.

По моему скромному мнению, всё зависит от культуры и моделей.

Если у человека в голове модель «я буду работать и стану менеджером». То ему будет некомфортно видеть человека без технического бекграунда.
Я сам в молодости этим переболел. Был горячим и амбициозным. Работал в одной мощной компании в новосозданном отделе.
Начальник моего отдела в Киеве уволился. А мне руководство корпоративной практики сказало: «Витя, мы не можем сделать тебя менеджером, потому что у тебя большой опыт работы в деливери — ты хорошо разбираешься в проектах и находишь общий язык с командами. Потому нам выгоднее нанять тебе начальника, а ты будешь работать „в поле“». Меня это сильно задело, я понял, что как бы я ни старался — движения не будет, и я (весь такой замечательный и перспективный) не смогу себя реализовать. В общем, через полчаса я написал заявление.

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

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

Или другой пример. В качетсве коуча мне приходилось работать с множеством команд. На первых этапах довольно часто коучу приходится эти команды менеджить. (Особенно, когда нужно что-то делать, не ломая и не останавливая текущий процесс. Т.е. тушить пожар в едущем поезде так, чтобы поезд ехал и приехал, как ранее ожидалось.) Причём, делать это приходится задаванием вопросов, побуждением к каким-то действиям и т.п.

Естественно, что членами команды коуч не воспринимается как менеджер. И никакого конфликта не возникает (кроме первых нескольких дней, когда команда привыкает к новому персонажу). Наоборот, при правильном подходе, люди открываются и раскрываются, люди растут и зажигаются.

> — Как можно решить задачу?
> — Вот так.
> — А по времени?
> — 3 дня.

Вопрос же можно поставить по-другому. :) Например: «Нам нужно решить эту задачу. Давайте проанализируем способы её решения.» (набросать критериев) Тем самым мы вовлекаем технарей, даём им вкусное для ума, расширяем их кругозор, и при этом техническая компетентность менеджера никого не муляет.

> есть ребята, которые обеспечивают классный командный результат и успевают писать код (Кстати, таких на самом деле очень и очень немного и чаще, увы, получается что-то одно).

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

Да, классно и полезно, когда менеджер знает какие подходы, практики и технологии могут помочь решить какие-то производственные проблемы, но вот уметь «написать bubble sort на Java» или «заменить любого из членов команды» — это лишнее и даже где-то вредно.

Есть мнение, что эффективный менеджер и успешный менеджер — не одно и то же. Эффективных менеджеров обычно не очень видно, но без них — процесс деградирует, а вот успешных — видно издалека, но если их убрать — все продолжает работать.
«Софт-скилз» точно помогут быть успешным, но без технических знаний врядли можно быть эффективным. В идеале, конечно нужно и то и другое, но в реальности это редкость.

Менеджер проекта работает на стыках разных активностей и ему желательно понимать «интерфейсы», чтобы делать это эффективно. Эффективно, это значит не хуже чем конкуренты в отрасли. Например, если в практике отрасли принято, что менеджер проекта имеет общее понимание о системах VCS, то ему не надо обращаться к экспертам для согласования этого вопроса, и решение о подключении новой команды к разработке будет приниматься быстрее, чем у менеджера, который с VCS не знаком.

То есть эффективность зависит от отрасли и специфических ей знаний. Менеджер строительных проектов сможет перейти в ИТ-проекты, и наоборот, но он будет менее эффективным, чем ранее, какими бы «софт-скилз» он ни обладал.

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

Вставлю свои 5 копеек.
Технические навыки нужны:
— RnD проекты
— Малые проекты, где не нужен выделенный ПМ

Технические навыки не важны:
— Взрослые проекты
— Простые проекты на базе существующих систем
— Крупные проекты и программы, где есть архитекторы чтобы закрыть тех часть и огромный объем управленческой работы

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

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

— Малые проекты, где не нужен выделенный ПМ
а в чём простите разница?
— Взрослые проекты
Менеджеру проектов (как и менеджеру в принципе) технические скиллы не нужны
был такой советский анекдот:

после полета американцев на Луну, Брежнев вызывает к себе советских космонавтов и приказывает им слетать на Солнце.
На приказ Генсека космонавты говорят: — сгорим Леонид Ильич невозможно.
А Брежнев категорично: — вы что думаете, что в Политбюро дураки сидят, ночью полетите...
так вот это как раз про таких менеджеров...

В минулому мав багато досвіду з супер-зубатими РМами які практично нічого не відстрілювали в технологіях і все нормально було. Задача РМа — зробити скоуп за обмежений час та ресурси (гроші/людей і тд), і хороший РМ з чим чудово впорається і без знання що таке транспайлери та конпелятори. Нижче баттхерт людей які просто не працювали з нормальними РМами.

DHH з вами не погоджується, а погоджується з тими самими дослідниками.

m.signalvnoise.com/...y-ac8e1ebd444c#.8iyb6z69b

Спасибо, эта ссылка посолиднее, чем британские учёные (красиво с Ворвиком в статье выкрутились), которые сравнивают мягкое с тёплым: "

серьезной технической экспертизой и глубоким знанием бизнеса
" на практике это — противоположности кроме скрам-команд :)

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

И тут появляется тонкая грань:
1. ПМы, доказывающие что достаточно софт скилов — однозначно не достаточно опытны или, в отдельных случаях, глупы.
2. Технические специалисты, уверенные в ничтожности позиции ПМа, как таковой:
— однозначно мало/плохо или вообще не разбираются в процессах построения команды и этапах создания продукта (разработка, это один из этапов).
— скорее всего, за свою карьеру не встречали опытных менеджеров.
— имеют проблемы с социализацией и (только «и», «или» тут не уместно) завышенную самооценку. Есть исключения с заниженной самооценкой и пофигистами, просто пишущими код.

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

В условиях работы в аутсорс, когда ПМ может работать с разными проектами, разными технологиями, разными командами, и разными клиентами, складывается такое впечатление, что ПМ обязан быть технически подкован под каждого в команде, каждую технологию и каждую сферу бизнеса. Да! Это действительно было бы большим преимуществом. Но тут будет уместен вопрос: сколько времени понадобится на качественное изучение всего этого?

И следующий вопрос: должен ли технический специалист знать «N» технологий одновременно, да бы небыло проблем в коммуникации между любыми технологиями фронтенда, бекенда, девопс, мобайл, десктоп, тестировщиками, автоматизаторами, embedded?

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

Так же, очень часто путают понятия «управлять» проектом и «руководить» проектом. И руководство подменяют понятием управление. Руководят проектом за частую: Владелец, СЕО, Директор, Фаундер, Синиор/Супер синиор/Програм менеджер.

Проектный менеджер же, это часть всей команды/компании/отдела. Это человек, который связывает выше перечисленных персон и команду (кто бы в нее не входил), консультирует их и направляет. Тем самым, обеспечивая и поддерживая работу всего механизма, а не только команды разработки. Как он это делает и какие дополнительные обязанности и навыки ему требуются для работы с данным проектом и данной командой — это уже отдельный вопрос требующий индивидуального подхода.

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

не нужны и даже вредны.
нет хуже менеджера который лезет с советами как программистам надо программировать.

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

донести какие-то технические решения менеджеру, которые возможно дольше по срокам, но лучше в перспективе
Что будет, если это сделать? нужно ли это клиенту, вписывается ли в стратегию развития продукта?
Чего не будет, если этого не сделать? несет ли это дополнительные риски?
Если таки браться, то чем придется пожертвовать?

Правильные вопросы нарабатываются опытом менеджмента(риски, приоритеты, стратегия), а не опытом разработки.

а менеджер смотри на ETA и все
--->
то это неверно уже клиника..
Нужны ли технические навыки менеджеру проектов?
Нужны в обязательном порядке. Иначе получается бесполезный разговор ежа с табуреткой.

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

В нарушении доверия к компетентности свою роль играет и формат отношений «начальник-подчиненный», «начальнику» легче быть лишенцем (нифига не делая и не разбираясь в теме вообще), чем подчиненному (подчиненных как правило больше одного и они компетенцию друг друга палят). Переход к формату «кооператив» — позволяет успешно воздействовать на внутри командный климат, приводя к росту доверия, снижая необходимость «доказательства» компетентности в неиспользуемых областях (тут вопрос о нужной глубине знаний в непрофильной области для успеха совместного действия).

Еще один холиварный топик — оценка качества работы менеджера. Т.к. тут идет не только управление командой, а в продуктах/проектах, что включает в себя дополнительные опции (общение с параллельными командами, стороной клиента, и т.д.). Да и каждый человек оценивает по-разному, включая личные впечатления, один будет доволен менеджером, другой будет жаловаться что его ущемляют.
Причина всех бед в команде это отсуствие нормального общения и донесения своей мысли/проблем до собеседника.

Причина всех бед в команде
 Их не одна. И не все причины могут быть изменены / проигнорированы / и т.д.

Естественно. Но если бы один объяснил что ему надо, а другой донес свою мысль, было бы намного проще. Стонут ведь от «нетехничности» менеджера по той причине, что не могут донести свою мысль и получить необходимую информацию.

ну ... ета прогресс :) А то давеча полемизировали нужно ли ПМ-у на работу приходить и на мыло вовремя отвечать :8)

Результаты были в какой-то мере ожидаемыми.
Ессно люди предпочитают разговаривать со «своим», пусть и бывшим, спецом «среди чужих», а не просто с управленцем, который будет руководить чем угодно.
менеджер свои задачи, как организовать работу команды должен решать за счет soft skills. И с этими утверждениями достаточно трудно поспорить.
Но можно :) Згрубша :8), я бы на вопрос ответил так: время от времени от ПМа требуется принимать срочные решения. Например, ответить уважаемому клиенту на вопрос «когда наконец я получу от вас этот факен сервис, назовите мне дату!». Или «мы хотим получить преимущество перед конкурентами, потому релиз продукта сдвигается на два месяца вперед, подтвердите, что Вы успеете все, что запланировано, и добавите еще такие фичи: [список фич] ». Если вместе с ПМ-ом на колле с заказчиком нет (или вааще в тиме нет) техлида/архитектора, то сам ПМ и должен быть настолько технически грамотным, чтобы удовлетворить (насколько это возможно) свою команду. И настолько soft skill-ным , чтобы удовлетворить клиента.
А то давеча полемизировали нужно ли ПМ-у на работу приходить и на мыло вовремя отвечать :8)

Неужели началось?
Где можно почитать? :)

PM, как я считаю, должен уметь говорить на одном языке как с командой, так и с заказчиками. С командой — техническим языком (не допуская приведенных в статье диалогов, это превращает Вас из руководителя в посмешище), с заказчиками — языком рисков и бюджета.
PM без практического технического бэкграунда — это статист. Управлять проектом он не может, поскольку не способен принять стратегическое решение из-за недостатка знаний, максимум, что он может — это служить прокладкой между заказчиком и командой, принимая на себя раздражающие команду вопросы типа «почему моя вчерашняя хотелка не сделана позавчера». Это, конечно, тоже неплохо — но не называется управлением проектом.
Под стратегическим решением я понимаю примерно вот такие ситуации: есть команда — 3 разраба (2 синьора, 1 джун) и 1 QA. 1 синьор разраб хочет делать проект на Node.js, другой говорит, что Angular лучше. Какое решение сможет принять такой PM, если он данные технологии видел только на картинках? Сможет ли он сопоставить текущие требования проекта, прикинуть, в какую сторону они могут поменяться, базируясь на понимании рынка, исходя из этого, просчитать архитектуру, хотя бы обзорно, применить полученные выводы к особенностям технологий, о которых идёт спор, просчитать риски по каждой из них, разработать меры по их уменьшению и на базе риск-анализа принять решение о той технологии, которая будет использована? Я думаю, ответ угадаете сами :)
В случае PMа без технических знаний, управление проектом принимает на себя лид (хорошо, если он есть), в случае его отсутствия — тот, кому не впадло. В случае, если впадло всем — решения принимаются человеком, ответственным за выполнение конкретной задачи, соответственно, проблемы интеграции, архитектуры и пр. будут решаться по ходу, и не факт, что вообще будут системно решаться, а не забиваться костылями и велосипедами. В случае существования такого проекта более полугода, можно смело ванговать кошмарное качество кода, тесты, написанные «от случая к случаю» без вменяемой стратегии измерения покрытия, постоянно растущий технический долг, которым тупо никто даже не заморачивается, баги регрессии, выпадающие в самых неожиданных местах и прочие радости.
Далее, пройдусь насчёт контроля проекта. PM, обладающий техническим опытом, может контролировать решения и временнЫе оценки задач. Он понимает, о чём задача и сколько времени надо, чтобы её сделать. В случае отсутствия опыта, это вырождается в 2 варианта: либо PM верит всему, что ему скажут, после чего команда начинает работать, как хочет, либо он начинает базироваться на оценках заказчика, которые, в свою очередь, базируются на хотелках, а не на понимании деталей проекта, после чего на тестирование регрессии, которое объективно занимает неделю, выделяется 1 день.
Могу ещё много чего рассказать про то, чего не умеет нетехнический PM :)
ИМХО — такой юнит ограниченно полезен в случае проекта с техлидом. В случае проекта без техлида — такой юнит зачастую будет больше вредить проекту, нежели будет полезен.

поскольку не способен принять стратегическое решение
аккуратнее с терминологией )) (уровней как правило 3: стратегический, тактический и оперативный и для каждой области действия они свои). Технические стратегические решения — тех.лид/архитектор. Не технические стратегические решения — уже другая область. Роль ПМ в рамках работы по стратегическому техническому решению — оценка изменения бюджета/сроков (ресурсов) при внесении изменения (оценка — это выводы о допустимости, рисках и прочее управленческое). Проблема возникает, если между Тех.лид/Архитектор и ПМ отсутствует продуктивное взаимодействие и они неспособны предоставить совместный результат, который позволит принять другое стратегическое решение (инвестиционного уровня, уровня Заказчика) — «быть или не быть», «и если да, в каком виде».

В случае, если на проекте нет тех. лида (например, команда небольшая) зачастую PM шарит роль тех. лида и PM и должен принимать как технические, так и нетехнические стратегические решения.

:) У нас 80% PM бывшие бармены, HR, маркетологи, продажники

Да. А ещё у нас конкурс на вакансию PM больше, чем даже на Junior QA :) Пруф где-то на ДОУ был.

есть команда — 3 разраба (2 синьора, 1 джун) и 1 QA. 1 синьор разраб хочет делать проект на Node.js, другой говорит, что Angular лучше. Какое решение сможет принять такой PM, если он данные технологии видел только на картинках?
То, которое в полной мере обеспечит заявленные требования заказчика, бюджет и сроки. Все перечисленное PM должен уметь посчитать.
Если оба варианта одинаковы в рамках соблюдения требований, бюджета и сроков, то никто не запрещает PM пригласить к обсуждению своего начальника, других экспертов, или о Боже, дать на выбор заказчику. Само собой, вопросы, которые выносятся на такое обсуждение не должны быть мелочными.
Я за PM-ов с техническим бэкграундом. Любой PM должен знать предметную область своих проектов, это как минимум даст ему плюсы в карму перед командой(об этом собственно и статья). Но никто не запрещает PM без тех. навыков в процессе работы их получить. Хотя бы на уровне понимания и поддержания беседы с командой. У хорошего PM всегда стоит такая цель.

Хочу обратиться к ребятам, которым повезло не встречать технически слабых или в целом слабых проектных менеджеров. Вы даже не представляете, насколько вам повезло!

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

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

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

Но главное веселье начинается тогда, когда коммуникация с клиентом происходит только через такого менеджера. Вы просто не сможете получить нужные ответы на все необходимые вопросы. Вам придется догадываться, что и как нужно сделать. Потом такой менеджер обязательно найдёт виноватых. Это делать они почему-то умеют.

Это делать они почему-то умеют.
Логично. Потому что кроме этого они, по сути, больше ничего не умеют.
Вам придется догадываться, что и как нужно сделать. Потом такой менеджер обязательно найдёт виноватых.
Если кто то позволяет себе догадываться, вместо того что бы знать... ну, он виновен. Если знание невозможно (по любым причинам), в проекте делать нечего. Если (по любым причинам) вы все равно в проекте... будьте готовы к «сложностям».
Если знание невозможно (по любым причинам), в проекте делать нечего

Вы такой крутой!

Пытаюсь сопоставить в единую логику ваше первое и последнее предложение. Помогите.

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

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

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

Я говорю о совершенно конкретных ситуациях и не утверждаю, что все ситуации такие

Я разумный. И дочитывайте до конца.)

В ведущих мировых IT-компаниях сегодня есть явная тенденция привлекать (или продвигать) на позиции ВСЕХ менеджеров (а не только менеджеров проектов) людей с техническими скилами. Нет сомнений, что это ускоряет многие процессы в IT-организации, а значит повышает ее конкурентноспособность.
Также вполне очевидно, что гораздо легче прокачать софт-скилы техническому эксперту (или найти такового со скилами), чем обучить, например, продавца-гуманитария продавать файерволы или ERP-системы.
Внимание: легче, не значит, что невозможно :) Мотивированный человек всегда и всему может научиться.

ораздо легче прокачать софт-скилы
вопрос для спора.
явная тенденция привлекать (или продвигать) на позиции ВСЕХ менеджеров (а не только менеджеров проектов) людей с техническими скилами.
экономия (рост конкуренции) во всей красе.

Это скорее происходит не в результате привлекания со стороны а в результате внутреннего роста. В инженерной компании многие менеджеры верхнего звена это в прошлом инженеры. А если нанимают со стороны то это может оказаться менеджер из конкурирующей компании где он прошел такой же вертикальный путь

Менеджер проектов — это прежде всего человек, отвечающий за правильную организацию процессов и взаимодействие между ними. Технический бэкграунд несомненно полезен, но не обязателен. То есть высококомпетентный менеджер проектов (именно менеджер) без тех. навыков намного более полезен, чем средний менеджер выросший из программистов. Здесь идет речь об IT, а если сегодня менеджер работает над IT-проектом, завтра над строительным, а после завтра над аэрокосмическим? Ему нужно уметь кодить, строить и самолетостроение знать? Нет, ему нужно быть профессиональным менеджером проектов и только.

Здесь идет речь об IT, а если сегодня менеджер работает над IT-проектом, завтра над строительным, а после завтра над аэрокосмическим? Ему нужно уметь кодить, строить и самолетостроение знать? Нет, ему нужно быть профессиональным менеджером проектов и только.
Бред, Бред Пит.
С ваших слов, будучи ПМом в разработки десятка сайтов визиток и пяти интернет магазинов ( в сумме 2-3 года работы) вы смело можете перепрыгнуть ПМ строительной компании и так же виртуозно руководить строителями, архитекторами, подрядчиками не имея понятия что такое цемент или стяжка потолков. Вас будут иметь все-все-все, а вы будите ходить и улыбаться. В случаи если вы захотите проявить свои сильные стороны менеджмента и давления на принятия важных решения отталкиваясь опытом в IT сфере, вас уволят без последнего слова.
Аэрокосмическим ПМ вам не стать вообще :) Для начала нужно иметь должное образование, дальше как минимум нужно понимать что вы там будите разрабатывать. Ваши бравые выкрики в стиле — спринт неделя, будет проигнорирован, а вы посланы лесом.
Даже в администратором в ресторане вы не станните. Для этого нужно поработать простым официантом.
Так что ПМу нужно понимать проект и для этого важно иметь Софт скил. Я не говорю что он должен программировать, а уметь верстать и хотя бы азы PHP, javascript знать.

а как насчет менеджить проект под Android, если из навыков — только HTML/CSS?
или энтерпрайз система после работы над выпуском игр?

Все верно. Научился ходить и пошел к цели. Или можешь не идти, но понимания у тебя уже появились

а как насчет менеджить проект под Android, если из навыков — только HTML/CSS?
или энтерпрайз система после работы над выпуском игр?
А что в архитектуре мобильных приложение не так? Там важнее правильно сделать UX дизайн и больше тестов на экраны сделать( Android).
По энтерпрайз системам проще для того кто работал кроме ПМ и на других работах. Если брать меня, то работая в крупных компаниях видел всю кухню в лицо и могу написать для любой компании энтерпрайз систему. Я знаю чего хочет клиент, потому что работал под его руководством и с его ресурсами.
Игры — моя больная тема. Очень хотел стать Гейм Дизайнером. Но туда просто зайти с фразой — у меня в Lineage 2 10 геровем 100 лвл не прокатит. Потому для самообучения прошу высылать тестовые ТЗ и делаю их для себя. И знаешь, много нового открыл. Даже программиста нанял для создания простой игры в стиле комбатс по написанному мной ТЗ.
Да, что бы лучше понимать я изучал азы C++, PHP, javascript, CSS/HTML, mySQL и математику для создания игр. Также ковырял Unity3D (по инструкциям делал игры).
А что в архитектуре мобильных приложение не так?
всё — так. а что не так в строительстве?
Там важнее правильно сделать UX дизайн и больше тестов на экраны сделать( Android)
куча собственных нюансов, начиная от диверсификации платформы и заканчивая загонами с play market. как опыт использования float: left позволит это учесть?
Ведь вы утверждали, что
Вас будут иметь все-все-все, а вы будите ходить и улыбаться
вот я и пытаюсь понять, где та грань, после которой «недостаточно просто разобраться, надо начинать обучение с производственной позиции, иначе никак».
и могу написать для любой компании энтерпрайз систему. Я знаю чего хочет клиент
Боюсь, вы можете сильно ошибаться. ...особенно во второй части.

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

нахрен манагери без тех скилов нужни вообше ? каково их предназначение ? че они делают ?

насиловать мозг разрабам

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

если на способен спуститься с детерминированной реальности до абстрактной...
«Нарисуйте мне семь перпендикулярных прозрачных красных линий»?

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

Вот здесь и нужен менеджер с техническими скиллами.

т.е. менеджер с техническими скиллами — на роль requirement manager’a/бизнес-аналитика? окей. бывает, да.
А еще фулл-стек разработчик с навыками тестирования. И всё отлично складывается. Всего два человека всю работу делают.
Развели тут, понимаешь, какую-то специализацию.

Не вижу ничего плохого в навыках(!) тестирования у разработчиков.
Понимание работы смежных специальностей вообще полезно.

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

Не знал, что фехтование — смежная специальность для бухгалтера.

Непонятно о чем вопрос. Это ж cмотря чем конкретно заниматься, и куда целиться.

Мой любимый другой пример: представьте себе, что вы ПМ в проекте, который делает С++ компилятор, и ваши пользователи — это не только продвинутые программисты С++, но и члены комитета по стандартизации, а также авторы книжек. Что вы должны знать о программировании как ПМ в этом случае?

С другой стороны — вы организуете большой PR-ивент, под который как часть всего проекта нужно еще и сайтец склепать. Тоже работа ПМа, в которой чуть другие навыки нужны.

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

А people skills, кстати, и разработчикам бы хорошо иметь.

Отдельный плюс автору статьи за ссылки с пруфами по каждому утверждению 👍

А ниже есть тема — Как работать ПМу 4 часа в день дома и отвечать на все запросы связи в 12-00 и 16-00. При этом имея опыт работы на данной должности 2 месяца и не имея технические навыков.

По сути, ПМ, который обладает навыками разработки и управляет командой,- это и есть тим лид. Однако он не обладает отличными навыками общения и не может уделять много времени на общение с заказчиком. Значит можно добавить прослойку в виде обычного менеджера, который будет болтать с заказчиком о погоде и рассказывать как всё хорошо идёт в проекте. Но на этапе консультаций, тим лиду нужно будет напрямую общаться с заказчиком, а если задачи нужно постоянно корректировать и сарафанное радио через менеджера будет медленным, нужно будет нанимать технического консультанта, который будет будет вместе с менеджером общаться с заказчиком. Но тогда выходит дороже. Сам то менеджер дешевый, но вместе с консультантом выйдет дороже одно стандартного ПМ. Однако у обычного ПМ будет ряд существенный минусов: не может предложить альтернативы и технически проконсультировать, при этом дословно передавая пожелания заказчика как приказ, а второе — если управление тасками отдать в руки ПМ, а не тимлида, то есть почти 100% вероятность, что самые важные задачи не будут решаться(или даже вообще существовать в задачах), а какие-то декоративные хотелки заказчика будут топ приорити, не говоря уже о пересечении задач и мерж войнах.

ПМ, который обладает навыками разработки и управляет командой,- это и есть тим лид.
Это просто грамотный ПМ, который стоит на 1к-2к дороже своего собрата без технических знаний.
Так же нужно понимать уровень навыков разработки. Чем он выше, тем меньше данный ПМ будет ПМом. Так как сущность у него будет программиста, а это огромный минус в тех вопросах, которые должен решать ПМ.
Самый идеальный вариант когда ПМ програмил на уровне джуна (3-6 месяцев) и понимает логику работы кода, базы данных и этапы создания проекта. Этих знаний ему вполне хватит что бы ответить на 90% вопросов заказчика. По мере работы с проектами он будет обрастать большеми знаниями и сможет правильно принимать решения
ПМ програмил на уровне джуна (3-6 месяцев) и понимает логику работы кода, базы данных и этапы создания проекта

Это на каком это проекте он этого наберётся, работая девом 3-6 месяцев? Особенно интересно про этапы.

Нет ничего более жалкого и беспомощного, чем ПМ который не разбирается в том, что происходит в проекте. Хорошо, что вы это понимаете и можете давать какой-то value, а не быть просто оператором Jira и оранизатором митингов. Представьте, себе что генерал не разбирается в техническом оснащении армии, тактике, логистике, разведке, то есть в «технических» вопросах, зато обладает soft skills))), умеет строить графики, планировать и делегировать. Грош цена такому военноначальнику. В IT конечно все не так критично, особенно в простых проектах, но аналогия думаю ясна.

оснащение армии, тактике,логистике, разведке != технические вопросы.
Технические вопросы это стрелять и сидеть в окопе.

Технические вопросы это стрелять и сидеть в окопе.
Честно говоря, аналитик из вас так себе. Вы в вопросе явно мало понимаете, а заявление делаете. Ну просто typical BA.
На современной войне идет общевойсковой бой с применением авиации, артилерии, снайперов, ДВР, бронетехники и пехоты. Никто в окопе не сидит как в WWI, (позиционная война ушла в прошлое 100 лет назад) . Все это требует координации, снабжения, тактической подготовки, планирования, при чем на разных уровнях от батальона до армии.
Вот скажите, много навоюет командир артилеррийского подразделения, есть он не был артеллеристом? Сколько неверных и опасных решений такое чудо предпримет?
p.s. Одно дело разбираться, другое — непосредственно исполнять.
умеет строить графики, планировать и делегировать
ну-ну. Судя, по данным высказываниям, наблюдается абсолютное неведение что же на самом деле входит в обязанности проджект менеджера. Что касается тех скиллов: уж явно ПМ не должен продумывать архитерктуру приложения, сидеть кодить за программистов,тестить за тестировщиков и т.д.))) Да, он должен иметь понимание, что происходит в проекте, но для этого достаточно владеть общими знаниями, о чем в принципе говорилось в этой статье. Иначе ж получается: чтобы стать ПМом надо поработать тестировщиком, девелопером, девопсом, дорасти до лида в каждой сфере, а уж потом переходить в менеджмент
Судя, по данным высказываниям, наблюдается абсолютное неведение что же на самом деле входит в обязанности проджект менеджера.
Как будто оно у вас есть, вы вот хотябы PMP получили? Без него, вы не пм, а просто секретарь проекта. Вот получите сертификат, умудритесь годами опыта, желательно не только в такой специфической отрасли как аутсорсинг, но в продуктовой разработке, тогда и поймете почему специфические «технические» опыт и знания важнее чем просто софт скиллы и умение вести табличку с рисками.
Что касается тех скиллов: уж явно ПМ не должен продумывать архитерктуру приложения, сидеть кодить за программистов,тестить за тестировщиков и т.д.))) Да, он должен иметь понимание, что происходит в проекте, но для этого достаточно владеть общими знаниями, о чем в принципе говорилось в этой статье.

Скажем так, чтобы работать например программистом — нужно просто уметь писать код.Но, чтобы быть хорошим программистом, нужно знать алгоритмы, понять предметную область, уметь делать архитектуру, коммуницировать и еще много чего. Точно так же и с пмами, гораздо больше цениться пм с опытом тестировщика или девелопера чем просто чувак с сфотскиллами. Я кстати слышал, что у вас (или в конторе с похожим названием, не суть) медицинские проекты ведет чувак с медицинским образованием, как вы думаете за что его ценят?

Иначе ж получается: чтобы стать ПМом надо поработать тестировщиком, девелопером, девопсом, дорасти до лида в каждой сфере, а уж потом переходить в менеджмент
В большинстве топовых компаний это так, за исключением топ менеджемента. В Google к примеру пм обязан обладать техническим бекграундом иначе его не допустят до управления проектом.
вы вот хотябы PMP получили? Без него, вы не пм, а просто секретарь проекта.
вообще не поняла. Это что скрытая реклама PMP? ))
Вот получите сертификат, умудритесь годами опыта, желательно не только в такой специфической отрасли как аутсорсинг, но в продуктовой разработке,
А если у меня есть опыт в продуктовой разработке?)
Ладно, из того что я вижу Вам необходимо подтянуть свои софт скиллс и научиться вести дискуссию не переходя на личности и не унижая достоинство людей, не согласных с Вашим мнением. Поверьте, это очень важно. Удачи Вам и успехов в карьере!)
Ладно, из того что я вижу Вам необходимо подтянуть свои софт скиллс и научиться вести дискуссию не переходя на личности и не унижая достоинство людей, не согласных с Вашим мнением
Nice, типичная менеджерская отмазка) А по существу есть что сказать?

Чего Вы пристали к опытному ПМу с опытом работы в продуктовой компании.... ХАМ !! :D :D

Не ну если Вы не поняли, что-то то не значит что это неправильно ) Это Вы просто не поняли )) Вы очень красивая поэтому я Вам поясню другими словами — иметь общее понимание о конструкции авто это не значит что вы сможете его отремонтировать или руководить СТО! Если Вы полезете в авто — Вы его поломаете и это будет явно видно ))) А в Айти можно сказать, что у кого-то не хватает софт или хард или еще каких-то скилов ))
Теперь понятнее ? )))

Если Вы полезете в авто — Вы его поломаете
А чего весь разговор про девелоперов-то? В командах что других ролей не существует? Вы же не только с девелоперами общаться будете. И вот тут -то нестыковочка. Согласно Вашей логике, как бывший девелопер будет менеджить тестировщиков? Ну он же не бывший тест лид или синиор БА и т.д. Он не владеет такими знаниями. Он не сможет вести проект.)))
Любой другой менеджер (не из бывших девелоперов) вполне может научиться программировать если захочет. Ресуров для этого уйма. Было бы желание. Как я говорила ранее, я согласна, с тем что хороший IT PM должен разбираться в технологиях. Но не обязательно ему идти сначала в девелоперы. Научиться давать команды железу гораздо легче, чем научиться давать команды человеку. Мозг человека, к сожалению, не подебажишь, а жаль))
Он не сможет вести проект.))) Любой другой менеджер (не из бывших девелоперов) вполне может научиться программировать если захочет.

тут мы можем ставить точку ))

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

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

Особенно про PMP, которое в сфере IT как раз таки не пользуется спросом, PMP — это для тех ПМов которые будут «терминалы аэропортов» строить, а у айтишных ПМов — PMI Agile и/или скраммастерские сертификации.

Прости Егор, ну ты и вправду мало смыслишь в том, чем на самом деле занимается ПМ на проекте, но судя по твоему коментарию, ты как раз таки хочешь им стать и поэтому так агресивно продвигаешь непопулярную идею ПМа из разрабов.
Просто троллю на самом деле.
а у айтишных ПМов — PMI Agile и/или скраммастерские сертификации.
Самое бесполезное что вообще можно придумать, кстати, для меня сертфицированный скрам мастер это матюк.

хотя-бы пмп. А выше пмп украинскому менеджеру что-то нужно? со скрам мастером согласен. Трата денег — полезно наверное разве что в 9-5 работе менеджером. Не вырастешь оттуда особо.

А как ценится сертификат CAMP — PMI? На PMP опыта не хватает. А CAMP удовольствие тоже не дешевое.

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

Вот здесь можно посмотреть держателей сертификаций по типу сертификата. Работет как фильтр так что можно пользоваться первой буковкой фамилии. Для сравнения САПМ на букву Б — 2 человека. ПМП — в районе 30.
certification.pmi.org/registry.aspx

Спасибо, очень показательная статистика.

Да и в Украине по-моему сертификация никакой особой прибавки к жалованию и прочим в краткосрочной перспективе не дает
Это субъективно, или есть данные от более-менее репрезентативного количества спецов PMP?

субъективно. Пара мыслей:
1) К моменту сдачи пмп ты уже обычно либо упираешься в потолок, либо близко к нему (речь идет о «рядовых пмах», не екзекутивс).
2) на месяц назад в украине было 411 пмп специалистов. у всех не спрашивал.

Мне кажется, утверждение что ПМП специалисты получают больше — верно, но не потому что они ПМП специалисты :)

я как-то так вижу.

скраммастерские сертификации.
Скраммастер — це не РМ взагалі, а SCRUM — це не проектне керівництво.

А какой вы сертификат получали что называться Lead Developer, а не оператор печатной машинки?

В процессе подготовки к AWS Certified Architect.

Может тогда пока не полуили сертификат, стоит сменить статус на более правдивый?

А почему ты RoR девелопер? У тебя сертификат есть?) Не доводи все до абсурда.

Это Ваша фраза, не моя:

Как будто оно у вас есть, вы вот хотябы PMP получили? Без него, вы не пм, а просто секретарь проекта.

Да и если получите

AWS Certified Architect
, то все равно это не позволяет Вам называться Developer’om, а только DevOps’om

Какое-то странное название сертификата. У меня с AWS Architect возникает ассоциация только с чуваком, который работает в амазоне и занимается архитектурой самого AWS, а этот сертификат должен был бы называться AWS Certified User))

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

Если честно, то у меня иллюзий на этот счет нет. Но ради marketability — сойдет.

Смішно. Многа лі наваюєт на фронті (енді) ПМ-бекендщик, якщо він у минулому не був фронт-ендщиком? Многа лі наваюєт на фронті тестування ПМ з фронт-енд минулим?
Командир артилерійського підрозділу це не ПМ, це умовно лід команди артилеристів. А головнокомандувач армії може взагалі «дупля не відстрілювати» в мат. розрахунках відстрілювання живої сили супротивника артилерією, зате він вміє працювати з відповідними підлеглими, розуміє правильні та сучасні алгоритми ведення бойових дій на глобальному рівні, та принципи стратегічного планування і тактичного управління армійськими підрозділами.
У вас відсутність елементарної, вибачте, Lohik’и, і typical мислення over-ambitious but overall ignorant developer, який цінує лише свою роботу в команді та не має збалансованого бачення розробки, що якраз є важливим критерієм придатності для роботи PM’ом. Набирайтесь знань, у вас ще довгий шлях до перспективи керування проектами, хоча не факт що знання вам допоможуть — з поганим attitude хорошим менеджером не станеш.

А головнокомандувач армії
Вы сравнили обычного ПМа с главнокомандующим армии? Вы что-то явно путаете.

Я порівняв потребу наявності глибоких артилерійських знань в командира артилерійського підрозділу і головнокомандуючого. Не подобається «головнокомандуючий» — візміть будь-яку іншу умовну посаду, яка потребує координації та контролю роботи об’єднання різнопланових «юнітів», кожна з яких має свою складну специфіку і які в сукупності мають працювати як злагоджений механізм із спільними підходами, стандартами взаємодії та розумінням задач. Не думаю, що умовність порівняння від цього критично зміниться.

во-первых главнокомандующий это самый топ менеджер, что никак не вяжется с ПМом. Во-вторых даже если взять например командующего ВВС (конечно это тоже топ менеджмент, но все же) то этот человек закончил высшее военное училище, отслужил на должностях начиная с тех которые соответсвуют лейтенантскому званию, думаю у него будет очень большое количетсво часов налета, скорее всего он был инструктором у других летчиков, он дослужился до полковника, окончил академию чтобы стать генералом и т.д. И да, этот человек будет знать как устроен самолет и как им управлять. Так что ваше сравнение совсем не уместно.

Різнопланових. Це і був ключовий аспект мого порівняння. Умовно: підводний човен + літак + мотопіхотний батальйон. Спеціаліст по балістичним траекторіям підводних торпед може вважати свої знання критично необхідними для будь-яких військових операцій, і так воно і є — але на його власному рівні. А офіцерів, які координують діяльність таких армійських об’єднань, вчать окремо, їм дають універсальні знання керування військовими підрозділами, принципи взаємодії різних родів військ і.т.д. І якщо торпедних справ майстер хоче стати таким керівником — йому доведеться пройти екзамен не на знання балістики торпед — а на знання тих самих універсальних знань та навичок. І глибоке знання торпед після цього йому якщо і допоможе, то в якихось дуже унікальних та специфічних ситуаціях, а в більшості випадків це буде надлишкове — рівень задач буде зовсім інший. З чим йому, природно, буде важко змиритись, якщо глибоко в душі він все одно відданий торпедам. Але тоді навіщо він хоче керувати «групою армій»?

підводний човен + літак + мотопіхотний батальйон
Авианосцем командует командир корабля(капитан), авиагруппой управляет командир эскадрильи, у мотопехотной группы свой командир, координирует их деятельность группа военных аналитиков, нет какого то одного офицера с набором каких-то как вы говорите
тих самих універсальних знань та навичок

«Карл Рудо́льф Герд фон Ру́ндштедт — німецький воєначальник часів Третього Рейху. На початковій фазі операції „Барбаросса“ командував групою армій „Південь“.»

Уявіть собі що з усієї групи армій «Південь» залишились один літак, один човен та один мотопіхотний батальйон, а бункер аналітиків знищено, окрім одного новачка, що саме в цей момент бігав до вітру. І ось цей останній аналітик прибігає в ставку воєначальника і доповідає: «Масштаб твоєї діяльності змінився, Карл! Але з моїми аналітичними дослідженнями характер роботи залишився той самий. Хоча я, взагалі-то, тільки 3 дні як військовий аналітик, а раніше я був BA, тому добре вмію тільки малювати блок-схеми і рахувати техніку». І Карл тут не розгубиться, бо хоч у нього і стало менше ресурсів і деякі неналежної якості, але характер їхнього використання — той самий, що й був, плюс завдяки аналітику він точно знає їх кількість і може скоригувати масштаб своїх дій. А завдяки своїй освіті він добре знає, коли від стратегії треба перейти до тактики, якщо у тебе залишився тільки один літак, один човен і один підрозділ. А PM-и просто, зазвичай, з самого початку замість окремого штабу аналітиків мають 1-2х у складі команди, і замість окремих команд БЕ, ФЕ мають по декілька людей на кожному напрямку.

Приклад свідомо містить невеличку дозу абсурду, але закликаю вас допустити в дискусії певний рівень абстракції та умовності, інакше вона втрачає будь-який сенс ще до початку.

А разве в вооруженных силах не требуется военное образование ? Там ведь все это и учат — мат. расчеты, таректории полета и т.п. Или главнокомандующим может стать любой желающий окончив курсы из серии «... за 21 день» ?

Якщо вже на те пішло, то Верховним Головнокомандуючим нашою армією є Президент країни. Ніхто не забороняє йому мати військову освіту, але при цьому ніхто цього не тільки не вимагає, але й не очікує від даної посади. Чи президентом України у нас може стати тільки генерал з трьома військовими дипломами та десятьма успішно проведеними військовими операціями? А це ж найвищий рівень військової відповідальності, як же ж так?

А так воно є тому, що чим вищим є масштаб прийняття рішень і відповідальності, чим більше тобі підпорядковується окремих чи об’єднаних у структурні одиниці людей, тим більше акцент вимог професійної діяльності переходить від питань технічних до питань організаційних та особистісно-комунікаційних. І є загальновідомий факт, що на певному рівні у деяких розробників, що змінили тип діяльністі на PM, занадто сильний фокус на конкретному наборі аспектів розробки більше заважає команді та проекту, ніж допомагає. Тож якщо узагальнити — володіння технічними знаннями для PM може стати великим плюсом (якщо вміти їх використовувати правильно), але тільки на додачу до маст-хев особистих якостей та організаційних талантів, а не навпаки.

Я понял вашу мысль. Но, если вам ближе сравнение с вооруженными силами, то ПМ это примерно командир взвода. Обычно это лейтенант или капитан, получивший военное образование. Глобальная стратегия компании и управление одним проектом это ведь разные вещи.

Не можу обґрунтовано це прокоментувати (відповідність посад), але скажу тільки, що в моєму порівнянні постарався акцентувати не рівень впливу в межах організації, а неоднорідний характер і тип підпорядкованих ресурсів. Тобто — рівень відповідальності у порівнянні з військовими топами, безперечно, різний, але необхідність об’єктивно оцінювати різнохарактерні ресурси та інструменти, і ефективно їх використовувати — спільна. Якщо задуматись, напевно PM зосереджений більше навіть на тактичних питаннях, ніж на стратегічних — для стратегій, в тому числі і окремих проектів, є Product Manager’и/Product Owner’и і.т.д.

Честно говоря, аналитик из вас так себе. Вы в вопросе явно мало понимаете, а заявление делаете.
Как жеж без оценивающего мнения, Вам конечно виднее какой я аналитик :)
На современной войне идет общевойсковой бой с применением авиации, артилерии, снайперов, ДВР, бронетехники и пехоты.
В первоначальном комментарии вы где то указывали временные рамки войны?
Вот скажите, много навоюет командир артилеррийского подразделения, есть он не был артеллеристом? Сколько неверных и опасных решений такое чудо предпримет?
В данном случае командир артилеррийского подразделения это Team Lead. Или вы хотите сказать, что каждый генерал просто обязан послужить во всех родах войск, которыми руководит?
Или вы хотите сказать, что каждый генерал просто обязан послужить во всех родах войск, которыми руководит?
Вообще-то так и есть. Генерал это не всегда ведь генерал армии, а есть например генералы ввс, генералы танковых войск, адмиралы. Обычно не назначают адмиралов руководить танкистами, а танкистов руководить летчиками.

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

Генерал это не всегда ведь генерал армии, а есть например генералы ввс, генералы танковых войск, адмиралы.
Правильно написали, не всегда!
Вот или другая аналогия, почему больницей руководит главврач, а не менеджер без малейшего или поверхностного понятия о медицине?
Так здесь же разговор только о техническом бэкграунде и о том, что не только разработчики могут быть хорошими руководителями.
Люди из других смежных процессов, имеют на это такую же возможность быть хорошими менеджерами )
Правильно написали, не всегда!
Генерал армии это звание, считайте что это топменджер.
Так здесь же разговор только о техническом бэкграунде и о том, что не только разработчики могут быть хорошими руководителями
Ну, мне тут пмы доказывали совсем обратное, что все кроме разработчиков могут оными быть.

Пруф, пожалуйста. Жозе Моуринью в футбол профессионально никогда не играл, помешало ли ему это стать топ-тренером?

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

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

вроде как в статье написаное четко:

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

И суть в том, что такой человек будет намного дороже стоить чем те кто

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

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

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

Если бы это написал PM, поставил бы лайк, потому что в целом согласен. Но пренебрежение к нетехническим персоналиям в данных строках аж брызжет с экрана монитора. Вы, наверное, из тех людей, кто считает другие профессии недостойными и над родителями смеётся из-за возможно более высокой зарплаты.

Это у вас классовая неприязнь. Как же кто-то посмел критиковать святую профессию пма!

Но пренебрежение к нетехническим персоналиям в данных строках аж брызжет с экрана монитора. Вы, наверное, из тех людей, кто считает другие профессии недостойными и над родителями смеётся из-за возможно более высокой зарплаты.
Отнюдь. Смотрите мой комментарий — dou.ua/...rums/topic/19502/#1043344

Нет, товарищ, это у ВАС классовая неприязнь, потому что редкий менеджер станет пренебрежительно относиться к разработчику или тестировщику по той простой причине, что менеджеры с людьми общаться умеют. Зато любой девелопер, от формошлёпа-говнокодера до лид девелопера, считает, что раз он пишет код, то он просто творец, двигатель прогресса, а вокруг него только кнопкодавы и сжигатели графиков. За примерами далеко ходить не нужно — Вы зашли высрать своё мнение в крайне деликатную, потенциально холиварную тему, чтобы, собственно, словить лулзов или как это называется. А выглядит со стороны убого, козырять залайкаными комментами тут не нужно, он точно также пропитан желчью и псевдоинтеллектуальным содержанием.

Не слабо вам бомбануло.

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

Да что они вообще о себе возомнили? Бунт на галере! ))

о, я только думал принять оффер от Lohika.
Почитал ваши коменты.
Спасибо, передумал

Полностью поддержу Егора, хотя сам сталкивался с тем, что не редко бывает так, что PM начинает свою карьеру почти без технических знаний. При этом, не смотря на якобы низкий порог входа, в процессе работы сложность задач увеличивается, начинают всплывать неоднозначные детали. Разработчики всё больше устают от глупых вопросов и отвечают резко или неохотно. В результате PM, который не хочет погружаться и вникать в происходящее очень скоро перестаёт понимать, что на самом деле творится в его проекте.
Это действительно серьёзная проблема. Рынку труда нужны проектные менеджеры и бывших программистов на всех не хватит. Поэтому PM-ам важно самим повышать техническую грамотность... Мои мысли по этому поводу не уместились в формат комментария, поэтому написал статью

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі