Definition of Ready для P&L Dashboard

Описание

Definition of Ready показывает, какие условия должны быть выполнены, чтобы задача по разработке P&L Dashboard была готова к взятию в работу.

DoR помогает снизить риск недопонимания между заказчиком, аналитиком, BI-разработчиком, финансовым блоком и командой разработки.

Для P&L Dashboard особенно важно заранее согласовать финансовую методологию, источники данных, правила расчёта показателей и границы MVP.

User Story для DoR

В качестве основной user story выбрана история операционного директора:

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

Definition of Ready

1. Согласована структура P&L

Перед началом разработки должна быть зафиксирована структура P&L-отчёта.

Должны быть определены показатели:

– выручка;

– себестоимость;

– валовая маржа;

– операционные расходы;

– операционная прибыль;

– распределённые общие затраты;

– полная маржа;

– маржинальность в процентах.

Критерий готовности:

– есть согласованный список показателей;

– для каждого показателя есть описание;

– финансовый блок подтвердил структуру P&L.

2. Согласованы формулы расчётов

Для каждого показателя должна быть определена формула.

Примеры формул:

Валовая маржа = Выручка – Себестоимость

Операционная прибыль = Валовая маржа – Операционные расходы

Полная маржа = Операционная прибыль – Распределённые общие затраты

Критерий готовности:

– формулы зафиксированы в документе;

– формулы согласованы с финансовым директором или финансовым аналитиком;

– нет неоднозначности в трактовке маржи.

3. Определены источники данных

Для каждого показателя должен быть определён источник данных.

Критерий готовности:

– есть список источников данных;

– известно, какие поля используются;

– определены ответственные за данные;

– известна периодичность обновления каждого источника.

4. Согласованы правила объединения данных

Данные из 1С, Excel и CRM должны объединяться по единым ключам.

Нужно определить:

– идентификатор магазина;

– название магазина;

– регион;

– категория товара;

– период;

– дата операции;

– источник данных;

– правила сопоставления справочников.

Критерий готовности:

– описаны ключи объединения;

– согласованы справочники магазинов и категорий;

– определено, что делать при несовпадении данных;

– есть пример data mapping.

5. Определены правила работы с расхождениями

В проекте есть риск расхождений между 1С, Excel и CRM.

До разработки нужно определить:

– какой источник считается главным для каждого показателя;

– как обрабатываются ручные корректировки;

– кто подтверждает финальные цифры;

– как отображаются неполные данные;

– что делать, если данные по источнику задерживаются.

Критерий готовности:

– зафиксирован источник истины для каждого показателя;

– описаны правила обработки расхождений;

– определён ответственный за сверку данных.

6. Определены разрезы и фильтры MVP

Для первой версии дашборда должны быть согласованы обязательные разрезы анализа.

В MVP входят:

– период;

– магазин;

– категория товаров;

– регион, если данные доступны.

Критерий готовности:

– согласован список фильтров;

– определены обязательные разрезы;

– согласовано, что не входит в MVP;

– drill-down до SKU вынесен в следующую фазу.

7. Согласованы роли пользователей

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

Роли:

– собственник бизнеса;

– операционный директор;

– финансовый аналитик;

– руководитель розничной сети;

– руководитель категории.

Критерий готовности:

– роли пользователей описаны;

– определены основные сценарии использования;

– понятно, кому нужна агрегированная картина, а кому детализация;

– определены ограничения доступа, если они нужны.

8. Определён состав MVP

Перед разработкой должен быть согласован минимальный состав первой версии.

В MVP входят:

– базовый P&L по магазинам;

– сравнение магазинов;

– выделение убыточных точек;

– базовая динамика по периодам;

– фильтры по периоду и магазину;

– базовый разрез по категориям;

– дата актуальности данных.

Не входит в MVP:

– прогноз окупаемости;

– сценарный анализ;

– drill-down до SKU;

– расширенная сезонность;

– сложные пользовательские настройки.

Критерий готовности:

– MVP согласован с заказчиком;

– функции следующей фазы вынесены отдельно;

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

9. Подготовлены макеты или схема интерфейса

Перед разработкой должна быть подготовлена структура дашборда.

Минимально нужно описать:

– первый экран;

– карточки ключевых показателей;

– таблицу магазинов;

– фильтры;

– график динамики;

– блок убыточных магазинов;

– детализацию по категориям.

Критерий готовности:

– есть wireframe или схема дашборда;

– согласован порядок блоков;

– понятно, какие показатели отображаются на первом экране;

– согласовано, какие элементы являются обязательными для MVP.

10. Определены критерии приёмки

Для задачи должны быть описаны acceptance criteria.

Пример критериев:

– пользователь видит P&L по магазинам за выбранный период;

– отображаются выручка, себестоимость, маржа, расходы и прибыль;

– убыточные магазины визуально выделены;

– данные можно отфильтровать по периоду и магазину;

– дата последнего обновления данных отображается на дашборде;

– показатели совпадают с контрольным расчётом финансового блока.

Критерий готовности:

– acceptance criteria согласованы;

– каждый критерий можно проверить;

– критерии связаны с user story и MVP.

Чек-лист готовности задачи

Риски, если DoR не выполнен

1. Некорректные показатели

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

2. Расхождения в данных

Если не определить источник истины, пользователи могут спорить, какие цифры правильные.

3. Перегруз MVP

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

4. Неподходящий интерфейс

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