Файл: Разработка регламента выполнения процесса «Управление информационными ресурсами».pdf

• отдел консалтинга – 15 человек;
• отдел разработки – 17 человек;
• отдел тестирования – 3 человека.

Решения разрабатываются на платформах Microsoft Dynamics CRM, Microsoft Dynamics 365 и Terrasoft. Решения позволяют обеспечить прозрачное и удобное взаимодействия продавца и покупателя, непрерывное обслуживание и персонализированный сервис; увеличивается скорость взаимодействия с клиентом и надежность сервиса.

Департамент BI-систем (Business Intelligence) состоит из 11 человек: отдел консалтинга – 6 человек и отдел разработки – 5 человек. Сотрудники департамента занимаются разработкой и внедрением решений на платформе Microsoft Power BI для визуализации и всестороннего анализа бизнес-данных для клиентов в банковской сфере и сфере страхования. BI-решения позволяют эффективно управлять бизнесом любого уровня сложности и обеспечивают точность принятия управленческих решений.

Департамент портальных решений состоит из 12 человек: отдел консалтинга – 7 человек и отдел разработки – 5 человек. Департамент предлагает клиентам в банковской сфере решения по автоматизации внутреннего документооборота на платформе Microsoft Dynamics 365 и Terrasoft Creatio. СЭД позволяют наладить взаимодействие между подразделениями и обеспечить эффективность обмена информацией.

На протяжении всей своей деятельности компания осуществляет разработку и внедрение информационных систем по каскадной (Waterfall) или инкрементной модели. Как правило, для проектов длительностью до 1 года используется предиктивный тип жизненного цикла проекта, а для проектов длительностью более 1 года – инкрементный.

Перед началом проекта внедрения информационной системы из сотрудников департамента формируется проектная команда. Процесс формирования команды осуществляется следующим образом:

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

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

В случае, если жизненный цикл проекта – предиктивный, процесс разработки и внедрения информационной системы содержит следующие фазы.

1. Анализ:
   1. руководитель проекта оценивает сроки и бюджет проекта и согласовывает оценку с заказчиком;
   2. аналитики разрабатывают проектную документацию (Частное техническое задание (ЧТЗ) и Техническое задание на разработку архитектуры системы), руководитель проекта после проверки согласовывает ЧТЗ с заказчиком;
   3. после согласования проектной документации заказчиком осуществляется переход к следующему этапу.
2. Дизайн:
   1. дизайнеры (внешние сотрудники) разрабатывают макеты экранных форм системы;
   2. после согласования макетов заказчиком осуществляется переход к следующему этапу.
3. Разработка:
   1. руководитель проекта определяет приоритет задач и распределяет их между аналитиками;
   2. аналитики ставят задачи разработчиком и контролируют их выполнения;
   3. специалисты по тестированию выполняют ручную проверку функционала;
   4. после завершения всех работ из ЧТЗ осуществляется переход к следующему этапу.
4. Тестирование:
   1. руководитель проекта координирует тестирование системы заказчиком (в режиме опытно-промышленной эксплуатации на выбранной группе пользователей/филиалов) и собирает обратную связь;
   2. руководителем проекта совместно с заказчиком осуществляется оценка системы: если система удовлетворяет требованиям, осуществляется переход к этапу «Поставки» (внедрения системы в промышленную эксплуатацию);
   3. если система не соответствует требованиям, руководитель проекта совместно с аналитиками разрабатывает технические задания на дополнительную функциональность и оценивает сроки и бюджет;
   4. после завершения разработки дополнительной функциональности, система заново проходит этап тестирования заказчиком.
5. Поставка:
   1. аналитики разрабатывают пользовательскую документацию и проводят обучение конечных пользователей;
   2. осуществляется запуск системы в промышленную эксплуатацию и последующее сопровождение.

В случае, если жизненный цикл проекта – инкрементный, на этапе анализа определяется количество и функциональность каждого инкремента, после чего первый инкремент проходит фазы от «Анализа» до «Поставки». Далее осуществляется переход к процессу разработки и внедрения следующего инкремента (набор фаз аналогичный).

Для управления проектом и контролем задач используется следующее программное обеспечение:

• MS Project используется руководителем проекта для решения задач:
  • планирование стадий проекта с указанием сроков;
  • планирование и оценка трудозатрат задач внутри стадии;
• Jira используется для решения задач:
  • постановка задач разработчикам;
  • уточнение информации по задачам;
  • контроль выполнения задач.

В Jira используются стандартные типы запросов (issue): задача (task) и ошибка (bug), а также базовый бизнес-процесс (рисунок 13):

Рисунок 12. Организационная структура компании

Источник: https://wiki.teamlead.ru/pages/viewpage.action?pageId=85229701

Вся проектная документация хранится в отдельной папке проекта в Microsoft SharePoint, доступ к папке есть только у проектной команды и руководителей.

2.2. Обоснование выбора методологии проектного управления

Последние несколько лет компания стала сталкиваться с проблемами при реализации проектов: при использовании привычной каскадной или инкрементной модели на фазе «Тестирование» от клиентов на разных проектах стало поступать большое количество требований на изменение текущей функциональности или разработку новой.

Новые требования вызваны разными причинами:

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

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

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

Для проверки возможности использования гибких методологий была проведена оценка применимости Agile-модели на выполняемых проектах. Анкету было предложено заполнить руководителям департаментов, менеджерам и руководителям со стороны заказчика на действующих проектах. Результат оценки представлен в таблице 4 и на рисунке 14.

Таблица 4. Оценка применимости agile на проектах компании

Рисунок 14. Диаграмма применимости подхода agile в компании (Agile Practice Guide, 2017)

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

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

Таким образом, необходимо, разработанная методология обладала следующими характеристиками:

• требования к системе в целом и отдельно к MVP продукта (Minimum viable product, Минимально жизнеспособная версия продукта) формируются до начала разработки, но после каждой итерации могут быть изменены или дополнены;
• разработка продукта осуществляется короткими (не более 1 месяца) итерациями;
• по завершении каждой итерации заказчику для получения обратной связи предоставляется работоспособная версия продукта;
• есть возможность пересматривать и изменять план следующих итераций;
• в проекте есть задачи, которые не могут быть реализованы с использованием Agile-практик (например, задачи по реализации интеграции с внешними системами, у которых отсутствует тестовый стенд).

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

1. События:
   1. Sprint (спринт, итерация): разработка будет проводиться короткими итерациями (длиной от 2 до 4 недель в зависимости от проекта);
   2. Sprint Planning (Планирование спринта): планирование спринта будет осуществляться руководителем проекта совместно с заказчиком и ведущим разработчиков;
   3. Daily Scrum (Ежедневный стендап): ежедневные встречи с команды с руководителем проекта со стороны заказчика для обсуждения статуса задач;
   4. Sprint Review (Анализ спринта): демо инкремента для заказчика (проводится при необходимости);
2. Артефакты:
   1. Product Backlog (Бэклог продукта): набор задач, который формируется на основе проектной документации;
   2. Sprint Backlog (Бэклог спринта): набор задач, которые обеспечивают реализацию необходимой функциональности инкремента;
   3. Increment (Инкременты): работоспособная версия продукта, которая предоставляется заказчику по итогу каждой итерации.

В качестве единицы итерации будет использоваться задача, а не пользовательская история, так как заказчики и команда уже привыкли работать с этим понятием. Перечень задач, которые должны быть выполнены за итерацию, определяет руководитель проекта совместно с заказчиком. Задачи оцениваются руководителем проекта совместно с аналитиками и ведущим разработчиком команды. Задачи оцениваются в часах, а не в Story points, потому, что заказчику сложно ориентировать в абстрактных единицах оценки и ему для понимания требуется оценка задачи в часах с указанием ориентировочного срока выполнения (в какой итерации будет реализовано).

Таким образом, применение SCRUM в чистом виде невозможно в рассматриваемой компании, но большинство практик могут быть успешно использованы. Сравнение гибридной методологии для компании с фреймворком SCRUM представлено в таблице 5.

Этап подготовки и согласования технического задания на проект до начала фазы разработки остается аналогичным предиктивной модели.

Таблица 5. Сравнение разработанной гибридной методологии с фреймворком SCRUM