Пожалуй, сложно найти того, кто не знает, что такое проект или ни разу не участвовал в проектной деятельности. А также того, кто не испытывал это чувство неизвестности, неопределенности или волнения на старте проекта.
Я Александр Жульков, руковожу внутренними инфраструктурными проектами в Cloud.ru. В статье расскажу, как понимание жизненного цикла развития команды поможет руководителю проекта снизить градус неопределенности в проектной деятельности, а также улучшить проектное управление в целом.
Что такое эволюционная модель команды проекта
Проект сам по себе — это деятельность с высокой степенью неопределенности. А проектная команда — ключевой элемент, созидающий продукт.
Эволюционная модель проектной команды — это взгляд на команду как на живой организм, который развивается по законам эволюции. Поэтому модель включает четыре основных стадии развития: детство, юность, зрелость и мудрость.
Каждая из стадий в нашей модели соответствует тому или иному этапу проекта:
детство — старту проекта и этапу проектирования;
юность — этапу, на котором формируется MVP;
зрелость — этапу, на котором идут доработки и интеграция;
мудрость — выводу продукта в эксплуатацию и завершению проекта.
А еще на каждом из этапов есть свой действующий фактор — такой фактор, который воздействует на команду в позитивном плане. На него стоит делать упор при управлении, чтобы команда могла по максимум раскрыть свои возможности и достичь высокого уровня эффективности. А помогут в этом лидеру выбор фокуса внимания и модели поведения — на каждом этапе они будут разными.
Так как же работает эволюционная модель команды проекта? Давайте разбираться на примерах — поделюсь реальными историями из моей работы в различных компаниях и проектах.
Детство: первая стадия
Что происходит на этом этапе понятно каждому: команда только собралась и начинает формироваться. Отмечу ключевой момент — от того, как будут сформированы первые «коммуникационные потоки» и налажено взаимодействие, будет зависеть и будущее команды — успех либо сложности на протяжении всего проекта.
На чем лидеру стоит держать фокус? В первую очередь на снижении неопределенности. Для этого, во-первых, лидеру команды нужно захватить инициативу, предложить команде практику конструктивной коммуникации и решения производственных вопросов. Причем, как по задачам проекта, так и около проектным задачам, которые могут возникать (и обязательно возникнут). Это можно назвать установкой «операционной системы» команды.
Во-вторых, выделить инструменты и каналы взаимодействия, как минимум два (например, чат и почта или почта и видеоконференцсвязь). А еще обозначить, как часто собирается команда, как эскалируются возникающие конфликты, что и в каких ситуациях стоит сделать и так далее. В общем, покрыть базовые вопросы команды и тем самым уже на порядок снизить градус волнения перед новым и неизвестным.
И второй основополагающий момент — формирование атмосферы безопасности. Как? Для начала лидер команды должен транслировать, что у каждого есть право на ошибку. И самое главное — обсудить, договориться с командой, что именно стоит делать, если понимаешь, что «зашел не туда». С каких шагов начать — сразу выйти на лидера и оперативно сообщить, что выбранный путь оказался неверным, а не тайно в одиночку пытаться решить проблему. Ведь это очень важно — именно в начале проекта у нас еще есть ресурсы и время для того, чтобы всё продумать, нивелировать ошибку или полностью ее устранить.
Правило «право на ошибку» дает колоссальную энергию, которая помогает команде выходить на лучшую продуктивность. Когда в команде установилась атмосфера безопасности (к слову, базовой потребности любого человека), участники раскрепощаются и направляют внутренний ресурс уже не на тревогу и волнение, а творчество и генерацию крутых идей. Как обещал, приведу два примера из моей практики.
Первый пример — про то, как важна атмосфера безопасности. Я работал над крупным проектом в большой госкорпорации, проводил стартовую встречу с командой — на ней я всегда рассказываю о тех принципах, по которым мы будем работать. Рассказываю, что считаю, что право на ошибку есть у каждого. И вдруг на этой встрече у одного из разработчиков буквально вырвалось: «как хорошо, что ты это сказал...». У человека камень с души упал! И это ощущение затем покатилось по всей команде. Все буквально выдохнули. И с этой командой мы затем успешно реализовали большой и сложный проект. Вот таким несложным действием можно вызволить большой запас энергии, которая особенно важна на старте проекта.
Второй пример — про гибкие границы проектных ролей. Роли есть в любом проекте: архитектор, разработчик, тестировщик, аналитик. Границы этих ролей очерчивают ту или иную область ответственности. И именно на этапе формирования команды, этапе «детства» можно эти границы динамично двигать.
Что было: на один из проектов к нашей команде присоединился главный архитектор, который должен был оценить обстановку и принять ключевое решение. Он великолепно знал все решения на рынке, их сильные стороны, минусы и плюсы, мог любому варианту дать подробную оценку. Но проявился один большой минус: он никак не мог принять окончательное решение и выбрать один вариант. И все наши попытки его на это побудить ни к чему не приводили. Тогда я сделал отдельную встречу, на которой собрал только равных по компетенциям (а это уже само по себе более безопасная атмосфера) — архитекторов по кибербезопасности, инфраструктуре, технических архитекторов и других. Цель встречи — выбрать конкретное решение. К чему мы в итоге пришли? К тому, что «миссию» принять финальное решение участники в итоге с главного архитектора переложили на технического ?. И это спасло ситуацию — решения принимались своевременно, работа по проекту пошла дальше. Так что, если ситуация того требует, можно гибко двигать границы ролей. А еще здесь большой шанс для членов проектной команды относительно «безопасно» примерить на себя задачи других ролей, которые стоят у них в карьерных планах.
Юность: вторая стадия
Особенность второй стадии — креативность. Почему? Да потому что на этом этапе команда начинает создавать нечто новое — вплотную приступает к реализации тех задач, которые определили на этапе проектирования.
А еще то, что я называю дерзостью. Конечно, в положительном смысле. Дерзать — это смело стремиться к чему-либо новому и благородному. Побуждать команду дерзновенно подходить к задачам — значит пробуждать в них ту энергию, которая позволит вывести работу на максимально продуктивные значения производительности. Каждая задача должна восприниматься участником команды через призму удивления — неужели я это могу? Неужели получится? И задача руководителя такой энтузиазм подкреплять и поддерживать.
Объясню на примере. Ситуация следующая: в работе проект для подрядчика со своим референтным решением, которое мы в команде должны серьезным образом переработать. И по договору в его скоупе находится три предприятия (это более 3 000 человек) и 19 информационных систем. Прошло проектирование, начинаем выполнять задачи по созданию ядра решения и тут выясняется, что SAP-модуль, который занимается передачей кадровой информации в нашу систему IDM, имеет серьезные проблемы масштабируемости. Получается, что в рамках договора подрядчик свои требования закрывает и испытания нормально проходит, но в дальнейшем уже не сможет масштабироваться (наше решение на всю дивизионную структуру — это более 100 предприятий, более 100 000 пользователей и около 200 корпоративных систем). Модель перестанет давать нужную производительность и мы выйдем за рамки допустимых значений по информационному обмену. Что делать? Проблема реальная и большая. Не сейчас, но в ближайшем будущем.
И тут «вызывается» наш технический архитектор — говорит, что видит серьезные пробелы в текущей реализации у вендора и предлагает решить эту задачу по-новому (сделать редизайн). Мы просим его оценить фронт работ по времени и он решает, что всё займет около месяца. Что же делать? Даем ему этот шанс, рискуем и перестраиваем работу всей команды. Он работал в выходные дни и даже ночью, но проект не стоял на месте. Каждый делал свою часть работы, но командные встречи и другие активности мы всегда подстраивали под него, с учетом его загруженности. И здесь я имею в виду, что продуктивность всей команды может напрямую зависеть от продуктивности одного участника, если он играет ключевую роль в проекте.
Что сказать, наш архитектор больше чем в три раза превысил этот срок (в процессе открылось второе дно и даже третье, как это часто бывает). Но в итоге проект мы завершили достойно и успешно.
Зрелость: третья стадия
На этом этапе мы видим, что команда работает как единый механизм и пульсирует на одной частоте, работает в одном ритме. Если вы всё верно сделали на предыдущих этапах, то, в принципе, вы этого гарантированно достигнете.
С чем это можно сравнить? Как будто команда на качелях, которые качаются с огромной амплитудой, и чтобы сохранять эту скорость, от лидера достаточно совсем небольшого импульса в нужный момент. Каждый член команды ощущает этот единый порыв максимальной производительности, а если вдруг кто-то начинает быть немножко «не в ресурсе», то быстро восполняет свою энергию. Его вовлекает в работу эта мощная энергия единой команды, чувство локтя соседа, ощущения единства целого с командой.
Вот пример: серьезный проект с контролем на разных уровнях, в том числе на госкорпорации. На одном из регулярных статусов я докладываю о проекте, о проблемах (а они всегда существуют) и рисках проекта. И слышу от одного высокопоставленного руководителя: «Вы так говорите о проблемах, что ощущение, что их на самом деле нет. Такую невозмутимость руководителя проекта я впервые встречаю!». Конечно, приятно такое слышать, но как оно так получилось?
Всё просто — вы так раскачали команду на предыдущих этапах, что она уже работает как бы по инерции. И особенно важно, что сейчас любой неверный импульс может погасить эту энергию. Проект уже перешел свой зенит, надо двигаться к завершению, но на этом этапе нередко появляется кто-то (чаще со стороны заказчика), кто хочет его дополнительно проконтролировать — придумать какую-то еще отчетность, посчитать дополнительные метрики и так далее. А это дополнительная работа — команда отвлекается, энергия утекает на смежные задачи. В этот момент лидеру особенно важно отстоять интересы команды, защитить ее и уберечь. Общая энергия, которую вы зародили на ранних этапах, — это серьезная поддержка, фундамент и уверенность, которая помогает отстаивать интересы команды перед руководством и внешними событиями.
Мудрость: четвертая стадия — финальная
Часто возникает соблазн быстро завершить проект: хорошо поработали и разбежались. Но для правильного завершения всё-таки нужен отдельный этап, финальный аккорд — «вознаграждение» за потраченные усилия. И речь не столько о финансовом или денежном аспекте. Речь о том, что, когда команда вкладывалась в проект (особенно, если он был протяженный — от трех месяцев и более), недостаточно просто сказать всем: «молодцы, здорово поработали!». Та энергия, которую участники постоянно генерировали, всплескивали — она просто огромная. Поэтому организм и психика требует реального, физического воплощения заслуг: как минимум неоднократно и разнообразно похвалить самого себя и других, отметить, что мы молодцы.
Чтобы восполнить баланс, каждый должен получить что-то осязаемое в конце проекта. Самому себе презентовать результаты в красивой обертке. Например, это может быть что-то вроде дембельского альбома, в котором будут истории, стихи, анекдоты, комиксы, шаржи, да всё что угодно!
Провести разбор полетов, ретро, а затем отметить завершение — полезные практики, которые позволят как вам, так и остальным участникам, входить в новый проект в очень энергичной позиции.
Последний пример. Уже не из рабочей практики, а из жизни. Если помните, раньше были пионерские лагеря. Первый раз я поехал в пионерский лагерь после первого класса школы и закономерно попал в самый младший отряд — десятый. В тот год всё было отлично, весело и интересно. Но в следующее лето на пункте отправки выяснилось, что меня почему-то записали в четвертый отряд, к ребятам на три-четыре года старше. И никто в этой схеме ничего не стал менять — так я провел в «чужом» отряде целую смену. А у них программа, мягко говоря, другая — выше уровень ответственности и поручений. И мне приходилось вместе с ними «тянуть» все эти требования. И я помню — чтобы соответствовать, я проводил внутри себя мини-ретро и регулярно рефлексировал: как себя вести, что сказать, как лучше сделать, как перераспределить ресурсы, чтобы быть с ними на уровне. И это позволило мне потом, на следующий год, быть в своем третьем отряде самым компетентным и уверенным — я уже знал практически всё, что может случиться, границы лагеря и все его истории. Проблемы и сложности меня уже не пугали. И в IT таких примеров, думаю, тоже много можно найти — хватит на большой сборник историй?.
Итоги
Возможно, у вас возник вопрос — а если я уже в проекте, то что делать? Доводить как есть, ждать следующего? Вовсе нет: начните с диагностики команды и поймите, на каком этапе вы находитесь. И в зависимости от этого выбирайте нужный фокус и инструменты — они помогут вылечить все «детские болезни» команды и эволюционировать до нужной стадии развития проекта?.
Если остались вопросы, задавайте их в комментариях и делитесь историями из своих проектов — буду рад почитать, обсудить и забрать «в копилку» для будущих статей и выступлений по этой теме.
Полезные материалы в блоге: