Авторы: Алексей Янчук, Константин Кондратюк

Каждому айтишнику приходилось читать творчество бизнес-аналитиков, называемое спецификацией. Что мы частенько видим перед собой? Путанное, неполное, противоречивое описание системы. Концентрируется на тривиальном. Сложные моменты объясняются двумя-тремя ничего не говорящими предложениями . В отдельных клинических случаях бывало и так, что согласно спецификации одна и та же функция системы должна работать диаметрально противоположно — в зависимости от того, читаете вы главу 3 или 9ть.

Можно привести свой опыт разработки проекта по спецификации. Все делаем по книжке, клиент подписал задание, рисуем прототипы, регулярно устраиваем чек-поинты с представителями пользователей, собираем обратную связь, уточняем планы. И вот, у нас демо перед запуском. Приглашаем небольшой коллектив представителей заказчика, показываем им систему. И тут главный товарищ со стороны заказчика говорит: а что-то я не вижу вот такой вот структуры данных в интерфейсе. А я (Алексей Янчук) с удивлением — простите, какой-какой структуры? Главный сдвигает брови, и сурово спрашивает, а зачем мы его тогда пригласили на демо, если самого важного во всей системы по факту не наблюдается? Простите — говорю ему — давайте обратимся к заданию. Вот тут у нас спецификация на 50 страниц, вот мы по ней все сделали. Не все! — отвечает заказчик, открывает спецификацию на середине и тыкает пальцем. Вот! — всем body language показывая, какого «высокого» он мнения о наших умственных способностях — вот тут доходчиво написано, что мне надо, а все остальное — это просто рюшечки вокруг ключевого функционала!

Что оказалось? В спецификации из 50 страниц на суть того, что должна делать система было отведено… 4,5 строчки текста. Четыре с половиной! Остальное, как оказалось, было добавлено «для солидности». Только вот мы разработчики, а не телепаты, и чужие мысли на расстоянии читать не умеем.

Тем не менее, печальная история, приведенная выше, показывает, зачем бизнес-анализ нужен и во что может вылиться его некачественный результат. А к сожалению, результат «в среднем по больнице» чаще всего некачественный, поэтому недовольны все: заказчики, бизнес-аналитики, и разработчики. Последние спецификации если и читают, то по диагонали — чтобы не засорять голову неправильными идеями.

Почему так получается? Тут есть два момента. Момент первый: бизнес-аналитик по определению менее квалифицирован в технической области, чем программист, да и часто имеет весьма далекое к ней отношение. Например, у него может быть диплом в сравнительной эконометрике и бизнес-кейс он может рассчитать с блеском, но вот сервер для него — это квадратик на логической схеме.

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

Бизнес-анализ — в ИТ — нужен, чтобы донести задачу до разработчиков, поскольку бизнес-клиент эффективно это сделать— в силу объективных причин — не может. К сожалению, частенько на практике бизнес-анализ заканчивается простым переведением слов клиента в MS Word. Что, как мы знаем, особо никому не помогает, зато генерирует занятость аналитикам. 😉

Что должен отражать качественно проведенный бизнес-анализ? Во-первых, он должен объяснить самому заказчику, что и как именно для него изменится, когда заказанная система заработает. Там, где систему невозможно просто включить, нужно иметь представление, как в принципе будет происходить введение в эксплуатацию. Кто и как ее будет поддерживать, и сколько это будет стоить.

Во-вторых, анализ должен обозначить риски и выделить приоритеты: что критично для работы, что важно, и чем — в особенности на первых порах — можно пожертвовать. Поскольку мы сейчас говорим о бизнес-анализе, хочется ясности относительно того, насколько пользователи становятся зависимыми от работоспособности новой системы: если система не работает, могут ли пользователи получить бизнес-результат альтернативными способами, могут ли они найти себе другое занятие.

В третьих, анализ должен обозначить допустимые отклонения от того, что заявлено в спецификации. Если заказанная система должна обрабатывать на пике 10,000 транзакций в минуту, что случится, если в реальной жизни максимум на пике упадет до 9,500?

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

И под конец пятое, самое важное. Анализ должен быть логичным, понятным, и не заставляющим десять раз думать. Анализ, который может понять только человек с двумя докторскими степенями — плохой анализ.

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