Виды рисков и способы их снижения при выполнении информационных проектов

Обновления выпускают не одним большим релизом, а по мере готовности и как можно чаще. Доработки и усовершенствование продукта происходят циклично. Короткие циклы работы над каждой задачей называют итерациями.
Длина итерации равна двум-трем неделям. Каждая итерация – это самостоятельный мини-проект, который включает анализ требований, проектирование, программирование, тестирование, документирование, оценку результатов. Принцип такой: разработали – протестировали – учли обратную связь – идем дальше. В тестировании продукта участвуют реальные потребители, которые дают обратную связь, высказывают свои пожелания. Итогом каждой итерации должен стать пусть и не окончательный продукт, но работающий прототип, уже способный порадовать пользователей и огорчить конкурентов. Каждый цикл гибкой разработки AGILE вносит в продукт что-то новое. Каждая следующая итерация дорабатывает его, обновляет до новой версии, увеличивает эффективность и функциональность, добавляет новые возможности. По окончании итерации команда производит оценку результатов и переоценку приоритетов. Затем начинается новый виток разработки. Модель итерации: для работы над проектом собирается рабочая группа специалистов разного профиля (3-10 человек), внутри которой происходит постоянное взаимодействие. Важные требования к персоналу: способность к самоорганизации и самостоятельному принятию решений; T-SHAPE – непрерывное осваивание новых знаний, обучение друг у друга, расширение бэкграунда; кросс-дисциплинарность: каждый специалист не замыкается на своей узкой сфере, а владеет базовыми знаниями из смежной области:
 Например, программист или UX-дизайнер должен быть немного маркетологом. Фиксированной зарплаты обычно нет. Главная цель – произвести работающий продукт информационного проекта. К этому результату и привязано вознаграждение. Над проектом работают не только тестировщики и дизайнеры интерфейса, но и представители заказчика (product owner) – менеджеры проекта, бизнес-аналитики. В этом суть технологии эджайл – заказчик и разработчики непрерывно взаимодействуют друг с другом: регулярно собираются на короткие совещания, обсуждают актуальные задачи и разрабатывают способы их решения.
Подход AGILE эффективен для информационных проектов при организации труда небольших проектных групп, которые выполняют творческую и при этом однородную работу, например, занимаются разработкой новой версии продукта. Востребована гибкая методология в сферах дизайна и UX. По принципам эджайл интуитивно организуют свою работу многие коллективы программистов.
AGILE-менеджмент: роль и задачи управленца информационных проектов. Эджайл – это не столько способ управления, сколько способ командного взаимодействия, который позволяет эффективно работать над продуктом.
AGILE-команда информационных проектов строится на самоорганизации и равенстве всех участников. Логично, что и функции управленца в этом случае меняются. AGILE менеджмент информационных проектов – это управление проектом не на принципах иерархии, а на ответственности отдельных участников друг перед другом. Начальник в команде AGILE – это скорее куратор, идейный вдохновитель и помощник. Его задача – не довлеть своим авторитетом, а донести до исполнителей, каким должен быть конечный продукт, организовать людей для эффективной совместной работы.
Задачи управленца, применяющего технологию AGILE: знать, что важно для заказчика и пользователей. Оценить каждую пользовательскую историю и правильно расставить приоритеты.
Определить последовательность работ, что сейчас, что позже: например, срочно устранять ошибки или заняться сложным апргейдом без немедленной коммерческой выгоды.
Но, который поможет проекту «выстрелить» в будущем. Сделать так, чтобы задержки в работе одного отдела не влияли на работу остальных.
AGILE-management удачно управляет рисками информационных проектов, так как для оценки эффективности работы команды используют специальные метрики. К выбору метрик в AGILE применяется тот же гибкий подход: нет универсального набора. Каждая команда выбирает свои показатели. Для большинства проектов подойдут следующие метрики: Velocity и WIP (Work-in-Progress).
Velocity оценивает количество задач, выполненных за одну итерацию, WIP – лимит задач на разных стадиях (он не должен быть слишком высоким: большое количество задач невозможно эффективно проработать).
Capacity – прогнозирование идеального количества часов для каждой итерации. Позволяет понять, сколько времени есть на работу и как это время эффективно распределить, спланировать количество задач.
Метрики оценки качества моделирования проектных процессов на основе сетевых моделей. К ним относится индекс стабильности требований, который позволяет определить время, потраченное на переделывание задач. Его можно рассчитать по формуле: общее количество оригинальных требований + количество требований, которые изменились к этому времени + количество требований, которые добавились + количество требований, которые убрали / общее количество оригинальных требований
Метрики оценки ценности продукта для пользователей информационных проектов. Например, пропорциональный рост числа пользователей после каждого цикла усовершенствования продукта. Метрики информационных проектов необходимо постоянно пересматривать, меняя устаревшие – в этом основа минимизации рисков информационных проектов.








2