Сестра, разряд! Инструкция по реанимации проекта

Сестра, разряд! Инструкция по реанимации проекта

Привет, я Вика Строгонова, руководитель проектного офиса KTS.

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

Такой проект вам могут передать в комплекте с менеджером, или он может достаться вам «в наследство» после ухода другого сотрудника.

В этом материале речь пойдет не только о проектах, где всё плохо. В первую очередь я хочу обратить внимание на первые звоночки того, что на проекте что-то не так:

  • Заказчик написал кому-то вышестоящему в компании о проблеме
  • Перед очередным релизом что-то пошло не по плану, и команда работала в выходные
  • Заказчик недоволен, что озвученные сроки уже несколько раз сдвигались

Содержание

Как поднять проект со дна

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

Шаг 1. Актуализировать статус проекта

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

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

В этой статье мы не рассматриваем проекты, в которых задачи вообще не велись на доске, но если вдруг у вас все настолько плохо – в первую очередь заведите доску и добавьте колонки, соответствующие вашему процессу. Даже если кажется, что для ведения задач не нужен таск-трекер и «все понятно в чате» — все равно заведите.

Алгоритм:

  • Актуализируйте статусы задач по колонкам справа налево. В первую очередь нужно рассмотреть наиболее готовые задачи: bug-fix → test → in progress → to-do и так далее
  • Проверьте, ко всем ли задачам есть описания. Все участники процесса должны понимать, что мы ожидаем по итогу выполнения каждой задачи. Описание должно быть исчерпывающим, чтобы команда могла приступать к работе, не расходуя время на уточняющие вопросы. Это поможет вам принимать конкретные решения в дальнейшем. Даже если разработчик говорит «ну тут-то мы знаем что делать» — это не значит, что задача будет сделана в соответствии с требованиями, и что тестировщик тоже поймет задачу
  • Проставьте оценки в задачи. Оценка должна быть видна на карточке задачи. Это помогает управлять приоритетами и понимать, когда что будет готово
  • Удалите лишние задачи из колонки to-do. В колонке должны находиться только задачи, которые должны делаться в ближайшее время

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

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

Шаг 2. Встретиться с заказчиком 1 на 1

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

На такой встрече важно признать объективные ошибки команды и обозначить дальнейшие шаги по их решению.

План встречи:

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

Если заранее понятно, что «корень» проблемы на нашей стороне, то лучше сразу обсудить проблему с командой и пойти к заказчику уже с готовым решением.

Шаг 3. Встретиться с командой

В рамках встречи с командой нужно провести разбор полетов и обсудить, что было сделано не так. Задача такой встречи – не поиск виноватых и их публичное порицание, а совместное обсуждение проблем и выработка решения. Если команда вовлечена в процесс, получившийся план не будет восприниматься ее членами как очередное «потому что менеджер так сказал».

Чек-лист:

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

Кейс: расставляем приоритеты правильно

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

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

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

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

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

В заключение

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

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

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

Кстати, сейчас мы ищем системного аналитика уровня middle. Подробнее о требованиях и условиях можно посмотреть по ссылке:

66
Начать дискуссию