Какие артефакты нужны проекту?

Любая проектная бумажка - инструмент коммуникации и без четкой цели бесполезна.
Классический проектный менеджмент и всякие аудиты попросят вас показать project charter, project management plan (это не таймлайн!), dependencies mapping, timeline / project schedule, risk register, communication plan, project status report и еще пару штуковин. Часто их пилят по ужасно стремным шаблонам, которые созданы "чтобы по-учебнику". Вам нужно другое!

1. Страничка в confluence или какой у вас там ноушн - вместо project charter. То есть лендинг вашего проекта для всех интересующихся. Там ответы на вопросы: зачем делаем, что делаем, когда делаем, кто делает, кто спонсор, ссылки на техническое и продуктовое решения, ссылка на таск-трекер, основные метрики и почему такие + всякие другие мелочи, которые сводят основные данные проекта в понятный TL;DR. Экрана на три максимум, это не лонгрид.

2. Линейка с колбасками, в любой форме, но чтобы понятно без объяснений - что-кто-когда в каком статусе. Да, можно запихать таймлайн даже проекта на 2 года и 200 человек в один понятный всем слайд. Не получается? Вы недостаточно подумали. Иногда нужно два-три таких слайда, чтобы показать в разрезе разных контекстов для разной аудитории.

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

4. Вместо project management plan (план управления проектом) соберите на тот же лендинг ответы на вопросы что вы будете делать, если что-то пойдет не так, план коммуникации и риски. План на самом деле никому не интересен, он вам только для сдачи PMP нужен - на практике никто не делает, unless корпоративная бюрократия.

5. Зависимости и риски тоже на лендинг, в формате короткой таблички на скажем 5 колонок и не больше 15-20 строк. Потому что иначе это все читать никто не будет. Фу-фу-фу эксельки на 100500 полей строить, ужас какой. Да, по теории нужно считать вероятности-импакт и еще кучу всего, но! Подумайте, что нужно вашему начальству. Для небольших / несложных проектов зависимости и риски вообще удобно объединять в одну кучу. Потому что это про одно и то же - известное неизвестное. Туда же допишите позитивные риски (да, это реальный феномен). Все это в формате "что произойдет если мы ничего не сделаем и почему это плохо". Допишите кто / когда / статус и ура.

6. План коммуникации это не RACI! RACI это фу-фу-фу и нужно тогда и только тогда, когда уже ничего не работает. Если вы не можете словами через рот договориться и сделать так, чтобы люди сами взяли ответственность потому что понимают смысл проекта, вы недостаточно подумали. Напишите какие митинги / когда / зачем + какие письма когда / зачем + какие каналы в Slack и хватит. Escalation path и все такое это тоже рюшечки когда ничего не работает. Для проектов с внешними подрядчиками полезно добавить peer matrix - написать кто кому является равным = кто к кому будет бегать за советами.

7. Проектный отчет на 1 слайд живет в слайдах проекта и органично собирается из предыдущих пунктов. Не получается собрать один аккуратный слайд? Вы недостаточно подумали. Контент:

- 2-4 метрики проекта и их статус + прогноз
- RAG статус и почему такой
- Что сделали за прошлый период
- Что делаем в следующем периоде
- Ссылка на лендинг проекта
- Три самых важных сейчас риска / зависимости и что мы про них делаем
- Явный запрос к аудитории = ответить на "ну рассказал ты мне это, и че?"

Если к вам часто бегают с "а где мне посмотреть X про твой проект?", вы или недостаточно понятно собрали артефакты, или недостаточно широко ими кидаетесь в людей. В идеале вы будете отправлять всем только две ссылки: слайды и лендинг.

Какие встречи нужны проекту?

Сделать поток коммуникации на проекте - самая сложная часть работы менеджера. Потому что все неоднозначно. Однако точно нужны:

1. Общаяя статус-встреча проекта: представители всех направлений / команд / отделов собираются на полчаса и проходятся по таймлайну, отвечая на вопрос "что по статусу / срокам". Если хорошо фасилитировать, вам достаточно 15 минут на проект любого размера, этакий стендап. Вторая часть - поговорить по что у кого болит друг к другу. Если не проводить, придется бегать собирать вводные для статуса с каждого и люди не будут знать что у кого происходит. Средний уровень абстракции погружения в контент проекта. Инженеров звать не обязательно.

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

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

4. Общий slack-канал для асинхронной коммуникации. Там проходят короткие дискуссии, туда вы кидаете сторонние апдейты. Чтобы не делать встречи на каждый чих и ничего не потерять.

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

_____________________

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

Регулярность зависит от скорости проекта / частоты изменений статуса. Базово проектная встреча раз в 2-3 недели, steerco раз в 4-8 недель, технический форум каждую неделю, таргетированные встречи раз в 2-4 недели на тему. Поперчить и посолить по вкусу - оно динамично в течение проекта.

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

Последовательность зависит от контекста, но обычно так: тех форум --> таргетированное --> статус встреча --> steerco --> проектный отчет. То есть одно дает вводные другому и не надо бегать лишний раз 🙂

Секрет успеха - предсказуемое пространство под разный контекст. Вы все правильно настроили, если кроме этих встреч у вас редко бывают доп обсуждения шире чем на 2-3 человека / одноразово.

Должности и регалии в проектном управлении не отражают навыков.

1. Разница seniority проектных / программных менеджеров это масштабируемость приложенных усилий. Junior может работать по шаблонам и внутри одной-двух команд. Principal - изобретать процессы на всю компанию и рулить стратегическими программами на два года и дольше.

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

3. Разница в годах работы может быть важной, а может и нет. Можно за три года набраться опыта больше, чем сосед за 10.

4. Разница в размере проектов не показатель навыков. Маленький проект может по сложности быть жестче, чем программа на 200 человек. Обращайте внимание на сложность заказчиков и уровень неопределенности.

5. Разница в горизонте планирования показывает бизнес-ориентированность, а продуктовая ментальность - нет. Можно уметь придумать 100 новых фич, но не понимать, что проект никому не нужен через полгода. Крутой проектный менеджер может предсказывать риски и проблемы за 2 года и больше.

6. Разница в должностях это семантика и зависит только от представлений организации. Я была project / program / delivery / business development / integration / consulting менеджером, а делала все то же самое. Это как мороженное с разными вкусами, смысл не меняется.

7. Разница в числе сертификатов показывает только способность сдавать экзамены. И чаще всего веер сертификатов показывает только внутреннюю неуверенность в навыках.

8. Разница в наличии прямых подчиненных не показывает вообще ничего. Можно иметь команду из 10 других проектных менеджеров и быть так себе в хард скиллах. Управление людьми и управление проектами это параллельные вселенные.

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

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

Вот уходите вы в отпуск. А дела как-то должны делаться. Как быть?

Проверочный вопрос на сеньорность менеджера: Какие процессы поломаются, если вы завтра резко уйдете в отпуск на 2-3 недели?

В идеале, процессы в управлении проектом, отделом, командой и примерно чем угодно должны управлять собой сами. Мастерство менеджера = выстроить систему, которая функционирует сама. Это не значит, что выстроил (делегировал) и чешешь пузо / меняешь проект! Если выстроили и стало скучно что аж хочется валить, вам не хватает seniority и есть много куда расти.

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

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

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

Есть термин такой business continuity. Он про сохранение работоспособности в случае кризисов и катастроф, но не только. Для ИТ это в первую очередь incident / crisis management. SRE и некоторые другие коллеги меня здесь очень хорошо поймут. А для менеджеров любого вида это непрерывность делания дел. Другими словами, применяя сакральные знания от друзей инженеров (PPRR framework):

1. Prevention: завязка на роли, а не на людей. Цельтесь в то, чтобы для ухода в отпуск было достаточно написать 2-3м людям по несколько строчек сообщения и может поставить 3-4 авто-сообщения на будущее aka напоминалки. Все. Можно меньше 😉

2. Preparedness: приоритизация и четкие инструкции, в том числе что может ждать, а что нужно разруливать на месте. Чтобы люди вокруг вас умели делать вашу работу если надо. Пример: вместо обмена письмами туда-сюда чтобы апрувнуть бюджет, напишите сразу "до Х денег без апрува, до Х+N писать М. или К., до X+Y писать К. или Е." Вы снизите чисто фрикций в коммуникации и время всем участникам процесса.

3. Response: имена куда бежать, по темам. Сразу в авто-ответ в почту и / или в статус в Slack.

4. Recovery: как вы будете возвращаться после отпуска? Лучше всего перед отпуском накидать себе на после отпуска встреч, где вы будете выяснять а что случилось пока вас не было. Если же вы аж неделю вкатываетесь и целый первый день читаете почту, вы недостаточно подготовились. Можно сильно проще.

5. Rehearse, Maintain and Review: что еще можно оптимизировать? Как помочь другим сделать процессы мягче и быстрее?

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

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

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

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

Что-то в вашем прошлом личном опыте "царапает" и мешает (не)делать желаемое. Коучинг, менторинг и карьерные консультации помогут на время, но не факт что решат ситуацию системно. Но! Бывает, что достаточно всего лишь поговорить с умным человеком как проходить собесы или чем занимается проектный менеджер. Другими словами, есть категория запросов на экспертизу, где не нужно ничего изобретать кроме ответов "в лоб".

Вы наверняка знаете, что я постепенно меняю карьеру. Я заканчиваю учиться на гештальт-терапевта. Уже имею право практиковать, однако клиентам важно знать что я студент. Кроме того, я регулярно прохожу супервизию (терапия для терапевтов про терапию).

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

Я теперь работаю в двух форматах:

1. Как раньше: менторская / консультативная одноразовая встреча на моей экспертизе. Для запросов формата "как искать работу / как писать CV / чем занимается проджект / как мне из инженера вырасти в менеджера" + "я прочитал(а) твои статьи и хочу поговорить про около-менеджерское".

2. Как гештальт-терапевт: долгосрочно, регулярно, про вас и не про мою экспертизу. Я помогаю вам понять что-то в своих реакциях на мир.

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

Пишите в личку @covectb_cobaka и мы договоримся о встрече. Встреча в любом из форматов 1 час, в зуме, с камерой и чтобы никто не отвлекал. Стоимость 55 евро или 6000 рублей за встречу, что удобнее.

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

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

Я не могу быть вашим терапевтом если мы напрямую знакомы вне контекста этого канала / мы в общих офлайн тусовках / я терапевт вашему близкому другу или родственнику / я консультировала вас по формату (1) больше одного раза. Однако меня можно рекомендовать - просто перешлите этот пост.

На консультациях меня часто спрашивают как стать продактом и надо ли туда идти.

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

Вот видос той встречи. Если вы сомневаетесь куда вам или не знаете как стать продактом, будет полезно.

Мои мысли и история в последней трети видоса. Круто услышать реальные кейсы разных людей!

https://www.youtube.com/watch?v=YLCuP8_E7kU

Я написала магистерский диплом про культурную интеграцию русскоязычных экспатов в Нидерландах, в контексте карьерного прогресса. Вот краткая выжимка: https://vas3k.club/post/24940/

TL;DR: учите язык, тусите с местными, выходите из пузыря и будьте открыты новому.

Привет свежеприбывшим! Я пишу посты нерегулярно, только когда появляются важные мысли. Комментариев к постам нет и не будет. TL;DR про проектный менеджмент это видос в закрепе. Про измененный контекст постов тоже смотрите в шапке канала. Если вам не нравится один пост, это не значит, что канал не для вас. Темы очень разные, но во всех постах есть части про психологию, менеджмент и часто про культуру.

------------------------------------------------------

Мы работаем собой.

Мне недавно сделали два лучших в моей жизни комплимента, причем в один день:
1) "Мне нравится, как ты видишь мир"
2) "Мне нравится, как я себя чувствую когда я рядом с тобой"

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

Тогда получается, что если перспектива окружающих на мир в целом не совпадает с вашей, то случится культурный mismatch. То есть важно искать "своих". А свои = похожие на вас = среднее между 5 вашими близкими друзьями именно по отношению к жизни и ценностям. На работе это работает точно так же. Если для вас коллеги это в первую очередь человеки, а не винтики, вы точно не сработаетесь с людьми формата "фигачим от забора до обеда и прыгаем через головы чтобы заработать кучу денег". И наоборот.

Есть чудесная книга "Surrounded by idiots". Она связана с DISC фреймворком и хорошо показывает как уживаться с людьми, которые в вашей системе ценностей попадают под определение "мудак".

Компании нанимают по culture-fit. Академически, есть два варианта: нанимать похожих на уже нанятых ИЛИ нанимать под новую-обновленную версию корпоративной культуры, к которой контора целенаправленно стремится. Второе случается только при наличии специально обученных чуваков в HR и это большая редкость. Собственно поэтому прохождение culture-fit собеседований это сложно. Чит-код - просто будьте собой. Если вы тут завалили, то значит вам туда не надо. Не на тот глобус сову натягиваете.

Как я себя чувствую это про быть собой рядом с другими. Получается внезапный вывод: чтобы попасть в контору, где вам будет приятно работать с людьми, нужно быть собой на собесе. Потому что если вы понравились "как есть", вы можете быть собой 24/7 и коллеги наверняка будут чем-то похожими на вас. Опасность только в резкой смене отдела-начальника сразу после выхода на эту новую работу, но об этом в другой раз. Как проверить? Задайте на собесе вопросы в местах, где вам важно.

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

// Быть собой = не ужиматься в своих реакциях на других, самовыражаться без оглядки на ожидания и мнение окружающих. Это кстати сложно. Over-thinking, детские травмы, внутренние установки, негативный опыт и проч, и проч, и проч. Да, вы их тащите в любое ваше сегодняшнее "быть собой".

Как понять на собесе, что вам будет хорошо в компании?

У меня один критерий: аутентичность. Я смотрю насколько собеседущие складываются в паттерн «быть собой».

У вас критерий может быть другой. Это не про должность-зп-задачи. Это качество людей. Например, у коллеги это критерий «людям не все равно, им нравится продукт».

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

Как проверить? Придумайте два вопроса. Или один. Или три.

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

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

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

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

Люди вас видят так, как вы видите себя.

Пример: Есть у вас знакомый. Он всем выпячивает некоторый навык. Например, постоянно показывает, что он знает технологию / говорит на языке / что-то еще. Вам это бросается в глаза. Но что-то не так, не получается поверить. Потому что почти наверняка человек сам не верит в свой навык. Выпячивает его подсознательно, чтобы получить внешнюю валидацию через похвалу. У меня так было с изучением английского сто лет назад. Короче. Хотите сделать человеку приятно и добавить уверенности? Похвалите этот его навык.

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

Пример: В начале карьеры меня больно укусили обратной связью, что я, мол, не имею достаточно технических знаний. Прямо говоря, я тогда и следующие 5 лет чувствовала себя полной дурой в этом месте. Образование в Computer science, умение кодить, знание консоли (со словарем), работа релизным менеджером - ничего не помогало. Я все равно чувствала, что я "не-технарь". И мне об этом регулярно говорили. Хотя в должности у меня стояло Technical Project Manager. В какой-то момент я стала искренне думать, что я более технически подкованный менеджер, чем среднее по больнице. Но у меня есть ограничения в знаниях и это нормально. Стала людям так и объяснять. И вы знаете, помогло! С тех пор в знаниях и проектах ничего не поменялось, а фидбек поменялся радикально. Даже роли руководителя разработки стали предлагать иногда.

Более структурно тезис выглядит так:
* Если вы не верите в свой навык, другие тоже не поверят;
* Если вы видите себя (даже неосознанно) некоторым образом, другие это считывают;
* Если вы себя за что-то ругаете внутренним критиком, люди будут вам прямо или косвенно возвращать то же;

Чтобы отметить эту разницу и понять что делать, подумайте:
1. Пять элементов каким вы себя видите;
2. Пять элементов каким вы хотите чтобы вас видели;
3. Где нестыковка, если честно посмотреть на фидбек от окружающих?
4. Какой фидбек вам часто дают? Если честно-честно, вы правда (не)такой?

Это нормально не видеть свои характеристики и / или их в себе не принимать. Или же хотеть стать "другим" и поэтому злиться / завидовать на людей, у кого эти штуки есть. Например, я могу вас бесить потому что вы "тоже так хотите", но этот механизм - тема для отдельного поста 🙂

Толерантность к неопределенности влияет на жизнь и проекты

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

Вероятно, при ответе Да на вопросы выше, вам до некоторой степени свойственен overthinking - придумывание кучи сценариев что может пойти (не) так, и это свойство часто приводит вас к сложностям в принятии решений.

Если разобраться, все это очень похоже на признаки глубинной тревоги. Тревога это страх будущего. Почему он есть, ответ у каждого свой. Часто стремление к определенности это форма попытки контролировать реальность, идущая как раз из тревоги.

Стремление к контролю это отличное качество для проектного менеджера, вероятно подумали вы =)

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

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

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

Как научиться толерировать неопределенность? Прочитайте "Антихрупкость" Талеба. Задумайтесь в терапии и поисследуйте а чего вы такого боитесь.

Проектные метрики: упрощенное и дополненное

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

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

Примеры:
- Техническое: Как мы выдерживем обещанные SLO / SLA / SLI, что по статистике инцидентов, и так далее. Проект эти метрики обычно не интересуют, unless временно потому что у вас там совсем жопа.
- Продуктовое: че там воронка конверсии, сколько бабоса заработали, че по экспериментам, и все такое. Опять же, проекту эти метрики обычно не нужны, с исключением если эскалации и бо-бо.
- Процессное: счастье команды, число зависимостей на соседей, поедание требований, и проч. Обычно эти метрики не количественные, а сравнительно абстрактные. Проекту эти метрики нужны больше в начале, чем в конце.
- Проектное: число штучек вашего скоупа, которые надо сделать. Milestones, общий статус проекта (RAG), общая картина по рискам, и все что придет в голову на основе теории 🙂

Что за метрики ставить зависит от проекта, заказчика, компании, личности менеджера и фазы луны. Тем не менее, есть кое-что общее и предметное: качество метрики.

Одна и та же метрика может быть или процессной или результато-ориентированной.
Пример: вы трекаете число перезаключенных контрактов.
Процессная часть: отправлено x from y + прогноз к следующему отчету.
Результатная часть: подписано N from M + прогноз.

Еще пример: вы трекаете число внедренных процессов и бюрократии их формирования. Происходит куча всего, дискавери и проч, но по вашему DoD пока ничего не готово. Но прогресс показать как-то надо, потому что он есть. Тогда:
Процессная часть: started x from y
Результатная часть: approved by <name> n from m

Фокус в том, чтобы у каждой метрики была база критериев как мы определяем что объект измерения завершен. А для этого почти наверняка придется придумывать шаги в процессе, например: начато -> процессы описаны -> runbook написан -> продакш тест пройден. (Это реальный пример, но не про фичи).

Какой интересный клубок получается, не правда ли? 🙂

Парадокс успешных изменений.

Change management и саморазвитие имеют общую философскую часть. Как внедрить изменение, чтобы быстро, не больно и чтобы изменение вообще случилось? В бизнесе часто говорят, что 80% изменений оборачиваются провалом (это вырвано из контекста, спасибо IBM и все не так, но мы не про то). В вакансиях просят навык управления изменениями. В личной жизни люди тоже хотят меняться. Привычки питания, спорт, поведение, переезды, отношения и всякие другие "хочу стать <таким>". А что такое изменение?

Концептуально, изменение это модификация атрибутов "что есть сейчас" в некоторое состояние светлого будущего. Подразумевается, что "сейчас" все плохо и надо "лучше". А что если убрать оценочные характеристики? Тогда получится научно доказанный парадокс, спасибо existential методам терапии и философам. Итак.

Первая часть: изменение случается только когда человек перестает пытаться измениться, а становится собой. То есть все эти штуки про "принять себя" на самом деле значат перестать пытаться себя куда-то извернуть, кем вы не являетесь. По факту, терапия направлена ровно на это, на усиление понимания себя. Потому что именно когда приходит осознание "я вот такой, со всеми шероховатостями", происходит рост. Есть чудесная японская философия и стиль керамики kinstugi, про восхищение несовершенствовами. Это не совсем wabi-sabi, но в ту же сторону.

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

Применение в работе:
Исследуйте как организация и / или ваш проект сейчас функционирует. Почему выросли такие механизмы? В чем их польза? Чего хочет проект? Чего организация в себе как бы не принимает? Зачем нужно именение? Что оно даст? В чем "цена" изменения? Как вы можете поддержать переживания про изменение, если оно внешне-мотивированно?

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

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

Применение в жизни:
Да все то же, если честно.

Кому интересно копнуть глубже, читайте Карла Роджерса и paradoxical theory of change. Кому-то рассуждения выше слишком абстрактны. Читайте про эти модели, они тоже научно доказаны:
1. Lewin’s Change Management Model;
2. Kotter’s 8-step model for change;
3. Prosci’s ADKAR Change Management Framework;
4. Kübler-Ross change model
5. Nudge Theory for change management

Фантазии про реакции окружающих съедают ресурс.

Было у вас такое, что вы заранее пытаетесь предугадать как другой человек отреагирует на ваши действия и высказывания?
То самое "а что он(а) подумает". Да лааааадно, у всех бывало. Однако если ваши действия часто основаны на вашей идее что подумает другой человек без проверки этой гипотезы, то у меня для вас плохие новости.

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

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

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

Что делать? Проверять гипотезы об реальность. Всегда! Как только вам показалось, что кто-то что-то про вас подумал, что вы <подставить свое> человек, тут стоит словами через рот спросить открытым вопросом:
- Насколько оффер подлежит переговорам?
- Помогите мне понять бенефиты от этого проекта?
- Расскажите, что вы думаете про мои комментарии?
- Остановите меня, когда вам надоест, пожалуйста?

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

Кто сказал, что "надо"?

У вас наверняка есть убеждения, что "надо быть <каким-то>". Хорошим, добрым, вежливым, и тд. Или же "Нельзя отказываться от предложенной конфеты". Или же "Нельзя опаздывать". Или "Всегда сохраняй позитив, даже когда кругом говно".

Посмотрите внимательно на свои надо / нельзя + всегда / никогда + должен / обязательно и прочие абсолютизмы как на подсказки, о чем подумать, если вам в чем-то сложно жить и / или работать.

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

Кто вам сказал, что вот это ваше конкретное "так и никак иначе потому что а где это видано-то?!" есть правда и она только одна? Это точно ваша правда? Точно-точно?

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

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

Проверочные вопросы для проектных менеджеров

1) Первый самый сложный вопрос: Как поймешь, что твой проект зеленый?

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

2) Второй самый сложный вопрос: Тебя назначили на проект в его середине. Ты никого с проекта не знаешь. Что будешь делать в первые 3 недели?

Ответ показывает навык управления stakeholders, навык managing up, способности к исследованию, ценности, умение работать в команде, и в целом seniority.

3) Третий самый сложный вопрос: Тебе нужно внезапно презентовать генеральному директору твоей (крупной) организации твой проект. Вся встреча длится 15 минут, от и до. На подготовку есть 1 целый рабочий день. Как будешь готовиться, что показывать?

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

Зачем вам это?
* Как кандидату: подумайте заранее и пожуйте "а что еще тут можно сказать?".
* Как рекрутеру: забейте, пост не для вас. Вы не сможете оценить ответы, это не ваша область экспертизы.
* Как нанимающему: этими вопросами вы быстрее подсветите сложные места, чем вопросами по теории. И сможете быстро понять, сработаетесь ли вы с человеком. Вопросы формата "расскажите случай, когда у вас <> и что вы сделали?" никто не отменял, конечно же. По теории людей только не гоняйте, пожалуйста.

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

Спойлер: здесь нет правильных ответов. У каждого своя правда. Отличная тема для дискуссии, кстати. Цель - понять, какая правда ваша и с какой правдой соседа вы готовы работать.

Вымирающие профессии.

Project manager в понимании "отвечаю на вопрос КАК, координирую и фасилитирую, бизнес-решений не принимаю" это вымирающая профессия. Потому что современные product managers берут на себя бОльшую часть delivery. Вместо придумывания куда корабли будут бороздить, целыми днями они пилят фичи, режут требования, общаются со stakeholders и вот это все. А инновациями на самом деле занимаются только директора по продукту (Head of Product), и то не всегда. Часто новые продукты появляются просто потому что "рыночек и конкурентики", но это другая история.

С учетом роли продакта, Project manager - в продуктовой организации это интеграционная роль. То есть если процессы построены, а команды автономны, то проектных менеджеров мало и они занимаются проектами "насквозь" продуктовые вертикали. Когда проект настолько большой, что один-два продакта его вытащить не могут потому что проект займет все их время. Органически, на такие роли нужны более синьорные люди. Вот и рождается роль Program Manager -- meta-project-manager. Который общается с продактами и в команды заходит редко. Это как бы современная эволюционировшая версия проджекта.

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

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

Где-то посередине родилась роль Delivery Manager. Этакий супермен, который может примерно все, но не глубоко. Раньше эта роль была в основном в аутсорсинге. Сейчас же много вакансий формата Product & Delivery Manager / Project & Delivery Manager. То есть у вас часть задач оттуда, а часть отсюда. В разных пропорциях.

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

В итоге ответ на вопрос "стать мне проджетом или продактом" такой:

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

Что делать, если вы не нужны или стали over-qualified для вашей роли или организации?

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

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

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

Вторая мысль, наверное надо валить. Куда? Как? Рынок нынче так себе. Если нет понимания, чего хочется от карьеры, то будете болтаться как, кхм, винная пробка в проруби чуть ли не год. А что делать пока ищется новая работа не понятно.

Третья мысль, наверное можно найти компромисс. Нууууу, тут зависит. Что можно попробовать сделать:
1. Найти карьерного спонсора внутри конторы. Кто-то из начальства, кто за вас болеет и будет вас рекламировать. Так найдутся новые прикольные проекты и задачи.
2. Прямо поговорить с принимающим решения высоким начальством в формате "кажется моя роль вам больше не нужна, что вы можете мне предложить на перспективе года?". Тут же можно сказать "меня нанимали на это и то, а делаю я черт знает что". Потенциально вас могут сократить, но с золотым парашютом. Это не плохо, это отличный исход.
3. Найти внутренние вакансии, поменять роль, успокоиться
4. Поискать альтернативные пути: стать тимлидом, преподавать свой опыт, посмотреть на соседние ветки развития
5. Использовать свою seniority, но в приложении к мелким проектам. Например, если вы можете вытянуть 3-летнюю программу на 200 человек, возьмите на себя 5 проектов по полгода, но одновременно.

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

Здесь помогут прагматизм и эмоциональная нейтральность: вы это не ваша роль или профессия. Да, работа это важная часть идентичности, но она вас не определяет и точно не есть основной способ самореализации. Но! Работа тоже вызывает разные чувства. И в сценарии как выше оно люто бешенно бесит, в первую очередь потому что здесь не все можно проконтролировать 🙁

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

1. Собрать перспективы заинтересованных людей. Сравнить. Копать где не совпадают. Для этого надо:
а) Понять, кто заинтересован в проекте. Наверное, вас отправят к этому / этим людям.
б) Понять, кто еще заинтересован и вовлечен. Для этого по принципу снежного кома задавайте всем вопрос "с кем еще мне стоит поговорить?". Повторить до достижения частичной сатурации = пока не перестанут поступать новые большие вводные.
в) Во встречах 1:1 люди более склонны делиться своими сомнениями = у вас должно быть много 1:1 встреч. По пути заходите во все релевантные групповые встречи и просите вас туда звать, даже если вы будете только молчать и улыбаться - контекст все равно нужно собрать.

2. Разобраться, что хотели изначально, что обещали, что сделали и что осталось сделать. Это почти наверняка 4 разных набора штуковин! Для этого:
а) У всех людей из предыдущего пункта спросить "а что мне посмотреть / почитать / на какую встречу сходить"
б) Посмотреть / прочитать / сходить и сделать заметки где мнения расходится.
в) Узнать, что последнее показывалось и обещалось руководству. Спросить у руководства, а что они собственно ожидают за следующий например месяц. По пути разобраться с отчетностью. Кивнуть, уйти подумать.

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

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

1) Вы можете или кому-то наступить на хвост делая их работу, или не доделать работу, которую ожидают от вас.
2) Вы никак совсем никак не можете подписываться под сроками и статусом, которые вы не проверили.
3) Если у людей расходятся ожидания, в тех местах точно будут проблемы.

В первые 2-3 недели на проекте вы можете только обещать, когда вернетесь с полноценными обещаниями.