Что мониторить при ведении проекта
Что проверяют
Есть ли у вас привычка следить за проектом после запуска и отличаете ли вы метрики продукта от метрик здоровья данных. Аналитик, который сдал дашборд и забыл про него, обычно узнаёт о поломке от бизнеса через месяц, когда решения уже приняты по мусору.
Как отвечать
Разложите ответ по слоям, снизу вверх.
- Данные: свежесть, то есть когда витрина обновлялась последний раз; полнота, то есть объём строк против обычного дня; дубли и нарушенная уникальность ключа; доля пустых значений в важных полях; сходимость с источником и с соседней витриной; изменение схемы, когда поле внезапно меняет тип.
- Расчёт: успешность запусков, длительность против нормы, застрявшие и перезапущенные задачи, стоимость расчёта.
- Продукт: та метрика, ради которой проект и делался, рядом с контрметрикой, чтобы поймать улучшение за счёт соседнего процесса. Воронку смотрят по шагам, а не только итог.
- Ведение самого проекта: сроки против плана, поток изменений требований, блокеры и решения, которые ждут владельца.
- Потребление: кто и как часто открывает отчёт. Дашборд, который месяц никто не открывал, проект уже провалившийся, даже если считается правильно.
Сильная часть ответа это не список метрик, а три вещи на каждую: частота проверки, порог, за которым это считается аномалией, и человек, которому уходит оповещение. Без порога и адресата мониторинга нет, есть график.
Где спотыкаются
Отвечают целиком языком управления проектами: статусы, встречи, отчёты для заказчика. Спрашивают аналитика, и ответ без слоя данных звучит как пересказ чужого курса по менеджменту.
Второе: перечисляют метрики без порогов и без реакции. Следом спросят, авария ли падение на десять процентов, и ответа не окажется. Полезно сразу назвать хотя бы одно правило сравнения: у большинства продуктовых метрик недельная сезонность, поэтому день сравнивают с тем же днём неделю назад, а не со вчерашним.
Третье: следят только за итоговой цифрой. Она агрегирована и инертна: сломанная отправка событий на одной платформе тонет в общем числе. Нужны разрезы по платформе, версии и региону плюс метрики качества самих событий, иначе поломку видно только когда провал станет двузначным.