Как мы сделали идеальный отчёт, которому нельзя было верить

25 августа мы проверяли, как syBoard завершает рабочий цикл команды.

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

Система сформировала итоговый отчёт: выполнение — 100%.

Сначала эта цифра даже выглядит приятно. Потом вспоминаешь про вторую задачу.

Мы не ускорили команду и не уменьшили объём работы. Мы просто нашли способ получить идеальный результат, перенеся всё незавершённое на потом.

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

Исчезла не задача, а неудобный факт

В Scrum объём задач часто оценивают в Story Points — условных единицах сложности. В нашем тесте выполненная задача стоила 3 балла, незавершённая — 5.

Пока рабочий цикл продолжался, система видела обе задачи: три балла сделано из восьми. Честный результат — 37,5%.

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

Но отчёт был построен по принципу «покажи всё, что относится к этому циклу сейчас». После переноса в старом цикле осталась только выполненная задача.

Три балла сделано из трёх. Сто процентов.

Формула не ошиблась. Она безупречно ответила не на тот вопрос.

Руководителю нужно знать: «Что команда обещала сделать и чем всё закончилось?»

Система отвечала: «Что осталось здесь после того, как мы убрали всё незавершённое?»

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

Почему красивая цифра оказалась опаснее ошибки на экране

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

Здесь всё было аккуратно: понятный отчёт, зелёный показатель, ровно 100%. Такой результат легко принять за факт и понести дальше — на планёрку, в отчёт руководству, в решение о загрузке команды.

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

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

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

Нам пришлось научить систему помнить прошлое

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

Для истории — нет.

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

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

Старый отчёт всё равно должен показывать прежние 37,5%. Работа, сделанная завтра, не может задним числом улучшить вчерашний результат.

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

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

Один вопрос, который быстро проверяет любой отчёт

После этой истории я стал иначе смотреть на управленческие показатели.

Когда система показывает итог периода, полезно спросить: он сохранён в момент события или вычисляется прямо сейчас по данным, которые уже успели измениться?

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

Если прошлый результат изменился, перед вами не история. Это сегодняшнее состояние, переодетое в отчёт о прошлом.

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

Хороший отчёт не обязан радовать

После исправления наш показатель упал со 100% до 37,5%.

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

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

Из этой ошибки мы вынесли простое правило: рабочая задача может двигаться дальше, а завершённый отчёт — нет.

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