Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Управление рисками






Риск 1: ошибки, присущие расписанию

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

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

Риск 2: появление новых требований

По ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки.

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

Риск 3: смена сотрудников

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

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

Риск 4: декомпозиция спецификации

При старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования.

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

Риск 5: низкая продуктивность

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

Решение-короткие итерации, нужные люди в команде, лидерство и развитие команды. Гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах. Закон Паркинсона гласит о том, что работа удлиняется, заполняя доступные рамки времени, а синдром студента говорит о том, что имея срок, люди зачастую ничего не делают до того момента, как этот срок будет близок. Применяя короткие итерации, работа разделяется на множество этапов (обычно 1-4 недели) и всегда существует чувство срочности. Гибкая методология не концентрируется на нужном персонале и развитии команды, но это основа роли лидера и применяется как в гибкой, так и в традиционной методологиях.

 

 

Приказ на начало выполнение проектных работ.

Сервис «Голосовой микроблог»

 

приказ

 

30.10.2015 № 154ПК

 

О начале работ по проекту сервис «Голосовой микроблог»

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

1. Обмен короткими голосовыми сообщениями.

2. Длительные голосовые переговоры.

3. Использование голосовых команд для управления сервисом

Приказываю

С 01.11.2015 г. Начать работы по проекту сервис «Голосовой микроблог»

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

Утвердить состав рабочей группы: директор – Абайханов Ибрагим Юнусович; тестировщик – Абайханов Ибрагим Юнусович; менеджер – Абайханов Ибрагим Юнусович а; программисты – Дмитриев Андрей Михайлович, Александров Дмитрий Владимирович, Васильева Анастасия Александровна, Петров Сергей Сергеевич, Смирнов Михаил Дмитриевич, персонал сопровождения -Дмитриев Андрей Михайлович, Александров Дмитрий Владимирович, Васильева Анастасия Александровна, Петров Сергей Сергеевич, Смирнов Михаил Дмитриевич, дизайнер - Доможиров Владислав Александрович, бухгалтер - Игнатьев Дмитрий Сергеевич

Контроль исполнения приказа возлагаю на Абайханова Ибрагима Юнусовича

 

Директор (подпись) Абайханов И Ю

 

Унифицированная форма № Т-1
Утверждена Постановлением Госкомстата России
от 05.01.2004 № 1

    Код
  Форма по ОКУД  
  по ОКПО  
       

(наименование организации)

  Номер документа Дата составления
ПРИКАЗ    

(распоряжение)






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.