Лавина люлей: что делать с проблемами в проекте

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

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

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

Четыре стратегии реагирования на риск проекта

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

Признаки, что проект уже съезжает

Срыв сроков редко случается за один день. Обычно его видно за несколько недель, если смотреть не на отчёты, а на поведение команды и цифры в трекере.

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

• задачи неделями висят в статусе «почти готово» или «90%»;
• скорость команды падает два спринта подряд;
• растёт число переоткрытых багов после тестирования;
• заказчик всё дольше даёт обратную связь и согласует макеты;
• ключевой разработчик единственный знает часть системы и уходит в отпуск;
• на статус-встречах звучит «в целом всё нормально» без цифр.

Как заметить срыв сроков по цифрам

Есть метод освоенного объёма (earned value). Он сравнивает, сколько работы должно быть сделано к сегодняшнему дню, сколько сделано на самом деле и сколько на это потрачено. Индекс выполнения сроков SPI ниже 0,9 — уже тревожный сигнал, ниже 0,8 — проект почти точно не успеет без изменений.

Полный earned value в небольшой команде считать необязательно. Достаточно burndown-диаграммы спринта или релиза: если линия две недели идёт горизонтально, говорить с заказчиком пора сегодня.

Как сообщить заказчику плохую новость

Плохую новость лучше приносить в одной и той же структуре. Тогда разговор идёт о решении, а не об эмоциях. Заказчик видит, что менеджер держит ситуацию, даже если она неприятная.

Отдельно про формулировки. «Будем больше стараться» и «команда работает в усиленном режиме» звучат как обещание, но ничего не меняют в плане. Заказчику нужны даты, объём и цена каждого варианта, тогда он может принять решение за одну встречу.

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

Статус проекта светофором

Удобный формат еженедельного отчёта — RAG-статус: зелёный, жёлтый, красный. Зелёный — идём по плану. Жёлтый — есть риск, и вот что мы делаем. Красный — без решения заказчика срок или бюджет не выдержать.

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

Управление ожиданиями заказчика с первого дня

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

Если заказчик заранее знает, что жёлтый статус — нормальная часть проекта, он реже реагирует на него как на катастрофу. Менеджеру тоже легче: ему не нужно выбирать между честностью и спокойной встречей.

Что зафиксировать на старте проекта

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

• кто у заказчика принимает решения по срокам, бюджету и объёму;
• как часто встречаемся и в каком формате присылаем статус;
• что считаем проблемой, о которой сообщаем сразу, а не на плановой встрече;
• сколько времени заказчик тратит на согласование макетов и сборок;
• какой резерв по сроку и бюджету заложен и кто им распоряжается.