Прогресс и освоенный объем (EVM) проекта в Google-таблице

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

EVM and weighted-progress tracking methodology for software delivery, implemented as a ready-to-copy Google Sheets template.

Готовый шаблон с формулами, тестовыми данными и кнопками: Google-таблица

Зачем

В fix-price разработке нужно в любой момент уметь ответить заказчику - и себе - на четыре вопроса:

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

Ответы на глаз ("процентов семьдесят готово") не защищаются перед заказчиком и не ловят проблему заранее. Методика дает их числами, и главное - в динамике: не "сегодня CPI 0,95", а "CPI падает четвертую неделю подряд".

Кому

Руководителям проектов, delivery- и PMO-специалистам, которым нужен прозрачный учет без внедрения отдельной системы. Экономистом быть не нужно: все метрики объясняются ниже на пальцах, а считает их таблица.

С чего начать

1. Откройте шаблон и сделайте Файл → Создать копию.
2. В своей копии обновите страницу - в строке меню появится пункт Методика.
3. Пройдите разовую настройку - чеклист Перед первым срезом.
4. Дальше - обычный недельный ритм, описанный ниже.

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

Из чего состоит таблица

Лист	Что там	Кто и как заполняет
Прогресс	дерево задач и подзадач, оценка по ролям, факт по исполнителям, процент готовности	руками, еженедельно
Этапы	базовый план: этапы контракта с датами и объемом часов	один раз при подписании
История	недельные срезы: замороженные цифры и все метрики поверх них	кнопкой, раз в неделю
Графики	пять графиков по истории	ничего не надо, рисуются сами

Что вносит человек, а что считается само

Человек вносит три вида чисел и только на строках подзадач:

• оценку в часах по ролям - сколько работы куплено (PM, аналитик, backend, frontend, QA, DevOps...);
• факт в часах по исполнителям - выгрузка из трекера;
• процент готовности - оценка самого исполнителя, сколько его куска сделано.

Все остальное - суммы по задачам, итоги проекта, взвешенная готовность, метрики EVM - таблица считает сама. Строки задач и строку проекта руками трогать не нужно вообще.

Почему взвешенная готовность, а не среднее. Если у задачи пять подзадач и одна из них закрыта, это не 20% готовности: подзадачи разного размера. Готовность считается взвешенной по трудоемкости, поэтому закрытая мелочь дает мало, а закрытый крупный кусок - много. То же на каждом уровне: подзадача → задача → проект.

Контроль ввода. В таблице есть служебная колонка-светофор: она ловит две типовые ошибки - часы списаны, а процент не проставлен (готовность занижена) и наоборот, процент есть, а часов нет. Перед снятием среза стоит посмотреть на нее: если флагов много, цифры недели врут.

Дерево задач: две кнопки

Меню Методика	Что делает
Добавить задачу...	спросит число подзадач и добавит новый блок в конец дерева
Добавить подзадачу под курсором	встаньте на строку задачи или любой ее подзадачи - новая появится под текущей

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

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

Если после ручных правок что-то поехало, есть кнопка Пересобрать формулы задач - она проходит по всему дереву и восстанавливает формулы по текущей структуре.

Перед первым срезом

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

• Уберите пример. Удалите тестовые задачи на листе Прогресс и лишние колонки срезов на листе История. Одну колонку среза оставьте: новый срез готовится копией предыдущего, и совсем пустую историю кнопка не примет. В оставшейся колонке впишите свои значения на дату старта - она станет первой точкой истории.
• Впишите роли в шапку. Колонок под роли семь: нужные переименуйте, лишние оставьте пустыми. Добавлять и удалять колонки нельзя - на их порядок опираются формулы и кнопки.
• Соберите дерево задач и подзадач кнопками из меню, проставьте оценку в часах по ролям.
• Заполните лист Этапы - этапы контракта с датами начала, сдачи и объемом часов. Без него не будет ни плановой кривой, ни метрик сроков (PV, SV, SPI), а База окажется нулевой и Резерв посчитается мимо.
• Сверьте два объема. Сумма часов по этапам должна совпасть с суммой оценки по дереву. Расхождение на старте значит, что одно из двух заполнено не до конца, - и дальше вся арифметика пересмотра объема будет врать.
• Договоритесь с командой до первого среза, а не после: что считается 100% готовности (написано? прошло ревью? принято заказчиком?), кто ставит процент и в какой день недели снимается срез.

Факт - накопительный. В колонки факта идут часы с начала проекта на дату среза, а не за прошедшую неделю. Это самая частая ошибка первого месяца: недельные часы дают заниженный AC, завышенный CPI и историю, которую потом уже не починить.

Если этапы идут параллельно - то есть контракт разбит на этапы юридически, а работы разных этапов делаются одновременно, - плановая кривая по этапам будет вам льстить: SPI покажет опережение там, где его нет. Признак: SPI заметно лучше CPI, а команда при этом не простаивает. В этом случае кривую строят не по этапам, а по помесячному плану загрузки часов: структура листа Этапы не меняется, меняется наполнение - вместо строки на этап строка на месяц (Начало - первое число, Конец - первое число следующего). Только не забудьте привести план к BAC: в бюджетной форме обычно сидит запас, и без нормировки SPI будет вечно меньше единицы без всякой вины проекта.

Недельный ритм

Раз в неделю, в один и тот же день:

1. Подтяните факт из трекера и попросите исполнителей обновить проценты готовности.
2. Разберите флаги в колонке контроля, если они есть.
3. Нажмите Методика → Снять срез..., подтвердите дату.
4. Впишите комментарий к срезу, если неделя была нестандартной: закрыт этап, влетел крупный незапланированный объем, менялась оценка.

Все. Метрики и графики обновятся сами.

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

• "Флагов Проверки больше нуля". Часы и проценты в дереве не сошлись, значит готовность недели занижена или завышена. Разберите рассогласования и переснимите срез: точка останется в истории навсегда и будет тянуть за собой темп и прогноз.
• "База и бюджет разошлись". Объем изменился, а изменение не оформлено. Само по себе это не ошибка - но причину назовите в комментарии к срезу, иначе через полгода излом на графике никто не объяснит.
• "План освоения нулевой". Лист Этапы пуст или все периоды начинаются позже даты среза. Сравнение со сроками в этой точке бессмысленно, смотреть на него нельзя.

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

Прогноз даты появится не сразу: он строится по темпу, а темп сглажен по четырем срезам назад, поэтому первое осмысленное число будет примерно на пятой неделе. До тех пор в строке прогноза стоит "нет темпа" - это не поломка. Там же он останется, если готовность стоит на месте или откатилась после пересмотра оценок: выдавать дату в таком случае нечестно.

Почему в один и тот же день. Часы попадают в трекер с задержкой, поэтому самая свежая точка всегда чуть приукрашивает. Если снимать всегда в один день, запаздывание одинаково у всех точек и тренд читается верно. Срез "когда вспомнили" ломает сопоставимость.

Почему списания все равно ежедневные. Вопрос "зачем списывать каждый день, если срез недельный" возникает у каждой команды. Причины две. За неделю человек не помнит, сколько куда ушло, и пишет ровные правдоподобные числа - из них складывается ровный правдоподобный, но неверный CPI. И вторая: только выгрузка с датами списания позволяет восстановить потраченные часы на любую прошлую дату, если срез пропущен или ошибочен.

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

Как читать метрики

Две колонки, которые смотрят каждый день

Σ% - доля выполненной работы: сколько из плановых часов уже сделано. Это не то же самое, что доля потраченных часов, и как раз расхождение между ними интересно.

Δ - это расхождение и есть: готовность минус доля израсходованного. Плюс - сделали больше, чем потратили; минус - потратили больше, чем сделали. Меряется в процентных пунктах, поэтому "-15" читается как "сожжено на 15 п.п. больше плана при текущей готовности". Колонка подкрашена: зеленая от +5, красная от -5.

Δ читается по уровням. На подзадаче это тактика - видно, какая именно горит. На задаче разнонаправленные подзадачи усредняются, и спокойная Δ задачи может скрывать внутри себя -30. На проекте Δ - сводная температура, в ней смешаны и реальные отставания, и overhead, и неравномерность списаний. Сильный плюс тоже не всегда хорош: чаще всего он означает, что часы просто не списывают.

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

Метрики EVM

Все меряется в часах и выводится из трех чисел:

	Что это	На какой вопрос отвечает
PV	сколько часов план обещал освоить к этой дате	"сколько должны были сделать?"
EV	сколько работы реально сделано, в плановых часах	"сколько сделали?"
AC	сколько часов реально потрачено	"сколько потратили?"

Главное здесь - EV. Он меряется не потраченными часами, а плановыми: сделали половину работы, которая по плану стоила 100 часов, - EV = 50 часов, независимо от того, ушло на это 30 часов или 80. Именно поэтому EV можно сравнивать и с планом, и с фактом.

Дальше все остальное - две операции над этими тремя числами:

• вычесть - получится разница в часах, имя кончается на V (Variance). Хорошо, когда больше нуля.
• разделить - получится безразмерный индекс, имя кончается на PI (Performance Index). Хорошо, когда больше единицы.

А первая буква говорит, с чем сравниваем EV: C (Cost) - с AC, то есть про бюджет; S (Schedule) - с PV, то есть про сроки.

	Вычитание -> часы	Деление -> индекс
против AC (бюджет)	CV = EV - AC	CPI = EV / AC
против PV (сроки)	SV = EV - PV	SPI = EV / PV

Отдельное семейство - "на момент финиша":

Термин	По-русски
BAC	бюджет на весь объем работ - тот объем, который делаем сейчас
EAC	прогноз, во что выльется, если дальше пойдем с текущей эффективностью
VAC	на сколько промахнемся: BAC - EAC
TCPI	с какой эффективностью надо пройти остаток, чтобы уложиться в BAC

Осторожно с BAC. В учебниках это "то, о чем договорились", а здесь - объем, который делаем сейчас: правите оценку, и BAC меняется. Договорный объем в методике живет отдельным числом - База, см. Изменение объема. Разошлись эти два числа - значит объем уехал от контракта, и это видно сразу.

CPI отвечает "как мы шли до сих пор", TCPI - "как надо идти дальше". Если TCPI заметно выше достигнутого CPI, план требует эффективности, которой на этом проекте еще ни разу не показывали.

Ориентиры по CPI - настраиваются под проект, но начинать можно с этих:

CPI	Как читать
0,8-1,0	умеренное отставание, обычно нагоняется
0,6-0,8	тревога, нужен план восстановления
ниже 0,6	разговор с заказчиком про объем или сроки

TCPI до 1,0 - идем как надо, рывок не нужен; до 1,1 - нужен умеренный рывок, обычно реалистично; выше 1,1 при заметно меньшем CPI - расчет на "наверстаем" несостоятелен: если полконтракта шли на 0,8, внезапно выдать 1,15 на остатке не выйдет. Это повод говорить об объеме, сроках или бюджете, а не обещать рывок.

Пример. Контракт на 1000 ч. План обещал к этой дате освоить 500 ч, сделали работы на 400 плановых часов, потратили 550.

Считаем	Получается	Читается
CV = 400 - 550	-150 ч	сожгли на 150 часов больше, чем сделали
CPI = 400 / 550	0,73	каждый заработанный час обходится в 1,37 потраченного
SV = 400 - 500	-100 ч	отстаем от графика на 100 часов работы
SPI = 400 / 500	0,80	сделали 80% от того объема, что план обещал к этой дате
EAC = 1000 / 0,73	1375 ч	при таком темпе выйдет 1375 вместо 1000
TCPI	1,33	остаток надо пройти почти вдвое эффективнее, чем шли (1,33 против 0,73), - на это рассчитывать нельзя

Полезно смотреть на пару CPI и SPI вместе. CPI 1,0 при SPI 0,8 - работаем эффективно, но отстаем по объему; самая частая причина - людей на проекте меньше плана. Проверяется сравнением AC с PV: если потрачено заметно меньше, чем план обещал к этой дате, дело действительно в ресурсе и лечится людьми. Если же AC идет вровень с PV, а SPI все равно низкий - ресурс расходуется как задумано, а продукта дает меньше, и добавлять людей бессмысленно.

EAC тоже стоит читать с оговоркой: он предполагает, что дальше пойдет с той же эффективностью, что и до сих пор. Если перерасход был разовым (одна переделка, один провальный модуль), реальный прогноз мягче. Пока история короткая, честнее показывать вилку - "перерасход 500-1000 часов в зависимости от того, разовый это провал или системный", - чем выдавать одно число за факт.

Важное ограничение SPI. Он меряется в часах, а не во времени, и к концу проекта неизбежно стремится к единице, даже если сдача опаздывает на два месяца. Он информативен в середине контракта и почти бесполезен на финише. И не показывайте его заказчику без даты: индекс 0,95 в июне и в декабре означают совершенно разное.

Незапланированные работы

Отдельная строка над деревом задач собирает часы, потраченные на работу, которой в плане не было: мелкие доработки, правки по ходу, разбор инцидентов. У нее есть факт, но нет оценки - в этом весь смысл.

График доли незапланированных с линией риск-буфера показывает, стабилизировался overhead или растет. Пересечение буфера - повод для разговора с заказчиком, а не для тихого героизма. Сам буфер в шаблоне выставлен на 10% - это отправная точка, а не универсальный порог: под проект его настраивают по тому, сколько overhead закладывали в оценку.

Изменение объема

Объем работ меняется почти всегда: часть задачи оказывается не нужна, что-то переносят с задачи на задачу, что-то дописывают сверху. Методика различает два числа:

• BAC - объем, который делаем сейчас. Он живой: правите оценку - он меняется.
• База - объем, о котором договаривались. Правка оценок ее не двигает; меняется она только при формальном пересмотре контракта, и тогда это отдельное событие с датой (см. правила ниже).

Разность между ними и есть изменение объема:

Что показывает	Как читать
Пересмотр = База - BAC	плюс - объем ужали, минус - объем вырос без допсоглашения, ноль - идем как подписывали
Резерв по контракту = База - EAC	сколько часов контракта останется, если пойдем с текущей эффективностью

Это закрывает случай, который обычно ломает учет: задачу пересмотрели частично. Было 100 часов, делаем 50, остальное не нужно. Просто ужать оценку - и готовность снова честная, 100% достижимы, а разность База - BAC сохраняет след того, что объем менялся.

Если работа переехала с одной задачи на другую, пересмотр по одной даст +50, по другой -50, и в сумме будет ноль: объем перераспределен, бюджет не тронут.

Итог таблица считает сама, а вот объем перетасовки внутри проекта - нет: базу она хранит только по проекту в целом, оценок задач на дату подписания у нее нет. Если этот показатель нужен, сохраните копию дерева с оценками при подписании и сверяйтесь с ней руками. Смотреть стоит: нулевой итог при сотнях переброшенных часов означает, что бюджет сошелся случайно, а оценка при подписании была плохая.

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

Выгода от снятия объема живет в Резерве, а не в CPI. CPI меряет эффективность внутри того объема, который делаем, и после пересмотра честно показывает единицу. То, что за те же деньги контракта сделано меньше часов, видно только в сравнении с базой.

Правила, которые нельзя нарушать

• Срез хранит значения, а не ссылки. Если в историю попадут формулы, ссылающиеся на живой лист, все "исторические" точки будут показывать сегодняшний день, и истории не возникнет вообще. Кнопка снятия среза делает это правильно; при ручном переносе - только "вставить значения".
• Снятый срез не редактируется. Живая таблица самолечится: поправили процент - все метрики стали верными. История этого свойства лишена, неверная точка остается неверной навсегда и портит все графики, которые через нее проходят. Исключений ровно два: опечатка, замеченная сразу, до того как цифры ушли в отчет, и досведение предыдущей точки - следующий пункт. Все прочее - пояснение в комментарии, а не правка числа.
• Предыдущую точку разрешено досвести один раз. Часы попадают в трекер с опозданием, поэтому самый свежий срез всегда чуть приукрашивает: AC занижен, CPI и прогноз выглядят лучше реальных. На очередном срезе можно пересчитать AC и незапланированные часы прошлой точки по устоявшейся выгрузке и отметить это в ее комментарии. Глубже одного шага назад не пересводить - поедет вся серия.
• Лучше пропустить неделю, чем внести точку, про которую известно, что она врет.
• Срезы не удалять и не переставлять. Расчет темпа смотрит на четыре среза назад, перестановка тихо ломает всю серию.
• База не ездит внутри версии базового плана. Перевыставляется она только при формальном изменении объема - и тогда дата ре-базлайна пишется в комментарии среза. Уже снятые точки задним числом не пересчитываются: иначе пропадет ровно то, ради чего история ведется.
• Держите локальную копию. Раз в неделю выгружайте историю в CSV. Процент готовности на прошлую дату не хранится больше нигде: факт добывается из трекера, план - из договора, а готовность живет только в этой таблице.

Чего в методике нет и почему

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

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

Интеграции с трекером. Факт переносится выгрузкой. Это сознательный размен: методика должна работать в любой компании с любым трекером, а не в одной с настроенным API.

Как это устроено внутри

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

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