Сегодня участвовал в панельной дискуссии с коллегами из Сбера, Самолёта и УБРиР на тему "Проектное управление в ИТ: олдскул или вы просто не умеете его варить?".

Мысли, которые звучали на дискуссии и которые меня зацепили:
- Несмотря на гибкие подходы в разработке, проджекты и проекты никуда не исчезли.
- Проджекты подключаются к большим проектам, где участвует много команд и разных департаментов. Командам требуется много синхронизации сроков и усилий, или есть аутсорс, или аутстафф, или много сложных стейкхолдеров.
- Больших проектных офисов в компаниях спикеров не осталось, проджекты работают децентрализовано. В некоторых компаниях есть центры экспертизы, которые помогают поддерживать общие практики управления проектами.
- Роль проджекта размылась, и сейчас это больше роль, которую может выполнять кто-то из команды: продукт-менеджер, тимлид или отдельный человек — проджект.
- Точно так же со скрам-мастерами: в новых командах они есть, а потом это становится ролью кого-то из команды. Скрам-мастера начинают отдаляться от команд и делать более сложные и масштабные задачи.
- Какие навыки нужны проджекту? Главный — ему не должно быть всё равно. Кроме этого, понимание гибких методологий и немного технической экспертизы. Ну и управление проектами, конечно.
- Почему 50% проектов проваливается? Пожимают по срокам, на которые не согласна команда. Но тут ещё вопрос: а почему это плохо? Если была нормальная коммуникация со стейкхолдерами, проект в целом успешен и запущен, и всем ок, то не всё ли равно?
- Почему PMO часто оторваны от реальности и делают бесполезное? Им не хватает продуктового подхода в своей работе. Если думать о пользователях и решать их проблемы, то всё будет хорошо.

Всем привет!
У моего канала первый праздник, нас стало

💯

🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉

С каждым новым подписчиком растет моя надежда, что я не напрасно пишу то, что здесь пишу и это интересно.

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

#Юбилейчик

🖥 Как-то руководил я в одном Банке (не скажу каком ☺️) проектом по внедрению ПО для бухгалтерии.

Вместо устаревшего ПО пользователи должны были увидеть новое, более современное, удобное, с большим функционалом.
ПО внедриться должно было одновременно везде. Сотрудники вместо одной иконки должны были нажать другую (со ссылкой в броузере).

🖱Все протестировали, всех предупредили, все, что могли предусмотрели.
📝Выпустили приказ от первого лица Банка о старте опытной или промышленной (не помню) эксплуатации.

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

Слава богу быстро нашли проблему, связана она была с сетевыми доступами, и быстро починили.

Осталось понять, у всех ли все заработало, поэтому написал руководителям ИТ территорий, вида: "проверьте, пожалуйста, работает ли".

💬 Руководитель ИТ одной из территорий делегировал задачу своему сотруднику, со словами: "Прошу проверить, по итогам отписаться инициатору и в ИТ".

В результате, спустя некоторое время, мне в почтовый ящик прилетает письмо.
✉️
В "кому:"
- Руководитель Блока ИТ Банка (и сейчас не скажу какого ☺️),
- Сотрудник канцелярии, который выпустил распоряжение о старте эксплуатации,
и я.
В "копия:"
- Председатель Правления Банка (того же самого)
- Все ИТ-директора территорий, все ИТ центрального офиса и все мое руководство - то есть получатели моего исходного письма.
Текст:
Все работает. Спасибо.

Успел выдохнуть и даже захохотать от сочетания получателей письма,
но посетившая следом мысль, а что было бы с моей карьерой, если на указанный состав получателей прилетело бы "ничего не работает" 😬
- вынудила меня сделать в работе технический перерыв, чтобы прийти в себя :) 👍

PS а к сотруднику-то претензий ровно ноль. Его просили уведомить инициатора и ИТ - он и уведомил инициатора (от кого распоряжение пришло) и ИТ (раз никого не знал - нашел в тел. книге руководителя), а так же меня с получателями исходного письма.

#СлучилосьСоМной

С притчей согласен на 💯. Учу этому своих.
В копилку сообщений выше про лифт-тест и разбуженного генерала

Рубрикатор

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

📌 чуть-чуть про себя и для чего веду канал

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

📌 почему тот, кто дает блокирующие замечания к проекту - не враг, а иногда союзник

📌 до какой глубины менеджеру имеет смысл погружаться в детали своего проекта

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

📌 какие мягкие навыки для руководителя проекта это - база

📌 как сделать так, чтобы тебя понимали на управляющих встречах

📌 как работать в токсичном проекте и почему это - еще и возможность

📌 почему стресс в менеджерской работе неизбежен и как с этим справляться

📌 Почему менеджер, внедривший крупный проект чувствует себя примерно как Евгений Трефилов и что делать

📌 Как не дать разовой коммуникации с незнакомым коллегой сделать обратную связь от руководителя негативной

📌 О том, что каждое слово при докладе Top-руководителям может стать последним

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

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

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

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

Как писал выше,

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

и поэтому, предлагаю подписаться на папку оптом по ссылке
https://xn--r1a.website/addlist/uI-feZcvhQdjMTMy

Сам читаю и уже нашел более чем интересный для себя контент.

6 советов как сделать так, чтобы тебя понимали на оперативках или докладах на управляющих встречах.

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

2. 📆На регулярных встречах использовать формат визуала, к которому все постоянные участники привыкли. А для этого, на первой встрече, подробно рассказать про формат, что какая область означает, чтобы приучить.

3. 🥷Не говорить быстро большой объем текста. Особенно, которого нет на визуале.

4. 🥱Не произносить долгую речь монотонно. Расставлять акценты.

5. 💭💬 Задавать слушателям вопросы или периодически спрашивать, все ли понятно или что-то повторить.
Иногда просить источник информации подтвердить сказанное.

6. ☝️В конце доклада повторить голосом все важные договоренности и кто что до следующего доклада должен сделать. Убедиться, что адресаты поняли.

Отпуск все же, давайте 3-й мем)))

#пятничное

@badtechproject

Ласковый теленок двух маток сосет. Но иногда случается по-другому

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

Пикантности ситуации добавлял тот факт, что заказчики этого проекта (назовем их Заказчик 1 и Заказчик 2) персонально друг друга на дух не переносили. Аж кушать не могли (с).

Но и это еще не все.
ИТ-проект входил в программу проектов. У программы был руководитель от Заказчика 1. Он отвечал за выполнение КПЭ программы, и он так же оценивал руководителей проектов, входящих в эту программу.
А Заказчик 2 отношения к программе не имел, и оценивал своего руководителя проекта на базе КПЭ своего проекта.

Заказчик 1 и Заказчик 2, которые друг друга не переносили, прекрасно понимали, что отменить друг друга они не могли, а кроме того еще и имели некоторое представление о том, как в корпорациях все работает.
И поэтому, они старались решать через ИТ все те разногласия, которые могли в ИТ отправить (т.е. 90%).

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

Если все вышеописанное упростить, то выходило, что руководитель проекта вынужденно писал объяснительные сам себе и затем самому себе на них отвечал.
Ну и люлей получал с двух сторон, куда без этого :)
Драма, в общем.

Предлагаю подумать о том, как бы вы построили свое поведение в роли Руководителя проекта.
Желающих предлагаю поделиться в комментариях.

В следующем посте, спустя некоторое время, скажу что я думаю по этому поводу.

#быль

Что ж, дал время желающим подумать над ответом на вопрос ⬆️ и пишу свой ответ.

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

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

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

2. Запрос поддержки 🙋‍♂️
После определения, что проект - токсичный, РП должен поставить в известность об этом своего руководителя, того, кому может прилететь со стороны Заказчика эскалация, чтобы заручиться поддержкой.
С высокой вероятностью руководитель предложит то, что описано в п.1, а по значимым перепискам попросит держать себя в копии. Это предупредит руководителя, даст возможность оказать помощь при необходимости и морально подготовит к возможной эскалации, которая в этом случае всяко пройдет мягче, чем в случае, когда случится полнейшей неожиданностью для руководителя

3. Нахождение над схваткой ⚖️
При наличии двух не дружественных друг к другу заказчиков, самая правильная линия поведения РП - быть над схваткой.
Кто-то просит новое требование без согласования второго?
- ОК. Спасибо. Фиксируем требование в нашем реестре. Можем ли мы обсудить это до регулярного статуса или озвучим на нем?
...
- Нет, я не могу взять без обсуждения, это требование займет ресурсы команды разработки и может повлиять на конечные сроки.
Даже оценка требования займет время и отвлечение ресурсов команды. Мы готовы это сделать, но прозрачно для всех участников проекта

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

😡 Заказчик эмоционально предъявил?
-Ок, поблагодарили за обратную связь, спросили причины недовольства, посмотрели отраженное на портале события, спокойно предъявили, пообещали сделать все возможное, чтобы помочь.
⌛️Разработчики отстают по срокам?
- Ок, обсуждаем на рабочей группе статус и причины, включая последние изменения.
📜Запросили объяснительную?
- Посмотрели на портал достали фактуру, включили в ответ


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

Когда уговариваешь саппорт внедрить фичу вне релизного графика

Получается, стрессовое событие не реализуется, а ресурсы мобилизованы.
Если тревога вхолостую случается часто, то это вообще довольно вредно для здоровья.

🔫Тема более чем актуальна для менеджеров, особенно проектных, потому что вся их работа так или иначе сопряжена со стрессом.

Во-1, менеджер должен постоянно принимать решения. Для кого-то - уже это стресс. Впрочем, таким в менеджеры идти я не рекомендую.
Во-2, в проекте постоянно происходят изменения, и далеко не всегда позитивные, а чаще кажущиеся на первый взгляд негативными.
В-3,4,5, и т.д. , в любой момент кто-то из рабочей группы или окружения может написать не то письмо, начать не так решать не ту проблему, залезть в вашу зону ответственности, породить вам работу, которой вы не хотите заниматься, да много чего..😡

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

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

3,5 моих совета, буду рад если кому помогут:
🛑 Скомандуйте себе «Стоп-машина!»
Если вас что-то выбесило и вы собираетесь отреагировать,
и если у вас не ситуация близкого дедлайна, где счет идет на часы,
задержите коммуникацию - не жмите отправить, сбросьте исходящий звонок...
Сделайте паузу, хотя бы на полчаса. Выпейте воды. Отвлекитесь.
Как минимум есть вероятность, что если речь идет о групповой переписке, кто-то может починить проблему и без вас или сразу поймет исходное письмо нужным для проекта образом.

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

🙋‍♂️Превратите гнев в вопрос
Если вы категорически не можете ни о чем другом думать, кроме как о реакции на письмо/действие, попробуйте сформулировать максимально не агрессивный вопрос, суть которого, понять: а что человек имел в виду?
Проиграйте в голове текст этого вопроса. Представьте, что вы задаете его стажеру.
И, если совсем невтерпеж - позвоните, поинтересуйтесь. И вы внезапно можете узнать, что у автора - другая информационная картина. Возможно, даже более полная, чем у вас. И не поругать его надо, а похвалить.

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

Технический пост.

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

В личку подписчик прислал мем ⬆️

Нууу, в качестве троллинга от инженеров - сомнительно, но окээй. 😁

На практике же, так думает не вменяемый менеджер (В. м.), а - долбодятел.
Зачем ускорять регулярной долбежкой работы, которые выполняются стабильно по времени?
В. м. просто эту длительность запланирует и все. ⏱

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

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

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

Не будьте как долбодятел, будьте - как В. м. 💪

Не мое творчество, коллеги из просторов интернета прислали )

Для ценителей Бекса и Пош Спайс 😜

#ИТшутит #РеквизированоВСети

История об одном Зампреде и Тибетском монахе.

Приехал как-то Зампред на заранее запланированный и забронированный визит к тибетскому монаху.
Далее, недословно.

Монах его принимает и спрашивает:
- ну, в чем твоя проблема, заставившая проделать такой путь и обратиться ?
- мне не хватает времени на личную жизнь и отдых
- а почему его тебе не хватает ?
- я работаю по 15 часов каждый день
- а тебя кто-то заставляет работать по 15 часов каждый день?
- нет, я сам это делаю добровольно и осознанно
- тогда в чем твоя проблема ?

#быль

Из комментов к пред. посту:

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

Если построить график зависимости переработок от позиции - то будет примерно парабола.

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

👨‍💼У инженеров и менеджеров среднего+ звена - уже и опыт есть, и подчиненные, и навыки делегирования.

🤵‍♂️А вот выше, начиная с некоторого уровня опять идет рост занятости, потому что зона ответственности расширяется до бесконечной.
Вы можете познать в своей работе все, идеально выстроить свой департамент и процессы в нем - а тут вам как надежному топ-менеджеру прилетает Олимпиада в Сочи или COVID.

Самый топ менеджер в нашей стране - ВВП.
Работает по 15+ часов в сутки при сильнейшей команде и умении делегировать.
Но и задачи уникальные и их бесконечное число.

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

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

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