Project Life Cycle. Дмитрий Абросимов, Руководитель департамента партнерских проектов, Terrasoft

Save this PDF as:
 WORD  PNG  TXT  JPG

Размер: px
Начинать показ со страницы:

Download "Project Life Cycle. Дмитрий Абросимов, Руководитель департамента партнерских проектов, Terrasoft"

Транскрипт

1 Project Life Cycle Дмитрий Абросимов, Руководитель департамента партнерских проектов, Terrasoft

2 Команда проекта

3 Структура команды проекта Исполнитель Заказчик Управляющий комитет Управляющий партнер Директор практики Заказчик проекта Спонсор проекта Руководство проектом Директор практики Руководитель проекта Куратор проекта/ Заказчик проекта Руководитель проекта Рабочая группа проекта МРК Консультанты по внедрению РГ КВ РГ РБР Разработчики бизнес-решений CRM-координатор Рабочая группа от бизнеса IT-координатор IT/Аналитики

4 CRM-координатор. Кто он? Профессиональные компетенции: Аналитик либо IT-специалист с хорошим знанием бизнеса Или: Представитель бизнеса с хорошими аналитическими способностями Требования: Знает все о бизнесе заказчика Знает требования бизнеса к системе В совершенстве владеет функционалом продукта Обучает и консультирует пользователей Понимает дальнейшее развитие проекта

5 Project Life Cycle. Фаза Initiation

6 Текущий проект Initiation Execution ППО+ КП + Roadmap Договор Поставки

7 Провести анализ рисков Фаза Initiation Определить рисковые работы и провести по ним исследования Проанализировать состав работ и определиться с составом команды Составить карту рисков и заполнить Project Health Card

8 Управление рисками в проекте Идентификация рисков процесс определения перечня рисков, которые могут воздействовать на проект Качественный анализ рисков процесс расстановки приоритетов в отношении рисков для их дальнейшего анализа или действий, выполняемых путем оценки и сопоставления их воздействия и вероятность возникновения Количественный анализ рисков численный анализ воздействия идентифицированных рисков на цели проекта в целом

9 Управление рисками в проекте Планирование реагирования на риски разработка вариантов и действий по расширению благоприятных возможностей и сокращение угроз для проекта Контроль рисков еженедельный мониторинг рисков, планов по реагированию и отслеживанию новых рисков

10 Пример отчета по проекту

11 Анализ рисков Игра «Найди риск». Мы задаем себе 4 вопроса: Что может быть источником риска? Явление, обстоятельство, обусловливающее наступление риска Какие симптомы у данного риска? Какие возможные последствия риска? Какая степень влияния риска?

12 Пример Проект не обеспечен ресурсами Формулировка риска Отказ от проекта Первопричина Условия Последствия Величина убытка Нехватка разработчиков Смещение сроков, урезка функциональности

13 Текущий проект Elaboration Устав Концепция

14 Фаза Elaboration: Устав Клиент CSD / CSE Эксперт Презентация проекта команде (внутренняя продажа) Актуализация и детализация списка работ, анализ предыдущего опыта, проработка темных пятен проекта Составление первой версии плана и устава Подготовка к первой рабочей сессии Первая рабочая сессия (презентация проектной методологии, обучение рабочей группы заказчика, воркшоп) Утверждение устава МРК

15 Фаза Elaboration: Устав На данной стадии проводится первая рабочая сессия с заказчиком и по ее результатам формируется окончательные варианты устава и календарного плана проекта В рамках первой рабочей сессии (личная встреча от 4 часов до 3 дней) проводится: презентация проектной методологии обучение продукту и Customer Success Portal детализация целей и задач проекта, работа по концепции Утверждение устава необходимый шаг для продолжения работ по проекту

16 Фаза Elaboration: подготовка к первой рабочей сессии Отправить информационный запрос на предоставление документов и описание бизнес-кейсов Проработать полученные документы. Составить перечень темных пятен Подготовить план обучения и рабочей сессии с учетом бизнес-кейсов и проданного функционала Составить первую версию календарного плана

17 Фаза Elaboration: пример запроса на бизнес-кейсы

18 Правило двух итераций Клиент Изучает предоставленные материалы/функционал Изучает предоставленные материалы/функционал Комментарии Комментарии Результат согласован Terrasoft Согласовывает и вносит изменения Согласовывает и вносит изменения

19 Фаза Elaboration: Концепция Развертывание тестовых сред Клиент CSD / CSE Разработка концепции Проведение углубленного обучения системе для CRMкоординатора Внутреннее согласование концепции Презентация и утверждение концепции с заказчиком Эксперт

20 Цель документа сформировать общее понимание работы в будущей системе Фаза Elaboration: Концепция Концепция создается на основании бизнескейсов, предоставленных заказчиком Концепция описывает весь процесс работы пользователей, включая действия вне системы Документ описывает работу в системе с процессной точки зрения с использованием нотации BPMN, а также затрагивает вопросы аналитики, интеграций и программно-аппаратных требований

21 Фаза Elaboration -> Execution Утвержден устав Утверждена концепция Развернута тестовая среда на площадке заказчика или в облаке Рабочая группа владеет нотацией BPMN и основным функционалом системы Старт написания еженедельных отчетов по проекту

22 Не проведено обучение: Увеличение вовлечения сотрудников исполнителя в процесс приемки-передачи поставки Фаза Elaboration -> Риски Увеличение сроков тестирования со стороны клиента Увеличение сроков при согласовании технического дизайна Методы минимизации: После обучения пользователей, провести опрос на знание системы. Даст возможность сформировать картину по пониманию заказчика платформы Минимизация трудозатрат аналитиков на будущих фазах проекта

23 Фаза Elaboration -> Риски. Пример Проект Получили в городе следующий Москва набор рисков: Необходимо увеличение сроков сдачи Клиент поставок. крупный Аналитики банк будут объяснять клиенту базовый функционал Провели Клиент 4 будет сессии не понимать обучению. какие задачи В общей сложности можно покрыть обучили через 40 человек. базовый функционал Команда тестирования Минимизация: со стороны заказчика Провели Направили срез РП знаний. клиенту Сформировали статистику. Описали 40 состав рисков. простых вопросов через используя Google Form Предложили провели опрос. направить Результат документацию по следующий: платформе только и видеоуроки 35% ответили на большинство Через месяц вопросов провести еще правильно раз срез знаний

24 Типы программно-аппаратных сред Production среда промышленная среда заказчика для ежедневного коммерческого/операционного использования Pre-production среда программно-аппаратная среда, которая является копией production среды; необходима для тестирования системы и связанных с ней систем с промышленным наполнением Тестовая среда программно-аппаратная среда с неполным (тестовым) наполнением данными, которая содержит систему Terrasoft и все интегрируемые системы, необходимые для настройки системы и выполнения тестирования результатов поставки. Рекомендуется делать тестовую среду аналогичной pre-production среде.

25 Текущий проект Execution Поставки

26 Фаза Execution: Поставка Фаза Execution Поставка 1 Поставка Р Логически связанный блок функциональности, передаваемый на тестирование рабочей группе заказчика

27 Фаза Execution: Поставка Поставка Стадия технического дизайна Стадия адаптации и тестирования Стадия сдачи-приемки поставки Стадия тестирования заказчиком Две итерации Условие старта: утвержден ТД Проход по тест-кейсам Две итерации

28 Цель документа описать требования к системе, которые будут реализованы в рамках отдельной поставки Фаза Execution: Технический дизайн Технический дизайн содержит: Требования к полям/интерфейсам объектов Детализацию требований к скриптам Детализацию требований к аналитическим отчетам Детальное описание требований к интеграциям Тест-кейсы для тестирования требований Утверждение технического дизайна с заказчиком обязательное условие для старта адаптации

29 Фаза Execution: Тест-кейсы Тест-кейс это набор условий и/или переменных, с помощью которых при сдаче/приемке системы в рамках поставки и тестовой эксплуатации можно будет определить, насколько полно система удовлетворяет предъявляемым к ней требованиям Тест-кейсы пишутся на основании предоставленных заказчиком бизнес-кейсов Риски, если тест-кейсы будут не написаны: Нет критериев приемки системы Сколько протестировано заказчиком и сколько осталось Затягивание сроков по тестовой эксплуатации

30 Клиент банк Не были написаны и согласованы тест-кейсы на этапе Elaboration Фаза Execution: Тест-кейсы. Пример проекта Клиент проводил тестирование без плана Не было понимания у команды исполнителя, сколько клиентом было уже протестировано Срок тестовой эксплуатации из 2 недель превратился в 2 месяца Команде исполнителя пришлось создать набор тест-кейсов Дальше проводили ежедневный контроль по пройдённым кейсам и количеству блокирующих ошибок Как результат, увеличение срока проекта, трудоресурсов

31 Фаза Execution: -> Transition Завершена адаптация системы согласно технического дизайна Утвержден технический дизайн и тест-кейсы всех поставок Развернута pre-production среда на площадке заказчика или в облаке

32 Фаза Execution: -> Transition Необходимо зарегламентировать с заказчиком процесс тестирования в документе «Программа тестирования» В данном документе мы фиксируем методику проведения тестирования и процедуру управления дефектами

33 Фаза Execution -> Transition. Программа тестирования Инструменты тестирования Область Инструмент Владелец/Площадка Версия/Ссылка Тест-менеджмент Excel-файл Terrasoft Бегтрекинговая система Jira Terrasoft

34 Фаза Execution -> Transition. Программа тестирования Как заказчик должен описывать замечания Название поля Обязательность Описание Название Критичность Да Да Краткое описание дефекта, отвечающее на один или несколько вопросов: Указать функционал Desktop или Mobile В какой системе/компоненте/модуле? Что произошло? После каких действий? Критичность дефекта. Возможные значения: Blocker Critical Major Minor. Описание критичности дефектов см. в Табл. 1. Исполнитель Нет Исполнитель дефекта (на кого назначен). Описание Да Описание дефекта: Номер тест-кейса и название тест-сьюта Шаги для воспроизведения Ожидаемый результат Фактический результат Дата и время обнаружения ошибки Компоненты Да Указывается один или несколько компонентов, которые классифицируют дефект. Обычно дефекты классифицируются по интеграционным сервисам, внешним системам, потокам данных или типам дефектов. Правила классификации дефектов будут определены перед началом тестирования. Вложение Нет Прикрепляемые файлы, например: Screenshot ошибки Логи

35 Фаза Execution -> Transition. Программа тестирования Классификация дефектов Тип Описание Функциональный дефект Нефункциональный дефект 3. Дефект данных 4. Дефект конфигурации Несоответствие поведения или реализации Решения предъявляемым к нему функциональным требованиям, описанным в ТЗ. Несоответствие поведения или реализации Решения предъявляемым к нему нефункциональным требованиям, описанным в ТЗ. Дефекты, возникшие по причине неправильных данных, но не по причине неправильных расчетов и вычислений. Дефекты, возникшие из-за неправильной конфигурации стенда. Возможные критичности Blocker Critical Major Minor Major Minor Blocker Critical Major Minor Major Minor Примеры, причины 1. Неправильные вычисления. 2. В расчетах не учитываются какие-либо условия. 3. Неправильная трансформация данных. 1. Время открытия форм или ответа от внешних систем больше, чем требуемое. 2. Система медленно работает на больших объемах данных. 1. Функционал работает на одних данных, но не работает на других. 2. В Систему не загружены данные по независящим от Системы обстоятельствам. 3. В Систему загружены неправильные справочные данные. 1. Не были сделаны необходимые настройки. 2. Не исполнены необходимые скрипты. 3. Конечная система не отвечает. 5. Дефект ТЗ Ошибка в документации. Blocker Critical Major Minor Требования в ТД не удовлетворяют следующим принципам: 1. Полнота 3. Непротиворечивость 2. Однозначность

36 Фаза Execution -> Transition. Программа тестирования D,M Bug D,T D,М(И) New (from M,D) D,M In Progress D,М(И) Test T Feedback Жизненный цикл дефекта D Suspended D,M T Suspended T,М(И) D,T,M Resolved D,M D,M М(И) D Pending D,М(И) Rejected

37 Фаза Execution -> Transition. Программа тестирования Риски Описание риска Описание характера и степени влияния на результаты тестирования Описание возможностей обхода риска 1. Отсутствие у специалистов Исполнителя доступа к интерфейсам внешних систем для проверки успешности вызовов интеграционных сервисов либо не готовность внешних систем. Сроки завершения тестирования могут быть увеличены. Предоставление специалистам Исполнителя доступов к интегрируемым системам, необходимых для проверки успешности выполнения интеграционных сервисов. При отсутствии доступов к интерфейсам внешних систем тестирование может производится с использованием эмуляторов внешних систем. 2. В интегрируемых системах отсутствуют тестовые данные в достаточном объеме и необходимом качестве. Сроки завершения тестирования могут быть увеличены. Перед началом проведения тестирования необходимо провести подготовку тестовых данных во всех интегрируемых системах. 3. Отсутствие реальных обезличенных данных для проведения тестирования. В случае отсутствия реальных обезличенных данных для проведения тестирования, тестирование будет проводиться на тестовых данных, возможно сильно отличающихся от тех данных, которые будут обрабатываться сервисами в промышленной эксплуатации. Использование тестовых дынных влечёт риск пропуска значительного количества критических дефектов. Предоставить обезличенные реальные данные, из интегрируемых систем, которые в дальнейшем предположительно будут пользоваться разработанными сервисами. 4. Несвоевременное предоставление тестовой среды в соответствие с календарным планом. В случае отсутствия тестовой среды или её несоответствия предъявляемым требованиям сроки тестирования могут быть увеличены. Проверка соответствия тестовых сред предъявляемым к ним требованиям должна быть проведена заблаговременно до начала тестирования. 5. Недоступность (поломка) тестового стенда. В случае отсутствия возможности продолжать тестирование на тестовой среде сроки завершения ПСИ могут быть сдвинуты Недоступность специалиста Заказчика, ответственного за изменение информации о дефектах в системе поддержки процесса тестирования или несвоевременное изменение статусов дефектов. В отчетах по дефектам возможно отображение неправильной статистики. Выделить дополнительного специалиста со стороны Заказчика, ответственного за изменение информации о дефектах в системе поддержки процесса тестирования. 7. Отсутствие или неработоспособность конечных систем. Сроки завершения ПСИ могут быть увеличены. Подготовка конечных систем и выполнение Smoke-тестов до начала ПСИ. 8. Отсутствие доступа к багтрекеру или его неработоспособность. Увеличение сроков анализа и исправления дефектов. Работа с дефектами в Excel.

38 Текущий проект Transition ТЭ ОЭ ОПЭ

39 Фаза Transition

40 Фаза Transition: тестовая эксплуатация Подготовка production-среды Клиент CSD / CSE Сквозное тестирование системы командой Terrasoft на preproduction среде Стадия сдачи ИТ/Аналитикам (2 итерации полного прохода по тест-кейсам) Стадия сдачи бизнесу (2 итерации полного прохода по тест-кейсам) Эксперт

41 Старт стадии презентация и согласование хода фазы Transition (рекомендуется личная встреча) Фаза Transition: тестовая эксплуатация Выполняется на pre-production среде Сдача проходит в две стадии: рабочая группа ИТ/аналитиков и рабочая группа бизнеса Перед сдачей рабочей группе бизнеса КВ готовит первую версию регламентов и проводит их обучение Сдача проходит по тест-кейсам (написаны в рамках ТД поставок) Каждая стадия проходит в две итерации полного прохода по тест-кейсам

42 Фаза Transition: ТЭ -> ОЭ Выполнен проход по всем тест-кейсам Отсутствуют инциденты с типом ошибка высокого и критичного приоритета Подготовлена production-среда

43 Выполняется на production-среде, которая готовится на стадии тестовой эксплуатации Фаза Transition: опытная эксплуатация В начале стадии актуализируются регламенты и проводится обучение опытной группы пользователей Экзамен у пользователей принимает CRM-координатор Первые дни работы пользователей сопровождаются экспертами Terrasoft в формате baby-sitting на территории заказчика

44 Фаза Transition: опытная эксплуатация Опытная группа работает на промышленной среде Истек срок опытной эксплуатации. Срок опытной эксплуатации зависит от масштаба проекта и определяется календарным планом Отсутствуют инциденты с типом «ошибка высокого и критичного приоритета» Актуализированы регламенты

45 Фаза Transition: опытно-промышленная эксплуатация Выполняется на production-среде Участвует вся пилотная группа, которая была согласована в уставе проекта Обучение пилотной группы проводится тренерами заказчика

46 Пилотные подразделения работают на production-среде Фаза Transition -> Operation Истек срок опытно-промышленной эксплуатации. Срок опытнопромышленной эксплуатации зависит от масштаба проекта и определяется календарным планом Отсутствуют инциденты с типом «ошибка среднего, высокого и критичного приоритета»

47 Текущий проект Operation Торжественное закрытие проекта и ревизия Roadmap Активация поддержки проектного решения Закрытие проекта +Lessons Learnt Analysis

48 Фаза содержит ряд внутренних работ и внешних мероприятий: Фаза Operation документирование проекта анализ полученных уроков активация поддержки проектного решения торжественная презентация заказчику результатов проекта ревизия RoadMap

49 Результаты Lessons Learnt Analysis оформляются в виде статей в базе знаний Фаза Operation: Закрытие проекта, Lessons Learnt Analysis В результате документирования проекта готовится бриф документ, содержащий краткое описание основных особенностей проекта и ссылки на бекап базы данных и документации по проекту Активация поддержки проектного решения является обязательным этапом закрытия проекта При передаче проекта в службу поддержки за клиентом закрепляется CSM, которого эксперт проекта обучает проектному решению

50 Фаза Operation: Торжественное закрытие + RoadMap Основная цель данного шага подвести итоги текущего проекта с заказчиком и спланировать дальнейшее сотрудничество Для подведения итогов и презентации дальнейшего RoadMap проводится личная встреча с заказчиком и спонсором проекта, на которой CSE презентует достигнутые цели и функционал системы В рамках личной встречи также проводится вручение сертификатов на право использования продукта и поздравление с днем рождения Terrasoft

51 Регламенты ведения проекта Коммуникации Еженедельные статус-коллы и отчеты Раз в 2-4 недели отчет перед управляющим комитетом Вся документация и управление изменениями через CSP Электронная переписка как официальный документ Управляемый ход проекта Принцип двух итераций в согласовании всех результатов Возможность изменения набора задач в пределах объема проекта Сроки Ответ на запрос 2 рабочих дня

52 Спасибо! Материалы конференции