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