Комментарии 17
Как человек, который работал и ПМом, и тех. спецом, могу сказать, что это все не совсем так. Точнее это может быть так, если не знать, что делает ПМ. Я не буду сейчас кратко описывать всякие там РПМбуки и прочее, а просто попробую сосредоточиться на том, что должен ПМ уметь
Ну во-первых, что такое ПМ? Это человек, которые отвечает за результат проекта, на который могли быть выделены большие деньги. И ему никто не говорит, как это сделать. Т.е. сразу отметаем всех ИТшников, которые копают от забора и до обеда (либо от таски до такси), как нерелеватных кандидатов. Т.е. если человек не перешел ту грань, за которой ему не нужен внешний постановщик задач - он не ПМ от слова совсем. Большинство ИТ-шников таким качеством не обладают, и многие не стремятся обладать.
Второе - ПМ должен выбирать между разными вариантами, где нет ни одного идеального. И принимать во внимание все факторы. Вот к примеру, много ИТшников вообще задумаются, что есть, к примеру, юристы, безопасность, операционные подразделения, финансисты. А все эти люди и еще много других могут иметь свое мнение "хрен оспоришь" и их нужно свести к единой точке. А много ли навыков и технаря "игр в политику" либо просто "находжения над схваткой"? А в большом проекте этого будет много и еще больше.
ПМ - в иделе ничего не делает сам по технической части. Т.е. навык делегирования должен быть развит абсолютно. Технарю надо будет переступить через себя и перестать им быть от слова совсем, иначе он будет делать работу команды, но не будет делать свою
ПМ - птица говорун. С заказчиком, зампредом, командой, поставщиками, .... много ИТ-шников готовы выступить перед кучей больших дядек, презентуя проект? А делегировать некому, так как ты главный и тебе отдуваться.
ПМ - кукла вуду для спонсора, если что-то идет не так. Да, потом можно транзитивно навалять члену команду, из-за которого пошло все не так, но от спонсора и прочих получаь люлей только тебе
------------------
Теперь о том, почему "технарь" типа круче
Эффективнее оценивать риски
Технические риски - лишь малая часть рисков, которые на изи напишет для вас тот же лид или архитектор, а вот остальные писаьт и работать с ними ПМу
Принимать обоснованные решения
Есть огромное число решений, в которой нет технической составляющей, либо она минимальна. Чего будем делать?
Принимать обоснованные решения
Как ни странно, хорошие ПМы и так отлично общаются. Это вообще несложно. Вы же общаетесь в реальном мире со строителями, автомастерами, не разбираясь в вопросе. Как-так то?
Понимают реальную работу команды
Самые веселый пункт, что знает тим лид про процесс препродажи, участия в тендере, контрактинга, организации командировок/воркшопов, поддержки решения после выхода в прод ... в реальности на большом проекте разработка дай бог чтобы половину времени занимала
-------------
Да, для маленьких проектов в части project execution - да. Для больших проектов пересечение по скилам с тех лидом практически отсуутствует
Поддерживаю всеми руками и ногами
Когда коммент мощнее чем целая статья 😄
Из системных аналитиков ещё часто получаются хорошие ПМ-ы, потому что они и в коммуникацию умеют и в технику, если есть способности и желание менеджерить - то хороший вариант, но и из всяких коммерческих челов вроде бывших продажников - вполне себе получаются 💪
Когда комментарий полезнее статьи (и написан лучше)
Во-первых, утверждение, что ИТ-специалисты не могут быть ПМ-ами, потому что они не обладают качеством самостоятельного постановщика задач, является обобщением. Многие ИТ-специалисты, особенно те, кто занимают руководящие должности, прекрасно справляются с задачей планирования и постановки задач. К тому же, навыки, необходимые для управления проектами, можно развить через обучение и практику.
Во-вторых, способность учитывать мнения различных заинтересованных сторон и объединять их в единое целое – это навык, который также можно приобрести и развивать. Технари, работающие на междисциплинарных проектах, часто взаимодействуют с юристами, финансистами и другими профессионалами, и таким образом, приобретают необходимые навыки для управления проектами.
Третье, утверждение, что ПМ в идеале ничего не делает сам по технической части, верно лишь отчасти. Хороший ПМ должен иметь базовые технические знания, чтобы понимать, как ставить задачи и оценивать их выполнение. Это не значит, что он должен сам все делать, но понимание технической стороны проекта поможет ему лучше управлять командой.
Четвертое, коммуникативные навыки действительно важны для ПМ, но утверждение, что технари не могут хорошо общаться с заказчиками или выступать перед большими аудиториями, также является обобщением. Многие технические специалисты обладают отличными навыками презентации и общения.
По поводу рисков: технические риски – это только одна часть. Однако ПМ, который приходит из технической среды, может лучше понимать и предвидеть технические проблемы, что в сочетании с обучением управлению другими видами рисков делает его только более эффективным.
Комментарий из разряда стереотипов, если айтишник, то это очкарик горбатый, в прыщах с грязными кружками у стола, пишущий код, а пм эдакий белый воротничок…
Во-первых, утверждение, что ИТ-специалисты не могут быть ПМ-ами, потому что они не обладают качеством самостоятельного постановщика задач, является обобщением.
Если бы вы нашел, где я такое писал, то было бы вообще прекрасно. А так выходит, вы как будто сами с собой общаетесь :)
Ну и дальше по тексту :)
--------
Ну и как вы понимаете, если я лично работал и как ПМ в том числе, и как линейный ИТ-руководитель, и как просто ИТ-эксперт - я отлично знаю о том, что вы пишете
Как ПМ, который не вышел из технических специалистов издания, а "управленец со стороны" тоже не могу согласиться. Точнее, я принимаю вашу позицию, но здесь больше рассматривается сторона взаимодействия с командой, а как же внешняя коммуникация? С другими отделами, с руководством, с клиентом?
Чаще всего в своей работе я понимаю, что тот факт, что я не являлась исполнителем, дает мне силы спокойно реагировать на правки от клиента, не пропускать их через себя. Опять-таки отсутствие огромного технического опыта дает возможность говорить с клиентом на понятном ему языке. Плюс ПМ не из технических кадров, обладающий малыми знаниями о технической стороне вопроса, чаще объясняет клиенту все шаги более подробно (таким образом, фиксируя их и для себя в том числе)
Есть третий путь, когда ПМ занимается бюрократией и выбиванием денег, а техническими аспектами, включая риски и сроки - тех. лид.
Когда не знаешь как правильно, вспоминай скрам.
1) Там продуктовый менеджер, он же product owner - это управленец "с улицы", а точнее менеджер со стороны заказчика, который занимается развитием продукта.
2) И есть проектный менеджер он же scrum master, который занимается организацией разработки.
Так что их два должно быть.
Управление проектами - это отдельная специальность, с отдельной большой областью деятельности и специфическими методами. ПМ может вырасти из кого угодно при нужных амбициях: специалиста техподдержки, аналитика, разработчика, архитектора, но управление проектом и продуктом - это отдельная специальность. И сейчас есть люди, которые специально этому учились. А ещё сейчас время жизни проекта сокращается, как и циклы рефакторинга, поэтому через 3-5 лет бизнес, код и продукт полностью изменится, нужно переходить на другой проект или полностью переписывать текущий, технические знания кода устаревшего продукта уже не так полезны, как знание методов запуска проекта с нуля и управление изменениями. Скорость обновления технологий тоже только растёт и постоянно нужно изучать новые методы управления, чтобы запускать процесс изменений. Причем тут знание кода и корпоративной культуры технического специалиста не очень понятно.
В статье смешаны в кучу навыки управления людьми и управления проектами. Прожект менеджер это даунгрейд для программиста. Ну во первых ПМ это такой же индивидуальный контрибьютор как и программист. А во вторых он должен пинать технарей не имея на то полномочий, то ест технари ему не подчиняются по структуре управления. А если подчиняются то это уже не ПМ а инжиниринг менеджер, совсем другой зверь.
Все зависит от ролевой модели в конкретной компании, ну и от продукта. Если между проджектом и командой есть тимлид, то проджекту и не обязательно иметь технический бэкграунд..
В подавляющем большинстве случаев хороший специалист рождается из человека, который учился на этого специалиста, зарабатывал релевантный опыт и имеет нужные для профессии навыки. В проектном управлении вообще есть такая линия на кривой развития, пересекая которую менеджеру все равно что "менеджерить" - хоть разработку ПО, хоть разработку автобусов.
Брать ПМа из технарей актуально только для очень маленьких проектов или для компаний, которые просто хотят сэкономить деньги за счёт времени и здоровья сотрудника (привет всем фулл-стекам и "техническим менеджерам"). Ибо это удобно, когда вместо ПМа, Лида и сисаналитика у тебя один человек на одну зарплату (которая никогда не будет равна сумме трёх зарплат отдельных специалистов).
Почему лучше нанимать Project Manager из технических специалистов, чем управленца «с улицы»