Сестра, разряд! Инструкция по реанимации проекта
Привет, я Вика Строгонова, руководитель проектного офиса KTS.
В идеальном мире проекты выполняются в срок, в соответствии с бюджетом, с заранее определенными ресурсами и с должным уровнем качества. Однако в реальности может случиться так, что в процессе реализации проекта команда забрела не туда, и начинает пахнуть жареным.
Такой проект вам могут передать в комплекте с менеджером, или он может достаться вам «в наследство» после ухода другого сотрудника.
В этом материале речь пойдет не только о проектах, где всё плохо. В первую очередь я хочу обратить внимание на первые звоночки того, что на проекте что-то не так:
- Заказчик написал кому-то вышестоящему в компании о проблеме
- Перед очередным релизом что-то пошло не по плану, и команда работала в выходные
- Заказчик недоволен, что озвученные сроки уже несколько раз сдвигались
Содержание
Как поднять проект со дна
Алгоритм, о котором я хочу рассказать, не привязан к решению конкретных проблем: он универсальный и приводит в порядок любой проект. Это базовый набор мер, с помощью которых прозрачность и предсказуемость процесса значительно повышаются для всех его участников. Они снимают большинство корневых проблем на проекте и закладывают фундамент для дальнейших улучшений и решения уже индивидуальных ситуаций.
Шаг 1. Актуализировать статус проекта
Самый наглядный инструмент, который покажет ситуацию на проекте — доска с задачами в таск-трекере. С ее актуализации начинается разбор полетов проблемного проекта.
Часто менеджеры не уделяют должного внимания этому инструменту, и на таких проектах обычно на доске беспорядок.
В этой статье мы не рассматриваем проекты, в которых задачи вообще не велись на доске, но если вдруг у вас все настолько плохо – в первую очередь заведите доску и добавьте колонки, соответствующие вашему процессу. Даже если кажется, что для ведения задач не нужен таск-трекер и «все понятно в чате» — все равно заведите.
Алгоритм:
- Актуализируйте статусы задач по колонкам справа налево. В первую очередь нужно рассмотреть наиболее готовые задачи: bug-fix → test → in progress → to-do и так далее
- Проверьте, ко всем ли задачам есть описания. Все участники процесса должны понимать, что мы ожидаем по итогу выполнения каждой задачи. Описание должно быть исчерпывающим, чтобы команда могла приступать к работе, не расходуя время на уточняющие вопросы. Это поможет вам принимать конкретные решения в дальнейшем. Даже если разработчик говорит «ну тут-то мы знаем что делать» — это не значит, что задача будет сделана в соответствии с требованиями, и что тестировщик тоже поймет задачу
- Проставьте оценки в задачи. Оценка должна быть видна на карточке задачи. Это помогает управлять приоритетами и понимать, когда что будет готово
- Удалите лишние задачи из колонки to-do. В колонке должны находиться только задачи, которые должны делаться в ближайшее время
Результат: все задачи находятся в актуальном статусе, вы можете использовать доску для обсуждения задач и дальнейших шагов с командой и заказчиком.
Когда доска приведена в порядок, вы сможете быстро ориентироваться в проекте и обсудить с заказчиком проблемы проекта.
Шаг 2. Встретиться с заказчиком 1 на 1
Если менеджер, который вел проект, все еще на нем работает, то с заказчиком лучше встретиться без него. Конструктивному диалогу может помешать эмоциональный багаж менеджера и желание оправдать ошибки. Но на этом этапе нужно не разбираться, из-за кого возникла проблема, а максимально быстро ее решить.
На такой встрече важно признать объективные ошибки команды и обозначить дальнейшие шаги по их решению.
План встречи:
- Соберите фидбек с заказчика. Важно не получить информацию по всем проблемам, а выявить наиболее критичные на данном этапе
- Признайте ошибки со стороны команды, если они есть
- Назовите конкретный срок, когда вернетесь к заказчику с решением. Для этого нужно понять, сколько времени потребуется на встречу с командой и выработку решений. В идеале – до конца дня вернуться к заказчику с планом действий по ближайшим шагам
Если заранее понятно, что «корень» проблемы на нашей стороне, то лучше сразу обсудить проблему с командой и пойти к заказчику уже с готовым решением.
Шаг 3. Встретиться с командой
В рамках встречи с командой нужно провести разбор полетов и обсудить, что было сделано не так. Задача такой встречи – не поиск виноватых и их публичное порицание, а совместное обсуждение проблем и выработка решения. Если команда вовлечена в процесс, получившийся план не будет восприниматься ее членами как очередное «потому что менеджер так сказал».
Чек-лист:
- Разберите ситуацию, возникшую на проекте
- Проговорите, как не допустить повторения ситуации
- Обсудите шаги по решению проблемы и зафиксируйте их в чате с командой
- Назначьте регулярную встречу для контроля работы команды (если она нужна)
Кейс: расставляем приоритеты правильно
У меня была ситуация, что на проекте мы раз в неделю показывали заказчику новые работающие фичи. В какой-то момент заказчик пришел напрямую ко мне в обход проджект-менеджера и сказал, что уже месяц не видел результатов работы. При этом невооруженным взглядом видна активная работа команды.
Я, как обычно, начала с актуализации доски. Уже на этом шаге вскрылась одна из проблем проекта — задачи по какой-то причине копились на этапе исправления багов.
Вместо того, чтобы в первую очередь выполнять задачи, которые стоят ближе всего к продакшену, команда часто брала новые задачи, исходя из того, что фичи важнее мелких правок. Как следствие, разработка превратилась в снежный ком и команда не могла отдавать в релиз завершенные задачи.
В этом проекте заказчику было важно видеть промежуточные результаты работы для показа топ-менеджменту. Поэтому основной ошибкой команды была неверная расстановка приоритетов при большом количестве задач и ограниченном ресурсе разработки.
Для дополнительного контроля мы назначили еженедельную встречу с командой. На ней мы планировали задачи на следующую неделю, оценивали и приоритизировали их с учетом рисков. Для этого мы использовали диаграмму Ганта. Это помогло обозначить среднесрочные планы для команды и заказчика и сделать проект более понятным и прозрачным для всех.
В заключение
Когда вы врываетесь в проблемный проект, важно собрать фидбек с разных сторон, чтобы получить объективную информацию о его состоянии.
Мой опыт показывает, что вместо решения всех проблем проекта, эффективнее выделить наиболее критичные и сосредоточиться на шагах, описанных выше.
Когда доска актуализирована, главная боль заказчика решена и команда настроена на улучшение процессов, можно приступать к решению других, менее приоритетных проблем.
Кстати, сейчас мы ищем системного аналитика уровня middle. Подробнее о требованиях и условиях можно посмотреть по ссылке: