![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Управление рисками ⇐ ПредыдущаяСтр 5 из 5
Риск 1: ошибки, присущие расписанию Благодаря своей неощутимой природе и уникальности программного обеспечения, процесс разработки ПО сложно оценить и расписать. Решение - все больше вовлекайте команду в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком. В проектах, использующих гибкую методологию, команда активно вовлечена в планирование. Работая в коротких этапах, скорость работы команды резко увеличивается, и это явно видно всем участникам проекта, кто на данный момент более вовлечен в проект. Риск 2: появление новых требований По ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки. Решение - постоянное вовлечение клиентов и разработчиков. В проектах, использующих гибкую методологию, регулярно планируются и обсуждаются все функции и сроки на границах каждого этапа. Изменения и требования в таких проектах принимаются как данность. Вместо простого использования методов подавления изменений, планируются сессии по установлению приоритетов, которые позволяют рационально выполнить все изменения. Риск 3: смена сотрудников Ключевые сотрудники могут покинуть проект, унося при этом с собой критическую информацию, что значительно откладывает и сносит проект с рельсов. Решение-высокий уровень сотрудничества и обмена информацией в команде. Техники обмена информацией в случае с гибкой методологией, такие как парное программирование, использование обобщенного кода и частые отчеты, каждодневно противостоят вероятности потери информации. При снижении фактора утери сотрудника многие члены команды обмениваются ключевой информацией, следовательно, риск, связанный с уходом ключевых сотрудников, низок. Также стоит учесть, что, работая в захватывающей, награждающей и кооперирующей среде, как в случае с проектами, основанными на гибкой методологии, люди реже хотят покидать проект. Риск 4: декомпозиция спецификации При старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования. Решение - нанять преданного менеджера по продукции для осуществления критических договоров и решений. Проекты с гибкой методологией используют опытных пользователей, экспертов в области или посредника клиентов в качестве менеджера по продукции. Идея заключается в том, что кто-то (или некая группа) должен быть готов отвечать на вопросы и осуществлять решения в проектах. Традиционные проекты страдают от декомпозиции специификации, когда никто не исполняет такую роль, и появляются конфликтующие предположения и решения. Проекты должны обладать некой ролью владельца проекта в составе команды для обеспечения своевременного принятия решений. Риск 5: низкая продуктивность Наличие впереди длительных сроков приводит к тому, что на ранних стадиях зачастую отсутствует чувство срочности в работе, а это в результате дает в начале проекта потерю времени, которое уже нельзя вернуть. Решение-короткие итерации, нужные люди в команде, лидерство и развитие команды. Гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах. Закон Паркинсона гласит о том, что работа удлиняется, заполняя доступные рамки времени, а синдром студента говорит о том, что имея срок, люди зачастую ничего не делают до того момента, как этот срок будет близок. Применяя короткие итерации, работа разделяется на множество этапов (обычно 1-4 недели) и всегда существует чувство срочности. Гибкая методология не концентрируется на нужном персонале и развитии команды, но это основа роли лидера и применяется как в гибкой, так и в традиционной методологиях.
Приказ на начало выполнение проектных работ. Сервис «Голосовой микроблог»
приказ
30.10.2015 № 154ПК
О начале работ по проекту сервис «Голосовой микроблог» В целях: Создание уникального инвестиционного проекта «Голосовой микроблог». В рамках предоставляемых услуг выделяют несколько видов работ с сервисом: 1. Обмен короткими голосовыми сообщениями. 2. Длительные голосовые переговоры. 3. Использование голосовых команд для управления сервисом Приказываю С 01.11.2015 г. Начать работы по проекту сервис «Голосовой микроблог» Назначить руководителя проекта директора Абайханов Ибрагим Юнусович. Утвердить состав рабочей группы: директор – Абайханов Ибрагим Юнусович; тестировщик – Абайханов Ибрагим Юнусович; менеджер – Абайханов Ибрагим Юнусович а; программисты – Дмитриев Андрей Михайлович, Александров Дмитрий Владимирович, Васильева Анастасия Александровна, Петров Сергей Сергеевич, Смирнов Михаил Дмитриевич, персонал сопровождения -Дмитриев Андрей Михайлович, Александров Дмитрий Владимирович, Васильева Анастасия Александровна, Петров Сергей Сергеевич, Смирнов Михаил Дмитриевич, дизайнер - Доможиров Владислав Александрович, бухгалтер - Игнатьев Дмитрий Сергеевич Контроль исполнения приказа возлагаю на Абайханова Ибрагима Юнусовича
Директор (подпись) Абайханов И Ю
Унифицированная форма № Т-1
(наименование организации)
(распоряжение)
|