управление проектами _контрольная работа. Управление проектами_зачет. Управление проектами skillbox skillbox skillbox skillbox skillbox skillbox модуль Требования и риски проекта

• Название: Управление проектами skillbox skillbox skillbox skillbox skillbox skillbox модуль Требования и риски проекта
• Анкор: управление проектами _контрольная работа
• Дата: 05.05.2023
• Размер: 0.75 Mb.
• Имя файла: Управление проектами_зачет.pptx
• Тип: Документы; #1111287

УПРАВЛЕНИЕ ПРОЕКТАМИ

SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX

Модуль 5. Требования и риски проекта

SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX

Мобильное приложение для поиска пульта с функцией NFC

Требования проекта

SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX

Критичные	Некритичные
Мобильное приложение для платформы Android с функцией NFC	Приложение разработано Kotlin
Приложение размещено в Google Pay	Создание лендинга с презентацией приложения, наличие ссылки на скачивание приложения в Google Pay
Закуплено сервисное оборудование, лицензии, RFDI- метки	Функционал лендинга расширен: добавлен заказ NFC- наклейки на пульт
Функция «радар» для поиска пульта	Функционал приложения расширен: добавлен чат-бот для осуществления поддержки пользователей
Функция привязки пульта к приложению
NFC- наклейки на пульт предоставлены для теста MVP членам рабочей группы
Функционал для сбора обратной связи

Требования проекта

SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX

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

Потребность (проблема): отыскать пульт от телевизора, к которому приклеена NFC-метка, тем самым сократить время на поиск пульта управления от телевизора и снизить уровень стресса пользователя.

Решение: разработать мобильное приложение по поиску пульта от телевизора с функцией NFC.

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

четкие: мобильное приложение для платформы Android с функцией NFC, приложение размещено в Google Pay и т.д.

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

«хотелки»: цвет приложения серого цвета, кнопка подписки розового цвета и т.д.

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

Риски проекта

SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX

Управляемые	Неуправляемые
Неверно выбраная технология реализации	Скрытые требования для реализации функционала считывания RFDI- метки
Высокая загруженность разработчика задачами на другом проекте	Обстоятельства непреодолимой силы
Высокая загрузка заказчика операционными задачами	Выпуск аналогичного мобильно приложения конкурентами
Переход на новую платформу (обучение, доступы)
Увеличение сроков на необходимые для проекта закупки: сервисного оборудования, лицензии, RFDI- меток, предоставления доступов (Jira), согласования результатов работ (дизайн и т.д.)
Увеличение стоимости проекта
Несоответствие ожиданиям

Риски проекта

SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX / SKILLBOX

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

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

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

Управляемые — риски, которые можно предугадать и акцентировать на них внимание уже на начальном этапе проекта, определим для них ответственных и будем держать под контролем.

Неуправляемые — возможные риски, появление которых мы не можем предотвратить.