Оставайтесь собой.

Один из маркеров высокой seniority (уровня профессионализма) проектного менеджера - способность быть собой в коммуникациях. В том числе само-предъявляться что "оно не полетит". В том числе аргументированно не соглашаться и органично убеждать группу принять непопулярное решение.

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

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

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

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

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

В категорию "оставаться собой" еще входит понимание своих ограничений. Например, я отлично умею делать технические проекты, особенно платежные и инфраструктурные. Но если поставить меня на проект открытия нового офиса, не факт что я буду правильным / успешным менеджером. Я отлично настраиваю процессы внутри и между своих проектов, но мне сложно раскачивать процессные изменения на всю компанию. У меня достаточно технических знаний чтобы читать архитектуру, но если проекту нужен бывший руководитель разработки (EM) или чувак с техническими знаниями уровня Solution Architect / Staff Engineer, то я не подойду.

Проактивное озвучивание таких ограничений показывает, что вы хорошо знаете себя и свои лимиты, тоже говорит про открытость и "Я вот такой. Не нравится - не ешьте". Что есть показатель высокой seniority.

Да, проектный менеджер не должен сильно разбираться в предмете своего проекта.**** Но некоторый опыт по теме таких проектов полезен. Да, проектный менеджер не решает, что и почему мы делаем. Но он должен понимать что может пойти не так с точки зрения бизнес-контекста его проекта. Этот подход превращается в "Понимаю зачем нужны и что такое SLA / SLO для моего сервиса, но как их настроить с нуля я хз и пойду спрошу технического чувака".

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

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

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

Уровень 1: помоги себе сам. Один раз написать гайды что делать если, дать шаблоны и отправить лида проекта (не-менеджера) в свободное плавание. Навык настраивать само-помогающие штуки для типичных проектов приходит год на пятый работы - нужен опыт. Эта способность - признак seniority. Не-менеджер = человек, который по каким-то причинам формально ведет проект, тимлид, продакт или EM, но которому нужна помощь. В performance review / CV продается как "implemented lean guidelines for managing typical projects". В планировании capacity команды проектных менеджеров продается как "снизить число запросов на назначение проектных менеджеров чтобы освободиться для более сложных проектов / стандартизировать процессы". Типичная задача для руководителя проектного отдела.

Уровень 2: спроси меня, где тебе надо. Действуем по принципу "держать за ручку". Лид проекта (не-менеджер) сам копает свой проект, желательно по вашим шаблонам и инструкциям. И периодически спрашивает "а как мне сделать вот такой отчет" или "у меня проблема оценить проект, помоги". Другими словами, менеджер тратит час-два каждые N недель на таргетированный менторинг. Хорошо работает чтобы добавить лидам уверенности в своих действиях. В performance review / CV продается как "mentored project leads to ensure project success". Для команды проектных менеджеров продается как увеличение зоны влияния и менторинг.

Уровень 3: я тебе скажу как надо. Менеджер проактивно говорит как лиду менеджить проект, ходит на основные проектные встречи, но не числится проектным менеджером этого проекта. То есть вовлекается на 1-3 часа в неделю на менторинг-консультирование. Хорошо работает чтобы помочь лидам вырасти в проектных менеджеров. В performance review / CV продается как "Overseen N projects by coaching project leads and steering the project direction to ensure delivery success". Для проектной команды значит "мы придумали как вам помочь, хотя у нас так-то нет свободных менеджеров".

Уровень 4: налей и отойди, я тут менеджер. Собственно стандартный вариант управления проектами. Менеджер есть менеджер, на нем коммуникации, красивые слайды и сбор вводных от команд(ы). Он не решает что и почему мы делаем. Не вкладывается в технические и бизнес решения, для этого есть другие умные люди. Для сложных и больших проектов мало масштабируется. Для маленьких - в заивимости от уровня seniority, можно одновременно брать от 1 до скажем 5 проектов. Это как жонглирование мандаринами, знайте свои лимиты 🙂

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

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

Я эти уровни сама придумала, в литературе их нет. Но! Я это внедрила в 4 организации разного размера и всем, даже мега-опытным проектным менеджерам такая схема очень нравится 🙂

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

Любая проектная бумажка - инструмент коммуникации и без четкой цели бесполезна.
Классический проектный менеджмент и всякие аудиты попросят вас показать 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 в части репортинга, навыки командной работы, способность связно коммуницировать, работу под давлением и много чего еще.

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

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

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