Спасибо за пример, думаю тем кто пока с такими проектами не сталкивался в карьере — будет полезно посмотреть.
Недавно тоже занимался enterprise проектом, и мой опыт вне IT, по тем же кадрам, финансам и прочему корпоративному — очень пригодился. Но в целом в таких проектах как вы описали — знания нужны специфические, и их не так много, поэтому я больше ссылался на аутсорс проекты меньшего масштаба, и без энтерпрайза.
т. к. знает специфику своего проекта на программном уровне
При наличии хорошего тимлида — нужно ли это знать ПМ-у?
Насчет каждого вопроса заказчика — даже зная общую структуру проекта, без глубины, зачастую клиенту можно на любой вопрос уже ответить, потому что зачастую у него нет технической подготовки, с ним говорят на языке бизнеса.
т. к. человек с высокими тех. навыками будет стоить от 80 000 руб. в месяц и выше (в зависимости от региона разумеется)
А навыки ПМ-а у него будут? Думаю что техлид-ПМ, то есть два в одном по навыкам и опытом будет стоить раза в 2-3 больше. 80к стоит обычный ПМ с парой лет опыта и технической грамотностью и английским.
Согласен.
Именно поэтому я больше ориентировался на аутсорс разработку небольшого и среднего масштаба. В проектах которые вы привели — да, как правило так. И это совмещение техлида и ПМ-а, но часто по другому никак. Хотя думаю многие на этом спотыкаются, сложно найти человека который и глубоко в проектном управлении разбирается, и технически подкован на уровне опытного разработчика, и при этом в теме новых вещей, его знания актуальны.
Бесспорно. Но в целом — нужна она на каком уровне ПМ-у? Насколько глубока. И так ли нужна на выбранном уровне, за те деньги которые он стоит — вот в чем вопрос.
Конечно говорю в общем, пытаюсь понять тенденцию.
Ребят статья классная, объемная подготовленная, проработанная.
Но я вижу много противоречий. Вначале набор таких клише, которые в целом есть везде. Но мне одно непонятно — статья же написана разработчиками, так почему разработчики указывают управленцам какие у них ошибки?) Ну серьезно. Или вы думаете топ-менеджмент в больших компаниях не в курсе про эти проблемы?
Более-менее неплохо дела обстоят в ИТ, где большинство (но, увы, не все) проджектов растут изнутри, из среды разработчиков.
Честно говоря я слышу больше мнений что в IT с менеджментом как раз все плохо ) Но это субъективно.
Но горе ИТ-компании, если менеджером технического проекта становится гуманитарий или выпускник «Менеджмента». Нет, это не плохие ребята, и вероятно, они прочитали много толстых книжек (включая многочисленные источники «мотивации»), но ИТ слишком специфическая отрасль для того, чтобы проектами управляли люди без технического бэкграунда (уверены, что с нами будут спорить — и хорошо, если есть истории успеха).
Ну это прям очень оценочно и аргументация слабовата. Кто-то из автором статьи учился на Менеджменте? Клише про мотивационные книжки это вообще из ВК, даже в самых захолустных универах мотивацию изучают исключительно с научной точки зрения. И насчет слишком специфичной — по сравнению с какой? А какие неспецифичные есть? Да кстати истории успеха не являются доказательством — всегда можно найти пару тройку примеров за и против. Это нормально.
Что касается других сфер, то в них менеджерами проектов берут людей без должного опыта, но, например, с релевантным образованием или резюме, в котором можно наврать с три короба. В общем, отбор должен быть более критичным, а ещё лучше — из внутренних резервов.
Тоже клише. Что за пренебрежение к другим сферам? Выглядит так будто в IT мы тут все умные, а другие лаптем щи хлебают. Опять же вопрос — насколько авторы в курсе о том что происходит в других сферах? И в скольких.
Не промахнитесь с менеджером проекта (чаще всего с этого все беды и начинаются). Менеджер проекта это не человек с какими-то требованиями к образованию (типа «Менеджмент», красный диплом) и не хороший презентатор, а человек, который разбирается в теме проекта и должен организовать систему, в которой всё отлажено, проще говоря, каждый процесс даёт выход, который служит входом для следующего процесса. В этом, конечно, кроется и коммуникация, и делегирование, и умение работать в команде.
Навыки презентации кстати очень важны, часто ПМ-у приходится говорить перед публикой и от этого много зависит. А все что вы описали — этому учат в технических ВУЗ-ах? И разработчики это умеют? Вижу противоречие с тем что выше — с одной стороны вы говорите что горе тем кто берет гумманитариев, а с другой описываете добрую часть того, чему как раз учат на Менеджменте.
Последний раздел слабый. Нельзя управление проектами вместить тезисно с один список, с разными уровнями абстракции. Все равно что попробовать тоже самое сделать к примеру с Javascript.
Вы абсолютно правы про управление — это все есть.
Но я склонен считать что сложные места, причины технических проблем, архитектура — это работа техлида, архитектора, и выше по уровню — СТО. Проектный менеджер в этих вопросах имеет совещательный голос, так как не эксперт зачастую.
Про совмещение этих двух ролей — отдельная тема.
Уровень менеджера должен быть как минимум не ниже уровня участников его команды, иначе его не будут уважать и слишком часто будут ставить на место более опытные разработчики.
А в чем смысл? Он ведь не программирует, он управляет.
Насчет ставить на место — зависит от ситуации, от личных качеств ПМ-а и разработчиков. В целом по моему опыту это миф. Разные позиции — разработчики опытны в разработке, менеджеры опытны в управлении гораздо больше вышеуказанных разработчиков. С чего кому-то кого-то ставить на место.
Согласен.
Берем усредненную историю заказной разработки. Это, как правило, сайты, веб и мобильные приложения низкой и средней сложности, возможно CRM, и другие корпоративные штуки.
Комон 2020 на дворе, может хватит отрицать ценность руководства, менеджмента. Попробуйте сами собрать группу разработчиков, и дать им проект и никак не руководя посмотреть что будет. Попробуйте поруководить вообще хоть кем-то.
Или вы сторонник теории что все вокруг государство, все организации, бизнес, любые команды — имеют руководителей, и они просто паразитируют ничего не делая? Серьезно?
Тут важно не перефразировать, в моем комментарии PM обозначен как не полноценный руководитель.
Я просто утверждаю что менеджер и руководитель это синонимы. Если нет руководство — в названии позиции слова «менеджер» быть не должно. Привет всем менеджерам по продажам )
В точку, при этом работа с персооналом является постоянной обязанностью и привелегией руководителя — что и является для меня доводом что PM не совсем руководитель.
Если имеется в виду работа с персоналом в плоскости найма/увольнения, развития — то не везде и не всегда. Это безусловно дает ему больше пространства для маневра — когда он контролирует подбор и работу с персоналом. Это происходит когда внедрена сильная матричная структура. Но при этом не является обязательным атрибутом. То что он не контролирует персонал не исключает то что он будет руководить командой. Да, это будет сложнее, полномочия ограничены, но они есть.
Что бы управлять — нужно понимать чем управляешь, особенно когда мы говорим о специфичных отраслях. В противном случае любой достаточно хитрый подопечный в легкую одурачит подобного «руководителя».
Согласен. Я больше скажу — все отрасли специфические, потому и отрасли. Если погрузиться — куча нюансов, технической составляющей, специалистов и специальностей. В этом надо разбираться, надо понимать точки контроля, и тогда обмануть будет сложно. Плюс есть же тимлид, который в этом разбирается глубоко, и разработчик попытается обмануть и его.
Отчасти да, в теории все красиво работает. Но думаю вы согласитесь что это своего рода костыль в системе управления. 2 руководителя у одного подопечного? Кто приоритетнее? За кем идти? Что делать? Неоднозначности ни в процессах, ни в задачах, ни в приоритетах не должно быть.
Нет, не костыль. Но сложно — согласен. И мало кто умеет нормально строить такую систему. 2 руководителя вполне нормально, если организация гибкая и руководители толковые. А условиях неопределенности без гибкости никак — потому что функциональное подразделение заточено на выполнение одних и тех же функций регулярно, минимум неожиданностей. Когда сделать надо что-то новое, непонятное — нужны проекты. И так уже другая специфика, другое руководство. Если разделить грамотно и распределить время — то вполне можно организовать чтоб работало нормально. Насчет неоднозначности — не надо пытаться ее убрать, это невозможно, потому что весь мир неоднозначен, есть куча факторов которые влияют, черные лебеди вон с коронавирусом. Выход — научиться работать в таких условиях, вот матричная структура как раз так и появилось, когда стало понятно что не выгребают и надо как-то менять процесс. Её не ввели просто потому что кому так вздумалось — таковы были условия.
Навыки общения и управления — развиваются, вопрос возможности и времени.
Тут есть момент. Пресловутые хард скиллз и софт скиллз, вторые по русски это компетенции. Так вот компетенции развиваются сложнее — потому что это по сути личные качества, проявляемые на работе. Вы видели когда нибудь чтобы личные качества людей быстро менялись? На это уходят годы работы над собой, по исследованиям в год можно прокачать на уровень одну, максимум две компетенции. А их десятки.
Второй момент — есть нулевой уровень компетенции, когда её у человека нет, и не будет. То есть нет потенциала её развития, он просто не может и всё. Шансы что он её разовьет настолько мал, что проще сфокусировать на других. Это я говорю про общение например. Управление это хард скилл который можно развить быстрее.
Мой посыл был в том что у разработчиков из за профессиональной специфики шансы стать профессиональным руководителем чуть выше. То что большинство не захочет — скорее всего.
Но это уже личный выбор.
Ну вот я с этим не согласен. Единственный аргумент такого подхода — хорошее знание сферы. Но это лишь одна составляющая управления, и не первого порядка. Именно по причине вышеперечисленные нюансов софт скиллов/компетенций — она не настолько важна. Еще раз — важна, но не самая важная.
Потому что коммуникация и управленческие навыки важнее. И потому это хард скиллы, их развить проще, чем научиться общаться.
Разработчики которые выходят в тим лиды, ПМ-ы, СТО, СЕО — это как правило люди у которых изначально был потенциал к этому, у них не было проблем с общением, они неплохо ориентировались в неопределенности, брали на себя роль неформального лидера. Это моя позиция.
Но тем не менее — если есть еще аргументы против — пишите, для меня интересно всегда подискутировать на эту тему. Не считаю свое мнение истиной в последней инстанции.
ты упускаешь возможность делать полезное и красивое самому.
Сейчас обидно стало ) Как будто менеджеры проектов не делают полезное и красивое. Бухгалтера тоже не делают тогда. И вообще мало кто делает. Хотя желание вернуться и делать так чтобы то что без вас не крутилось — начало крутиться (цитата), мне вполне понятно. Просто каждому своё.
Из всех ваших описаний ясно, что вы видите РМ только в аутсорсной разработке
Я говорю именно про менеджера проекта, и из этого следует что мое видение непричем, по факту в IT — проекты имеют место зачастую именно в аутсорсе. Не берем крупные не IT компании со своим проектным офисом — это другая истории. Это следует из самого понятия проекта.
РМ в аутсорсе отвественнен за «проект», в том чтобы он не провалился, но часто полномочий у него мало — влиять напрямую на кол-во людей в команде он не может (бюджет определяет клиент), увольнять людей может только в рамках проекта. «Просто по моему опыту, мало кто заморачивается всей нетехнической стороной, маркетингом там, бизнесом клиента и профилем юзера.» — этого РМ-у в аутсорсной и вовсе не будут давать, так как никто не поверит что он что-то может. Чаще всего РМ ответственен за коммуникацию, за мотивирование, координацию. Но если команда небольшая, то это всё прекрасно закрывает ВА, если команда большая, то он просто следит за организацией процесса, и пытается закрывать проблемы по мере возможностей. Плюс общение с заказчиком на старте, но тут и составление договора, и проработка первоначальной документации. Ну и быть ответственным, что заказчик «рад» заплатить по счёту.
Согласен, сплошь и рядом так — но считаю это минусом. Недостатками организации, и к этому постепенно приходят компании.
В продуктовой компании РМ больше имеет полномочий, за счёт того что команду можно набирать и увольнять, и чаще нужно вести людей в плане их развития (курсы, ревью знаний, рост по позициям). Опять же в продуктовой компании это может совмещать продакт в себе. Отдельный продакт и РМ возможны, но это означает что РМ номинальный и чаще всего он слишком похож на тимлида (Яндекс в пример, всё именно так).
В продуктовой компании ПМ — это продакт менеджер, посколько в ней нет проектов. Совсем другая роль, которую я не берусь описывать, там своя специфика. Продуктовая разработка не предполагает окончания, по крайней мере не планирует его. Проект же это предполагает всегда. И согласен что ПМ в продуктовых компаниях, это номинально, если развернуто называть его менеджером проектов, то терминологически это неверно. Скорее это как вы справедливо заметили — тимлид, либо зам продакта по операционке, либо координатор.
Нужен ли для координации и организации небольших команд разработки до 15-ти человек (большие всегда будут дробить на небольшие) МВА? С моей точки зрения — он не бесполезен, но не нужен в полной мере.
Не нужен абсолютно, я в принципе нигде и не говорил что нужен. Концепт MBA это в целом подготовка менеджером топ звена. Проектного управления к слову там почти нет, общие понятия не более. Польза скорее в том что даются достаточно четкие абстрактные закономерности и схемы, которые применимы практически в любой отрасли.
К самой статье есть ряд замечаний, но в целом она слишком «общая».
Это сделано вполне осознанно. Я в целом специализируют на общих вещах, стараясь выявить в них закономерности, попытаться сориентироваться в тумане.
Если уж совсем точно не общая, она просто не конкретная. Поскольку при выбора места работы информации мизер — конкретики нет и быть не может. Этот процесс нельзя уложить в четкую схему, так как для него недостаточно данных. В любом случае мы знаем очень мало и ориентируемся наощупь, с высокой вероятностью неожиданностей. В жизни в целом мне кажется все так и происходит — мы очень многого не знаем. Выражаясь терминологией системного мышления по Леванчуку — это уровень схемоида, но точно не схемы.
К слову хочу написать про это — может там товарищи хабровцы увидят высокий технический уровень.
Изучение компании лучше начинать с человека который уходит с вашей позиции или работает на аналогичной, так же не стесняться задавать эти вопросы при собеседовании — «Почему ушёл предыдущий? Чем занимается другой РМ сейчас? Могу ли я с ним пообщаться, чтобы лучше понять организацию работы?».
Замечание справедливо. Я этот момент не осветил, хотя он важен.
Для российского IT не нужен MBA. Это я понял и по рынку и на собственном опыте. Посмотрите вакансии на HH. Там только котируется PMP, и то, достаточно редко.
Если вы его получили — это плюс для вас, но лучше помалкивать. Как минимум на собеседовании. Иначе столкнетесь с негативом. У меня было такое неоднократно, когда собеседующий, потенциальный начальник, осознает, что у меня управленческого опыта больше чем у него, да еще и МБА.
Тоже были такие прецеденты, но это проблема руководителя. Моя личная позиция — мой MBA помимо того что это было отличное образование, еще дал громадный опыт жизни в другой культурной и языковой среде, оба фактора для меня важны — и если потенциальный работодатель комплексует по этому поводу, то скорее всего нам с ним не по пути.
Были с другой стороны и положительные примеры — когда руководители цеплялись этот пункт из резюме, и использовали мои знания и опыт во благо. В целом это проблема управленческой культуры — но это отдельная большая тема.
Культура управлением проектов в IT, где делают веб вообще низкая. И разработки зачастую тоже (большая часть веб-разработчиков — самоучки). Культура годного менеджмента и качественной разработки в вебе стала пропагандироваться только в последние годы. Затраты на её поддержание и развитие часто не по карману интернет-компаниям. Но оправданием обычно служат не затраты, а стремление к Lean и Agile (на самом деле это чаще приводит к халатности «И так сойдет»).
Увы, это так. Про разработчиков не скажу точно — но про управление абсолютно так. Мобайл аналогично, и энтерпрайз туда же. Мне кажется дело даже не в том что пропагандируется, хотя и это тоже. Просто растем, и когда растет сложность, становится больше неопределенности — без толкового руководства совсем никуда. Нельзя просто собрать программистов, тестировщиков и надеяться что они сами все построят — их надо еще и организовать, создать условия. Управлять тоже надо уметь. И ждать от технического специалиста этого по умолчанию, без какой либо подготовке — наивно.
В web IT PM — это тот, кто связывает бизнес и разработку, а функция управления скопом — это приятное дополнение. И результат от него ожидают каждый свой. Разрабы — чтобы меньше было работы и она была четче, бизнес — чтобы быстрее и больше было сделано. Соответственно, вы должны уметь говорить на одном языке и договариваться с этими разными группами людей. А как это будет реализован процесс проекта — мало кого волнует.
Совсем не вижу связи между вашим тезисом что это для джуниор ПМ-а или координатора.
И с тем что должен отличать бэк от фронта, и понимать разработку — абсолютно согласен. И сам этими вещами владею. Про коммуникацию аналогичной позиции придерживаюсь что и вы, и про все остальное. С клиентами я работаю именно так как вы описали. Тимлид занимается техническими вопросами, и оказывает поддержку ПМ-у своей экспертизой, но не проводит за него переговоры с клиентом.
Просто отличать бэк от фронта условно, и разбираться глубоко, имея за плечами опыт и профильное образование — это разное. Под техническим бэкграундом я подразумеваю системную подготовку. То что вы описали я называю общей технической грамотностью, которую можно развить даже самостоятельно и работая бок о бок с сильными техническими специалистами которые делятся знаниями.
По моему личному опыту, чем больше вовлечённость всех участников команды во все процессы, тем лучше. Если разработчики думают о бизнес-метриках, а бизнес имеет в виду, что с выходом FaceID может потребоваться время на рефакторинг приложения перед релизом, договориться несложно. Хуже, если каждый видит узкий сектор работы перед собой и не знает, что творится вокруг него.
Аминь. Из полностью вовлеченных команд рождаются самоорганизующиеся — когда все и каждый осознают что, как и для чего надо делать. Как быстро и какими средствами. Им эти вещи не нужно объяснять. Это мне кажется пик.
Поэтому, отвечая на Ваши вопросы, могу сказать: чем больше знаний и скиллов у менеджеров, тем лучше.
Больше понятно, а насколько глубоких? Ведь сложно стать специалистов в нескольких областях, вы сами признали что прийдя в менеджмент нужно учить управление. Мне интересно просто как оно происходит наоборот — пришел менеджер в IT допустим
Любопытный опыт. Всегда интересны выводы человека ставшего руководителем.
Интересно мнение, на фоне сказанного и особенно:
Чем больше ты менеджер, тем меньше разработчик. Как бы ты ни старался уследить за тонкостями технической части проекта, они ускользают от тебя с каждым днём всё дальше. И чем больше команда и активнее разработка, тем быстрее. Постепенно объем получаемой новой информации об Android и iOS свёлся к чтению release notes новых версий операционных систем да паре статей на Хабре в месяц.
Появляется куча нетехнических проблем. Работа с людьми — это отдельное умение, которое ещё нужно прокачать. На первых порах сильно тревожит то, что в общении с людьми нет универсальной “правильной” манеры. С каждым человеком нужно находить свой общий язык.
Больше ответственности. Намного больше. Теперь приходится отвечать не только за свои задачи, но и за команду и продукт в целом. Когда кто-то в команде что-то зафакапил, то это и моя забота.
Другой ритм работы и круг общения. Бесконечные совещания и созвоны с заказчиком, ПМом и всей командой вместе и по отдельности. Когда я был разработчиком, на встречи уходило 2-3 часа в неделю. У меня-менеджера в некоторые дни — до 70-80% времени!
Каким тогда должен быть менеджер проекта? Если даже тимлид отходит от разработки и понимает насколько много ответственности, как важна коммуникация. Что делать техническими скиллами? Насколько нужны?
PM это не полноценный руководитель, как по мне так эта роль переоценена.
PM не отвечает за конкретную команду/подразделение — его скоуп это «проект».
PM не влияет на рабочие процессы — он временное явление рядом с командой.
PM не имеет профильного технического опыта — в следствие чего вопрос, а как подобный менеджер может повлиять на качество и сроки?
Хм, мне странно что с MBA вы такое говорите. Если он не руководит то это не менеджер, это координатор — другая роль.
Он отвечает за проектную команду, не функциональную. Не буду вдаваться нюансы разных орг.структур — но если проекты и ПМ, то уже появляется матричная структура, где ПМ руководитель — проектной команды.
Проект в целом временное явление — но то как построена разработка проектов это бизнес-процесс. Я хотел передать в публикации что для ПМ-а этот самый процесс у потенциального работодателя — очень важен.
Влиять на качество — очень просто, управлением. Руководитель чего бы то ни было в целом не занимается исполнительской деятельностью, это делают другие — он управляет. И без технического опыта не значит совсем никакого понятия об этом. Уже подготовил опрос на эту тему — там можно будет обсудить как опубликую.
«Руководить» должен руководитель команды/подразделения, формальный и не формальный лидер, имеющий видение и стратегию развития своей команды, инструменты для мотивации и стимулирования, опыт работы в сфере и самое главное имеющий доверие своих людей.
Без этого все желания «поруководить» приводят к «чайка» менеджменту, разваленым командам и не выполненным обещаниям перед людьми.
Да, все так — в рамках функционального подразделения, но при той же матричной структуре руководит и ПМ.
По моему мнению PM не нужен команде разработчиков, его вполне может заменить секретарь/секретарша выполняющий административные функции. Грамотный тимлид в легкую убирает PM и растет вместе со свеой командой.
Это и есть координатор — другая роль. Про то что бывает когда его нет в другой статье писал, бывает когда все его обязанности перераспределяются, но вопрос хотят ли этого сами разработчики — выстраивать коммуникацию, принимать общие решения по проекту, общаться с заказчиком по бизнес-вопросам, заниматься досками, тасками, решать проблемы. И еще более важно — могут ли, есть ли у них навыки общения, управления, насколько они клиентоориентированы.
К слову большинство разработчиков имеют серьезные перспективы в росте в руководители и MBA может помочь в этом. Бизнес — это framework, MBA — документация и bootcamp
Не соглашусь. Руководителями в целом могут быть немногие, будь то разработчики или представители других специальностей. Это специфическая работа с большим набором как скиллов которые нужно на том же MBA получать, так и компетенций — которые надо развивать и то не у всех получится, ибо это сложнее и дольше. И вдобавок не все хотят этого. Я бы даже сказал что большинству разработчиков неинтересно много общаться с людьми, вникать в маркетинг, финансы, управление, брать на себя ответственность за результат команды, подразделения, компании. Это далеко не для всех.
Хотя конечно есть исключения — которые преуспевают в обоих сферах, но это уникальные люди, их очень немного.
Проблема статьи в том, что в ней можно заменить менеджера проекта на любую другую профессию и никто не заметит разницы :). Очень мало специфики.
Специфика с моем личном опыте, и в том что когда выбирает себе работу разработчик — это совсем другая история. Но за мнение спасибо.
позицию является единственным способом зарплатного и карьерного роста и когда приз уходит новому человеку извне — это чертовски неприятно. Есть конечно и менеджерские позиции, которые никто не хотел, но там все относятся с пониманием.
На западе — возможно. В наших реалиях менеджеры получают часто меньше разработчиков, и у последних пропадает интерес идти переходить в управление. Поэтому думаю конкретно на нашем рынке это не актуально.
Недавно тоже занимался enterprise проектом, и мой опыт вне IT, по тем же кадрам, финансам и прочему корпоративному — очень пригодился. Но в целом в таких проектах как вы описали — знания нужны специфические, и их не так много, поэтому я больше ссылался на аутсорс проекты меньшего масштаба, и без энтерпрайза.
При наличии хорошего тимлида — нужно ли это знать ПМ-у?
Насчет каждого вопроса заказчика — даже зная общую структуру проекта, без глубины, зачастую клиенту можно на любой вопрос уже ответить, потому что зачастую у него нет технической подготовки, с ним говорят на языке бизнеса.
А навыки ПМ-а у него будут? Думаю что техлид-ПМ, то есть два в одном по навыкам и опытом будет стоить раза в 2-3 больше. 80к стоит обычный ПМ с парой лет опыта и технической грамотностью и английским.
Именно поэтому я больше ориентировался на аутсорс разработку небольшого и среднего масштаба. В проектах которые вы привели — да, как правило так. И это совмещение техлида и ПМ-а, но часто по другому никак. Хотя думаю многие на этом спотыкаются, сложно найти человека который и глубоко в проектном управлении разбирается, и технически подкован на уровне опытного разработчика, и при этом в теме новых вещей, его знания актуальны.
Конечно говорю в общем, пытаюсь понять тенденцию.
Но я вижу много противоречий. Вначале набор таких клише, которые в целом есть везде. Но мне одно непонятно — статья же написана разработчиками, так почему разработчики указывают управленцам какие у них ошибки?) Ну серьезно. Или вы думаете топ-менеджмент в больших компаниях не в курсе про эти проблемы?
Честно говоря я слышу больше мнений что в IT с менеджментом как раз все плохо ) Но это субъективно.
Ну это прям очень оценочно и аргументация слабовата. Кто-то из автором статьи учился на Менеджменте? Клише про мотивационные книжки это вообще из ВК, даже в самых захолустных универах мотивацию изучают исключительно с научной точки зрения. И насчет слишком специфичной — по сравнению с какой? А какие неспецифичные есть? Да кстати истории успеха не являются доказательством — всегда можно найти пару тройку примеров за и против. Это нормально.
Тоже клише. Что за пренебрежение к другим сферам? Выглядит так будто в IT мы тут все умные, а другие лаптем щи хлебают. Опять же вопрос — насколько авторы в курсе о том что происходит в других сферах? И в скольких.
Навыки презентации кстати очень важны, часто ПМ-у приходится говорить перед публикой и от этого много зависит. А все что вы описали — этому учат в технических ВУЗ-ах? И разработчики это умеют? Вижу противоречие с тем что выше — с одной стороны вы говорите что горе тем кто берет гумманитариев, а с другой описываете добрую часть того, чему как раз учат на Менеджменте.
Последний раздел слабый. Нельзя управление проектами вместить тезисно с один список, с разными уровнями абстракции. Все равно что попробовать тоже самое сделать к примеру с Javascript.
Но я склонен считать что сложные места, причины технических проблем, архитектура — это работа техлида, архитектора, и выше по уровню — СТО. Проектный менеджер в этих вопросах имеет совещательный голос, так как не эксперт зачастую.
Про совмещение этих двух ролей — отдельная тема.
Чтобы убрать зависимость — описал примерно о какой команде и каких проектах речь.
А в чем смысл? Он ведь не программирует, он управляет.
Насчет ставить на место — зависит от ситуации, от личных качеств ПМ-а и разработчиков. В целом по моему опыту это миф. Разные позиции — разработчики опытны в разработке, менеджеры опытны в управлении гораздо больше вышеуказанных разработчиков. С чего кому-то кого-то ставить на место.
Берем усредненную историю заказной разработки. Это, как правило, сайты, веб и мобильные приложения низкой и средней сложности, возможно CRM, и другие корпоративные штуки.
Комон 2020 на дворе, может хватит отрицать ценность руководства, менеджмента. Попробуйте сами собрать группу разработчиков, и дать им проект и никак не руководя посмотреть что будет. Попробуйте поруководить вообще хоть кем-то.
Или вы сторонник теории что все вокруг государство, все организации, бизнес, любые команды — имеют руководителей, и они просто паразитируют ничего не делая? Серьезно?
Я просто утверждаю что менеджер и руководитель это синонимы. Если нет руководство — в названии позиции слова «менеджер» быть не должно. Привет всем менеджерам по продажам )
Если имеется в виду работа с персоналом в плоскости найма/увольнения, развития — то не везде и не всегда. Это безусловно дает ему больше пространства для маневра — когда он контролирует подбор и работу с персоналом. Это происходит когда внедрена сильная матричная структура. Но при этом не является обязательным атрибутом. То что он не контролирует персонал не исключает то что он будет руководить командой. Да, это будет сложнее, полномочия ограничены, но они есть.
Согласен. Я больше скажу — все отрасли специфические, потому и отрасли. Если погрузиться — куча нюансов, технической составляющей, специалистов и специальностей. В этом надо разбираться, надо понимать точки контроля, и тогда обмануть будет сложно. Плюс есть же тимлид, который в этом разбирается глубоко, и разработчик попытается обмануть и его.
Нет, не костыль. Но сложно — согласен. И мало кто умеет нормально строить такую систему. 2 руководителя вполне нормально, если организация гибкая и руководители толковые. А условиях неопределенности без гибкости никак — потому что функциональное подразделение заточено на выполнение одних и тех же функций регулярно, минимум неожиданностей. Когда сделать надо что-то новое, непонятное — нужны проекты. И так уже другая специфика, другое руководство. Если разделить грамотно и распределить время — то вполне можно организовать чтоб работало нормально. Насчет неоднозначности — не надо пытаться ее убрать, это невозможно, потому что весь мир неоднозначен, есть куча факторов которые влияют, черные лебеди вон с коронавирусом. Выход — научиться работать в таких условиях, вот матричная структура как раз так и появилось, когда стало понятно что не выгребают и надо как-то менять процесс. Её не ввели просто потому что кому так вздумалось — таковы были условия.
Тут есть момент. Пресловутые хард скиллз и софт скиллз, вторые по русски это компетенции. Так вот компетенции развиваются сложнее — потому что это по сути личные качества, проявляемые на работе. Вы видели когда нибудь чтобы личные качества людей быстро менялись? На это уходят годы работы над собой, по исследованиям в год можно прокачать на уровень одну, максимум две компетенции. А их десятки.
Второй момент — есть нулевой уровень компетенции, когда её у человека нет, и не будет. То есть нет потенциала её развития, он просто не может и всё. Шансы что он её разовьет настолько мал, что проще сфокусировать на других. Это я говорю про общение например. Управление это хард скилл который можно развить быстрее.
Ну вот я с этим не согласен. Единственный аргумент такого подхода — хорошее знание сферы. Но это лишь одна составляющая управления, и не первого порядка. Именно по причине вышеперечисленные нюансов софт скиллов/компетенций — она не настолько важна. Еще раз — важна, но не самая важная.
Потому что коммуникация и управленческие навыки важнее. И потому это хард скиллы, их развить проще, чем научиться общаться.
Разработчики которые выходят в тим лиды, ПМ-ы, СТО, СЕО — это как правило люди у которых изначально был потенциал к этому, у них не было проблем с общением, они неплохо ориентировались в неопределенности, брали на себя роль неформального лидера. Это моя позиция.
Но тем не менее — если есть еще аргументы против — пишите, для меня интересно всегда подискутировать на эту тему. Не считаю свое мнение истиной в последней инстанции.
Сейчас обидно стало ) Как будто менеджеры проектов не делают полезное и красивое. Бухгалтера тоже не делают тогда. И вообще мало кто делает. Хотя желание вернуться и делать так чтобы то что без вас не крутилось — начало крутиться (цитата), мне вполне понятно. Просто каждому своё.
Я говорю именно про менеджера проекта, и из этого следует что мое видение непричем, по факту в IT — проекты имеют место зачастую именно в аутсорсе. Не берем крупные не IT компании со своим проектным офисом — это другая истории. Это следует из самого понятия проекта.
Согласен, сплошь и рядом так — но считаю это минусом. Недостатками организации, и к этому постепенно приходят компании.
В продуктовой компании ПМ — это продакт менеджер, посколько в ней нет проектов. Совсем другая роль, которую я не берусь описывать, там своя специфика. Продуктовая разработка не предполагает окончания, по крайней мере не планирует его. Проект же это предполагает всегда. И согласен что ПМ в продуктовых компаниях, это номинально, если развернуто называть его менеджером проектов, то терминологически это неверно. Скорее это как вы справедливо заметили — тимлид, либо зам продакта по операционке, либо координатор.
Не нужен абсолютно, я в принципе нигде и не говорил что нужен. Концепт MBA это в целом подготовка менеджером топ звена. Проектного управления к слову там почти нет, общие понятия не более. Польза скорее в том что даются достаточно четкие абстрактные закономерности и схемы, которые применимы практически в любой отрасли.
Это сделано вполне осознанно. Я в целом специализируют на общих вещах, стараясь выявить в них закономерности, попытаться сориентироваться в тумане.
Если уж совсем точно не общая, она просто не конкретная. Поскольку при выбора места работы информации мизер — конкретики нет и быть не может. Этот процесс нельзя уложить в четкую схему, так как для него недостаточно данных. В любом случае мы знаем очень мало и ориентируемся наощупь, с высокой вероятностью неожиданностей. В жизни в целом мне кажется все так и происходит — мы очень многого не знаем. Выражаясь терминологией системного мышления по Леванчуку — это уровень схемоида, но точно не схемы.
К слову хочу написать про это — может там товарищи хабровцы увидят высокий технический уровень.
Замечание справедливо. Я этот момент не осветил, хотя он важен.
Тоже были такие прецеденты, но это проблема руководителя. Моя личная позиция — мой MBA помимо того что это было отличное образование, еще дал громадный опыт жизни в другой культурной и языковой среде, оба фактора для меня важны — и если потенциальный работодатель комплексует по этому поводу, то скорее всего нам с ним не по пути.
Были с другой стороны и положительные примеры — когда руководители цеплялись этот пункт из резюме, и использовали мои знания и опыт во благо. В целом это проблема управленческой культуры — но это отдельная большая тема.
Увы, это так. Про разработчиков не скажу точно — но про управление абсолютно так. Мобайл аналогично, и энтерпрайз туда же. Мне кажется дело даже не в том что пропагандируется, хотя и это тоже. Просто растем, и когда растет сложность, становится больше неопределенности — без толкового руководства совсем никуда. Нельзя просто собрать программистов, тестировщиков и надеяться что они сами все построят — их надо еще и организовать, создать условия. Управлять тоже надо уметь. И ждать от технического специалиста этого по умолчанию, без какой либо подготовке — наивно.
Абсолютно так.
И с тем что должен отличать бэк от фронта, и понимать разработку — абсолютно согласен. И сам этими вещами владею. Про коммуникацию аналогичной позиции придерживаюсь что и вы, и про все остальное. С клиентами я работаю именно так как вы описали. Тимлид занимается техническими вопросами, и оказывает поддержку ПМ-у своей экспертизой, но не проводит за него переговоры с клиентом.
Просто отличать бэк от фронта условно, и разбираться глубоко, имея за плечами опыт и профильное образование — это разное. Под техническим бэкграундом я подразумеваю системную подготовку. То что вы описали я называю общей технической грамотностью, которую можно развить даже самостоятельно и работая бок о бок с сильными техническими специалистами которые делятся знаниями.
Аминь. Из полностью вовлеченных команд рождаются самоорганизующиеся — когда все и каждый осознают что, как и для чего надо делать. Как быстро и какими средствами. Им эти вещи не нужно объяснять. Это мне кажется пик.
Больше понятно, а насколько глубоких? Ведь сложно стать специалистов в нескольких областях, вы сами признали что прийдя в менеджмент нужно учить управление. Мне интересно просто как оно происходит наоборот — пришел менеджер в IT допустим
Интересно мнение, на фоне сказанного и особенно:
Каким тогда должен быть менеджер проекта? Если даже тимлид отходит от разработки и понимает насколько много ответственности, как важна коммуникация. Что делать техническими скиллами? Насколько нужны?
Хм, мне странно что с MBA вы такое говорите. Если он не руководит то это не менеджер, это координатор — другая роль.
Он отвечает за проектную команду, не функциональную. Не буду вдаваться нюансы разных орг.структур — но если проекты и ПМ, то уже появляется матричная структура, где ПМ руководитель — проектной команды.
Проект в целом временное явление — но то как построена разработка проектов это бизнес-процесс. Я хотел передать в публикации что для ПМ-а этот самый процесс у потенциального работодателя — очень важен.
Влиять на качество — очень просто, управлением. Руководитель чего бы то ни было в целом не занимается исполнительской деятельностью, это делают другие — он управляет. И без технического опыта не значит совсем никакого понятия об этом. Уже подготовил опрос на эту тему — там можно будет обсудить как опубликую.
Да, все так — в рамках функционального подразделения, но при той же матричной структуре руководит и ПМ.
Это и есть координатор — другая роль. Про то что бывает когда его нет в другой статье писал, бывает когда все его обязанности перераспределяются, но вопрос хотят ли этого сами разработчики — выстраивать коммуникацию, принимать общие решения по проекту, общаться с заказчиком по бизнес-вопросам, заниматься досками, тасками, решать проблемы. И еще более важно — могут ли, есть ли у них навыки общения, управления, насколько они клиентоориентированы.
Не соглашусь. Руководителями в целом могут быть немногие, будь то разработчики или представители других специальностей. Это специфическая работа с большим набором как скиллов которые нужно на том же MBA получать, так и компетенций — которые надо развивать и то не у всех получится, ибо это сложнее и дольше. И вдобавок не все хотят этого. Я бы даже сказал что большинству разработчиков неинтересно много общаться с людьми, вникать в маркетинг, финансы, управление, брать на себя ответственность за результат команды, подразделения, компании. Это далеко не для всех.
Хотя конечно есть исключения — которые преуспевают в обоих сферах, но это уникальные люди, их очень немного.
Специфика с моем личном опыте, и в том что когда выбирает себе работу разработчик — это совсем другая история. Но за мнение спасибо.
На западе — возможно. В наших реалиях менеджеры получают часто меньше разработчиков, и у последних пропадает интерес идти переходить в управление. Поэтому думаю конкретно на нашем рынке это не актуально.
Вы бы хоть один аргумент привели для приличия, а то право как-то голословны.