Ок.
А делать-то что, если это - культурный код ? Нельзя же изменить культурный код общества в рамках отдельно взятого проекта.

На мой взгляд, руководитель или менеджер у своей команды должен ассоциироваться с двумя понятиями:
- доверие
- ценность.

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

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

Получается не сразу, не всегда, и не со всеми, но я стараюсь на этом фокусироваться, насколько это возможно в запаре и стрессе.

Так вот, есть некое ощущение, что А.Р.Б. своим заявлением хотел сказать своим новым подчиненным и контрагентам примерно то же самое.

Мультик Кордебалет от Смешариков - для меня лучший мультик про руководителя проекта и одновременно курс молодого бойца для начинающих РП

Значит плохо "продавал"

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

ИТ-Директор одной из крупных корпораций выявил, что у крайне важной для поддержки бизнеса старой ИТ-системы нет серверов и системы для резервирования. А значит, если система рухнет, то восстанавливать ее будет не откуда, и будут те или иные потери.
Осознав, что эти сервера с системой срочно надо купить, он отправился утверждать финансирование закупки, как полагается, на коллегиальном органе (комитете), принимающем важные решения в корпорации.
Сумма закупки была значительной, предположим, >1 миллиона долларов.

Пришел, выступил, рассказал зачем, почему так дорого...
Комитет посовещался и в финансировании отказал.

Спустя некоторое время ИТ-Директор снова пришел на этот же комитет, с тем же самым запросом о финансировании. Принес с собой графики утилизации, еще несколько ИТ-метрик в красной зоне, дескать, надо срочно покупать.
Комитет посовещался - финансирование не утвердили.

И в третий раз закинул старик в море невод пришел ИТ-Босс на комитет, снова попросил финансирование и снова решение не приняли.

Спустя незначительное время после третьего выхода на комитет, приключилась ИТ-авария, система упала, восстановить сразу не удалось, как минимум часть данных безвозвратно потерялась.

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

значит плохо "продавал".

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

Такой подход верен абсолютно на любом уровне принятия решения.
Даже в семье.

#быль

Ремонт квартиры как проект

Самый простой бытовой пример, объясняющий что такое проект и зачем нужен руководитель проекта (РП) - это ремонт квартиры.

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

Или вы - бригадир = РП,
у вас есть бригада ремонтников, которая вас слушается,
и есть хозяин квартиры = заказчик, которому нужно всегда знать:
- когда ремонт закончится;
- во сколько ему обойдется его новая хотелка "ой, а можно еще в ванной комнате кафель поменять";
и с которым надо согласовать всякие внезапно обнаруженные в ходе проекта-ремонта чудеса (ой, у вас тут электрокабели у розетки совсем сгоревшие, может хороший кабель поставим, а то может пожар случиться?).

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

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

Вот и в ИТ-проектах все ровно так же.

Добавлю еще, что у меня не было еще ни разу проектной ситуации, которую я не смог бы описать в виде аналогии ситуации с ремонтом квартиры :)

Важность контекста

Когда вам от руководителя или руководителю от вас по вашей задаче нужна помощь, начинать надо с введения в контекст.
Как кратко ввести в контекст зависит, безусловно, от того, когда последний раз и насколько плотно вы обсуждали задачу. Но как бы вы плотно ни общались, в текущий момент времени руководитель сфокусирован на своих проблемах, а не на ваших. А может, у него проблем сейчас и вовсе нет, и он спокойно делает свою запланированную работу и о вашем проекте вообще не думает.
Один мой знакомый зам. Руководитель блока ИТ, к сожалению, он ныне не с нами, легендарно учил одного из моих коллег.

- Вот представьте себе, я – генерал, сейчас ночь и я сплю. Вдруг раздаются взрывы, выстрелы, шум, гам...
Вбегаете вы, начинаете запыхавшись рассказывать, что у Иванова заклинило ружье и он стрелять не может, Петрову не хватает патронов, Сидоров – обделался…
🙉
…
Да вы хоть скажите мне, кто на нас напал?
...
Армия какого государства стреляет под моими окнами?
...
Ах это наша армия?! И сейчас учения идут?! Ааа, ну так бы сразу и сказали.
Адъютант! Соедините, пожалуйста, с полковником Смирновым, который за проведение учений отвечает

​​Инструмент для установления авторитета

В догонку к рассуждениям про доверие и ценность (см. ниже), когда менеджер приходит в новый проект и в новую команду, ему необходимо завоевать авторитет.
Банально, чтобы на его встречи ходили, а поручения - выполняли.

Авторитет - не дают, его - берут.

Как же его взять, если команда новая, и менеджера еще не знают?

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

Но чаще всего бывает не так, а бывает, что менеджер - не только не в одной штатной структуре с исполнителями, но даже и из другой организации.
И как быть в этом случае?

Значимым преимуществом менеджера проекта является "доступ к телу" стейкхолдеров или ключевых заинтересованных в проекте. Поэтому первое, чем должен на практике озаботиться менеджер проекта, это организацией способа регулярного общения с стейкхолдером (-ами).

👉 И тогда, это становится инструментом для управления проектной командой, причем в обе стороны.
С одной стороны, можно рассказать главному заказчику, что со стороны проектной команды вот здесь стоит что-то улучшить (вовлеченность, ресурсы, приоритеты и т.д.).
А с другой стороны, можно решение, необходимое для проекта и проектной команды быстрее принять, правильно "продав" его главному заказчику.

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

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

👆А второе, чем озаботиться - уже проведением этих встреч,
чтобы для стейкхолдеров она была интересной,
чтобы они туда ходили,
чтобы понимали контент и чего от них ожидается, и почему участвовать во встрече для них более ценно, чем ее пропускать в пользу других задач.

👆 Если ключевые участники проекта имеют доступ к стейкхолдерам и пользуются этой возможностью чаще и лучше вас - ваша ценность и ваш авторитет становится существенно ниже.
И тогда следует решать уже эту задачу

Если мультфильм, который полезно посмотреть, РП - это Смешарики "Кордебалет", то какой тогда фильм?

Мое мнение - Оппенгеймер.

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

P.S. Упоминать Криминальное чтиво и Уинстона Вульфа я не стал, т.к. этому примеру около 20 лет.

Деперсонификация как первый шаг разрешения проектного конфликта.

Представим себе очень распространенную ситуацию.
Есть задача что-то внедрить, предположим к концу следующего квартала.

🤵‍♂️ Есть заказчик, назовем его (чтобы имя случайно не совпало) Уолтер, который настаивает на сроке внедрения, уверенно говорит, какая катастрофа случится, если этот срок не выдержать даже на день (миллионы жалоб, отзыв лицензии, миллиардные убытки, банкротство и увольнение всех, нужное подчеркнуть...).
Доработать нужно 5 ИТ-систем, руководители разработки 4-х систем из 5 подтвердили, что к концу текущего квартала завершат разработку и выйдут на интеграционное тестирование, а к концу следующего - доведут свои системы до внедрения;

🧑‍💻 Есть пятый руководитель разработки, Стивен, который говорит, что он не успевает, и в лучшем случае к концу следующего квартала завершит разработку, а может даже и позже.

🧑‍🏫 Есть руководитель проекта, Джон, от которого и требуется завершить проект в желаемый Уолтером 🤵‍♂️ срок.

Я неоднократно слышал, от людей в роли РП-Джона 🧑‍🏫 предложения, как эту задачу решить, а именно:

🤜 Попробовать еще раз договориться со Стивеном 🧑‍💻 , указав дедлайн (некоторые, к слову, этот шаг пропускают и начинают сразу со следующего)

🤜🤜 Эскалировать вопрос на руководителя Стивена 🧑‍💻 и настоять на желаемом сроке

⛈️Эскалировать вопрос на Уолтера 🤵‍♂️, а то и на его руководителей, направив его гнев/аргументы на Стивена 🧑‍💻 . В формате (все согласны, один ты - такой-сякой)
И так до победного конца.
Успехом считается продавливание Стивена 🧑‍💻 на желаемый срок.

Лично на мой взгляд, данный сценарий имеет ряд не очень приятных свойств:
- не зная расклада, я бы оценил вероятность успеха в 50%: продавит Джон 🧑‍🏫 (+ помощь) или нет;

- победа в данном вопросе может стать для Джона 🧑‍🏫 одноразовой. В следующий раз Стивен 🧑‍💻 лучше подготовится и сможет запрос отбить. Более того, он может "обидеться", и отбить даже запрос, который смог бы своими ресурсами реализовать;

- часто бывает, что в результате такого сценария Джон 🧑‍🏫 , скажем деликатно, сильно усложнит будущее взаимодействие со Стивеном 🧑‍💻 совершенно без каких-либо плюсов, потому что окажется, что Уолтеру-то 🤵‍♂️ и не настолько этот срок - дедлайн. 🫤
Я сам лично слышал, как заказчик, который рассказывал мне и окружающим, какая катастрофа наступит на следующий день после дедлайна, если не завершить работы, он же потом целый квартал рассказывал всем как он без этого результата спокойно проживет.

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

А как тогда действовать?

Читать далее

#деперсонификация

По ситуативочке могу сказать только одно.
Стартовая позиция менеджера, если он хочет достичь договоренности,

всегда предполагает пространство для уступок. Но так же изначально должна подаваться твердо и уверенно, как будто пространства для уступок - нет.

Чем сложнее и важнее переговоры и сильнее оппонент - тем более верно это утверждение.

Когда еще работает деперсонификация конфликта.

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

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

🎭 Он может быть просто исполнителем, который ровно в этом действии видит свою ценность для вашего работодателя.
В своей картине мира он приносит пользу тем, что минимизирует риски или предотвращает катастрофу или предлагает достичь еще более сильного результата.
Зачем с ним воевать, если с ним можно объединиться и совместно достичь благих целей, причем благих для обоих?

🚦 А может быть он из тех, кто просто считает своей должностной обязанностью предотвратить нарушение/риск/катастрофу.
Как турникет в метро.
Турникет же не волнует ваша жизненная ситуация, куда вы опаздываете и как драматически изменится ваша жизнь, если вы опоздаете.
Билет не приложили - барьер закрылся. В некоторых случаях больно для частей вашего тела.
С вашей точки зрения турникет вступил с вами в конфликт, но точно ли целесообразно тратить нервы на войну или объяснение своей позиции ?

☝️ Для меня деперсонификация конфликта - это и есть выведение конкретного человека и эмоций по отношению к конкретному человеку - за скобки конфликта.
Я либо невольно оказался в конфликте с ролью, играющую по заданному сценарию - и тогда моя задача, чтобы мы сыграли вместе и в общих интересах. А их всегда можно найти.
Либо я конфликтую с "турникетом", и тогда мне нужно просто купить билет и приложить, чтобы "турникет открылся".

Нет человека - нет и конфликта.

#деперсонификация

Ничто так не мотивирует ответственного менеджера анализировать портфель своих задач, как регулярная отчетность для матричного руководителя.
Вплоть до того, что если такой отчетности нет - ее стоит придумать.

Умение видеть за деревьями лес - одно из важнейших качеств сильного менеджера проекта.

Менеджер всегда должен быть в контексте своего проекта и его окружения - без этого он не сможет ни проектом управлять, ни ожиданиями всех сторон.

📍Точно ли истинные мысли заказчика до буквы совпадают с тем, что он говорит на проектных встречах?
📍Если заказчик или смежник принимает "нелогичные" решения или предлагает "нелогичные" шаги, а ваши «логичные» предложения отвергает - точно ли вы правильно понимаете его логику?
📍Если прилетело распоряжение на всю корпорацию или на весь ваш блок, вы оценили его влияние на ваш проект? точно ли совсем никак не влияет?
📍Понимаете ли вы генеральную линию вашей корпорации и, в частности, чем ваш стейкхолдер дышит в контексте генеральной линии?

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

#контекст #окружение

Лучше всего учит видеть за деревьями лес - личный опыт. А если такого опыта нет - то надо начать его вырабатывать.
Прямо с ближайшей проектной встречи с ключевыми людьми.

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

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

Если ни один из способов не помог - не беда, вы просто воспринимаете ту позицию, как она есть и теперь - она часть вашей картины мира. И вы уже ее можете и должны учитывать в проекте.

💪 Упражнение повторять до того момента, как оно не войдет в привычку.

🔥🔥🔥

Всем привет!
Настало время порадовать моих подписчиков бесплатной лотереей.
У каждого кликнувшего на кнопку "Участвую!" есть шанс получить одну из двух книжек на выбор (см. рисунок).

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

Книжку вручу либо лично - кого знаю и с кем пересекаюсь, либо - направлю по почте за свой счет.

Лотерея продлится до 18:30 понедельника, 1 июля.
Победителя определит встроенный бот рандомайзер и он же оповестит о победителе.

Для менеджера не бывает бесполезной информации.
Бывает информация, которую менеджер не знает как использовать

🎉 Результаты розыгрыша:

Победитель:
1. Юрий (@arrow7272)

Проверить результаты

Выигравший приз Юрий @arrow7272 передает всем пламенный привет!

Поздравляем победителя!
От себя желаю, чтобы оставленные древними цивилизациями знания об управлении ИТ помогли прокачаться и принесли пользу в работе и в жизни в целом :)
Наш образовательный канал - он же ровно про это :)

Ура товарищи! 🎉

7 вопросов позволяющих понять, насколько глубоко погружаться в детали проектных работ.

Давно хотел написать на эту тему, т.к. вопрос встает более менее регулярно.
С одной стороны, ключевые правила управления проектами сходны в любой отрасли, будь то строительство или ИТ или PR-проект.
С другой стороны, как управлять тем, в чем не разбираешься?

Универсальной формулы, разумеется, нет, но сформулировал опросник, который поможет каждому желающему руководителю проекта определить для себя необходимую глубину.

🧘‍♂️1. Насколько вы для себя понимаете происходящее в проекте?
Тут критерий понимания - ваше спокойствие. Т.е. вы спокойны, т.к. понимаете как проект идет, где он находится и чего ожидать.
Если вас беспокоит неопределенность, доносящиеся снизу статусы не помогают, а запутывают - надо погружаться ровно настолько, чтобы разобраться и успокоиться.
Если программист свою работу не выполнил за срок в два раза больше запланированного, только ли проблема в работе программиста? Или он чего-то ждет от кого-то? А тот согласен или нет? А кто из них прав?

🤴2. Насколько глубоко в проекте/задаче/окружении разбирается ваш Заказчик ?
Если вы погружены не так глубоко, то у него как минимум будет перед вами переговорное преимущество, а как максимум, он статус проекта будет получать не у вас.
А если вы погружены, и сможете удовлетворить информационный голод заказчика на понятном ему языке - то вам респект, уважуха и доверие

👔 3. Насколько глубоко в проекте/задаче/окружении разбирается ваш непосредственный руководитель ?
То же, что и в п. выше, но про непосредственного руководителя и зависит от того, насколько детально ему ваш проект интересен. Чем детальнее он вас спрашивает, тем более глубоким должно быть ваше погружение.

🙋‍♂️4. Есть ли у вас подчиненный, которому вы 💯 доверяете и который в любой момент может вам представить статус в любой детализации?
Если такого нет, то см. п.п. выше

💪 5. Насколько знание деталей вам нужны для общения с лидером (-ами) команды исполнителей?
Часто с ростом профессионализма и авторитета, у лидера растет и самолюбие, а иногда и ощущение "я - звезда". В этом нет ничего отрицательного, более того, именно звезды приводят любую команду к звездному результату.
Но для этого он должен воспринимать вас как авторитета для себя. А вы должны создать ему комфортную обстановку и делать так, как ему лучше.
И убедить его, если он с вашей идеей сперва и не согласен.

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

🧑‍🔧6. Точно ли все в команде достаточно хорошо понимают что делать и знают как?
По сути обратно п. выше
Если ответ - "нет", то вам надо помогать и с организацией эффективной работы, и где-то своим опытом замещать выпадающие компетенции. Часто бывает, что даже сильные исполнители не участвовали в таких сложных проектах, как вот этот.

🪢 7. А точно ли вам данная детализация чем-то поможет в управлении проектом ?
Рано или поздно в погружении стоит остановиться. И для того, чтобы не беспокоить квалифицированных исполнителей глупыми вопросами лишний раз. И для того, чтобы не попытаться постичь "китайский язык за 10 дней". И просто чтобы не загромождать голову лишними знаниями.
Вот для меня вопрос-маркер - это именно насколько эти знания мне реально помогут. Или хотя бы сделают картину мира более ясной и успокоят (см. п.1.)

Кстати, про Месси и тренера в контексте менеджмента.
На проходящих прямо сейчас в одно время турнирах сборных, Аргентина с Месси вышла в финал Кубка Америки, а Франция с Мбаппе и Португалия с Криштиану - не вышли в финал чемпионата Европы.

Каждый, кто думает, что Криштиану, Мбаппе, чуть раньше Зидан и иные топ-звезды для команды авторитетнее, чем тренер - абсолютно правы.
А вот если кто-то думает, что у Месси эго меньше, чем у Криштиану или Мбаппе с Зиданом - сильно ошибается.

На самом деле менеджеру и не обязательно быть более авторитетным, чем звезда его проекта.
Ему важно, чтобы звезда играла ту роль, которая предусмотрена планом.
И чтобы вытянула проект, если что-то пошло не так.
А не отправила своим поведением/игрой/отношением план в тартарары.