analyst.by

Белорусское сообщество бизнес и системных аналитиков

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

Каждый проект в практике бизнес-аналитика по-своему уникален: не будет двух абсолютно идентичных, к примеру, 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:

Достоинства

Недостатки

  • Доступность актуальных версий спецификаций всем участникам проекта сразу же после изменений: не надо постоянно обновляться, следить за ревизиями.
  • Если необходимо всю документацию подписать с заказчиком, то придется её экспортировать в доступный формат (например, пдф), при этом связи документов между собой, все ссылки не переносятся (я не нашла возможности это сделать), значит надо править руками
  • Простота создания и поддержки документов, их иерархической структуры и навигации по ней (как по каталогам)
  • Сложно манипулировать таблицами (ширина, высота, фильтрация, стили и т.д.). Есть макросы, но в MS Word проще, честное слово =)
  • Простота линкования страниц, объектов, User Stories, внешних ресурсов
  • Ограниченные возможности форматирования текста.
  • Простота добавления картинок и файлов
  • Как следствие отсутствия интернета или недоступности Confluence, невозможно работать с документами, потому всегда хорошо бы иметь какой-то backup . Это теоретически. На практике же я не сталкивалась с потерей доступа к документации в Confluence.
  • Поддержка ревизий страниц, так же я не встречала конфликтов ревизий
  • Наличие авто-сохранения

 

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

Инструмент

Для чего использовался

  • XMind
  • Чтобы рисовать mind map
  • Jira & Confluence
  • Для ведения требований (User Stories и функциональные спецификации)
  • Visio & ARIS
  • Для создания wires CMS, визуализации бизнес – процессов
  • Basecamp
  • Общий ресурс, где команда заказчиков, разработчиков и DA выкладывали документы по проекту и замечания после demo, вели переписку по вопросам и таскам.
  • MS Word
  • Для документирования бизнес – требований.
  • MS Excel
  • Для traceability matrix

 

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

 

Спасибо,

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

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

EPAM Systems

 

 


17 Марта, 2013


Комментарии к “Бизнес-анализ на одном из моих проектов: процессы, инструменты, проблемы и результаты”
  1. Татьяна,
    спасибо за статью. Мне было интересно познакомиться с вашим опытом.
    Позвольте несколько замечаний, которые, возможно, будут полезны.

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

    В таких ситуациях я пытаюсь выяснить проблемы, которые хочет решить заказчик в проекте. В вашем случае это 

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

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

    Гораздо интереснее п. 2. Проблема сформулирована очень нечетко. Непонятно, в чем выражается отрицательный пользовательский опыт. Собственно, здесь пока и нет проблемы , а есть ситуация, которую можно охарактеризовать как «народу не нравится». Цель работы БА для этого пункта — найти и сформулировать проблему или множество проблем. 

    ИМХО, такой подход позволяет вовлечь заказчика в проект значительно глубже, чем дискуссии по поводу порядка коммуникаций с ним в проекте. С другой стороны, результаты обработки проблем заказчика позволят всей команде уже на старте проекта четко представлять себе рамки проекта. 

     

    • Спасибо за комментарий.

      Да, по опыту скажу, что это редкость, когда у заказчика изначально есть четко определенные требования, но для этого и существуют БА.

      По поводу п.2:  я не ставила целью в статье описать детально потребности заказчика (все-таки коммерческая тайна=)). Замечу лишь, что проблемы и пути их решения были  определены по пунктам и представлены в виде функций, ожидаемых в приложении. 

      По поводу “результаты обработки проблем заказчика позволят всей команде уже на старте проекта четко представлять себе рамки проекта”: что для вас есть старт проекта в этом случае?  Как результат обработки проблем заказчика, получается задокументированный набор того, что нужно сделать (Vision & Scope, Product backlog например). Отсюда да,  рамки проекта видны, но можно ли  100%  оценить трудозатраты в этот момент? И да, отмечу, что моя команда появилась только после того, как был составлен Vision & Scope.

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

  2. Что касается оценки трудозатрат проекта…
    Отталкиваясь от списка проблем проекта, логично сформировать список решений :) 

    Такой список решений будет включать условно следующие виды решений:
    1. Известные решения, ранее выполненные компанией в других проектах. Очевидно, что по таким решениям можно оценить трудозатраты с высокой точностью и малыми рисками.
    2. Известные в отрасли решения. Кто-то другой их уже делал. Очевидно, что по этим решениям оценить трудозатраты сложнее, но тоже можно, заложив дополнительные риски.
    3. Новые решения, разработанные непосредственно для решения данных проблем данного заказчика. Для этих решений, скорее всего, невозможно оценить трудозатраты с приемлемой точностью. Уровень рисков слишком высок. Как правило, в таких ситуациях разрабатывается прототип (concept proof) и только уже на его основе производится оценка трудозатрат.

    Здесь уже возникает управленческая проблема: трудозатраты нужно согласовать с заказчиком сразу; трудозатраты нужно согласовывать с заказчиком только после разработки прототипа. Один из возможных способов решения — разделение проекта на 2 части: 1) R&D проект по разработке прототипа 2) основной проект. Но, в каждом конкретном случае могут быть и другие варианты. 

     

  3. Я думаю, имеет смысл указывать в статьях следующие параметры.
    1. Примерны размер команды, работающий на проекте.
    2. Сроки проекта.
    3. Собственно проект fixed price или time and material.

  4. Возможно, вы правы. Для данного проекта было приблизительно так:
    - около 14 человек команды (с учетом коллег на стороне заказчика),
    - желаемые сроки у бизнеса — 2.5 мес с учетом праздников и выходных, реально вышло больше 4,
    - T&M 

Добавить комментарий
Также Вы можете войти используя: Facebook Google