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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я расскажу 😊