Нужно ли расти из технического специалиста или целенаправленно, с нуля учиться на менеджера? Смогу ли я управлять коллективом, не умея выполнять задания, которые я даю своим сотрудникам? Что ждет меня через 3-5-7 лет? Что предпринять сейчас, чтобы приблизиться к собственной мечте (и какова вообще она — карьерная мечта руководителя проектов)?
Я больше 10 лет занимаюсь проектным менеджментом и такие вопросы слышу часто (да что там — задаю их и сам себе). Единственно-верных ответов, конечно, не существует, а вот собственными соображениями я поделиться могу.
Сам я давно пришел к убеждению, что ни у специалистов по кадрам, ни у тех, кто занимается проф. ориентацией, нет ответов ни на эти, ни на более конкретные вопросы. Например, «Может ли менеджер проектов перейти из сферы ИТ, скажем, в строительство?».
Мы знаем, примеры есть. Однако, когда и почему такие переходы оказываются успешны — ответить затрудняемся.
Часто работодатели не ограничиваются в вакансии требованиями к знаниям проектного управления и общему стажу, а обязательно требуют релевантный опыт (например — 5 лет в управлении разработкой сайтов или внедрения ERP и т.п.). Сами менеджеры тоже стараются строить карьеру с таким прицелом, чтобы развиваться в наиболее симпатичной области. Но это на уровне интуиции. А можно ли подвести под нее какие-либо правила?
Мой ответ: можно. И не самые очевидные.
Я попытаюсь порассуждать на тему карьеры руководителя проектов: что она собой представляет и как меняется в зависимости от типа компаний, с которыми может свести судьба. Существенное место в моих рассуждениях займет классификация от Генри Минцберга, о которой подробнее скажу ниже.
Чтобы говорить о карьере менеджера, позвольте мне предложить хоть какое-то понимание сути его работы и критериев ее эффективности.
В самом деле, когда мы говорим о софтверном разработчике – все (на первый взгляд) гораздо понятнее. Хороший разработчик отличается от плохого хотя бы тем, что в более короткий срок создает более качественный продукт (в самом широком смысле — соответствия требованиям или ожиданиям, устойчивости и масштабируемости архитектуры продукта и т.п.). Я не хочу создавать серьезных споров, отмечу лишь, что разработчик делает продукт (софтверный), он делает его не для себя, а значит то, каким качественным и быстрым оказался результат — всегда можно проверить.
С менеджером немного сложнее. Он занимается чем-то, что гораздо трудней померить, а результат — всегда зависит не от него одного. Он сам, как правило, не производит ничего материального (кроме диаграмм Ганта или стикеров на Канбан-доске, да каких-нибудь актов приемки-передачи, если таковые на проекте нужны). Посему задача «отличить плохого менеджера от хорошего» отнюдь не является простой (в то время как ответ — критично важен для любого карьериста — к чему стремится, что показывать работодателю, какие качества и навыки развивать, чтобы рассчитывать на незаурядный профессиональный рост)?
Наверняка у вас уже есть простые ответы.
Например: «хороший менеджер закрывает проекты в срок и в бюджет», или «у хорошего менеджера довольный заказчик» или «хороший менеджер закрывает проекты с меньшими отклонениями, чем коллеги», или «хорошей менеджер — лидер» и т.п. Опять же, не буду спорить. Скажу лишь, что по моему опыту работает два принципа, которые все эти простые ответы немного нивелируют. Первый — «кто везет — на том и едут» (т.е. стоит менеджеру проявить себя, как ему начинают поручать более сложные проекты, рисковые задачи, подсовывать особо трудных клиентов и т.п. и в итоге его показатели завершения проектов «проседают», по сравнению с коллегами, хотя внутри компании все помнят — Егор работает на невероятно трудных задачах, он крутой). С другой стороны, проектный менеджмент — это всегда много коммуникаций и иногда — немного политики, а посему использование трудно измеримых показателей (типа менеджер проектов — «лидер») приводит к вкусовщине, и лучшими признаются те, кто громче и складнее говорит и к тому же лучше строит отношения, причем больше с менеджментом, чем с командой.
Тут я предложу немного пофилософствовать. Давайте сделаем шаг назад и попытаемся окинуть взглядом всю профессию проектного менеджера в целом, а уже потом снова вернуться к критериям, отделяющих «плохих» от «хороших».
О проектном управлении как профессии заговорили сравнительно недавно. При том, другие виды руководителей (директора, президенты, командиры и прочие) существуют и решают сложные задачи вполне успешно. Не менеджеры проектов строили первые пирамиды. Строительство первой морской армады, создание первых торговых путей через пол мира осуществлялось куда более традиционными управленцами и отнюдь не в демократичных проектных командах.
Так в чем же смысл? Зачем придумывать еще одну профессию? Ведь к настоящему моменту, во многих областях сложилась давно обкатанная система управления.
Оказывается, не везде. Отправная точка для проектного управления как раз в том, что есть отрасли, где специалисты не умеют систематически добиваться хорошего результата.
Где сегодня мы чаще слышим о проектах?
— сфера информационных технологий (ИТ в самом широком смысле)
— строительство
— развитие бизнеса
— медиа-деятельность (да, телепроект «Дом-2» и иже с ним)
— кое-где в научных кругах
— и т.п.
Именно тут привычные формы управления никак не могут позволить одной ИТ-фирме уверенно конкурировать с другой. Отчего-то первая версия софтверного продукта выходит вовремя, хоть сыроватой, а вторая разрабатывается ни шатко, ни валко, разочаровывает пользователя и позволяет конкурентам вырваться вперед. Строительство дома вязнет в бесконечных перипетиях согласований и ненадежности подрядчиков, в то время, как каждый день простоя башенного крана оборачивается многотысячными убытками.
Есть ли что-то общее у этих сфер – сравнительно молодого ИТ, гораздо более взрослого «медиа» и совсем уж древних по своему происхождению науки и строительства? Хотя бы то, что Генри Минцберг называл «внешней средой» для компании. В обоих случаях она, эта среда, оказывается в современных условиях – «сложной» и «динамичной». «Сложная» — значит сама компания со всеми имеющимися ресурсами интерпретирует свои задачи как тяжелые, трудно-постижимые, труднообъяснимые. «Динамичная» — значит, что постоянно приходится реагировать на принципиально новые запросы клиентов, осваивать новые технологии, учитывать другие драматические технологические и не только новации. О теории Минцберга мы еще скажем.
Зафиксируем тезис.
Проектное управление — это реакция на неумение систематически добиваться положительного результата.
Кстати, именно поэтому отчеты типа «Chaos report», говорящие, что не меньше трети всех проектов в ИТ проваливаются — отражают причину, а не следствие. Дело не в том, что менеджеры проектов повально и сплошь безрукие неумехи, но в том, что именно эти менеджеры принимают самые сложные вызовы в современном управлении. Вольно перефразируя Черчиля о демократии, «управление проектами не очень эффективно, но ничего лучшего человечество сейчас придумать не смогло».
Итак, внешняя среда — слишком сложная и быстро меняется, чтобы фирма (компания, госучреждение) могла эффективно управлять своей работой. И мы начинаем экспериментировать. Например, зовем менеджера проектов и вверяем достижение результата ему. Примерно, как пациент, перебравший все традиционные подходы вверяет себя экспериментальному методу лечения.
Вот тут очень важно определить — не оказался ли пациент в руках красноречивого шарлатана. Вновь, вплотную подходим к вопросу «как отличить хорошего менеджера от плохого».
Обращаясь к врачу, большинство из нас не ждет заумных диагнозов или длинных рецептов. Мы, в первую очередь, хотим перестать кашлять (и, если бы верили, что справимся сами, к доктору не обратились бы вовсе).
Так чего же ждут на самом деле от руководителя проектов? Зачем приглашают его на «проекты»? Уж точно не ради рассказа и внедрения проектных методологий, нарисованных диаграмм Ганта или расклененных стикеров на Канбан-доске, не ради харизмы и красноречия.
Наниматель менеджера надеется, что в его руках дело пойдет «лучше», чем прежде. В одних проектах важнее попадать в бюджет, в других — в бюджет и в срок, в третьих — на первом месте — ощущения пользователя. Как бы то ни было, любой работодатель может сформулировать, чего хочет на деле.
Сведем это к универсальным терминам: «эффективность» и «конкурентоспособность».
С приходом менеджера по значимым параметрам работа команды в целом должна улучшаться (эффективность) и при этом оказываться на адекватном уровне по сравнению с аналогами и соперниками (конкурентоспособность).
Никто не любит проектное управление «за красивые глаза». Бизнес и прочие структуры интересует лишь рост эффективности и конкурентоспособности. В сфере ИТ есть немало фирм, управляющих своей работой по принципам, утвержденным в 70-х, и это сильные игроки. У них своя специфика, никакого проектного управления им не надо (и не вздумайте предлагать). В том же строительстве есть подход, альтернативный управлению проектами (создание не команд, а жестко регламентированных и взаимодействующих по шаблонам «служб» или «управлений»), который имеет право на жизнь и в некоторых случаях более успешен.
Фиксируем второй тезис.
Универсальные задачи проектного управления — повышать эффективность и конкурентоспособность (компании, продукта, команды).
Это очень конкретные показатели. Их можно и нужно измерять (в каждой отрасли по-своему, но всегда однозначно).
Кстати, не стесняйтесь пользоваться этим, столкнувшись с предположительными демагогами или продавцами воздуха «от проектного управления». Переводите разговор о непременной важности методик, информационных систем управления и т.п. в измеримый эффект. Просите объяснить, что именно можно измерить «до» и «после», и каковы окажутся прогностические значения. А, получив ответ, опять же, не стесняйтесь в выводах.
Нужно больше конкретики.
Мы выяснили, что там, где компания не умеет систематически добиваться хорошего результата, она будет перебирать разные формы управления и, возможно, придет к проектному менеджеру. Задача последнего — повысить эффективность и конкурентоспособность. В конечном счете, от оправдания именно этих ожиданий будет зависеть его карьера.
Казалось бы, тут мы должны остановиться, потому как многообразие фирм, их заказчиков и прочих нюансов уже не позволит продолжить конкретный разговор.
Хорошая новость в том, что до нашего разговора были написаны десятки диссертаций, цель которых — как-то классифицировать организации, чтобы найти закономерности в их работе, развитии, требованиях к персоналу. Воспользуемся плодами труда наших коллег и попытаемся продолжить разговор.
Используем классификацию Генри Минцберга (сформулированную в его книге «Структура в кулаке») для того, чтобы понять, в каких компаниях может оказаться менеджер проекта, на какие ожидания ему там, внутри, придется равняться и, в конечном счете, какие формы может принять, в результате, его карьера.
Ниже я изложу суть теории Минцберга очень кратко и своими словами (намеренно опуская многочисленные нюансы). Для наглядности сопровожу иллюстрациями — предупреждаю, отдельные картинки, на первый взгляд, кажутся неприличными.
Минцберг провел сотни исследований разных фирм, некоммерческих структур и гос. предприятий и пришел к выводу, что любую из них по структуре можно отнести к одному из нескольких видов (мы рассмотрим только четыре).
Простая компания
Многие компании начинаются как маленький «стартап» — один основатель и несколько единомышленников, составляющих так называемое «операционное ядро». Этот тип называется «простая компания». Она демократична насколько это возможно. Но вся полнота власти — в руках основателя (он, в конечном счете, «узкое место» всей системы). В компании пока нет ничего лишнего.
Рисунок 1 — Простая компания
Механистическая бюрократия – власть стандартов и менеджеров
Затем компания растет. Например, таким образом: расширяется количество сотрудников (к примеру, инженеров), т.е. увеличивается операционное ядро. Основатель-собственник уже не справляется и приходят первые менеджеры.
По мере того, как фирма растет — менеджерская прослойка увеличивается. Она утолщается ближе к ядру (начальники секторов, отделов, департаментов), а тоньше — к «голове».
Со временем в компании появляются и два своеобразных довеска (на графике — в виде осьминогов). Они не относятся явно ни к тем, кто производит (инженеры и другие сотрудники ядра), ни к тем, кто командует (менеджерская прослойка и голова). Они как бы «сбоку». Один довесок — это всевозможные вспомогательные службы, неизбежно разрастающиеся при развитии фирмы: бухгалтерия, кадры, юристы, хозяйственники и прочие (на схеме — грустный осьминог).
Второй — не такой очевидный. Это силы, стремящиеся упорядочить систему, стандартизовать, описать, зафиксировать все процессы в виде инструкций. Это- всевозможные службы качества, аналитики (работающие над стандартизацией внутренних процессов). На схеме — веселый осьминог.
Рисунок 2 — Механистическая бюрократия
То, что мы описали сейчас, сам Минцберг называл «Механистической бюрократей» и относил к не самым человечным формам организаций (т.к. там особенно рядовые сотрудники в наибольшей степени подвержены демотивации и выгоранию). Яркий пример — завод по сборке автомобилей (по сборке, а не по изобретению). Деятельность основной массы сотрудников — простая и жестко регламентированная (конвеер). Начальники, в первую очередь, следят за соблюдением инструкций и регламентов, которые заботливо создает и уточняет один из «осьминогов». Стратегические решения принимаются в голове компании и, если надо, спускаются сверху вниз. Обратите внимание, такие компании нацелены на стандартизацию процесса работы (и сами эти стандарты описывают). Механистические бюрократии неповоротливы и очень хорошо себя чувствуют в простой и стабильной среде (и завтра, и послезавтра, и через 5 лет процедура сборки автомобилей едва ли существенно изменится, так что подобные заводы будут процветать).
Профессиональная бюрократия — власть специалистов
Развитие компании могло бы пойти и по иному пути. Например, если бы выяснилось, что работа, которой заняты ее сотрудники, слишком сложна. Настолько, что контролировать каждый их шаг — немыслимо. И даже переложить его в инструкции невозможно.
Пример — работа врача.
Каждый доктор — профессионал в своем деле. Если кто и контролирует доктора — то не столько начальник, сколько старшие товарищи (интерна опекают полноценные доктора, за докторами присматривают профессора на отделении).
Большую часть времени доктор работает на отделении один на один с пациентом. В сложном случае он может просить совета, но в целом — должен сам принимать решения. Тем более нелепо предположить, что глава клиники будет давать ему указания. На Западе клиниками чаще рулят управленцы, в России — это, почти всегда, бывшие врачи. Но и в российских реалиях, главный врач едва может охватить свою собственную бывшую специальность (например, кардиологию), и отнюдь некомпетентен в контроле, скажем, хирургов (заявляю ответственно, как бывший хирург).
Вот и получается, что для эффективной работы компания (в нашем примере — больница) перестраивается. Растет операционное ядро, растут и полномочия его сотрудников.
Растет вдогонку вспомогательный аппарат (грустный осьминог), т.к. должен обслуживать разнообразные потребности профессионалов — закупки бинтов, каталок, выставление счетов и т.п…
Веселый осьминог — напротив, съеживается (на схеме от него остались одни глаза). Мы уже выяснили, что едва ли кто-то в больнице или даже в целом мире возьмется составить инструкцию каждому врачу на все случаи жизни. Ограничиваются разве что небольшими регламентами (например, где хранить амбулаторные карты или куда сдавать талоны после приема). Научить же врача работе может только внешнее учреждение за долгие годы (ВУЗ). Так что ни одна больница не пытается стандартизовать работу, а только навыки, с которыми специалист должен влиться в ее ряды.
Рисунок 3 — Профессиональная бюрократия
Менеджерская прослойка сжимается за ненадобностью (даже в России доктора от главврача крупнейшей больницы отделяет всего 2-3 ступени: заведующий отделением, начмед, да какой-нибудь «зам. глав врача по лечебной работе»). Функции же головы компании также невелики и сводятся больше к администрированию. Очень многие запросы, в конечно счете определяющие стратегию больницы, идут снизу — доктора выходят с инициативами о закупке оборудования, лекарств, потребностях в новых коечных мощностях, а менеджеры и высшие руководители их интерпретируют и иногда претворяют в жизнь. Такую форму организации Минцберг называет «Профессиональная бюрократия». Она достаточно устойчива в сложной, но стабильной среде. Сложность предопределяет требования к профессионализму (мы не знаем, с чем придет пациент завтра и послезавтра, доктор должен уметь многое и научиться этому еще до прихода к нам — в этом отличие от рабочего у конвейера, которого мы можем чуть не с нуля научить сами). Но сама среда довольно стабильна (больница знает, какие болезни вообще существуют в природе, что ей в принципе может понадобиться сегодня-завтра-всегда) и при наличии профессионалов в штате и денег на счетах — готова справиться с любым адекватным вызовом.
Итак, три варианта. В каких же типах компаний работают менеджеры проектов? Правда в том, что во всех трех. Нанимают менеджеров даже маленькие стартапы с простой структурой, и большие бюрократии (на первый и второй взгляды никак к проектному управлению не приспособленные). Активны, конечно, и компании где у руля сами сотрудники.
Ну, а в какой же компании менеджеру живется лучше всех?
Ответ — ни в какой.
Давайте вспомним, что каждый вид компании формируется естественным образом в своей среде.
Простая — в простой, динамичной среде
Механистическая бюрократия — в простой, стабильной среде.
Профессиональная бюрокартия — в сложной, стабильной среде.
Чего-то не хватает, правда?
Да, именно, самого экстремального варианта: сложной, динамичной среды.
Т.е. такой, где навыки специалиста стандартизовать нельзя (как и в примере с врачом). Но при этом, сама среда очень изменчива. Сегодня клиент просит одно, завтра — что-то совершенно другое, приходится постоянно применять новые технологии и делать то, чего мы никогда доселе не делали, не умеем спланировать, не можем оценить.
Очень отдаленный пример, чтобы создать хоть какую-то точку опоры: в прошлом году мы создали софт под заказ, а в этом нас просят модернизировать чужую ИТ-систему, к тому же интегрированную с парочкой внешних систем, разработчики которых уже не существуют в природе и документации к системам не оставили. Пример вполне жизненный.
В такой ситуации, с точки зрения Минцберга — компания будет превращаться в Адхократию (от латинского «Ad hoc» — по запросу»). Системы «созвездий», т.е. самых разных людей самой высокой квалификации буду собираться вместе, чтобы сообща ответить на вызов внешней среды. Руководить ими будет не «начальник-в-кабинете», а, в каком-то смысле, гораздо более близкий к ним человек. Тот, кто не увязает в формализме, способен общаться с каждым членом команды непосредственно и адекватно, при этом не являться специалистом во всех аспектах (это невозможно — деятельность слишком сложная). При этом такой менеджер будет держать в голове глобальную цель и «интегрировать» (т.е. соединять в единое целое) всех участников, добиваться чтобы их усилия по возможности были направлены на общий результат, а не в стиле «лебедя, рака и щуки». Да-да, вот и появился классический менеджер проекта.
Адхократия — власть профессиональных созвездий, Родина менеджера проектов
На что похожа такая структура? Она чем-то напоминает простую, но происхождение ее отлично. Операционное ядро очень значимо (хотя, в некоторых случаях может состоять, скажем, из outsource-команды). Менеджер проекта погружен в него, но в то же время не теряет связи и с вышестоящими руководителями. Менеджерская прослойка сокращается (в ней нет нужды, результат, как и в примере с врачами, создается ниже этажом). Вспомогательный аппарат вливается в менеджера проектов и ядро (в самом деле, как часто менеджер проекта держит руку на пульсе в заключении контрактов, прохождении платежей, выверке соглашений, подписании актов и т.п.?). Стандартизация в полной мере невозможна (иначе она бы давно произошла) и тоже сочетается с работой менеджера проектов и ядра. Здесь всевозможные службы качества, здесь проектные методологии, которые здорово помогают, но никакой панацеей, в отрыве от людей, не являются.
Рисунок 4 — Адхократия
Итак, четыре типа структур. В каждой свое понятие эффективности и конкурентоспособности. Каждая (будьте уверены), публикуя вакансии или формируя штатное расписание, может внести в него ненароком «менеджера проектов». В каждом из четырех типов вы можете обнаружить себя.
Только что, при помощи Г. Минцберга мы сделали большой шаг — свели все компании к четырем основным типам (на самом деле, у автора их чуть больше, но сути это не меняет).
Можем ли мы теперь, как и намеревались, смоделировать обстановку, ожидания и возможный карьерный путь менеджера проектов в каждой из них?
Уверен, определенные соображения у вас уже возникли. Иные — потребуют широких дискуссий. Мне же не остается ничего более, как сообщить тут свое субъективное мнение и поделиться личными наблюдениям за своей и чужими карьерами за последние 10 лет. Сделаю это по возможности кратко и приглашу поделиться собственными примерами в комментариях.
Итак, работа и карьера.
Простые структуры. Их эффективность и конкурентоспособность — это создание (развитие) их основного продукта. Обычно, продукт один (или короткая линейка). Типичный маленький стартап ищет менеджера, готового поверить в продукт. Недосыпать и безо всяких гарантий посвящать всего себя созданию продукта-мечты.
Куда растут менеджеры проектов? Это почти готовые бизнесмены. На мой взгляд, в таких компаниях хорошо людям (по выражению Натальи Касперской «с повышенным уровнем внутренней агрессии»), людям немного авантюрным и нацеленным на творчество, риск и большой успех. Иногда простые структуры выстреливают и пополняют зал славы, а менеджеры — вливаются в ряды пожинающих большой успех (но, кстати, тоже не всегда). Гораздо чаще — простые структуры увядают (такова судьба едва не 99% стартапов). Но очень многие мои знакомые менеджеры, выходцы из таких структур, ищут себя как предприниматели. К тому же умелые менеджеры из простых структур — обычно, очень хорошие продавцы (и порой делают карьеру, дорастая до коммерческих директоров или специалистов по развитию бизнеса).
Механистические бюрократии. Их эффективность и конкурентоспособность — в соблюдении стандартов и регламентов, иногда в «крепком хозяйствовании». Обязательный навык выживания в таких структурах — корпоративная толстокожесть. Умение применять кнут (к подчиненным), ловить политический ветер (от руководства и от быстро поднимающихся коллег), умение находить компромиссы, быть дипломатичным и правильно выбирать сторону в корпоративной «игре престолов». Владение техническими навыками для руководителя, как правило, некритично, ибо с успехом компенсируется специальным менеджерским образованием (MBA и прочие) и локальными регламентами.
Куда растут менеджеры проектов?
Чаще всего это вертикальный рост. На моей практике, механистическими бюрократиями были либо некоторые производственные предприятия, либо крупные структуры с большой долей гос. капитала. Известные мне успешные карьерные истории менеджеров проектов — либо рост в местный топ-менеджмент, либо переход на гос. службу (где приобретенные навыки помогают адаптироваться очень быстро).
Профессиональные бюрократии. Эти компании нацелены на то, чтобы повседневно «делать свое дело». Тут царит абсолютная власть профессионалов, а менеджер в наибольшей степени рискует оказаться бесполезным и бессильным. Можно сказать, что менеджеру-не-выходцу из профессиональной среды освоится в таких фирмах очень трудно. Пытаясь ответить на вопрос «как я повышу эффективность и конкурентоспособность», он, то стремится овладеть нужным набором экспертных знаний, чтобы выдерживать дискуссию коллег (обычно, безуспешно), либо становится «нянькой» своей команде (фактически, уподобляясь вспомогательному осьминогу). С точки зрения руководства (да и менеджера проектов в частности) профессиональная бюрократия часто не выглядит управляемой системой вообще и менеджера кидает в крайность. Он пытается придумать систему контроля, ввести показатели, как-то формализовать работу команды (что, как мы помним, практически невозможно). Отсюда появляются разные извращения. Например, «палочная» система в работе полиции, когда вместо охраны правопорядка успешным считается полицейский, схвативший за месяц нужное количество преступников, лично раскрывший пару преступлений, а также предотвративший 1 ДТП — типичный пример неразумного и нерационального вмешательства менеджмента. Печальные последствия — широко известны. Менеджеры проектов (если не являются выходцами из той же специальности, что и их подчиненные коллеги) — часто быстро выгорают. Выходцы же — нередко чувствуют себя очень комфортно, их роль из руководителя порой превращается просто в «лида» (того самого старшего товарища, мнению которого доверяют). Часто такие менеджеры предпочитают горизонтальный рост.
Адхократии. Эффективность и конкурентоспособность — это выпуск нужного продукта (услуги) в срок заданными ресурсами. Команда адхократии должна превосходить в этом любую другую форму, иначе невозможно оправдать существование такой формы организации (неустойчивой и требующей очень грамотных управленцев). Команда адхократии строится на коммуникациях, в этой форме они особенно дороги. Потому особо важна способность менеджера проектов быть убедительным, внимательным, уверенным в себе, внятным, говорить доходчиво для всех, уметь вскрывать и управлять конфликтами и т.п. При этом, одними разговорами работа не делается, а при большом размере команды (тем более — при работе с распределенной командой) особую важность приобретают методологии. Они должны быть адекватными потребности — сложными настолько, насколько это оправданно, позволять команде видеть реальную ситуацию по проекту, менеджеру — эффективно планировать и контролировать проект, а не пассивно ждать «у моря погоды», и при этом не слишком всех отвлекать от работы. Быть профессионалом во всех тех же областях, что и члены команды менеджеру — не нужно (да и невозможно), куда важнее способность «объединять» команду в единое целое, направлять и поддерживать в стабильном состоянии.
Успешные менеджеры проектов из адхократий растут куда угодно. Кто-то уходит в вертикальный рост (на директорские посты), кто-то перебегает в механистические бюрократии (на мой взгляд, это те, кто по призванию, скорей, «регулярный управленец»), иные со временем переходят в стартап. А кто-то продолжает работать в адхократиях и, постепенно повышает масштаб (от управления проектами переходит к программам и портфелям — а это уже очень серьезная перспектива).
- управление проектами наиболее уместно там, где не получается систематически добиваться хорошего результата
- эффективность и конкурентоспособность — то, что проектное управление должно привносить в компанию
- профессия «менеджера проектов» — не устоявшееся понятие, аспекты карьеры (обязанности, возможности, перспективы) зависят, в том числе, от типа компаний, с которыми конкретный руководитель связывает свою работу
- не во всех компаниях востребованы руководители проектов «в чистом виде»
- переходить между компаниями разных типов для менеджера проектов бывает труднее, чем сменить предметную область
- тип компании определяет не только то, какие качества и навыки с высокой вероятностью вы разовьете через N лет работы, но и то, как рынок в будущем станет вас воспринимать
Все сказанное, на какие бы теории не опиралось, является лишь субъективным мнением и не претендует истину в последней инстанции. За рамками статьи осталось влияние типа компании на подбор проектных методологий, надеюсь, описать это со временем. Буду рад, если статья оказалась полезной.
Как же стать частью компании любого из 4 видов, представленных выше, и успешно внедрить ее методы и навыки в свой рабочий процесс?
Именно об этом я и расскажу на своем вебинаре в среду 12 ноября в 20:00 МСК, который является частью большой онлайн-конференции PRO+ЛЮДЕЙ от Школы менеджеров Стратоплан.
Участие в конференции платное: 980 руб. за 5 мастер-классов. На момент публикации уже >360 человек уже стали участниками.
Вы ничего не пропустите: каждый, купивший билет на Онлайн-Конференции PRO+ЛЮДЕЙ, получит записи всех вебинаров.
Присоединяйтесь и бронируйте вечера следующей недели под себя.
Хорошего дня!
С уважением,
Иван Селиховкин
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий