Как вывести проект из состояния «пожара»: пять шагов

Каждая команда, занимающаяся разработкой технологий и IT-решений, сталкивалась с ситуациями, когда проект находился в состоянии «пожара». Надежда Кузнецова, эксперт по управлению IT-проектами финтех-платформы ROWI, рассказала редакции РШУ о своем опыте и поделились лайфхаками, которые помогают не только сохранить проект в стабильном состоянии, но и улучшить его результаты.

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

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

Важно понимать, что мы здесь, чтобы помочь команде разобраться в ситуации, а не искать виновных. Для начала рекомендуем провести встречи с каждым заинтересованным участником проекта: партнерами, клиентами, командой и HR.

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

Кроме того, необходимо определить «почему сейчас так?» и «что привело к данной ситуации?» Наверняка, текущий подход применялся как наиболее подходящий для проекта в силу ресурсов, ограничений, компетенций.

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

На данном этапе проводится анализ команды: отслеживается процент увольнений с проекта и их причины, измеряется удовлетворенность, вовлеченность, экспертность, укомплектованность, культура и общая атмосфера, наличие критических зависимостей на одного человека (bus factor), отлаженность процесса подключения новых участников.

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

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

ЛАЙФХАК 1: Не надо бояться давать непрофильные задачи участникам команды. Это позволяет снизить вероятность выгорания и рассмотреть альтернативные направления для роста сотрудника.

ЛАЙФХАК 2: Если в команде не принято оставлять обратную связь, то необходимо сформировать привычку проведения ретро с командой или сессий 1-2-1. Правильный фидбек, даже если он негативный, позволит оптимизировать план действий и отслеживать динамику решения вопросов.

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

Рекомендуем проводить планирование в несколько этапов:

1. Подготовить максимально проработанную (с учетом имеющихся ресурсов и времени) документацию, техническое задание с описанием необходимых условий и требований для успешной реализации проекта. Обозначить важные маркеры, которые указывают, что задача, во-первых, может быть взята в спринт — DoR (Definition of Ready, список критериев готовности к выполнению работы конкретной командой/сервисом), а во-вторых, — считаться выполненной — DoD (Definition of Done, список согласованных критериев готовности задачи/продукта, зачастую представляющий набор действий, которые необходимо совершить над задачей, чтобы ее можно было считать готовой).

2. Определить количество допустимых задач, для реализации в спринте, на основании исторических данных производительности команды.

3. Выбрать подходящую методологию разработки (Scrum, Kanban, SAFe и т.д.), которая будет соответствовать формату работы команды и поставленным целям. Например, стоит учитывать вероятность частого внесения изменений в план, и далее, как вариант, заложить необходимые временные и ресурсные буферы или перейти на более подходящую альтернативную методологию.

4. Оценить качество поставленных задач. Это можно сделать через анализ различных метрик: соответствие факта изначальному плану, количество дефектов критического и высокого уровня, количество обращений в HelpDesk от конечных пользователей.

ЛАЙФХАК 3: Обязательно нужно включать бизнес-подразделение и смежные команды в рабочие процессы и делать их частью проекта. Это может помочь найти общие технические и бизнес-решения, согласовать технологический стек и определить приоритеты не только в разрезе одной команды, но и в рамках всего бизнеса. Это обеспечивает единое видение приоритетов и возможностей разработки.

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

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

ЛАЙФХАК 4: Важно поддерживать соответствие плана факту проделанной работы: выполнять обещания, которые дали клиенту и трезво оценивать при этом свои силы и сроки.

По мере работы над устранением кризисной ситуации, проект, как правило, проходит три этапа: «красный» — тушение «пожара», «оранжевый» — стабилизация работы над текущими задачами, «зеленый» — уверенное движение вперед, рост и развитие.

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

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

Зеленый. Стратегическое планирование и движение вперед. Должно быть видение, каким будет проект через 3-5 лет, если он долгосрочный, и уверенное движение к данному видению.

ЛАЙФХАК 5: Клиент и команда находятся в едином комплексе процесса проектной работы.

Чтобы проект оставался стабильным, недостаточно его просто вывести в «зеленую» стадию. Также необходимо придерживаться следующего плана действий: