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

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

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

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

• Заказчик написал кому-то вышестоящему в компании о проблеме

• Перед очередным релизом что-то пошло не по плану, и команда работала в выходные

• Заказчик недоволен, что озвученные сроки уже несколько раз сдвигались

Содержание

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

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

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

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

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

• В заключение

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

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

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

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

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

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

Алгоритм:

1. Актуализируйте статусы задач по колонкам справа налево. В первую очередь нужно рассмотреть наиболее готовые задачи: bug-fix → test → in progress → to-do и так далее

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

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

4. Удалите лишние задачи из колонки to-do. В колонке должны находиться только задачи, которые должны делаться в ближайшее время

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

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

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

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

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

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

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

• Признайте ошибки со стороны команды, если они есть

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

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

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

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

Чек-лист:

• Разберите ситуацию, возникшую на проекте

• Проговорите, как не допустить повторения ситуации

• Обсудите шаги по решению проблемы и зафиксируйте их в чате с командой

• Назначьте регулярную встречу для контроля работы команды (если она нужна)

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

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

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

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

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

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

В заключение 

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

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

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

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