Привет! Меня зовут Дарья, я руковожу продуктом Naumen Project Ruler. Вместе с командой изучаю задачи пользователей и определяю, какие сценарии и возможности продукта нужно развивать, чтобы эти задачи решать.

Дарья

Руководитель продукта Naumen Project Ruler

На статус‑митинге руководитель проекта оценил прогресс в 90%, все показатели в зеленой зоне. Команда движется отлично, все по плану. Через месяц все те же 90%. Показатели снова в норме, но почему процент не увеличился? Еще через месяц цифра по‑прежнему не меняется. И вот, за две недели до дедлайна статус «краснеет», и выясняется, что до закрытия всех задач нужно не меньше квартала.

Знакомо? Что за магическое число — 90%, откуда оно берется и в какой момент отображает реальное состояние проекта? И в чем тут проблема: РП приукрасил статус, ошибка в планировании либо расчете прогресса? Попытаемся разобраться.

Руководитель проекта приукрасил статус

Это самая частая и удобная версия. Фактически подразумевает персональную вину конкретного человека. Соответственно, именно ему нужно изменить подход к отчетам в сторону объективности. Но на самом деле не все так очевидно.

Смещение статусов в оптимистичную сторону задокументировано как регулярный факт в проектный деятельности. Это отмечено в работе Хараламбоса Иакова, Рона Томпсона и Джеффа Смита, опубликованной в MIS Quarterly (2009). Результаты исследования показывают, что искажение статуса — это последствия пяти организационных факторов проектной деятельности.

Под куратором подразумевается руководитель, напрямую заинтересованный в результатах проекта и отвечающий за бизнес‑результат. Именно перед ним отчитывается конкретный РП. Названные 5 факторов формируют характер их взаимодействия.

Проще говоря, РП может завышать реальные результаты не из стремления показать себя и команду в более выгодном свете. Им зачастую двигают опасения потерять ресурсы, зависимость от руководства, определенное давление. Он может опасаться, что куратор не прислушается к доводам и аргументам, которые объясняют реальную ситуацию.

Искажение статуса проекта в оптимистичную сторону может быть следствием как амбиций РП, так и системных непродуктивных взаимоотношений «куратор — РП». В первом случае справиться с проблемой проще, так как она действительно касается одного конкретного человека. Во втором — решить не так просто: нужно анализировать сложившиеся паттерны коммуникации руководства и команды. Будем честны, учитывая сложность и количество разных проектов, немного компаний будут копать так глубоко.

Изначально некорректная оценка объема работ

Ошибки в объеме и сроках работ — не редкость. Они могут быть допущены без умысла, например, в новых типах задач, с которыми команда еще не сталкивалась. Впоследствии опыт позволит оценивать все точнее.

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

Еще один вариант — на старте невозможно предусмотреть все необходимые работы. Так, Кэйперс Джонс много лет измерял рост требований по ходу выполнения проектов ИТ‑разработки. Его оценка — в среднем 2% в календарный месяц с момента окончания формулировки требований на старте до начала тестирования. В зависимости от класса разрабатываемого ПО показатели колебались от 1% в месяц на аутсорсинговой разработке до 3,5% на коммерческих продуктах.

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

В исследовании Форда и Стеймана есть два задокументированных проекта разработки микросхем. Первый планировался на 34 недели, к концу срока показывал 79% готовности, а завершился на 81-й неделе. Второй планировался на 39 недель, к финалу по времени показывал 73%, завершился на 69-й. Здесь мы видим, что магические 90% — все‑таки условный показатель. Закономерным моментом «застревания» проекта можно условно считать прогресс на две трети. И он происходит, когда заканчивается декомпозированная часть работ, и начинаются «сюрпризы», обусловленные тенденцией, которую выявил Джонс.

Проблема некорректной оценки новых работы решается сама собой со временем и опытом. Намеренное искажение объема и сроков бывает связано с человеческим фактором и неоптимальным взаимодействием руководства с РП. Появление новых задач уже при выполнении проекта — закономерное явление.

Неверный расчет прогресса

Вопрос в том, что относится к прогрессу в проектах и как его считать. Проекты бывают разные, со своими особенностями. Но для большинства все‑таки подход «прогресс = доля выполненных от запланированных задач» нерелевантен. Работы различаются по объему и приоритетам. Далеко не факт, что 10 типовых задач обеспечивает тот же прогресс, что три крупных. Важно определить «систему мер и весов» для каждого проекта, исходя из целей, иерархической структуры работ, и определять прогресс на этой основе.

Еще один аспект — инструменты для расчета. Если все делается вручную (сбор данных по выполненным задачам, аналитика приоритетов и эффективности) риск ошибок стремится вверх. Автоматизация проектных процессов даст более точный результат. Кроме того, в любой момент послужит доказательством и аргументом РП «что происходит на проекте» для стейкхолдеров, если у них возникнут вопросы.

Покажу на примере нашего продукта Naumen Project Ruler. Прогресс определяется автоматически: подзадачи → задачи → этапы → эпики → проект → портфель проектов. Учитывается не только количество закрытых задач, но и другие важные критерии.

При этом отсутствуют ошибки ручных расчетов. Система в любой момент автоматически выдает актуальное значение на основе данных, которые в ней содержатся. Такая арифметика точнее и честнее, чем «закрыто 47 задач из 52», так как убирает свойственное этому подходу искажение, обусловленное только количеством выполненной работы, а не ее качественной составляющей.

В вопросе расчета готовности все довольно однозначно. Необходима система приоритизации задач по значимости и объему, на основе которой определяется прогресс. Ручные подсчеты — трудоемкие и имеют большую погрешность в точности. Решения для автоматизации проектных процессов обеспечат актуальные показатели в любой момент.

Что, если изменить отношение к показателю прогресса?

Прогресс отражает долю освоенного планового объема работы. Это важно, чтобы понимать расходы, темп, трудозатраты, загрузку команды, видеть отклонение от плана. Но все это показывает лишь то, что уже сделано. И вот здесь возникает некий парадокс: показатель прогресса не может служить четким основанием для ответа на вопрос «Когда закончим?».

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

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

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

Что в итоге

Нужно перестать сводить два разных вопроса к показателю прогресса. Он отвечает только на один: «Сколько сделано?». Чтоб понять прогноз, нужна ясность в другом: «Какова оставшаяся доля неопределенности?». Например, какие интеграции не проверены на реальных данных, какие смежные команды не предоставили необходимые сведения, какая часть готового результата не принята. Эта информация позволит сформировать ответ и строить прогнозы.

И последнее. Прогресс 90% — это сообщение о том, запланированный объем работ почти освоен. Если этот показатель не растет, и сроки сдвигаются, значит, команда увязла в новых требованиях, задачах и переделках. В этом случае проект теряет свою итоговую ценность.

Вспомним определение PMI (Project Management Institute). Проект — это временное предприятие, направленное на создание уникального продукта или услуги. Временное — значит, завершенное в определенный срок. Смещение убивает эту ключевую характеристику, превращая проект в процесс бесконечных «допиливаний» и переделок, которые буквально «пожирают» ресурсы компании.

Заморозить такую инициативу, «готовую на 90%», большинство организаций не решится. Слишком много уже вложено. Остается вариант принудительной остановки новых требований и переделок имеющихся дефектов и запуск имеющегося MVP с доработкой в рамках поддержки.