34
потенциальная нехватка ресурсов для аналитических работ и ресурсов для
выполнения задач, связанных с координацией и контролем проекта. На
текущий момент, данная проблема решается следующими путями:
- совмещением для одного и того же сотрудника нескольких ролей;
- параллельное участие сотрудника в нескольких проектах;
- при условии достаточного уровня развития компетенции, привлечение
на аналитические и управляющие роли в проект сотрудников из числа
экспертов.
2.3. Анализ управления проектами по фазам, стадиям и этапам
жизненного цикла
Текущая схема проектной деятельности в компании ООО «ДИРЕКТ
КАТАЛОГ СЕРВИС» была разработана и введена в первом квартале 2018
года и действительна для всех участников процесса. Схема процесса
представляет собой каскадный (водопадный) подход к реализации продукта и
состоит из следующих фаз, стадий и этапов:
Этап 1. Инициация:
∙ Стадия 1. Инициация:
- Фаза 1. Формирование идей для будущих проектов к реализации.
- Фаза 2. Подача заявки в Департамент информационных технологий.
∙ Стадия 2 Анализ:
- Фаза 3. Подготовка бизнес концепции.
Этап 2. Планирование:
- Фаза 4. Оценка трудозатрат.
- Фаза 5. Комитет «Request Management Board (RMB)».
Этап 3. Исполнение:
∙ Стадия 3. Реализация:
- Фаза 6. Техническая разработка.
- Фаза 7. Тестирование.
∙ Стадия 4. Распространение:
35
- Фаза 8. Релиз.
Этап 4. Завершение:
∙ Стадия 4. Потребление
- Фаза 9. Оценка эффективности проекта.
Рисунок 14. Схема проектной деятельности в ООО «ДИРЕКТ КАТАЛОГ
СЕРСИС»
Фаза 1. Формирование идей для будущих проектов к реализации.
Инициация идей для будущих проектов может быть вынесена со стороны
любого из департаментов. Обычно данные идеи являются следствием
следующих ключевых потребностей:
- автоматизация или оптимизация бизнес процессов;
- запуск новых услуг и сервисов;
- требования законодательства, в связи с его изменением.
Внутри каждого департамент выделен ответственных сотрудник, который
аккумулирует весь список идей от своего департамента, формирует
представление о возможной реализации, определяет их приоритет и
потенциальные выгоды. Данному сотруднику назначается роль «Бизнес
партнер» и его определение является ответственностью руководителя
департамента. Бизнес партнерами внутри департаментов могут выступать:
бизнес-аналитик, старший менеджер или руководитель отдела / департамента.
36
Трудозатраты бизнес партнера на этом шаге могут варьироваться от 1 до 5
рабочих дней, в зависимости от целей и задач внутри департамента.
Каждый квартал в компании проходит ряд встреч рабочих групп,
состоящих из сотрудников с ролью «бизнес партнер» от всех департаментов
Данные встречи принято называть «Workshop».
Рисунок 15. График проведения Workshop
Workshop состоит их трех основных частей:
- мозговой штурм – в данной части все новые идеи совместно
обсуждаются и детализируется. Результатом завершения данной фазы
является формирование общего списка с принятыми идеями от всех
департаментов.
- «профиты» – в данной части все новые идеи проходят оценку с точки
зрения объема и значимости получаемой выгодны от их реализации.
Результатом завершения данной фазы является общий список идей и
оценками их потенциальных выгод по итогам реализации.
- назначение приоритетов – в данной части участники назначают идеям
приоритеты важности их реализации. На обсуждение попадают все идеи из
имеющихся на данный момент: идеи новые, которые были отобраны на
первых двух фазах и бэклок из отложенных идей. Результатом завершения
данной фазы становится финальный список идей, с оценками потенциальных
выгод и приоритетами по срокам реализации.
Общее время сессий, затрачиваемое на этап Workshop’а, может достигать
до 1 рабочей недели, в зависимости от объема накопленных идей.
37
Фаза 2. Подача заявки в Департамент информационных технологий.
После проведения встреч рабочих групп в рамках Workshop, ответственные
сотрудники департаментом составляют и подают заявку в департамент
информационных технологий по списку тех идей своего департамента,
которые получили высокий приоритет по необходимости реализации и
высокие оценки потенциальных выгод. Заявки заводятся только для новых
задач. По отложенным идеям, которые получили высокие оценки и
приоритеты в рамках Workshop, сотрудник только добавляет
соответствующие комментарии в уже созданные задачи. Для коммуникации с
департаментом информационных технологий используется программное
обеспечение Jira, разработка компании Atlassian. Как правило, на
формирование заявок и проставление комментариев закладывается 1 рабочий
день.
Фаза 3. Подготовка бизнес концепции. Для перехода на следующий этап
реализации идеи, необходимо подготовить функциональный документ –
«Бизнес концепция». Подготовка данного документа является совместной
работой бизнес-аналитика из департамента бизнес процессов, системного
аналитика из департамента информационных системе и автора задачи,
выступающего в рамках эксперта. Дополнительно для создания документа
могут привлекаться иные сотрудники департаментов и внешних партнеров,
выступающие в качестве экспертов или ответственных лиц, которым автор
задачи делегировал такие полномочия. Документ включает в себя результаты
трех анализов:
- анализ требований – включается в себя описание требований к объему
реализации, границы задачи, допущения и ограничения, а также бизнес кейсы.
Как правило, предоставляется со стороны заказчика и актуализируется, для
включения в бизнес концепцию со стороны бизнес-аналитика.
- бизнес анализ – включает в себя описание текущего процесса, если идея
касается его оптимизации (as is) и представление будущего процесса (to be).
Описание обязательно включает в себя подготовленную визуальную схему
38
процесса, составленную в любой из нотаций, при необходимости схема может
быть декомпозирована на несколько уровней. Если процесс в рамках
планируемой к реализации идеи, является новым – в результатах анализа
выступает только схема будущего процесса (to be). Анализ подготавливается
со стороны бизнес-аналитика, с привлечением автора задачи и системного
аналитика в качестве экспертов.
- функциональный анализ – включает в себя требования и варианты
технической реализации по задаче для систем, в которых проходит описанный
в бизнес анализе процесс. Требования содержат список всех необходимых
изменений в системах, их характер и потенциальные риски. Подготовка
функционального анализа является ответственностью системного аналитика.
После завершения аналитики и составления бизнес концепции, документ
в обязательном порядке проходит оценку качества – «Quality Gate».
Качественную оценку документа проводят: архитектор систем(ы),
руководитель департамента, для которого заявлена доработка и старший
менеджер команды разработчиков. Результатом качественной оценки
становятся их визы и/или комментарии к заявке в Jira. Соответственно либо
документ считается принятым, либо документ возвращается на доработку и
исправления.
В зависимости от объема изменений, сложности реализации и наличия
свободных ресурсов у участников аналитики, на подготовку бизнес концепции
может быть затрачено от 1-ой до 3-х и более недель. Выделение ресурсов
бизнес-аналитика и системного аналитика производится исходя ресурсных
планов работ на квартал в департаменте информационных систем и
департаменте проектов. Затраченное время для экспертов и их участие в
выполнении задачи по созданию бизнес концепции автор заявки
согласовывает с их руководителями.
Фаза 4. Оценка трудозатрат. Только по итогам верифициронного анализа,
со стороны департамента информационных технологий и департамента
39
проектов подготавливает оценка потенциальных трудозатрат. В рамках
данной оценки рассчитывается количество часов для следующих ролей:
- Разработчик (и) – сотрудник(и), осуществляющие непосредственно
кодирование и разработку продукта по идеи в системах компании. В
зависимости от объема проект, его сложности и специфики, работы могут
выполнять как одним сотрудникам, так и несколькими, последовательно или
параллельно;
- Аналитик ИТ систем – сотрудник(и), осуществляющие поддержу
проекта с точки зрения систем, в которых планируются работы по продукту.
Также в зону ответственности аналитика входит организация и проведение
пользовательских тестов (UAT);
- Менеджер по продукту – сотрудник, осуществляющий декомпозицию и
постановку задач проекта для аналитика и разработчика, отвечает за
соблюдение требований, коммуникацию с бизнес подразделениями и
согласование открытых вопросов, возникающих в ходе фазы разработки.
Также, в его зону ответственности может входить приемка работ по итогам
завершения стадии разработки, и вынесение решения о выпуске продукта на
продукционных сервер. Данные полномочия предоставляют сотруднику
ответственные лица со стороны бизнеса;
- Менеджер проекта – сотрудник, осуществляющий управление проектам
по оставшимся фаза проекта: контроль бюджета и сроков реализации,
согласование дополнительных расходов, если возникает такая необходимость,
также менеджер проекта осуществляет анализ эффективности проекта, по
итогам выпуска функционала на продукционный сервер;
- Координатор проекта – сотрудник, обеспечивающий административную
поддержку проекта: организация встреч и ведение их протоколов, подготовка
презентационных материалов, организация документа оборота.
Для удобства, оценка ресурсов производится в рабочих днях (m/d). В
зависимости от специфики и сложности задачи для реализации, набор ролей и
запланированное количество часов может разниться. Также, в рамках
40
проектной деятельности, один и тот же сотрудник, может выполнять
несколько ролей одновременно, соответственно его часы занятости
суммируются при их объединении. На фазу оценки ресурсов закладывается от
1-ой до 2-х недель. В этот срок закладывается оценка всех ресурсов для всех
бизнес концепций, прошедших качественную оценку. Без составленных
оценок общих трудозатрат идея не может пройти на следующую фазу
проектной деятельности.
Фаза 5. Комитет «Request Management Board (RMB)». После получения
оценок трудозатрат, идея для реализации попадает на специальный комитет
«Request Management Board (RMB)», где происходит ее презентация и защита
перед представителями бизнеса (уровень CEO, CEO-1) и финансовым
департаментом. На комитете происходит утверждение идеи к разработке и
выделение бюджета. Именно на данной фазе мероприятий завершаются
одновременно стадии инициации, планирования, а также стадия аналализа,
выдвинутая идея переходит в статус проекта к реализации или включается в
список задач более крупного проекта, который был утвержден.
В компании ООО «ДИРЕКТ КАТАЛОГ СЕРВИС» ввиду специфики
систем и их архитектуры, техническая разработка проводится только силами
собственных сотрудников департамента информационных технологий,
аутсорсинговые и аутстафинговые партнеры не привлекаются. Поэтому для
удобства, расчет выделяемого бюджета производится так же в рабочих днях
(m/d), сотрудники финансового департамента самостоятельно производят их
конвертацию в денежный эквивалент, согласно ставкам штатного расписания.
По итогам завершения разработки, на фазе оценки эффективности реализации
проекта, данные по фактическим трудозатратам, фиксируются финансовым
департаментом отдельно в отчете для бизнеса.
Финансовые затраты проекта относят к центру затрат департамента
продаж и разделяют пропорционально уровню влияния разработки на проект.
Например, если техническая доработка касалась всех действующих интернет
магазинов, то совокупные затраты по реализации лягут полностью на его
41
выделенный центр затрат, соответственно, если доработка касалась всех - ее
итоговая сумма затрат будет разделена на количество участвующих в ней
интернет магазинов. Процесс разделения долей затрат в данном случае будет
абсолютным, без применения коэффициентов по уровню прибыльности или
объемам продаж того или иного интернет магазина. Интернет магазин (ы) для
которых будет проведена разработка называются «спонсорами проекта».
В случаях, когда идея к реализации затрагивает только операционные
процессы и не связана с внедрением новых услуг или сервисов для конечных
покупателей, бюджет проекта формируется только из центра затрат
операционного подразделения – заказчика такой разработки. Подтверждение
такого решения является ответственностью руководителя данного
департамента.
Проектный менеджер осуществляет контроль расходов бюджета по
средствам отчета логирования времени выделенных сотрудников, в созданных
подзадачах по проекту в Jira. Если на стадии реализации уровень трудозатрат
фактически или потенциально будет превышать заложенный объем –
выделение дополнительных ресурсов производится только после согласования
бизнеса и финансового департамента, в рамках следующего комитета или
отдельной встречи.
На комитете идея может получить следующие статусы:
- «подтверждена к разработке в будущем релизе» – данный статус
означает, что идея принята к реализации, трудозатраты утверждены, а ресурсы
для реализации будут выделены. Проект признается краткосрочным,
техническая разработка и выпуск идеи на продукционный сервер будут
осуществлены в следующем релизе.
- «подтверждена к разработке в нескольких релизах» – данный статус
означает, что идея принята к реализации, трудозатраты утверждены, а ресурсы
для реализации будут выделены. Проект признается среднесрочным или
долгосрочным (в зависимости от количества релизов на фазе реализации),
техническая разработка и выпуск идеи на продукционный сервер будут
42
осуществлены в течение нескольких релизов.
- «отложена до следующего комитета» - данный статус означает, что идея
не была утверждена, бюджет на ее разработку не подтвержден, однако идея не
отклоняется, а будет повторное рассмотрена на следующем комитете. Такой
статус назначается задачам, которые бизнес признает необходимыми к
реализации, но трудозатраты которых не покрываются имеющимися
ресурсами или в проект требуются дополнительные инвестиции, например
закупку дополнительных лицензий или стороннего программного
обеспечения.
- «отклонена» - данный статус означает, что идея не принята к
реализации и выделение бюджет на нее не будет производиться. Такая идея
исключается из общего списка, а проектная деятельность по ней считается
завершенной. На практике, такие отклоненные идеи могут быть переработаны
со стороны бизнес партнеров
Фаза 6. Техническая разработка. После завершения комитета RMB, для
идей которые получили подтверждения в виде комментариев «подтверждена к
разработке в будущем релизе» и «подтверждена к разработке в нескольких
релизах», и перешли в статус «проект к реализации», со стороны департамента
информационных технологий и департамента проектов осуществляется
распределение ресурсов персонала, который планируется к привлечению в
реализации проекта. Результаты фиксируются в виде обновления в
квартальном плане работ. Далее информация об участии в проекте доносится
до выделенных сотрудников со стороны их линейных руководителей, по
средствам заведения соответствующих подзадач по проекту в Jira.
Далее начинаются операционные работы по фазе технической
разработки:
- Менеджер проекта проводит установочную сессию и совместно с
проектной командой разрабатывают: общий план работ, список открытых
вопросов, составляет карта коммуникаций и матрицу согласований, а также
устанавливается регламент информирования заинтересованных лиц по
43
проекту о его результатах. Итогом встречи становится создания документа
устав проекта или project summary.
- Менеджер по продукту совместно с аналитиком и разработчиком
проводят рабочую встречу, на которой все задачи по разработке проходят
декомпозицию. Такой подход делает стадию разработки более эффективной и
гибкой.
- Разработчик(и) по итогам декомпозиции осуществляют процесс
кодирования. Полученный в результате билд или несколько билдов с пакетами
изменений для системы развертывают на тестовом окружении, и проверяет
его работоспособность с технической стороны. В рамках проверки
рассматриваются как качество самого кода (оценка Quality Gate), так и его
стабильная работа, доступность нового функционала с точки зрения его
устойчивости. Если будущий функционал связан интеграционными
процессами с другими системами – осуществляется проверка интеграционных
точек и к данному шагу технической фазу тестирования привлекаются
контактные лица от остальных систем участников. Только после успешного
завершение процесса кодирования и технического тестирования разработчик
передает задачу аналитику для проведения пользовательских тестов.
- После получения информации от разработчика о завершении работ и
готовности кода с билдом по продукту Аналитик проводится бронирование
тестового пользовательского окружения и подготавливает сценарии
тестирования.
Длительность данной фазы может составлять от 2-х до 3,5 недель, если
разработка должна быть выпущена в ближайший релиз и от 3,5 недель до 7-ми
и более недель, если выпуск продукта осуществляет в рамках нескольких
релизов. После окончания данных работ фаза технической разработки
считается завершенной.
Фаза 7. Тестирование. На данной стадии Аналитик привлекает
Менеджера по продукту и/или экспертов и они совместно проходят
последовательное или параллельное выполнение тестовых кейсов.