Comments 10
Здорово что вы доросли до специализации, планирования спринтов и составления тз.
Непонятно только почему у вас тестирование называется "review" а UAT - "customer review" .
А в целом удачи.
Здравствуйте! Спасибо) В review входит не только тестирование, но и валидирование описания таблицы, процесса, пользовательского отчета (в зависимости от задачи). Чтобы не городить огород из разных этапов в Jira, решили агрегировать их в один. Customer review «сложился исторически», но главное, что всем понятен ? А в вашем проекте тестирование внутри команды и тестирование у заказчика — это разные этапы бизнес-процесса?
Процесс зрелой команды BI, которая делает отчетность не на коленке ??
Постоянно изменяющиеся требования могут говорить о нечетко сформулированной для себя цели отчета со стороны заказчика. Возможно, ему нужно с этим помочь. Иногда бывает, что в реализацию пошло незрелое решение. Нарастить зрелость, да и с требованиями определиться часто помогает этап прототипирования.
Касательно внутренних улучшений — они действительно будут в проигрыше по приоритету перед бизнесовыми задачами. Очень часто эта проблема становится особенно острой, когда ресурсом BI-команды управляет заказчик, например Product Owner, который находится на стороне бизнеса.
Полезно иметь отдельный забронированный пул ресурса на внутренние задачи. Это может быть какое-то фиксированное кол-во часов или процент от общего ресурса. И каждый спринт планировать активности в этот пул. Пускай это будет хотя бы небольшое кол-во часов, но лучше понемногу делать самые важные улучшения, чем не делать их вообще и надеяться на свободные часы в будущем (они с высокой долей вероятности не найдутся или заполнятся внезапными проблемами).
Спасибо за ценные комментарии касательно текущих сложностей! Обязательно возьмем на заметку.
Очень интересна ваша идея о прототипировании. На этапе ТЗ мы вместе с заказчиками составляем и согласовываем подробное ТЗ и рисуем макет будущего отчета. Это имеется в виду или нечто иное?
Так как не всегда заказчику легко представить как будет выглядеть функционал, не исключено, что он может с некоторыми вещами соглашаться, а потом в процессе понять, что это не то.
Прототип — это наскоро собранная модель данных или подгруженный ограниченный семпл данных + подготовленные визуализации. На этом этапе мы публикуем в UAT для рабочей группы заказчика приложение, чтобы он мог его покликать, воспроизвести свои user cases, понять, чего ему не хватает в визуале, что удобно, а что нет. Можно провести встречу чтобы разработчик увидел, что с этим приложением хотят делать, чтобы скорректировать функционал, предложить что-то посмотреть.
На этом этапе мы не добиваемся выверенных и обновляемых данных, они могут быть даже тестовыми или сгенерированными. Главное — в нужном разрезе.
Важно заказчику дать ограниченное время на тестирование и консолидацию ОС от рабочей группы. Иногда достаточно провести одну встречу чтобы закончить этот этап.
Чтобы потом к прототипу допилить аккуратный etl, причесать настройки визуализаций.
На этом этапе мы не берём в работу принципиально новые требования. Но всё, что накидывают сразу записываем в jira, складываем в бэклог, его приоритезируем.
В разработке в рамках задачи оставляем то, что требуется заказчику для работы сразу же и то, что вписывается в объемы оценки задачи. Хотя лучше прототип выносить в отдельный этап и оценивать отдельно.
Прототипирование не требуется для всех отчетов и почти никогда не нужно при доработках. Но нужно там, где требования до конца не ясны или со старта требуется что-то объемное, где по вашему опыту требования часто меняются, прилетает куча доработок после внедрения и т.д.
Постаралась обогатить комментарий нюансами)
Как у вас с одним и тем же KPI в разных репортах? Считаются в репортах ? или выносите в общее место?
Забавно читать в 2023 году про waterfall.
Если в ways of working не заложена быстрая итеративность, то тут вообще можно дальше не читать. У вас цикл разработки 1.5 месяца. А должен быть на уровне дней.
Мантра с числами Фибоначчи - вечно спрашиваю почему люди считают что это работает, ответ обычно "ну так все пользуются".
Разработчики — налево, методологи — направо: четыре шага к оптимизации работы BI-аналитиков