Всем привет!
В одном из чатиков (PM Lunch) одним из участников был озвучен интересный вопрос: а что делать новоиспеченному PM'у после назначения в проект? В данной статье я бы хотел описать приблизительный алгоритм действий в медовый месяц 👨💼.
Надеюсь, что статья вызовет некоторую дискуссию по теме. Очень хотелось бы, чтобы вы поделились своим опытом входа в новую команду.
Оригинальный вопрос звучал так:
Ребят, привет. Нужен совет. Как быстро вкатиться в проект? Пришел в компанию на уже запущенный проект. Дедлайн стоит к концу месяца. Куча задач. ПО контролируют выполнение задач. Дорожной карты нет. Есть названия фич которые ожидают получить - фича1, фича2... фича 10. В некоторых фичах есть небольшие подразделы. есть грубая оценка по срокам. Часть работы выполнена. Не понятно состояние где сейчас находимся. Что готово а что осталось. Успеваем к сроку или нет. Из отчетов команды не ясно над какой фичей работают. Задачи заводят по ходу дела... Работают недельными спринтами. Первым делом я хочу нарисовать ИСР и дорожную карту - привязать к как-то к календарю. Ну и как-то надо побыстрей вникнуть в терминологию , чтобы понимать на дейликах, о чем идет речь.
Первое время у новоиспеченного менеджера происходит процесс получения эндорфина, чувствуется эмоциональный подъем и высокая мотивация все исправить, сделать "как надо". Зачастую в голове мысли вида: "Наконец-то, вот сейчас-то я наведу тут движуху в болоте, сделаю по правильному! ИСРы нарисуем, диаграммы Ганта построим и вообще заставим всех быть эффективными!".
Менеджеры по своей сути - всегда эмоциональны. А делать дело на эмоциях- это ошибочный паттерн поведения. Особенно, когда вокруг новые люди, другие процессы и неизвестные ожидания ключевых заинтересованных сторон.
В этом посте я буду опираться на модель формирования команды Берна. Полезно также ознакомиться с другими описательными моделями команды:
- Модель Брюса Такмана
- Модель М. Е. Литвака (гуглить по ключевым словам "Карьеристы", "Культурники", "Алкоголики")
Модель команды Берна содержит две границы власти:
- Внешняя граница;
- Внутренняя граница;
Концепт этой модели состоит из следующих частей:
- У команды должна быть внешняя граница для определения "свой-чужой" и есть некоторая общность интересов.
- Есть внутренние границы, где некоторые члены команды создают законы, по которым живут остальные участники. Если какой-то член команды не соблюдают правила, то его могут и исключить.
Из концепта модели становится понятно, что новому менеджеру необходимо пересечь из внешней среды сразу в центр круга. Очевидно, что если это делать топорно и без плана, то команда такого человека сразу же и отвергнет.
- Во внутреннем круге могут находится несколько человек. Например, это PM, продуктовый менеджер (Product Owner) и Ведущий разработчик.
- Внутри внешнего круга также могут происходить различные движения и тряски. Это происходит из-за нахождения членов команды в разных квадратах матрицы компетенции-интереса (к проекту / продукту).
Действующие лица
Для описания ситуации в посте нам потребуется ввести некоторые количество персонажей в нашу историю:
- Мартин Алексеевич (МА) - новый руководитель проекта, который успешно получил офер в компанию.
- Борис Борисович (ББ, БигБосс, Спонсор) - человек, который нанял Мартин Алексеевича на роль PM'а в проект.
- Захар Самуилович (ЗС) - заказчики проекта и ключевые заинтересованные стороны.
- Команда проекта (КП) - коллеги, которые выполняли ранее операции проекта. их много.
- Сергей Максимович (СМ) - предыдущий руководитель проекта, который куда-то делся. Может быть ушел сам, а может быть и ушел "плохо".
- Станислав Петрович (СП) - смежные проекты или отделы, подрядчики.
Ситуация
Рассматриваемая ситуация - следующая:
- Существует проект, который находится на какой-то стадии. Каким-то образом этот проект делался ранее и реализовывается сейчас.
- Письмом ББ назначает Мартина Алексеевича (МА) руководителем проекта (КП).
- Предыдущий менеджер (СМ) куда-то делся. Наверняка, есть официальная и неофициальные версии произошедшего. В КП - стресс.
Примечание: так вышло, что в организации отсутствует Устав проекта (да и вообще какой устав, если используется Scrum?). Руководством в лице ББ было принято волевое решение о продолжении проекта, а не его перезапуске из-за смены PM'а.
Мысли в головах
Представьте себе ситуацию о назначении нового руководителя для вас. Какие вопросы пытается задать себе мозг в первое время?
- Это кто ваще, ааааа? Почему он? Он ваще служил?
- Почему не я? Я ведь служил!
- А как пить пиво по четвергам? Ведь предыдущий - пил.
- За что его так, бедолагу? // В ситуации, когда понятно, что должность расстрельная
- О! А я ведь его знаю! Может быть он поможет мне решить мои амбиции?
У всех все по разному...
Представьте себя на позиции ББ:
- А не поедут ли сроки?
- А правильный ли выбор я сделал? Справится ли МА с проектом?
Захар Самуилович приуныл сразу же, т.к. теперь сроки проекта поедут точно. Станислав Петрович в недоумении, а что делать дальше? Как же теперь ему работать с МА?
Из всей этой ситуации можно выделить группы людей, которых беспокоит новое назначение:
- Команда проекта
- Спонсор / руководитель
- Заказчики
- Смежники
У каждой из групп есть свои надежды, ожидания, страхи и опасения. Есть большое количество вопросов, на которое сходу нет ответов. Мартин Алексеевич должен посвятить свой месяц на работу с каждой группой: ожидания и надежды - услышать; на вопросы - ответить; снять опасения и страхи. Ему важно войти во внутренний круг власти. При этом, законы и ритуалы создавались не им, но у него есть полномочия их изменить - люди боятся изменений, у них на них аллергия!
Оговорка: штормит не всех. Наверняка, есть сотрудники, которые просто делают свою работу и делают ее хорошо.
Реакция на изменения
- Мозг человека так устроен, что он автоматически анализирует изменения:
- Активное или пассивное произошло изменение?
- Полезное или бесполезное это изменение?
- Опасное или безопасное изменение?
Назначение МА на роль руководителя проекта - это изменение привычного порядка работы и жизни. Для облегчения входа в команду наш герой МА должен быть одновременно полезным и безопасным.
Выводы:
- Чтобы стать активным нужно привлекать ББ, человека с правами назначать нового члена команды. Нужно попросить его формально авторизовать власть в проекте и объяснить КП официальную причину такого изменения.
- Чтобы стать безопасным не нужно бросаться что-либо менять и делать по-другому. Революция не нужна никому - на нее не хватает авторитета и неформального лидерства.
Первые шаги, которые можно сделать в этой ситуации:
Признать текущие достижения команды.
Дать КП понять, что революции не будет. Да и вообще, первое время основной задачей МА - это ничего не сломать и не усугубить.
Чтобы быть полезным наш герой МА должен разобраться, а что собстенно происходит?
После анализа ситуации мозг человека генерирует большое количество вопросов. А что же происходит в голове, если вопрос есть, а ответа - нет?
- Человек начинает додумывать (если может).
- Берется аналогичный пример из опыта (если такой опыт есть).
- Человек пытается проецировать себя на место инициатора события / главного героя.
Если человек себе уже сформировал картину произошедшего, то переубедить его в будущем может быть настоящей проблемой! Поэтому, пока есть вакуум в мозгах ответы на причины событий или изменений должен дать тот, кто эти события / изменения предпринял. В нашей истории таким человеком должен стать ББ, который используя свою власть принял решение о назначении МА.
- Если в голове человека существуют страхи/опасения, то естественной реакцией является сопротивление:
- Кто-то может явно или неявно перестать хорошо стараться работать.
- Некоторые могут даже пойти на саботаж процессов из-за обиды!
- Коллегам МА не понятно, а что с ними будет завтра / в будущем?
Если Мартин Алексеевич внедрит изменения сразу же после прихода в команду, то это может сказаться на привычном укладе жизни. В свою очередь, это вызовет сопротивление из-за отсутствия авторитета (а в некоторых ситуация, и смысла - полезности).
Со страхами и опасениями надо работать!
Для этого рекомендуется назначать 1-1 со всеми членами команды.
В случае саботажа МА должен применить следующий алгоритм:
- Учить - снимать страхи и опасения, если возможно.
- Лечить - договариваться, аргументируя официальной версией.
- Гасить - МА обладает властью, демонстрирует, что может ее применить.
Алгоритм входа в команду
Когда новый менеджер входит в команду, то все приходит в движение. Не все члены команды готовы принять эти изменения, ведь это прямо влияет на привычный ритм работы.
Используемые техники:
- Легитимная передача власти.
- Попросить совета (у коллег).
- Маленькая победа.
Для того, чтобы МА влиться в команду нужно получить информацию:
- Планы руководства по проекту / команде
- Планы заказчика по проекту / команде
- Планы сотрудников по работе в команде
- Унаследованные обещания / обязательства
- Существующие организационные и технические проблемы
Группы для обхода (опроса / коммуникации):
- Команда.
- ББ / заказчик.
- Компания // соседние департаменты, отделы, проекты.
Алгоритм обхода получается следующим:
0. Раздобыть контакты предыдущего менеджера. Если он ушел "хорошо", то позвать его на кружку чая / пиво / чего покрепче:
- Узнать кто есть кто в команде? Уточнить о существующих конфликтах.
- Узнать о существовании некоторых обещаний и т.п.
- Узнать об алгоритмах коммуникации в компании.
Это нулевой шаг, который применим к алгоритму в целом.
- Собрать встречу с командой.
- Произвести легитимную передачу власти. На встречу позвать ББ, попросить его рассказать об официальных причинах изменений.
- Признать текущие достижения команды.
- Попросить время на разбор текущей ситуации в команде и проекте. // Как минимум, некоторые обновят резюме завтра, а не сегодня
- Пойти на встречу с ББ, выяснить его ожидания от работы МА.
Прежде похода к ББ стоит выяснить у смежных менеджеров стиль коммуникации с ББ. Дополнительные инсайды взять у предыдущего менеджера. // Позволит не накосячить сразу
- Узнать, а с чего бы начал ББ? Что с проектом с его точки зрения?
- Узнать, а что с предыдущем менеджером? Что он делал хорошо, а что можно сделать лучше?
- Задать вопрос: "А что еще я у вас не спросил?" // Позволит включить мозг ББ
- В процессе общения с ББ узнать, а не стоит ли сходить к Заказчику? Вполне возможно, что на этом шаге ББ сам инициирует встречу и придет на нее.
В случае, если случилась встреча с Заказчиком:
- Не давать обещаний! Нужно переговорить с командой.
- Узнать, а что болит больше всего? Какие есть "глобальные" проблемы?
- Задать открытый вопрос вида "Что еще не спросил МА?"
- Вернуться к команде после общения с ББ (и заказчиком)
- Рассказать о результатах общения с ББ (и заказчиком)
- Озвучить понимание, что у команды есть вопросы к МА. Некоторые вопросы невозможно задать на общей встречи, поэтому, пообещать назначить встречи 1-1. Рассказать об отсутствии революции и изменениях в команде.
- Назначить 1-1 встречи с членами команды. Со всеми!
- У кого есть вопросы - назначить встречи 1-1 в первую очередь.
- На встречах 1-1 выяснить ожидания, страхи и опасения. Если есть готовые ответы на вопросы - озвучить их.
- Если есть новые обещания, то вернуться к ББ для их обсуждения.
- Назначить встречи смежным командам
- Обсудить дальнейшее взаимодействие
- Узнать о существовании обещаний.
Заключение
Первый месяц нового руководителя проектов называют "медовым". В этот период происходит шторминг и форминг команды. У менеджера происходит огромное количество коммуникаций! Важно соблюдать все прежние ритуалы и действовать согласно алгоритму.
Ни в коем случае не устраивать революции с первых дней.
В описании задачи есть сокращение "ПО". Я бы спросил у человека, "ПО"- это проектный офис или программное обеспечение? Если есть проектный офис, то адаптация нового руководителя проекта как раз их зона ответственности.
Из описания задачи можно предположить, что человек раньше не работал с подобными методиками управления проектами и в этой отрасли, следовательно назначение на проект - вынужденный смелый шаг или ошибка руководителя.
"Определитесь с терминами и половина споров пройдет". Нужно договориться что называть проектом, а что продуктовой разработкой с ограниченными ресурсами.
Предполагаю, что уже на первых 2-3 ежедневных собраниях новый руководитель сам поймет что в работе, что сделано и требует проверки, а что ещё в бэклоге. Если общей системы нет (доски со стикерами, файлика с перечнем задач и статусами) то нужно эту систему ввести. Этой системой может быть специализированное программное обеспечение для командной работы, либо, в крайнем случае, один наиболее информированный человек, который сможет структурировать информацию и регулярно ее поддерживать в актуальном состоянии (это может быть администратор проекта).
Кроме того, что уже назвал Сергей, предлагаю выяснить: