2. Факторы эффективности
Для руководителя проектов, эффективность
использования аналитических работ
напрямую зависит от:
• получаемых «выгод»
• стоимости работ
Летний Аналитический Фестиваль 2012
4. Выгоды
1. Повысить эффективность разработки, за
счет уменьшения количества изменений.
2. Повысить эффективность коммуникаций.
3. Улучшить процесс управления.
4. Снять риски потери ключевых знаний.
----------------------------------------------------------------
Документирование
Летний Аналитический Фестиваль 2012
6. Затраты
1. Внедрение процессов (МП+ВА)
2. Управление требованиями (МП+Команда)
3. Разработка требований
4. Поддержка требований
Летний Аналитический Фестиваль 2012
7. Эффективность разработки
Таким образом, простейшими измерениями
эффективности аналитических работ,
является отношение переработок,
которые он смог(бы) предотвратить, к
затратам на него
Летний Аналитический Фестиваль 2012
8. Методы измерения
Статистический – подсчет количества Update
Hot Update
Product Development
переработок может оцениваться исходя из
Fix Pack 1 Pack 2
функционала, который был выброшен из
проекта или сильно переработан.
a) подсчет количества версий системы
вышедшей после релиза, но до начала
эксплуатации;
b) маркировка требований, как «пропущеные
или дефектные» требования.
Летний Аналитический Фестиваль 2012
9. Методы измерения
Экспертный – предложение руководителю:
– привлечь на проект необходимые
аналитические ресурсы и
– пройти необходимое обучение;
одновременно с требованием определить
стоимость проекта после этих изменений.
Летний Аналитический Фестиваль 2012
10. Характеристики проекта, на
которые может влиять
• Точность оценки бюджета проекта.
• Возможность управления объемом
проекта.
• Определение текущего прогресса.
• Количество проблем при сдаче-приемке.
Летний Аналитический Фестиваль 2012
12. Возможность управления
объемом проекта
Основные требования:
• оперативное выявление изменений,
выходящих за рамки текущего объема
• адекватное реагирование на него )оценка
стоимости изменения и принятие решения
о его внесении в объем проекта)
реализации.
Летний Аналитический Фестиваль 2012
13. Определение прогресса
• Метод освоенного объема.
• Burn-Up/ Burn-Down charts в разрезе
требований.
• Качество функционала (распределение
багов по требованиям).
Летний Аналитический Фестиваль 2012
14. Что важно учесть
• Управление требованиями (УТ) должно
происходить по заказу менеджера проекта
по единому процессу и с участием всей
команды
• Разработка требований (РТ) может иметь
огромную скрытую стоимость
• Небольшое повышение качества
требований или процессов может
выливаться в другой порядок стоимости
Летний Аналитический Фестиваль 2012
15. Типовые проблемы УТ
• Нет общепризнанной схемы деления
• Не выбран принцип деления на элементы
объема
• Нет единого места учета
• Границы зафиксированы отрывочно и по разному
• Требования оторваны от структуры системы
• Высокая трудоемкость поддержки выбранной
схемы учета
• Высокая трудоемкость управления изменениями
Летний Аналитический Фестиваль 2012
16. Типовые проблемы РТ
• Полная стоимость РТ не учтена при
планировании
• Обрыв в потоке информации (недоступны
источники информации или потребители)
• Не совмещен контекст
• Нет возможности получить адекватное
проектное задание
• Нет разделения на варианты проработки при
создании новой системы
Летний Аналитический Фестиваль 2012
17. Рабочий поток РТ
ПЗ/обр.
связь
ИД
ИИ
РТ
Потребители
Требования
ИИ
Эксперты ЛПР
Летний Аналитический Фестиваль 2012
18. Эффективность взаимодействия
Эффективность
аналитических
работ
1
Время аналитика/
Общие трудозатраты команды на РТ
Летний Аналитический Фестиваль 2012
20. Качество требований
1. Входящие требования зафиксированы как
есть
2. Достаточно для
a) Учета объема системы
b) Оценки работ (указанной точности)
c) Приемки и разработки системы
d) Тестирования
С ростом качества стоимость разработки и
поддержки растет нелинейно.
Летний Аналитический Фестиваль 2012
21. Документ vs контекст
Общий контекст
Команда Документы Заказчик
Летний Аналитический Фестиваль 2012
22. Эффективность коммуникации
Заказчик 1 Группа разработки 1
Заказчик 2 Аналитический Группа разработки 2
процесс
Заказчик 2
Тест лаб.
Летний Аналитический Фестиваль 2012
23. Разделение роли аналитика
• Менеджер проекта
• Владелец системы/представитель
заказчика/менеджер продукта
• Архитектор/разработчик/тестировщик –
кросс-функциональные игроки
Летний Аналитический Фестиваль 2012
24. Выделенный аналитик
• Очень много (десятки) заинтересованных лиц вне
проекта, мнения которых надо сводить воедино (когда
МП не хватает)
• Очень большая команда (десятки) с отчетливым
разделением ролей
• Необходимость контрактирования и организации сдачи-
приемки
• Большие потоки изменений, требующие управления
• Сложная концептуальная проработка
• Разработка сложной технологии применения ИТ
• Необходимость создания центра экспертизы
Летний Аналитический Фестиваль 2012
25. Чтобы аналитик был эффективен
• Адекватный заказ от менеджера проекта
(компетенция МП не всегда позволяет
применить аналитика эффективно)
• Вовлечение всей команды в управление
требованиями
• Вложение полной стоимости в разработку
требований
• Обеспечение неразрывности потока
информации
Летний Аналитический Фестиваль 2012
26. Летний
All you need is … Аналитический
Фестиваль
г. Иваново
23-24 июня 2012
conf.uml2.ru