Формула, которая кажется очевидной
Доля работ, сданных не позже срока, от всех работ со сроком. Проблема в том, что каждое слово в этом определении нужно уточнять, иначе разные модули системы посчитают по-разному и покажут разные цифры на соседних экранах.
Одно и то же число отличается в карточке проекта и в общей сводке. Если такое случилось — расчёт разъехался, и доверять нельзя обеим цифрам.
Ошибка первая: игнорировать время дедлайна
Дедлайн «17 июля» и дедлайн «17 июля, 12:00» — разные обязательства. Если сравнивать только даты, работа, сданная в 21:00 при сроке «до полудня», засчитывается как выполненная в срок. Формально дата совпала. Фактически клиент не получил материал к эфиру.
Правильно: если у дедлайна задано время — сравнивать полный timestamp. Если время не задано — считать границей конец дня, 23:59:59 в часовом поясе агентства. И то и другое должно применяться одинаково во всех модулях.
Ошибка вторая: брать последнее закрытие вместо первого
Задачу закрыли вовремя, через два дня переоткрыли для правок, закрыли снова. Что считать фактом сдачи?
Если брать последнее закрытие — работа становится просроченной задним числом, хотя в срок её сдали. Люди начинают бояться переоткрывать задачи и вместо правок заводят новые: история проекта рассыпается.
Считать первое закрытие. Оно отвечает на вопрос «уложились ли в срок». Правки после сдачи — это отдельная метрика, доля переделок. Смешивать их в одном числе нельзя: они требуют разных управленческих действий.
Ошибка третья: считать архив вместе с живыми проектами
Завершённые и архивные проекты продолжают лежать в базе. Если их не отфильтровать, метрика описывает не текущее состояние агентства, а всю его историю. Проект, закрытый год назад с тремя провалами по срокам, тянет вниз показатель, по которому вы принимаете решения сегодня.
Фильтр должен применяться во всех аналитических модулях одинаково — иначе на одном экране 78%, на другом 91%, и доверие к системе исчезает.
Ошибка четвёртая: не отличать продление договора от провала
При продлении контракта система сбрасывает этапы в исходное состояние, чтобы начать новый цикл. Для наивного алгоритма это выглядит как массовый откат назад: десять этапов одновременно ушли из «готово» в «ожидание».
Цикл проекта считается длиной в 33 дня вместо 2, потому что сравниваются точки из разных периодов. И команде записывается десять возвратов, которых не было. Пакетные операции нужно определять по признаку «несколько записей одного проекта в одну операцию» и обрабатывать как границу цикла.
Знаменатель важнее числителя
«Сдано в срок: 94%» — от чего? Разные знаменатели дают разные цифры на одних и тех же данных.
| Знаменатель | Что показывает |
|---|---|
| Все работы со сроком | Общее качество планирования |
| Только завершённые | Завышает: просроченные и незакрытые не считаются вовсе |
| Завершённые + просроченные открытые | Честная картина на сегодня |
Дисциплина отображения
Метрика без выборки — не метрика. Пять доставок и 80% — это четыре из пяти, а не устойчивый уровень. Показывайте рядом объём выборки и понижайте «уверенность» показателя, когда наблюдений мало.
Пустое значение честнее нуля: если закрытий не было вовсе, писать «0%» — прямая ложь, нужно писать «нет данных».
Как это устроено в DETROYD
Платформа считает on-time delivery отдельно по этапам и по задачам, учитывает время дедлайна, берёт первое закрытие, исключает архивные проекты и учитывает только те проекты, что входят в зону доступа сотрудника. Пакетные сбросы при продлении договора распознаются и не портят ни цикл, ни персональную статистику. В модуле «Дедлайны» те же правила применяются к карточке каждого проекта, поэтому цифра в сводке и цифра в проекте всегда совпадают.