BA на IT-проекте
Большинство IT-проектов проваливаются не из-за плохого кода. Они проваливаются потому что построенное не соответствует тому что было нужно - и никто не заметил разрыв пока не стало слишком поздно. Эта услуга - о том, чтобы быть человеком, который предотвращает это.
Что включает эта услуга
Когда бизнес заказывает проект разработки ПО или внедрения системы, кто-то должен находиться между бизнесом и командой разработки на протяжении всего проекта - не только в начале. Это и есть данная роль.
С одной стороны: точно понять что нужно бизнесу, зафиксировать это полностью и убедиться что ничего не подразумевается и не остаётся несказанным. С другой стороны: перевести эти потребности на язык, с которым могут работать разработчики, проверять то что они строят на соответствие договорённостям и сигнализировать об отклонениях до того как их исправление станет дорогостоящим.
Это не роль проектного менеджера. Это содержательная роль - о существе того что строится, а не о расписании кто это строит. Бизнес-аналитик на проекте - это человек, который знает одновременно что система должна делать и что она реально делает в любой момент времени, и может выявить разницу.
Работа также включает контроль бюджета: отслеживание что потрачено, что осталось и правильно ли оцениваются и согласовываются изменения охвата. IT-проекты хорошо известны перерасходами бюджета, которые можно было выявить раньше. Выявлять их раньше - часть работы.
Результат - не документ. Это работающая система, которая делает то что клиент ожидал, в рамках бюджета, который был понятен и контролировался на протяжении всего проекта.
Как это работает
Система управления складом - адаптация процессов для многозонного объекта
Логистическая компания, эксплуатирующая распределительный центр, нуждалась в адаптации существующей системы управления складом под специфику планировки и операционные требования нового объекта. Новый склад включал трёхуровневую антресольную зону отбора - конфигурацию, не поддерживаемую стандартной системой - и требовал изменений в трёх ключевых процессах: разгрузка транспорта, приёмка товара и размещение. Проект прошёл путь от функциональных требований через техническое задание, разработку, тестирование и обучение пользователей. Бюджетные цифры ниже иллюстративные; фактические финансовые показатели проекта конфиденциальны.
Шесть функциональных изменений в трёх складских процессах, реализованных за 12 недель. Каждое изменение было определено в объёме, задокументировано, разработано и протестировано независимо, при этом единый BA обеспечивал преемственность по всем из них.
Иллюстративная структура бюджета с долями фаз для проекта данного типа. Все цифры только ориентировочные - фактические затраты варьируются в зависимости от состава команды, ставок разработки и охвата. Реальные финансовые показатели проекта конфиденциальны.
Фрагмент документа ФТ по Изменению 1.1 - Доверенный режим разгрузки. Каждое изменение задокументировано с одинаковым уровнем детализации: предпосылки, пронумерованные требования с приоритетом и условиями, явные критерии приёмки для тестирования.
Фрагмент ТЗ по алгоритму обработки первого сканирования штрихкода в доверенном режиме разгрузки. Роль BA включала проверку всех подобных диаграмм на соответствие ФТ для обеспечения полноты и корректности до начала разработки.
Фрагмент инструкции оператора по доверенному режиму разгрузки, подготовленной как часть пакета передачи. Инструкции написаны для самостоятельного использования операторами дока с первого дня без поддержки разработчиков.