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