Дипломная (вкр): Формирование функциональных требований к CRM системе в сфере retail

-       всегда стоит придерживаться определенной структуры семинара;

-       участники семинара должны быть уполномочены принимать решения по модификации требований и формирования новых;

-       участники семинара всегда должны быть подготовлены к семинару и ознакомлены с повесткой встречи и прилагаемыми материалами;

-       все участники семинара должны понимать предметную область и «говорить на одном языке». В этих целях обычно утверждается Глоссарий;

-       все принятые решения должны быть зафиксированы и согласованы ответственными лицами со стороны заказчика в обязательном порядке;

Метод анализа и моделирования требований

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

.        Каждое требование должно быть уникально

.        Каждое требование должно быть представлено четко и ясно.

.        Каждое требование должно быть атомарным

.        Требования должны быть представлены последовательно

.        Каждое требование должно быть выполнимо

.        Каждое требование должно быть недвусмысленно

.        Каждое требование должно быть проверяемо

.        Каждое требование должно быть отслеживаемо

.        Отсутствие каких-либо неопределенных терминов, таких как «и т.д., и т.п., возможно, универсальный» из-за того, что из-за таких «лазеек» может быть очень сильно увеличен объем требования, а, следовательно, и скоуп работ по проекту.

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

Из-за очень сжатых сроков выполнения проекта, к процессу написания ФТ подключился процесс разработки сценариев использования систем (далее по тексту СИС). СИС в организации используется по аналогии с ТЗ, и далее передается разработчикам. В результате такого совмещения процессов разработки СИС на начальных этапах совпала с заключительными этапами разработки ФТ, что позволило более детально проработать требования. Сам по себе СИС - один из основных организующих механизмов, помогающих обсуждению и анализу функциональных требований. Цель их создания - облегчение взаимопонимания между заказчиком и исполнителем, детализация требований и нахождение слабых мест. Данная методика моделирования требований - это в большей степени просто упорядоченная структура для получения, анализа и согласования требований.

На этапе анализа на каждый процесс был выделен владелец со стороны исполнителя и ответственный со стороны заказчика по требованиям к определенному процессу (см. Рисунок 19). Таким образом, из-за большого объема информации для удобства согласования документа, по каждой группе процессов подготавливался отдельный СИС.

Рисунок 19 Матрица ответственных

Далее рассмотрим процесс разработки ФТ на примере процесса «Работа с обращениями», подпроцесса «Регистрация обращения/ задачи». Соответственно, для данного процесса также был подготовлен СИС. В общем и целом, структура этого документа представляет собой непосредственно описание самих сценариев, а также включает в себя:

-     электронные одноразовые прототипы пользовательских интерфейсов (см. Приложение В);

-     спецификации полей и кнопок используемых экранов (см. Приложение Г);

-     схемы БП (см. Рисунок 20);

-     диаграммы статусов (см. Рисунок 21);

-     визуализация различных алгоритмов (см. Приложение Д)

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

-     визуализация алгоритмов выбора обращения и т.д.;

-     другие различные вспомогающие средства визуализации.

Рисунок 20 Схема БП «Регистрация обращения / задачи»

Рисунок 21 Модель состояний работы с обращениями Клиентов (поле «Статус» для обращения)

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

Во время работы над сценариями использования системы были выделены несколько их преимуществ как анализа и моделирования требований:

·        Позволяют находить пропущенные шаги

·        Возможность построения хронологической последовательности

·        Возможность для различных предложений со стороны представителей заинтересованных лиц вследствие более детального понимания взаимодействия с системой

·        Позволяют избежать дублирования, двусмысленности, неактуальности требований

Путем совмещения методик, описанных в разделе «Методика сбора и анализа требований» и методик по написанию сценариев использования системы были выявлены, задокументированы и согласованы функциональные требования. Ниже приведена выдержка из ФТ, применительно к рассматриваемому процессу «Работа с обращениями» (см. Таблица 10).

Таблица 10 Выдержка из ФТ

Специфика документирования требований

Все функциональные требования заносятся в единый, выявленный опытным путем, шаблон написания документа, фиксирующего функциональные требования к продукту (см. Таблица 10). На момент составления документа по ФТ, каждому бизнес требованию был присвоен уникальный идентификатор. В целях сохранения иерархии каждое детализированное требование было описано со ссылкой на соответствующее родительское БТ. Так же для поддержания процесса управления требованиями в структуре документа заполнялся раздел «История документа» с указанием следующих параметров:

-       Версия документа

-       Дата изменения

-       Автор изменения

-       Описание внесенных изменений

-       Комментарий

Для каждой версии документа (0.1, 0.2, 1.1, 1,2….) используется последовательная нумерация. Актуальные версии документов ведутся в общей системе Confluence а все изменения в документах выполняются в режиме правки.

Специфика согласования требований

Особенностью проекта является то, что согласование требований происходило не только со стороной заказчика, но и так же с вендорами. После этапа сбора требований и их разработки с представителями со стороны заказчика необходимо было провести валидацию требований с представителями компании внедряемой Системы Maxxing. На встрече проводился GAP анализ, результатом которого был список разрывов между функциональными требованиями и реальными возможностями системы, который был скорректирован в соответствии с временными рамками проекта.

Рисунок 22 Процесс согласования требований на проекте

Каждый подготовленный документ, кроме протоколов встречи проходил процесс согласования, схематически изображенный на Рисунке 22.

Специфика управления требованиями

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

Ниже представлена утвержденная диаграмма процесса управления изменениями.

Рисунок 23 Диаграмма процесса управления рамками проекта

Все запросы на изменения должны быть адресованы Руководителю проекта, предпочтительно с помощью формы регистрации запроса на изменения (см. Таблица 11)

Таблица 11 Форма регистрации запроса на изменение

Руководитель проекта должен координировать все действия, связанные с запросом на изменения. По всем запросам на изменения должен осуществляться анализ влияния на проект, включая предварительное перепланирование проекта.

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

После утверждения изменений Руководитель проекта должен провести стандартные процедуры перепланирования проекта, а именно обеспечить внесение изменений:

•в календарный план проекта;

•реестр рисков и открытых вопросов/проблем;

•в проектную и пользовательскую документацию;

•все изменения вносятся по мере необходимости.

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

Что касается успешного контроля хода проекта, на проекте используется:

-       Определение базовой версии документа

-       Контроль версий документов

-       Ведение атрибутов требований (владелец, приоритет, версия, дата изменения)

-       Использование инструментария Attlasian Confluence + Attlasian Jira

Системы от Atlassian славятся своей гибкостью и легкостью в управлении и настройке. Сочетание Jira и Confluence помогает эффективно управлять требованиями и большим спектром задач. В ходе проекта вся документация хранится и актуализируется в Confluence, там ведется вся информация и атрибутика требований, журнал изменений (см. Рисунок 24). Более того, при создании протоколов в Confluence есть возможность привязки поручения/ задачи в рамках документа (см. Рисунок 20). Опытным путем было выявлено, что в данных системах эффективно происходит взаимодействие всей проектной команды, легко и удобно отслеживается ход работ в рамках разработки требований.

Рисунок 24 Контроль версий документов в пространстве Confluence

Рисунок 25 Привязка поручений/ задач в Jira

Во время исследования были сформировано новое видение разработки функциональных требований, а также выявлены новые эффективные сочетания методов разработки требований к функционалу внедряемой системы

На основании полученных данных, эффективной разработки и согласования документа «Функциональные требования к проекту» и успешного завершения стадии «Анализ», можно сделать вывод об эффективности примененной стратегии. Благодаря хорошему руководству и опыту ведения больших проектов по внедрении CRM систем, проектной команде удалось внедрить систему лояльности за короткий срок, не критично нарушая временные рамки, успешно перераспределяя ресурсы.