Бизнес-анализ на одном из моих проектов: процессы, инструменты, проблемы и результаты

Каждый проект в практике бизнес-аналитика по-своему уникален: не будет двух абсолютно идентичных, к примеру, Agile проектов (даже в одной предметной области). На каждом будут свои команда и заказчик (все мы люди со всеми вытекающими =)), свои специфические проблемы и решения, инструменты и т.д. Я уверена, что у многих практикующих БА есть свои занимательные истории и набитые шишки. Это опыт.  В этой статье я бы хотела рассказать немного об одном из проектов, на котором мне довелось быть БА.

Предлагаю на рассмотрение следующее:

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

Итак, о заказчике и проекте.

Одна крупная компания по производству напитков в лице отдела маркетинга пожелала внести изменение в процесс предоставления контента на одном из своих крупных ресурсов для 3000+ сотрудников. Также они хотели обновить концепцию этого контента по многим причинам:

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

Для этого было принято решение запустить пилотную версию небольшой части приложения:

• новая концепция,
• другая система управления контентом,
• добавление внутренних социальных сетей и т.д.

Работать над концепцией и дизайном было приглашено стороннее дизайнерское агентство (назовем его DA), а компании, в которой работала я, необходимо было разработать само приложение под другую Content Management System (CMS).

Теперь об IT команде, которая в итоге должна была отдать продукт заказчику и пользователям (я не считаю DA, т.к. после выполнения своих задач эта команда не участвовала в процессе поставки продукта):

Со стороны заказчика:

• Менеджер, отвечающий за бюджет, поставку продукта и коммуникацию с заказчиком (отделом Маркетинга),
• Менеджер проекта, отвечающий за разработку;
• Архитектор;
• Консультант;
• Владелец продукта (представитель отдела Маркетинга).

Команда, членом которой я являлась:

• Менеджер, отвечающий за бюджет, поставку продукта и коммуникацию с заказчиком (всегда onsite)
• Бизнес-аналитик (я);
• Команда разработчиков;
• Команда по тестированию.

Много? Не мало, это точно. Сразу хочу отметить, что у заказчика большая иерархическая структура. Отсюда и определенные правила. Например, отдел Маркетинга сначала должен обратиться в свой IT отдел с запросом о предоставлении решения, и только после определения бюджета начинается работа.

Зачем я так подробно описываю? Чтобы показать «масштабы бедствия».

Немного о командировке

Я знала существующее приложение, контент, текущую CMS, цели заказчика (мне попали в руки документы, связанные с запросом на реализацию продукта, и исследования отдела маркетинга), потому составление предварительного плана и вопросов не вызвало особенных затруднений. План встреч формировался изначально заказчиком, а после –  инициаторами (IT, DA, Отдел Маркетинга) на ближайшие несколько дней в зависимости от вопросов, которые надо было решать. В то время, как DA активно проектировало концепцию будущего ресурса и рисовало первые wireframes клиентской части (полноценный дизайн еще впереди), я заканчивала сбор и подтверждение бизнес-требований и высокоуровневых функциональны требований. Мы регулярно обменивались документами и комментариями с DA, проводили совместные митинги, но плотной работы вместе не вышло (об этом позже). Приступить к детальным функциональным требованиям возможности не представлялось, т.к. wireframes не были закончены, а без хоть каких-то картинок заказчик был просто не готов обсуждать детали. Согласитесь, приятнее рассматривать картинки и комментировать, чем  думать над mind map и скучными вопросами =). Об обсуждении деталей работы в новой CMS и речи не шло.

Уезжала я с чувством выполненного долга, потирая руки в предчувствии бурной деятельности, ведь теперь будет сформирована наша команда, и еще много вопросов по реализации предстоит решить! Ну и что, что удаленно от заказчика, они очень милые и легко идут на контакт, и все будет замечательно, а я свой рабочий график смогу сместить так, как понадобится…

Проект был продан с условием использования итеративного подхода (по расписанию демонстрировать реализацию того, что было изначально запланировано в итерации, собирать отзывы после демонстрации, вносить изменения в требования и планировать следующую итерацию). Причин тому было несколько:

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

Первые проблемы появились, когда стало ясно, что с DA общаться удаленно получается ну очень медленно и только в присутствии заказчика. Сначала через руководителя команды DA, а потом и вовсе только узнавать детали дизайна из файлов, выложенных на общем ресурсе, и от заказчика (представителя отдела Маркетинга, который активно работал с DA и подтверждал дизайн). Организовывать ежедневные митинги оказалось крайне трудно, на письма и вопросы на общем ресурсе отвечают медленно, а ответы вызывают еще ряд вопросов, а новые вопросы, в свою очередь, вызывают удивление, раздражение и, порой, даже негодование.

Дизайн задерживается (менялось конечное видение объектов, что влияло в свою очередь на CMS), а разработка системы приостановиться не может. Понятия и объекты приложения изменяются…

Ввиду перечисленных проблем было принято несколько решений:

• делать определенные допущения относительно системы  внутри IT команды, информировать заказчика, ждать реакции и обсуждать по необходимости, вести разработку, показывать заказчику, а по отзывам после демонстрации результатов работы вносить изменения;
• привлечь локального консультанта, который мог бы выяснять важные вопросы с заказчиком лично.

Хочу отметить, что работать стало легче всей IT команде. Да, порой предположения не оправдываются, но мы их оглашаем заранее (до реализации), если опровержений не поступает,  делаем так, как предположили, а все исправления будут либо в следующей итерации, либо сразу после демонстрации (если это изменение не требует от команды больших усилий). Таким образом, у нас чуть больше свободы и заказчик не нервничает по поводу постоянных вопросов.

Если говорить об инструментах и требованиях, то ввиду тех же причин, по которым было принято решение об итеративном подходе к ведению проекта, бизнес-требования были разбиты на блоки функциональных требований, а требования были представлены в виде User Stories, которые и сформировали первоначальный Product Backlog. Перед каждой итерацией пересматривались User Stories в Backlog (ну никак без этих заморских словей), уточнялись и описывались детали, менялись приоритеты, определялись Story Points и Capacity команды, после чего формировался лог User Stories на следующую итерацию. Системой управления задачами и проектом была выбрана внутренняя JIRA. Для CMS системы создавались wireframes, чтобы наглядно объяснить идеи. Хочу добавить, что функциональные требования детально описывались так же  и на Confluence, а User stories и требования линковались: в каждой User story была ссылка на страницу с требованиями и наоборот. Я уже предчувствую эти вопросы =). Зачем описывать детально требования, если есть User Stories?? Это решение было принято по ряду причин:

• Команда слишком распределенная (PM-onsite; разработчики и тестировщики – разбросаны по Беларуси и Украине, БА после командировки не находится рядом ни с PMом, ни с тестировщиками, ни с разработчиками).
• Заказчик привык работать по своим определенным процессам, часть которых заключалась в поэтапном подписании и подтверждении всей документации на проекте (Business Requirements, Functional Requirements, Logical design, Physical design etc.). Хотя конкретно данный проект и был пилотным, документации не требовалось изначально, подстраховаться надо было.
• Ну и что греха таить, с заказчиком работали довольно давно, сами привыкли писать подробную документацию.

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

Напоследок прилагаю перечень тулов, которые были использованы в работе БА, а также немного о достоинствах и недостатках ведения детальных спецификаций на Confluence в сравнении с MS Word применительно к этому проекту.

Достоинства и недостатки ведения документации в Confluence:

Инструменты и средства по созданию и поддержке требований на проекте:

Вот как-то так, итерация за итерацией, мы и работаем =). Релиз не за горами…  Коллеги, хотелось бы услышать также ваши истории: как вы ведёте свои проекты, как общаетесь с заказчиком, какие инструменты и техники используете, что считаете важным, а без чего можно обойтись… Ведь обмен опытом необходим в нашей профессии.

Спасибо,

Татьяна Петкевич

Бизнес-аналитик,

EPAM Systems