В части 2 мы узнаем:
- Главный вопрос: Сколько денег?
- “Кладбище проектов”. Хорошие РП не ошибаются?
- А команде РП зачем?
- РП со стороны заказчика. Кто это и зачем нам целых 2 РП?
Мы обсудили в первой части- с чего начать, что поизучать. Самый, наверное, интересный вопрос: сколько можно заработать денег и от чего зависит заработок руководителя проекта?
Сколько можно заработать денег? А сколько можно заработать денег программистом? Смотря, какой ты программист. Можно зарабатывать 50 тысяч, а можно и 500. Очень сильный разбег: в зависимости от того, какой ты программист, как ты устроился, куда устроился и как ты себя продал. И, соответственно, как смог договориться. Так же, наверное, с руководителем проекта может быть по разному. Я бы сказал, что адекватная система оплаты труда должна быть точно привязана к результату. Понятно, что есть и оклад - он всем нужен и всем хочется какой-то стабильности.
И тут вопрос: к какому именно результату привязывать руководителя проекта? К результату проекта в целом? Самый правильный и “прикольный” с точки зрения компании, но вообще “не прикольный” с точки зрения сотрудника. Потому что проект может идти и год и больше, соответственно, год жить без премии (если у нас, например, оклад не очень большую часть составляет, а премия - большую) и ждать, когда проект закончится через год, это может быть очень грустно.
Мы для себя пошли по пути поэтапных закрытий. Этап закончился - руководитель проекта получает премию по этапу, но не всю, а часть откладывается к моменту завершения всего проекта. .И накопительным итогом, когда закончился проект целиком - финальная премия по проекту целиком, которая все это время накапливалась. На мой взгляд - это самая адекватная система.
По деньгам. Ну, наверное, это сильно зависит от профессионализма руководителя проекта; от того, в какой он работает сфере: что он автоматизирует, как ты говоришь - “ларьки” или он заводы какие-то запускает или холдинги гигантские. Или он с какими-нибудь ГОСами или оборонкой работает. Я бы сказал, что доход от 200 тысяч в месяц - это мне кажется вообще нормально, прям минимум, это не много. А реалистично: 300-400-500 в месяц руководителю проекта зарабатывать. И больше.
Я видел руководителей проекта, которые зарабатывают в месяц и 800 тысяч, и 1 000 000 . Но понятно, что это большие сложные проекты: требующие высокой экспертизы, сложные в управлении заказчики и руководители проектов такие виртуозы, которые ходят буквально по какой-то грани между политическими всякими сложными решениями, какими-нибудь неожиданными требованиями, чтобы заказчик и доволен был одновременно и деньги платил и при этом на голову не сел и не начал по голове стучать 🙂. Вот поэтому, РП теоретически можно заработать больше всего: потому что ты влияешь и на бюджет доходов (на то - как эти деньги приходят, на то - как закрываются этапы, как они актируются), и в целом на размер проекта в какой-то степени тоже. Ты говоришь: “ Я могу взять большой проект”, “Я могу взять два проекта одновременно”.
При этом ты влияешь с какой-то стороны и на расходы. У тебя есть команда, ты понимаешь какие зарплаты в этой команде, премии. Ты можешь сказать: “Я не хочу работать с этим программистом: он не результативен, он хочет много денег, но у него очень низкая выработка, он мало делает задач и он плохо их делает, мы потом их переделываем…”
Получается, если ты - РП с полнотой власти в проекте, то ты влияешь и на доходную составляющую и на расходную. И ты можешь этим управлять и, как следствие, влиять на свой доход сильнее других сотрудников. Ну, наверное, за исключением менеджмента компании в целом (собственника там, директоров). Мне кажется, руководитель проекта имеет самое большое влияние на личный доход: когда он уже всё умеет и умеет управлять всеми.
Сколько можно заработать денег? А сколько можно заработать денег программистом? Смотря, какой ты программист. Можно зарабатывать 50 тысяч, а можно и 500. Очень сильный разбег: в зависимости от того, какой ты программист, как ты устроился, куда устроился и как ты себя продал. И, соответственно, как смог договориться. Так же, наверное, с руководителем проекта может быть по разному. Я бы сказал, что адекватная система оплаты труда должна быть точно привязана к результату. Понятно, что есть и оклад - он всем нужен и всем хочется какой-то стабильности.
И тут вопрос: к какому именно результату привязывать руководителя проекта? К результату проекта в целом? Самый правильный и “прикольный” с точки зрения компании, но вообще “не прикольный” с точки зрения сотрудника. Потому что проект может идти и год и больше, соответственно, год жить без премии (если у нас, например, оклад не очень большую часть составляет, а премия - большую) и ждать, когда проект закончится через год, это может быть очень грустно.
Мы для себя пошли по пути поэтапных закрытий. Этап закончился - руководитель проекта получает премию по этапу, но не всю, а часть откладывается к моменту завершения всего проекта. .И накопительным итогом, когда закончился проект целиком - финальная премия по проекту целиком, которая все это время накапливалась. На мой взгляд - это самая адекватная система.
По деньгам. Ну, наверное, это сильно зависит от профессионализма руководителя проекта; от того, в какой он работает сфере: что он автоматизирует, как ты говоришь - “ларьки” или он заводы какие-то запускает или холдинги гигантские. Или он с какими-нибудь ГОСами или оборонкой работает. Я бы сказал, что доход от 200 тысяч в месяц - это мне кажется вообще нормально, прям минимум, это не много. А реалистично: 300-400-500 в месяц руководителю проекта зарабатывать. И больше.
Я видел руководителей проекта, которые зарабатывают в месяц и 800 тысяч, и 1 000 000 . Но понятно, что это большие сложные проекты: требующие высокой экспертизы, сложные в управлении заказчики и руководители проектов такие виртуозы, которые ходят буквально по какой-то грани между политическими всякими сложными решениями, какими-нибудь неожиданными требованиями, чтобы заказчик и доволен был одновременно и деньги платил и при этом на голову не сел и не начал по голове стучать 🙂. Вот поэтому, РП теоретически можно заработать больше всего: потому что ты влияешь и на бюджет доходов (на то - как эти деньги приходят, на то - как закрываются этапы, как они актируются), и в целом на размер проекта в какой-то степени тоже. Ты говоришь: “ Я могу взять большой проект”, “Я могу взять два проекта одновременно”.
При этом ты влияешь с какой-то стороны и на расходы. У тебя есть команда, ты понимаешь какие зарплаты в этой команде, премии. Ты можешь сказать: “Я не хочу работать с этим программистом: он не результативен, он хочет много денег, но у него очень низкая выработка, он мало делает задач и он плохо их делает, мы потом их переделываем…”
Получается, если ты - РП с полнотой власти в проекте, то ты влияешь и на доходную составляющую и на расходную. И ты можешь этим управлять и, как следствие, влиять на свой доход сильнее других сотрудников. Ну, наверное, за исключением менеджмента компании в целом (собственника там, директоров). Мне кажется, руководитель проекта имеет самое большое влияние на личный доход: когда он уже всё умеет и умеет управлять всеми.
А какое, на твой взгляд, должно быть оптимальное соотношение между фиксированной частью (оклад) и премиальной частью?
Между фиксированной и премиальной частью? Хороший вопрос….Я бы сказал, оптимальное - то, о котором договорились. В компании есть своя какая-то политика по выплате зарплат и премий. И есть конкретный человек, у которого есть свои ожидания. Он приходит в компанию: либо они договорились, либо нет. Я бы сказал, по моим ощущениям: 50 процентов от дохода иметь премиальными - для руководителя проекта это хорошо. Мне кажется, это правильно: половину дохода иметь фиксированным окладом, а на половину дохода влиять качеством и продуктивностью своего труда. Ну, может быть, кому-то комфортнее работать полностью с окладом: никаких премий, просто большой оклад и всё. Я уверен, есть такие люди. И, наверное, есть такие компании тоже, которые просто платят оклад без всяких премий, без всего.
Да, спасибо. Такой еще вопрос: мы вначале с тобой говорили - не всем это надо и нужно понять, точно ли надо туда идти ( в руководство проектами). Как человеку определить, собственно: нужно ему это или нет?
Вот есть свой бизнес: кто-то хочет быть предпринимателем, потому что он готов нести эти риски на себе. То есть свой бизнес - это, с одной стороны, теоретическая возможность зарабатывать неограниченное количество денег, а с другой стороны - ты несешь все риски, какие только есть и нет никого, кто тебе что-то гарантирует. Нет у тебя никакой зарплаты: вот сколько заработала компания, вот столько и твоё. И это состояние с одной стороны - неопределенности, с другой - больших возможностей. Поэтому есть люди, офигенно крутые специалисты в своей сфере, которые говорят: “Я никогда не буду заниматься своим бизнесом. Никогда. Потому что я хочу понимать, что у меня такого-то числа зарплата. Такого-то и такого-то числа мне падают денежки на карточку. И пусть они будут меньше, чем я мог бы теоретически заработать где-нибудь когда-нибудь, но зато они точно будут. Я не хочу заниматься своим бизнесом и вот этим вот всем.”
Вот мне кажется, что с руководителем проекта примерно тоже самое: нужно по настоящему прямо хотеть этого. Нужно понимать: “Я хочу приносить пользу людям, я хочу приносить пользу бизнесам.” Если мы говорим про наши проекты, то в конечном итоге мы какую-то пользу предпринимателю приносим, собственнику. То есть собственник решил потратить, скажем, 10 миллионов, потому что он хочет прослеживать себестоимость. Он хочет управленческие отчеты получать моментально: кнопочку нажал и посмотрел, а не попросил и через месяц тебе их принесли. Месяц прошел - ты уже никакие решения не примешь, потому что поздно о чем-то думать. То есть у собственника есть какие-то боли, ради чего он все это дело затеял и почему он решил со своими деньгами расстаться. Потому что он хочет что-то.
И если тебе реально хочется этим бизнесам помогать, ты хочешь помогать им развиваться, хочешь помогать им выстраивать систему управления и видеть результат - да, там люди работают в этой новой системе, разные, в разных отделах, они ей пользуются и им всё нравится в целом ( не всегда всё, но в целом, в основном нравится) ; и компания заказчика полностью “вкатилась” и эта новая система стала их “нервной системой” и теперь является для них неотъемлемой частью: вот если тебе это нравится, ты хочешь этим заниматься и тебе приносит это удовольствие, то ты и деньги будешь зарабатывать. То есть ты сможешь в этой сфере зарабатывать деньги, ты сможешь преодолевать стрессы, ты сможешь бороться с выгоранием. Потому что удовольствие от внедренного успешно проекта, оно всё равно будет тебя подпитывать настолько, что всё вот это вот - какой-то геморрой, ругань, уволившийся посреди проекта программист, заказчик, у которого внезапно поменялся финдир - вот это все будет положительными эмоциями, от ощущения сделанной работы оно будет компенсироваться. И тогда у тебя будут деньги, у тебя будет профессиональный рост, у тебя будут большие проекты. Тебе будет интересно развиваться, учить, учиться.
А если тебе это не приносит радость, то в любом случае накопится усталость, потому что управление проектами - это точно стресс, всегда. Не бывает успешных полностью проектов, которые проходят целиком гладко от начала до конца: какой-бы ни был лапочка-заказчик, какая бы ни была замечательно сработанная команда - все-равно какие-нибудь риски где-нибудь выстрелят. Никогда не бывает так, что все от начала и до конца шло, катилось как по маслу. И если тебя не радует конечный результат, ты будешь уставать-уставать-уставать 😫 и никакие деньги в конце-концов тебе не принесут радости. Получишь ты в конце этого проекта 500 тысяч или миллион бонусами - но ты больше не хочешь их делать, эти проекты. Как бы круто: ты теперь знаешь, как их делать; ты научился; ты знаешь, какие проблемы возникают, какие риски, как с ними работать, ты заработал бабла -но ты больше не хочешь этого делать и теперь тебя это ужасает еще больше, чем в начале…
Мне кажется, это призвание. Просто надо представить себе, как это сложно. Представить себе, как все орут, когда система не запускается или ты ее запустил, а там машины какие-нибудь не могут выехать за ворота или въехать - потому что твоя система вдруг внезапно не работает так, как надо. Представить себе этот стресс и понять: готов ты проходить через это или не готов. Если готов: есть смысл учиться, развиваться, в эту сторону двигаться. Если не готов или ты хочешь такой спокойной работы… Аналитик - это спокойная работа, консультант - тоже в принципе спокойная, программист - спокойная работа; ты делаешь конкретные задачи, ты за эти задачи конкретно и отвечаешь; ну да, может там на тебя техлид поругаться, что ты фигню какую-нибудь сделал или хранилище поломал или еще что-то там … или в пятницу вечером накатилась релиз и у тебя все поломалось…
Но это несравнимо с тем, когда целая компания у тебя сидит на голове, потому что сегодня должны пойти отгрузки, а они не уходят из-за тебя. Это все несопоставимые сложности.
Между фиксированной и премиальной частью? Хороший вопрос….Я бы сказал, оптимальное - то, о котором договорились. В компании есть своя какая-то политика по выплате зарплат и премий. И есть конкретный человек, у которого есть свои ожидания. Он приходит в компанию: либо они договорились, либо нет. Я бы сказал, по моим ощущениям: 50 процентов от дохода иметь премиальными - для руководителя проекта это хорошо. Мне кажется, это правильно: половину дохода иметь фиксированным окладом, а на половину дохода влиять качеством и продуктивностью своего труда. Ну, может быть, кому-то комфортнее работать полностью с окладом: никаких премий, просто большой оклад и всё. Я уверен, есть такие люди. И, наверное, есть такие компании тоже, которые просто платят оклад без всяких премий, без всего.
Да, спасибо. Такой еще вопрос: мы вначале с тобой говорили - не всем это надо и нужно понять, точно ли надо туда идти ( в руководство проектами). Как человеку определить, собственно: нужно ему это или нет?
Вот есть свой бизнес: кто-то хочет быть предпринимателем, потому что он готов нести эти риски на себе. То есть свой бизнес - это, с одной стороны, теоретическая возможность зарабатывать неограниченное количество денег, а с другой стороны - ты несешь все риски, какие только есть и нет никого, кто тебе что-то гарантирует. Нет у тебя никакой зарплаты: вот сколько заработала компания, вот столько и твоё. И это состояние с одной стороны - неопределенности, с другой - больших возможностей. Поэтому есть люди, офигенно крутые специалисты в своей сфере, которые говорят: “Я никогда не буду заниматься своим бизнесом. Никогда. Потому что я хочу понимать, что у меня такого-то числа зарплата. Такого-то и такого-то числа мне падают денежки на карточку. И пусть они будут меньше, чем я мог бы теоретически заработать где-нибудь когда-нибудь, но зато они точно будут. Я не хочу заниматься своим бизнесом и вот этим вот всем.”
Вот мне кажется, что с руководителем проекта примерно тоже самое: нужно по настоящему прямо хотеть этого. Нужно понимать: “Я хочу приносить пользу людям, я хочу приносить пользу бизнесам.” Если мы говорим про наши проекты, то в конечном итоге мы какую-то пользу предпринимателю приносим, собственнику. То есть собственник решил потратить, скажем, 10 миллионов, потому что он хочет прослеживать себестоимость. Он хочет управленческие отчеты получать моментально: кнопочку нажал и посмотрел, а не попросил и через месяц тебе их принесли. Месяц прошел - ты уже никакие решения не примешь, потому что поздно о чем-то думать. То есть у собственника есть какие-то боли, ради чего он все это дело затеял и почему он решил со своими деньгами расстаться. Потому что он хочет что-то.
И если тебе реально хочется этим бизнесам помогать, ты хочешь помогать им развиваться, хочешь помогать им выстраивать систему управления и видеть результат - да, там люди работают в этой новой системе, разные, в разных отделах, они ей пользуются и им всё нравится в целом ( не всегда всё, но в целом, в основном нравится) ; и компания заказчика полностью “вкатилась” и эта новая система стала их “нервной системой” и теперь является для них неотъемлемой частью: вот если тебе это нравится, ты хочешь этим заниматься и тебе приносит это удовольствие, то ты и деньги будешь зарабатывать. То есть ты сможешь в этой сфере зарабатывать деньги, ты сможешь преодолевать стрессы, ты сможешь бороться с выгоранием. Потому что удовольствие от внедренного успешно проекта, оно всё равно будет тебя подпитывать настолько, что всё вот это вот - какой-то геморрой, ругань, уволившийся посреди проекта программист, заказчик, у которого внезапно поменялся финдир - вот это все будет положительными эмоциями, от ощущения сделанной работы оно будет компенсироваться. И тогда у тебя будут деньги, у тебя будет профессиональный рост, у тебя будут большие проекты. Тебе будет интересно развиваться, учить, учиться.
А если тебе это не приносит радость, то в любом случае накопится усталость, потому что управление проектами - это точно стресс, всегда. Не бывает успешных полностью проектов, которые проходят целиком гладко от начала до конца: какой-бы ни был лапочка-заказчик, какая бы ни была замечательно сработанная команда - все-равно какие-нибудь риски где-нибудь выстрелят. Никогда не бывает так, что все от начала и до конца шло, катилось как по маслу. И если тебя не радует конечный результат, ты будешь уставать-уставать-уставать 😫 и никакие деньги в конце-концов тебе не принесут радости. Получишь ты в конце этого проекта 500 тысяч или миллион бонусами - но ты больше не хочешь их делать, эти проекты. Как бы круто: ты теперь знаешь, как их делать; ты научился; ты знаешь, какие проблемы возникают, какие риски, как с ними работать, ты заработал бабла -но ты больше не хочешь этого делать и теперь тебя это ужасает еще больше, чем в начале…
Мне кажется, это призвание. Просто надо представить себе, как это сложно. Представить себе, как все орут, когда система не запускается или ты ее запустил, а там машины какие-нибудь не могут выехать за ворота или въехать - потому что твоя система вдруг внезапно не работает так, как надо. Представить себе этот стресс и понять: готов ты проходить через это или не готов. Если готов: есть смысл учиться, развиваться, в эту сторону двигаться. Если не готов или ты хочешь такой спокойной работы… Аналитик - это спокойная работа, консультант - тоже в принципе спокойная, программист - спокойная работа; ты делаешь конкретные задачи, ты за эти задачи конкретно и отвечаешь; ну да, может там на тебя техлид поругаться, что ты фигню какую-нибудь сделал или хранилище поломал или еще что-то там … или в пятницу вечером накатилась релиз и у тебя все поломалось…
Но это несравнимо с тем, когда целая компания у тебя сидит на голове, потому что сегодня должны пойти отгрузки, а они не уходят из-за тебя. Это все несопоставимые сложности.
Кстати, да: про успешные и неуспешные проекты. Ты вот согласен с мыслью, что у каждого хорошего РП должно быть , есть “кладбище неуспешных проектов”? Или можно прямо со 100-процентной гарантией работать?
Я не верю, что 100-процентная гарантия бывает. И я не верю, что есть руководители проектов, у которых этого кладбища нет. А вопрос в том, что ты после этого кладбища какие-то уроки выносишь. То есть после того, как у тебя проект получился неудачный. Неудачный - это, конечно, не значит, что гонялись за тобой по всему городу с бейсбольной битой. Неудачный проект - может быть, он завершился, система внедрена, акты даже подписаны, даже деньги получены - но клиент говорит “Это было ужасно вообще. Я не хочу больше с вами работать. Я пожалел, что с вами связался. Слава богу, что мы с вами закончили. Больше ко мне никогда не приходите.” Это тоже неудачный проект. Хотя мы акты, деньги, может быть даже прибыль получили. Но проект неудачный, потому что клиент говорит: “Зачем я только начал эту 1С внедрять? Как было раньше хорошо.”
Такие неудачные проекты в большей или меньшей степени есть у всех, по разным причинам. Иногда продали проект клиенту, которому не надо было продавать: и это, кстати, очень частая причина. То есть хотелось сделать проект, продать: продали, начали и застряли. Например, там с самого начала были какие-то маркеры - которые говорили о том, что с этим клиентом дойти до конца будет сложно. Но хотелось денег, хотелось кейс интересный, не было загрузки проектной и поэтому ему продали, начали и потом на середине всё встало, встряло и отношения зашли в тупик. То есть продали не тому - тому, кому не надо было продавать вообще.
Иногда бывает, что со стороны клиента что-то поменялось. Ну я не знаю: поменялся главный заказчик, например: был один IT-директор, а потом посреди проекта другой IT-директор пришел - начал все критиковать, привел свою команду - и как хорошо всё не делай, всё будет плохо всё равно.
Бывает так, что подрядчик накосячил. То есть где-то не додумали, не учли какие-то риски, недоуправляли ими. И проект постепенно превратился в кризисны, но подрядчик это своевременно не понял и не начал какие-то действия предпринимать для того, чтобы его спасти. И соответственно проект, в том числе усилиями подрядчика, зашел в такую ситуацию, откуда его вытащить уже нельзя. То есть накопилась такая масса противоречий, что они, эти противоречия, уже не решаемы
Провальные проекты есть у всех. И у меня они были: лично у меня, когда я руководителем проектов был. И у нас, как у компании, есть проекты, которыми я не горжусь и жаль, что они были. Иногда было лучше не начинать. Иногда было лучше остановиться в какой-то момент. Если есть возможность вернуть какие-нибудь деньги - мы возвращали деньги. Например: если мы видим, что мы застряли на каком-нибудь там этапе обучения и запуска и мы не можем договориться о том, как двигаться дальше - мы иногда передаем всё что есть, все наработки, возвращаем авансы и говорим “Слушайте, мы вам не нравимся, мы это понимаем. Вот вам всё, вот вам назад последние авансы. Вот вам система, вот вам памятки/инструкции. Надумаете продолжить - возвращайтесь, обсудим как продолжить.” По-разному бывает.
Я не верю, что 100-процентная гарантия бывает. И я не верю, что есть руководители проектов, у которых этого кладбища нет. А вопрос в том, что ты после этого кладбища какие-то уроки выносишь. То есть после того, как у тебя проект получился неудачный. Неудачный - это, конечно, не значит, что гонялись за тобой по всему городу с бейсбольной битой. Неудачный проект - может быть, он завершился, система внедрена, акты даже подписаны, даже деньги получены - но клиент говорит “Это было ужасно вообще. Я не хочу больше с вами работать. Я пожалел, что с вами связался. Слава богу, что мы с вами закончили. Больше ко мне никогда не приходите.” Это тоже неудачный проект. Хотя мы акты, деньги, может быть даже прибыль получили. Но проект неудачный, потому что клиент говорит: “Зачем я только начал эту 1С внедрять? Как было раньше хорошо.”
Такие неудачные проекты в большей или меньшей степени есть у всех, по разным причинам. Иногда продали проект клиенту, которому не надо было продавать: и это, кстати, очень частая причина. То есть хотелось сделать проект, продать: продали, начали и застряли. Например, там с самого начала были какие-то маркеры - которые говорили о том, что с этим клиентом дойти до конца будет сложно. Но хотелось денег, хотелось кейс интересный, не было загрузки проектной и поэтому ему продали, начали и потом на середине всё встало, встряло и отношения зашли в тупик. То есть продали не тому - тому, кому не надо было продавать вообще.
Иногда бывает, что со стороны клиента что-то поменялось. Ну я не знаю: поменялся главный заказчик, например: был один IT-директор, а потом посреди проекта другой IT-директор пришел - начал все критиковать, привел свою команду - и как хорошо всё не делай, всё будет плохо всё равно.
Бывает так, что подрядчик накосячил. То есть где-то не додумали, не учли какие-то риски, недоуправляли ими. И проект постепенно превратился в кризисны, но подрядчик это своевременно не понял и не начал какие-то действия предпринимать для того, чтобы его спасти. И соответственно проект, в том числе усилиями подрядчика, зашел в такую ситуацию, откуда его вытащить уже нельзя. То есть накопилась такая масса противоречий, что они, эти противоречия, уже не решаемы
Провальные проекты есть у всех. И у меня они были: лично у меня, когда я руководителем проектов был. И у нас, как у компании, есть проекты, которыми я не горжусь и жаль, что они были. Иногда было лучше не начинать. Иногда было лучше остановиться в какой-то момент. Если есть возможность вернуть какие-нибудь деньги - мы возвращали деньги. Например: если мы видим, что мы застряли на каком-нибудь там этапе обучения и запуска и мы не можем договориться о том, как двигаться дальше - мы иногда передаем всё что есть, все наработки, возвращаем авансы и говорим “Слушайте, мы вам не нравимся, мы это понимаем. Вот вам всё, вот вам назад последние авансы. Вот вам система, вот вам памятки/инструкции. Надумаете продолжить - возвращайтесь, обсудим как продолжить.” По-разному бывает.
Главное - делать выводы. Сделали такой проект, в котором все пошло не так, заказчик не доволен - прям садиться разбирать, не жалея себя Разбирать без пощады к себе: “А что можно было сделать? Где надо было принять какие-то решения? И что нам нужно изменить - в подходе к клиенту, к продаже, к управлению, к рискам, к работе с командой, к работе с заинтересованными сторонами в проекте - чтобы в следующий раз такого не допустить?”
И вот эта вот рефлексия - это, наверное, самое главное. Кстати, очень “прошаренные” клиенты, которые выбирают, с кем проект делать, они всегда спрашивают про “кладбище проектов”, всегда спрашивают про неудачные проекты. И не для того, чтобы сказать “О, у вас были неудачные проекты?” А как раз для того, чтобы потом спросить: “Ну и какие выводы вы из этого сделали?” Это прямо прикольный вопрос, который говорит о том, что клиент такой супер образованный. То есть он подходит к выбору подрядчика очень осознанно.
Если ты можешь сказать, какие ты из этого сделал выводы - ты молодец. Если ты говоришь: “У нас нет таких проектов. У нас всегда всё хорошо” - значит, обманываешь.
Значит, есть что скрывать...
Да-да!
ОК, спасибо. Хотела еще вопрос задать, тоже от читателя, Василия. “При каких условиях нужен РП и что команда получит при его наличии?” Вот именно со стороны команды?
При каких условиях нужен РП? Ну, я бы сказал, что есть РП - как роль, а есть РП - как человек, как должность. Если у нас есть проект… А проект - это что такое? Проект - это деятельность, направленная на создание уникального результата с ограниченными ресурсами в ограниченное время. Да? То есть это не просто какая-то куча задач, которые мы делаем - а это какая-то уникальная деятельность, направленная на создание уникального результата. Вот это - проект. И если у нас есть проект - нам нужен руководитель проекта.
Другое дело, что роль руководителя проекта может исполнять не отдельный человек. Очень часто в небольших проектах роль руководителя проекта совмещена с ролью аналитика. То есть то же, кто снимает задачу и потом пишет требования - он же как бы и руководит этим процессом. Потому что всё равно кто-то должен сделать план.
Даже в маленьком проекте, даже в очень простом проекте есть последовательность действий, которые необходимо осуществить для того, чтобы было всё правильно: ну, глупо сначала загрузить данные, а потом сделать доработки. А потом понять, что доработки, которые мы сделали - они требуют других данных и теперь данные надо загружать заново. Теперь мы все это сделали, а потом пойдем к клиенту и спросим у него, а чего же он хотел? - и будем описывать требования.
Все равно есть последовательность шагов.
Этот план должен кто-то сделать. Кто-то должен сделать план запуска самого. Да, сам запуск - это тоже мероприятие. Оно не очень длинное (ночь или выходные), но у него есть план:
Это тоже план. Кто-то должен этот план сделать. Кто-то должен следить, что мы по этому плану идем, что мы эту задачу сделали. Нам заказчик пообещал прислать файлики до конца недели, мы ему напомнили десять раз, он нам прислал эти файлики, мы их проверили - не те файлики он прислал, мы его поправили, сказали - что он сделал не то…Всё равно есть работа по планированию, по контролю выполнения этого плана. И всё равно есть работа с рисками, есть работа с заказчиком и с его ожиданиями, есть работа с командой, даже если там полтора человека всего.
Просто в каких-то случаях эту роль выполняет кто-то из команды. Программист - супер организованный, который не боится людей, не боится разговаривать, умеет писать требования, умеет программировать (ну типа как ты, Настя, да?🤓) - он может выполнять работу РП, в целом. То есть у него есть такая роль. Он часть времени программирует, часть времени он пишет, часть времени он с заказчиком общается, пытается понять что заказчику надо, часть времени он ему сдает эту работу. А часть времени он думает о том, какой дальше шаг сделать, чтобы этот проект у нас закончился. Поэтому мне кажется, что роль РП, роль руководителя проекта всегда есть.
А вот когда нужно выделить отдельного человека, который занимается только руководством проектами, ну вот это уже зависит от масштабов проектов, от того - сколько сотен или тысяч человеко-часов в этом проекте, от того - насколько сложный компания-заказчик.
Если компания-заказчик - это какой-нибудь там холдинг (там бюрократия, там куча отделов; там куча лиц, принимающих решения - там вот это все; там такая связь между ними запутанная и есть разные люди, у них у всех разные интересы и все эти интересы - они пересекаются друг с другом и все по-разному влияют на проект - нам точно нужен РП, сразу отдельный человек. Потому что мы этот проект не запустим. Нам надо заниматься политикой, надо заниматься управлением. И я не думаю, что какой-нибудь программист или аналитик будет в восторге от того, что ему каждый день нужно будет ходить на статусы и там, как ужу на сковородке, лавировать между разными заинтересованными сторонами, каждый из которых тянет этот проект на себя, как эти одеяла. И надо, чтобы и одеяло не порвалось и все были в тепле при этом 😁
Если компания заказчика простая, понятная и легко управляется, проект легко идет, заказчику самому очень надо и он ответственный, он быстро делает задачи, которые ему сказали сделать, то можно вести проект без выделения отдельного человека. Но всё равно такая роль есть. Всё равно кто-то отвечает за конечный результат.
Ну и соответственно (отвечая на вопрос “ а что команде то от этого?”): а кто отвечает за результат? То есть: есть команда, в команде есть (ну не знаю) два аналитика, два программиста и один консультант. А кто отвечает за то, что проект будет сделан или нет? Кто отвечает за конечный результат? Все вместе? - Ну, я не верю. Если проект будет не запущен и к нам приедет заказчик со словами:
И вот эта вот рефлексия - это, наверное, самое главное. Кстати, очень “прошаренные” клиенты, которые выбирают, с кем проект делать, они всегда спрашивают про “кладбище проектов”, всегда спрашивают про неудачные проекты. И не для того, чтобы сказать “О, у вас были неудачные проекты?” А как раз для того, чтобы потом спросить: “Ну и какие выводы вы из этого сделали?” Это прямо прикольный вопрос, который говорит о том, что клиент такой супер образованный. То есть он подходит к выбору подрядчика очень осознанно.
Если ты можешь сказать, какие ты из этого сделал выводы - ты молодец. Если ты говоришь: “У нас нет таких проектов. У нас всегда всё хорошо” - значит, обманываешь.
Значит, есть что скрывать...
Да-да!
ОК, спасибо. Хотела еще вопрос задать, тоже от читателя, Василия. “При каких условиях нужен РП и что команда получит при его наличии?” Вот именно со стороны команды?
При каких условиях нужен РП? Ну, я бы сказал, что есть РП - как роль, а есть РП - как человек, как должность. Если у нас есть проект… А проект - это что такое? Проект - это деятельность, направленная на создание уникального результата с ограниченными ресурсами в ограниченное время. Да? То есть это не просто какая-то куча задач, которые мы делаем - а это какая-то уникальная деятельность, направленная на создание уникального результата. Вот это - проект. И если у нас есть проект - нам нужен руководитель проекта.
Другое дело, что роль руководителя проекта может исполнять не отдельный человек. Очень часто в небольших проектах роль руководителя проекта совмещена с ролью аналитика. То есть то же, кто снимает задачу и потом пишет требования - он же как бы и руководит этим процессом. Потому что всё равно кто-то должен сделать план.
Даже в маленьком проекте, даже в очень простом проекте есть последовательность действий, которые необходимо осуществить для того, чтобы было всё правильно: ну, глупо сначала загрузить данные, а потом сделать доработки. А потом понять, что доработки, которые мы сделали - они требуют других данных и теперь данные надо загружать заново. Теперь мы все это сделали, а потом пойдем к клиенту и спросим у него, а чего же он хотел? - и будем описывать требования.
Все равно есть последовательность шагов.
- Мы сначала снимаем задачу в каком-то виде, описываем требования,подбираем программный продукт,
- Настраиваем (то, что можно настроить) типовое, дорабатываем ( то, что нельзя настроить) типовое доработками.
- Понимаем, как должны выглядеть справочники. Понимаем: откуда их взять, как их загрузить, перенести из файликов, из другой системы. Загружаем, проверяем.
- Делаем инструкции, обучаем пользователей,
- Запускаем систему, поддерживаем пользователей в новой системе, пока они не научатся в ней нормально работать.
Этот план должен кто-то сделать. Кто-то должен сделать план запуска самого. Да, сам запуск - это тоже мероприятие. Оно не очень длинное (ночь или выходные), но у него есть план:
- мы в пятницу вечером выключаем старую систему,
- снимаем копию, выгружаем, загружаем, разворачиваем,
- создаем пользователей; под всеми пользователями заходим, проверяем что у всех всё работает,
- выкладываем новую систему на сервер,
- раскидываем всем доступы к новой системе.
Это тоже план. Кто-то должен этот план сделать. Кто-то должен следить, что мы по этому плану идем, что мы эту задачу сделали. Нам заказчик пообещал прислать файлики до конца недели, мы ему напомнили десять раз, он нам прислал эти файлики, мы их проверили - не те файлики он прислал, мы его поправили, сказали - что он сделал не то…Всё равно есть работа по планированию, по контролю выполнения этого плана. И всё равно есть работа с рисками, есть работа с заказчиком и с его ожиданиями, есть работа с командой, даже если там полтора человека всего.
Просто в каких-то случаях эту роль выполняет кто-то из команды. Программист - супер организованный, который не боится людей, не боится разговаривать, умеет писать требования, умеет программировать (ну типа как ты, Настя, да?🤓) - он может выполнять работу РП, в целом. То есть у него есть такая роль. Он часть времени программирует, часть времени он пишет, часть времени он с заказчиком общается, пытается понять что заказчику надо, часть времени он ему сдает эту работу. А часть времени он думает о том, какой дальше шаг сделать, чтобы этот проект у нас закончился. Поэтому мне кажется, что роль РП, роль руководителя проекта всегда есть.
А вот когда нужно выделить отдельного человека, который занимается только руководством проектами, ну вот это уже зависит от масштабов проектов, от того - сколько сотен или тысяч человеко-часов в этом проекте, от того - насколько сложный компания-заказчик.
Если компания-заказчик - это какой-нибудь там холдинг (там бюрократия, там куча отделов; там куча лиц, принимающих решения - там вот это все; там такая связь между ними запутанная и есть разные люди, у них у всех разные интересы и все эти интересы - они пересекаются друг с другом и все по-разному влияют на проект - нам точно нужен РП, сразу отдельный человек. Потому что мы этот проект не запустим. Нам надо заниматься политикой, надо заниматься управлением. И я не думаю, что какой-нибудь программист или аналитик будет в восторге от того, что ему каждый день нужно будет ходить на статусы и там, как ужу на сковородке, лавировать между разными заинтересованными сторонами, каждый из которых тянет этот проект на себя, как эти одеяла. И надо, чтобы и одеяло не порвалось и все были в тепле при этом 😁
Если компания заказчика простая, понятная и легко управляется, проект легко идет, заказчику самому очень надо и он ответственный, он быстро делает задачи, которые ему сказали сделать, то можно вести проект без выделения отдельного человека. Но всё равно такая роль есть. Всё равно кто-то отвечает за конечный результат.
Ну и соответственно (отвечая на вопрос “ а что команде то от этого?”): а кто отвечает за результат? То есть: есть команда, в команде есть (ну не знаю) два аналитика, два программиста и один консультант. А кто отвечает за то, что проект будет сделан или нет? Кто отвечает за конечный результат? Все вместе? - Ну, я не верю. Если проект будет не запущен и к нам приедет заказчик со словами:
“Возвращайте все деньги назад, вообще всё отвратительно и ещё мы на вас сейчас в суд подадим, потому что мы издержки понесли” (а заказчики это любят).
Не просто “верните нам все авансы" а мы еще и пострадали от вас, мы кучу денег потратили где-то там параллельно (мы вам про это не говорили, но теперь мы вам про это скажем)”. Кто будет работать? Кто будет с этим заказчиком разговаривать? Программист? То есть кто отвечает за неудачный результат, за отсутствие результата?
Если все хорошо и заказчик говорит “какие вы молодцы ребята, какие вы клевые” - все поделят успех проекта между собой с радостью. А кто будет отвечать, если все плохо? Все равно какой-то есть старший, ответственный. Может быть - это самый старый сотрудник в команде. Может быть - самый опытный, который так или иначе эту роль на себя берет и ее выполняет, может быть, даже неосознанно. Мне кажется, что команде от этого только польза.
Не хотят люди в команде, исполнители (исполнители - это не плохое слово, это нормальное слово: хороший разработчик, хороший архитектор, хороший аналитик или консультант по какой-то сфере): они не хотят нести ответственность и тратить свое драгоценное время, вместо того, чтобы делать интересную задачу - полдня сидеть на зуме с заказчиком и выслушивать недовольного бухгалтера. Кто это будет делать? Кто будет потом объяснять заказчику, что не надо делать все, что они сказали; что это помешает проекту, растянет сроки, растянет бюджеты, “давайте мы это отложим”? То есть команда отгораживается от этой административной работы, от управленческой работы и делает то, в чем каждый является специалистом, в чем каждый профессионал.
Ок. Если мы говорим не про консалтинг. А, допустим, у нас IT-отдел в штате, мы внедряем 1С (может, даже с подрядчиком каким-нибудь, а не своими силами): как понять, нужен ли нам РП? Вот именно свой, со стороны заказчика, как выделенный человек.
Слушай, ну вообще нормальный подрядчик всегда скажет: “А кто будет руководителем проекта у заказчика? Кто будет РПЗ? И он попросит этого РПЗ предъявить. То есть РПЗ нужен точно.
Почему нужен руководитель проекта от заказчика? Потому что на стороне клиента есть своя работа. Как бы мы ни хотели, как бы клиент ни хотел… Но работать в парадигме “ я вам деньги отдам, а теперь ну все: я ж вам заплатил - просто принесите мне через полгода систему, которая работает ” не получится.
Есть задачи, которые клиент должен делать. Сначала нужно приходить (ну не знаю, если это большой проект) на интервью. То есть это какие-то серии интервью, куда приходят какие-то рабочие группы ( закупщики там, продажники, РОПы, кладовщики, руководители отделов). Они приходят на какие-то интервью, они отвечают на вопросы, они спорят - как надо делать лучше. Кто-то должен организовать эти интервью. То есть понятно, что мы - как исполнители - мы даем график какой-то, табличку. И говорим что “нам нужно пообщаться с продавцами, потом с закупщиком, с кладовщиками, потом с этими, с этими, с этими…” Но кто их соберет? Кто скажет: “Так, ребята: вы пойдете 15-го, вы пойдете 16-го, вы пойдете 21-го…”? Кто-то должен их организовать.
И мы не можем это сделать - потому что у нас нет власти внутри компании. Мы не можем прийти и сказать: “Василий Иванович, вот 15-го числа Вы свою работу оставьте, пожалуйста, и 4 часа мы Вас будем мучать с утра.” Это - часть работы РПЗ: организовать, чтобы на эти интервью люди пришли; потом (ну, я не знаю) организовать прочтение документов (документы надо читать, их надо утверждать) . Как у нас бывает: один отдел внес одни правки, другой отдел внес другие правки и эти правки - они диаметрально противоположны🤔 Невозможно сделать одновременно и так и так, надо выбрать как делать. Кто-то должен внутри заказчика решить, как правильно: вот этот вариант или этот вариант или вообще какой-то третий?
А для этого нужно что:
Можем мы это сделать вместо клиента? Ну, теоретически, конечно - если нам дадут такие права, командовать внутри компании заказчика - мы можем. Но вряд ли заказчик захочет, чтобы мы пришли и начали там командовать, кого-то выдергивать из работы и вот это вот всё организовывать. Это всё тоже работа РПЗ, тоже работа руководителя проекта от заказчика.
И в общем-то достаточно много таких организационных моментов, которые находятся внутри компании-клиента. На которые нам сложно повлиять, потому что мы не сотрудники и мы не имеем ни формальной, ни неформальной власти, полномочий кому-то там приказывать и тем более кому-то указывать. И какие-то собирать совещания, требовать каких-то решений и так далее.
Мы всегда помогаем РПЗ. Мы рассказываем ему: что он должен сделать, зачем и почему это важно. То есть мы его не бросаем, типа “ты РПЗ - вот давай свою часть работы делай”. Мы рассказываем ему, что нужно делать и зачем. И почему документы надо читать, как их читать. Но все равно эта роль и такая должность - она есть.
Это обычно кто-то из топов, руководителей ? Кто это по позиции в команде?
Здесь очень по разному бывает. Бывает РПЗ - ну например, главбух. Мы не очень любим такое, если это не бухгалтерский проект (проект внедрения бухгалтерии). Мы не очень любим главбухов в качестве РПЗ по ряду причин. Но бывает успешно в целом, бывает успешный опыт. Бывает РПЗ - IT-директор или IT-менеджер. Бывает РПЗ - финдир или коммерческий директор. Чаще всего - это кто-то из руководства -линейного руководства или высшего руководства - потому что у рядового человека может просто не хватать власти, ему власть нужна внутри компании и ему просто ее не хватает.
Плохой РПЗ, например, гендир - у него власти достаточно, а времени нету (смеется): времени во всем этом разбираться, погружаться и читать у него нет. Поэтому лучше у нас так бывает, что клиент на пресейле говорит (гендир говорит): “Мне нужен этот проект. Я буду вашим руководителем проекта.” Мы всегда отговариваем: “Давайте мы будем просто Вас звать, когда это важно. Но Вы кого-то назначьте, пожалуйста. Потому что у Вас просто физически не будет времени и желания во всё это погружаться.” Мы же понимаем, что у гендира есть другая работа. Обычно кто-то из руководителей.
Конечно, здорово, если IT-директор. IT-директор может быть хорошим РПЗ. Особенно если у него есть опыт именно проектной работы ( он понимает в целом, как проект построен), то вообще получается близкое к идеальному взаимодействие.
ОК, спасибо. Наверное, финальный вопрос: может, ты хочешь что-то по теме добавить, о чем я не спросила? Либо какое-то дать напутствие?
- Слушай, мы так подробно обо всем пообщались. Я даже не знаю, что еще можно добавить по теме руководства проектами. Но наверное, я еще раз “подсвечу” тот момент, что, конечно - руководитель проекта может зарабатывать много денег - но идти в профессию только ради денег смысла нет. Точно можно заработать много денег более простыми путями и менее нервными. Руководитель проекта - это такая нервная работа, которая сопряжена с постоянным стрессом. И чем больше проект, чем больше заказчик и, как следствие, чем больше потенциальное вознаграждение финансовое где-то в итоге - тем эти стрессы серьезнее. Потому что риски гораздо выше и люди, с которыми предстоит общаться и работать - они гораздо серьезнее и сложнее, они требовательнее. И, соответственно, работая в проекте в каком-нибудь холдинге (где проект будет стоить 50 млн или 150 млн или 250 млн) -нагрузка на руководителя проектов, именно эмоциональная - огромная.
Это такая очень серьезно нагруженная работа. И заниматься этим стоит, если вы реально хотите управлять проектами, вам это интересно. Вам прям круто, нравится придумывать - как получится вот это цельное из кусочков и как к этому прийти - то есть вас реально “зажигает” эта работа. Тогда есть смысл туда идти и двигаться.
А если вы этого не хотите - вы боитесь людей, боитесь ответственности, вы не хотите на себе вот это вот всё тащить (сотрудников - которые могут заболевать, увольняться, проваливать задачи; клиентов - которые могут игнорить свои задачи, быть недовольными, быть в плохом настроении) - просто представьте себе всё вот это вот: хотите вы нести это все на себе или нет? Если не пугает - то добро пожаловать в проектное управление 😁
Супер, Алексей. Спасибо. Было очень интересно 🙂
Было весело🙂 Спасибо, Настя.
Не просто “верните нам все авансы" а мы еще и пострадали от вас, мы кучу денег потратили где-то там параллельно (мы вам про это не говорили, но теперь мы вам про это скажем)”. Кто будет работать? Кто будет с этим заказчиком разговаривать? Программист? То есть кто отвечает за неудачный результат, за отсутствие результата?
Если все хорошо и заказчик говорит “какие вы молодцы ребята, какие вы клевые” - все поделят успех проекта между собой с радостью. А кто будет отвечать, если все плохо? Все равно какой-то есть старший, ответственный. Может быть - это самый старый сотрудник в команде. Может быть - самый опытный, который так или иначе эту роль на себя берет и ее выполняет, может быть, даже неосознанно. Мне кажется, что команде от этого только польза.
Не хотят люди в команде, исполнители (исполнители - это не плохое слово, это нормальное слово: хороший разработчик, хороший архитектор, хороший аналитик или консультант по какой-то сфере): они не хотят нести ответственность и тратить свое драгоценное время, вместо того, чтобы делать интересную задачу - полдня сидеть на зуме с заказчиком и выслушивать недовольного бухгалтера. Кто это будет делать? Кто будет потом объяснять заказчику, что не надо делать все, что они сказали; что это помешает проекту, растянет сроки, растянет бюджеты, “давайте мы это отложим”? То есть команда отгораживается от этой административной работы, от управленческой работы и делает то, в чем каждый является специалистом, в чем каждый профессионал.
Ок. Если мы говорим не про консалтинг. А, допустим, у нас IT-отдел в штате, мы внедряем 1С (может, даже с подрядчиком каким-нибудь, а не своими силами): как понять, нужен ли нам РП? Вот именно свой, со стороны заказчика, как выделенный человек.
Слушай, ну вообще нормальный подрядчик всегда скажет: “А кто будет руководителем проекта у заказчика? Кто будет РПЗ? И он попросит этого РПЗ предъявить. То есть РПЗ нужен точно.
Почему нужен руководитель проекта от заказчика? Потому что на стороне клиента есть своя работа. Как бы мы ни хотели, как бы клиент ни хотел… Но работать в парадигме “ я вам деньги отдам, а теперь ну все: я ж вам заплатил - просто принесите мне через полгода систему, которая работает ” не получится.
Есть задачи, которые клиент должен делать. Сначала нужно приходить (ну не знаю, если это большой проект) на интервью. То есть это какие-то серии интервью, куда приходят какие-то рабочие группы ( закупщики там, продажники, РОПы, кладовщики, руководители отделов). Они приходят на какие-то интервью, они отвечают на вопросы, они спорят - как надо делать лучше. Кто-то должен организовать эти интервью. То есть понятно, что мы - как исполнители - мы даем график какой-то, табличку. И говорим что “нам нужно пообщаться с продавцами, потом с закупщиком, с кладовщиками, потом с этими, с этими, с этими…” Но кто их соберет? Кто скажет: “Так, ребята: вы пойдете 15-го, вы пойдете 16-го, вы пойдете 21-го…”? Кто-то должен их организовать.
И мы не можем это сделать - потому что у нас нет власти внутри компании. Мы не можем прийти и сказать: “Василий Иванович, вот 15-го числа Вы свою работу оставьте, пожалуйста, и 4 часа мы Вас будем мучать с утра.” Это - часть работы РПЗ: организовать, чтобы на эти интервью люди пришли; потом (ну, я не знаю) организовать прочтение документов (документы надо читать, их надо утверждать) . Как у нас бывает: один отдел внес одни правки, другой отдел внес другие правки и эти правки - они диаметрально противоположны🤔 Невозможно сделать одновременно и так и так, надо выбрать как делать. Кто-то должен внутри заказчика решить, как правильно: вот этот вариант или этот вариант или вообще какой-то третий?
А для этого нужно что:
- Собрать совещание, посадить представителей одного отдела, другого отдела и кого-то из руководства.
- Обозначить, что у нас есть такая проблема: закупщики хотят так, продавцы хотят так - давайте решим как делать.
- Организовать эту встречу, эту проблему решить и решение до нас, как до подрядчика, донести.
Можем мы это сделать вместо клиента? Ну, теоретически, конечно - если нам дадут такие права, командовать внутри компании заказчика - мы можем. Но вряд ли заказчик захочет, чтобы мы пришли и начали там командовать, кого-то выдергивать из работы и вот это вот всё организовывать. Это всё тоже работа РПЗ, тоже работа руководителя проекта от заказчика.
И в общем-то достаточно много таких организационных моментов, которые находятся внутри компании-клиента. На которые нам сложно повлиять, потому что мы не сотрудники и мы не имеем ни формальной, ни неформальной власти, полномочий кому-то там приказывать и тем более кому-то указывать. И какие-то собирать совещания, требовать каких-то решений и так далее.
Мы всегда помогаем РПЗ. Мы рассказываем ему: что он должен сделать, зачем и почему это важно. То есть мы его не бросаем, типа “ты РПЗ - вот давай свою часть работы делай”. Мы рассказываем ему, что нужно делать и зачем. И почему документы надо читать, как их читать. Но все равно эта роль и такая должность - она есть.
Это обычно кто-то из топов, руководителей ? Кто это по позиции в команде?
Здесь очень по разному бывает. Бывает РПЗ - ну например, главбух. Мы не очень любим такое, если это не бухгалтерский проект (проект внедрения бухгалтерии). Мы не очень любим главбухов в качестве РПЗ по ряду причин. Но бывает успешно в целом, бывает успешный опыт. Бывает РПЗ - IT-директор или IT-менеджер. Бывает РПЗ - финдир или коммерческий директор. Чаще всего - это кто-то из руководства -линейного руководства или высшего руководства - потому что у рядового человека может просто не хватать власти, ему власть нужна внутри компании и ему просто ее не хватает.
Плохой РПЗ, например, гендир - у него власти достаточно, а времени нету (смеется): времени во всем этом разбираться, погружаться и читать у него нет. Поэтому лучше у нас так бывает, что клиент на пресейле говорит (гендир говорит): “Мне нужен этот проект. Я буду вашим руководителем проекта.” Мы всегда отговариваем: “Давайте мы будем просто Вас звать, когда это важно. Но Вы кого-то назначьте, пожалуйста. Потому что у Вас просто физически не будет времени и желания во всё это погружаться.” Мы же понимаем, что у гендира есть другая работа. Обычно кто-то из руководителей.
Конечно, здорово, если IT-директор. IT-директор может быть хорошим РПЗ. Особенно если у него есть опыт именно проектной работы ( он понимает в целом, как проект построен), то вообще получается близкое к идеальному взаимодействие.
ОК, спасибо. Наверное, финальный вопрос: может, ты хочешь что-то по теме добавить, о чем я не спросила? Либо какое-то дать напутствие?
- Слушай, мы так подробно обо всем пообщались. Я даже не знаю, что еще можно добавить по теме руководства проектами. Но наверное, я еще раз “подсвечу” тот момент, что, конечно - руководитель проекта может зарабатывать много денег - но идти в профессию только ради денег смысла нет. Точно можно заработать много денег более простыми путями и менее нервными. Руководитель проекта - это такая нервная работа, которая сопряжена с постоянным стрессом. И чем больше проект, чем больше заказчик и, как следствие, чем больше потенциальное вознаграждение финансовое где-то в итоге - тем эти стрессы серьезнее. Потому что риски гораздо выше и люди, с которыми предстоит общаться и работать - они гораздо серьезнее и сложнее, они требовательнее. И, соответственно, работая в проекте в каком-нибудь холдинге (где проект будет стоить 50 млн или 150 млн или 250 млн) -нагрузка на руководителя проектов, именно эмоциональная - огромная.
Это такая очень серьезно нагруженная работа. И заниматься этим стоит, если вы реально хотите управлять проектами, вам это интересно. Вам прям круто, нравится придумывать - как получится вот это цельное из кусочков и как к этому прийти - то есть вас реально “зажигает” эта работа. Тогда есть смысл туда идти и двигаться.
А если вы этого не хотите - вы боитесь людей, боитесь ответственности, вы не хотите на себе вот это вот всё тащить (сотрудников - которые могут заболевать, увольняться, проваливать задачи; клиентов - которые могут игнорить свои задачи, быть недовольными, быть в плохом настроении) - просто представьте себе всё вот это вот: хотите вы нести это все на себе или нет? Если не пугает - то добро пожаловать в проектное управление 😁
Супер, Алексей. Спасибо. Было очень интересно 🙂
Было весело🙂 Спасибо, Настя.
