Пришло время для самого важного вопроса, встающего перед каждым Руководителем проектов, решающим сменить работу: «Куда мне лучше пойти работать?».

Выбор большой: продукт или ИТ услуги? ИТ услуги в роли Заказчика внутри большой компании или в интеграторе/консультанте в роли Исполнителя? Большая компания, где большая зарплата, соцпакет, стабильность и спортзал или маленький стартап, где хаос, ничего нет, но через пару лет обещают золотые горы?

Эта статья - продолжение предыдущей «Какие бывают Руководители проектов в разных компаниях», где разобрали чем отличается РП в продукте, внутреннем ИТ и внешнем ИТ.
В этой разберем чем отличаются большие компании от маленьких, и так уж ли важно идти в Большую компанию с Модным названием? Ну и, наконец, получим ответ на вопрос: "А куда пойти?"

Это очередная (но важная) статья для Руководителей проектов о том, «как делать хорошо», когда что такое «хорошо» вам никто не объясняет. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Для начала, что делает человек, когда ему приходит мысль сменить работу:

Куда можно пойти поработать, если вы – Руководитель проектов? Есть много сладких названий: Яндекс, Тинькоф, Сбер, Авито, ВК. Есть еще Газ-Нефть-Полиметал-Тех-сырье компании, есть просто ИТ подразделения не ИТ компаний типа Магнита или Технониколь. Есть еще системные интеграторы Т1, IBS, Softline и так далее. Есть ли среди всей этой карусели отличия, и что вы получите, работая в каждой, кроме того что сможете сказать «Я работал в /Name/?

Эта статья посвящена тому, чем работа Руководителя проектов буде отличаться в разных компаниях. Прочитав ее, вы сможете для себя понять, куда лучше пойти, чтобы получить тот опыт, который вы хотите получить, а куда лучше не ходить.

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Статья не претендует на 100% знание истины (опыт у каждого свой), но основана на личном опыте автора, который поработал во многих компаниях, прошел больше сотни собеседований сам и прособеседовал не менее нескольких сотен Руководителей проектов из разных компаний.

Руководитель проекта должен любить людей. И любить с людьми общаться. Потому что к только вы становитесь Руководителем проектов, вам нужно начинать говорить с кучей народа: с командой – это минимум несколько человек, с заказчиками – это тоже часто несколько человек. Еще есть линейный руководитель, руководители команды, руководители заказчиков, релиз менеджеры, инженеры поддержки, внешние эксперты - короче, если вы не любите разговаривать с людьми, если долгое общение вас сильно утомляет, лучше всерьез подумать о какой-то другой работе.

Неопытному руководителю очень просто запутаться в этом треше из созвонов, чатов в Телеге, писем в почте и устных договоренностей. Эта статья поможет распутаться: понять, какие есть каналы коммуникаций и как ими пользоваться.

Действительно ли надо всегда звонить, а не писать письмо? Какие еще есть варианты?

Как правильно и экологично проводить встречи?

Как не превращать встречи в ППР?

Обо всем этом коротко ниже.

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Каждый РП рано или поздно меняет работу. Вы уходите со старого места, где вы уже хорошо ориентируетесь, и приходите в неизвестность:

- неизвестный проект с неизвестными рисками;

- непонятный руководитель (при первом знакомстве он душка, но какой будет в реале?);

- непонятные коллеги;

- непонятный заказчик.

Причем, как правило, проект, который вам отдают, уже несется на всех парах: команда пашет, заказчик чего-то хочет, у нового руководителя какие-то ожидания. И хорошо, если все так просто. А часто случается, что проект уже летит в бездну, бюджет израсходован, заказчик всех ненавидит, а руководство ждет от вас сдачи на следующей неделе (да, такие случаи тоже бывали 😊).

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть. Ну и на все про все у вас примерно 2 недели. 4 от силы, если место ванильное, и поезд еще не разогнался.

Как не свернуть шею и не попасть под колеса на этом славном пути – по пунктам ниже

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

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

Вам придется научиться формулировать вашу проблему определенным образом, чтобы получать результат. Как это делать - под катом.

Это очередная статья о том, чего не расскажут на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Для начинающих Руководителей проектов часто становится новостью, что у них не только новая звонкая должность (руководитель!), зарплата и премия, но и неприятная обязанность отвечать вообще за все неприятности на вверенном проекте.

Эта статья – очередная из цикла статей о том, чего не говорят на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории - читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

То есть я теперь отвечаю не только за себя, но и за тех, кто, вроде бы, сам за себя отвечать должен:

• сотрудник обещал сделать, и не сделал – крайний РП;

• заказчик не сформулировал нормально требования, а теперь не хочет принимать работы – виноват РП;

• руководитель ругается, что работы не сделаны в срок, хотя именно он месяц не согласовывал начало работ – виноват РП;

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

Бывает такое, что на проекте произошла неприятность, требующая немедленного извещения вашего руководителя или Заказчика, а те не отвечают? А время идет и вы понимаете, что в бездействии обвинят вас, РП, ведь именно вы должны были всех оповестить. Что делать в этой ситуации?

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

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

Статья навеяна вот этой статьей на Хабре: https://habr.com/ru/articles/846700/ (почему не надо оставлять честную обратную связь).

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

Руководителя винить здесь бесполезно: руководитель - не штатный психолог компании, он не папка (или не мамка) сотрудникам, который должен учить их жизни, лечить и помогать. Нет. Все, что надо руководителю – это выполнить цели компании, и чтобы команда не разбежалась после этого. Это все. Руководитель не отвечает за моральное и психологическое состояние сотрудников. Это ответственность самих сотрудников**

Но как правильно отвечать на давление? Как правильно и, как сейчас модно говорить, экологично отвечать, когда вы чувствуете, что вас используют, не предлагая ничего стоящего взамен?

Вот про это и предлагаю поговорить ниже.

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

Почему так получается? Что, на ИТ проектах вообще нет рисков, только одни проблемы? Или работать с рисками надо начиная с определенного уровня проекта?

Давайте разберемся с рисками.

Эта статья – часть цикла статей о том, чего обычно не рассказывают на курсах РП и до чего я дошел сам, наступая на многочисленные грабли за все 25 лет опыта в ИТ. Если вам такой опыт интересен, читайте другие мои статьи здесь на Хабре и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Эта статья - продолжение моей статьи "о пользе регламентов" в рамках цикла статей "О чем РП не рассказывают на курсах". 

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

Если вы чувствуете, что у вас в компании какой-то бардак, но не можете сформулировать словами - прочитайте эту статью и, возможно, вам станет понятнее, почему все именно так.

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

Эта статья будет о наболевшем. О правилах в разработке и что бывает, когда их нет.

Она не совсем про Руководство проектами, она пошире: про руководство командами разработки. Но если вы Руководитель и у вас на проекте разработки ПО есть хотя бы пара разработчиков, вам ее будет полезно прочитать.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Правила – это скучно.

Я давно заметил, что, когда набираю новых менеджеров и рассказываю им про регламенты и правила разработки в компании, они очень внимательно слушают, усиленно кивают и вообще – само внимание. А спустя пару недель или месяц, внезапно выясняется, что они не даже не кликнули по ссылке, которую я отправлял в письме. И читают регламенты исключительно из-под палки. Хотя, казалось бы, что там: 5 листов, 30 минут осознанного времени, не более. Почему так?

Тема статьи: коммуникации РП и команды: как это делать правильно, а как неправильно, и к чему это вас приведет.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

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

Все нижесказанное основано на моем личном опыте, как РП с опытом 25 лет и РПО с опытом 10 лет.

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.

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

Однако есть один маленький нюанс: Руководитель проектов должен соблюдать границы проекта, он не волшебник. У него нет бесконечного бюджета и сроков, а значит, иногда придется спорить и отстаивать границы. А значит, говорить «НЕТ». Как это делать так, чтобы не разрушать отношения на проекте, в команде, на аккаунте, а, наоборот, их укреплять? Вот об этом и предлагаю поговорить.

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

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

О том, как это сделать – ниже.

Это статья для тех, кто хочет стать Руководителем проектов или кто уже является Руководителем проектов. Ну и для всех остальных, кто сталкивается с ними чтобы понимать, что вам ждать от Руководителя проектов, когда вы его встретите, а чего ждать не стоит (и есть ли у РП волшебная палочка, которая позволяет взмахом выполнять все сроки и поднимать маржинальность проекта, или ее нет 😉).

Всем привет! Этой статьёй я открываю серию постов из моего личного опыта, которого у меня больше 25 лет, из которых 20 — в управлении проектами.

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

Что делать, если сроки срываются, а вы не виноваты? Что делать, если заказчик требует невозможного, а сказать «нет» нельзя? Что делать, если вы чувствуете, что вы везде крайний, а никаких инструментов повлиять на ситуацию у вас нет? Ничего этого нет в PMBoK или Agile Manifest. Как сделать действительно качественный продукт, как принести прибыль компании, а себе заработать денег, вас не научат на курсах владения MS Project. Но вам может помочь опыт других РП, которые уже прошли то все сами и понимают, почем фунт лиха.

Так что надо делиться.

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

Я расскажу 😊