Эффективность аналитических работ. Юрий Химонин и Сергей Нужненко

All you need is www.uml2.ru

Эффективность аналитических работ

Химонин Юрий,Нужненко Сергей

Летний Аналитический Фестиваль 2012

Факторы эффективностиДля руководителя проектов, эффективность

использования аналитических работ напрямую зависит от:

• получаемых «выгод»• стоимости работ



Выгоды1. Повысить эффективность разработки, за

счет уменьшения количества изменений.2. Повысить эффективность коммуникаций.3. Улучшить процесс управления.4. Снять риски потери ключевых знаний.----------------------------------------------------------------

Документирование



Затраты1. Внедрение процессов (МП+ВА)2. Управление требованиями (МП+Команда)3. Разработка требований4. Поддержка требований


Эффективность разработкиТаким образом, простейшими измерениями

эффективности аналитических работ, является отношение переработок, которые он смог(бы) предотвратить, к затратам на него


Методы измеренияСтатистический – подсчет количества

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

a) подсчет количества версий системы вышедшей после релиза, но до начала эксплуатации;

b) маркировка требований, как «пропущеные или дефектные» требования.

Product Development Hot Fix

Update Pack 1

Update Pack 2


Методы измеренияЭкспертный – предложение руководителю:

– привлечь на проект необходимые аналитические ресурсы и

– пройти необходимое обучение;

одновременно с требованием определить стоимость проекта после этих изменений.


Характеристики проекта, на которые может влиять• Точность оценки бюджета проекта.• Возможность управления объемом

проекта.• Определение текущего прогресса.• Количество проблем при сдаче-приемке.


Точность оценки бюджета


Возможность управления объемом проектаОсновные требования:• оперативное выявление изменений,

выходящих за рамки текущего объема• адекватное реагирование на него )оценка

стоимости изменения и принятие решения о его внесении в объем проекта) реализации.


Определение прогресса• Метод освоенного объема.• Burn-Up/ Burn-Down charts в разрезе

требований.• Качество функционала (распределение

багов по требованиям).


Что важно учесть• Управление требованиями (УТ) должно

происходить по заказу менеджера проекта по единому процессу и с участием всей команды

• Разработка требований (РТ) может иметь огромную скрытую стоимость

• Небольшое повышение качества требований или процессов может выливаться в другой порядок стоимости


Типовые проблемы УТ• Нет общепризнанной схемы деления• Не выбран принцип деления на элементы

объема• Нет единого места учета• Границы зафиксированы отрывочно и по разному• Требования оторваны от структуры системы• Высокая трудоемкость поддержки выбранной

схемы учета• Высокая трудоемкость управления изменениями


Типовые проблемы РТ• Полная стоимость РТ не учтена при

планировании• Обрыв в потоке информации (недоступны

источники информации или потребители)• Не совмещен контекст• Нет возможности получить адекватное

проектное задание• Нет разделения на варианты проработки при

создании новой системы


Рабочий поток РТ

РТИД

ИИ

ИИЛПРЭксперты

Требования

Потребители

ПЗ/обр. связь


Эффективность взаимодействия

Время аналитика/Общие трудозатраты команды на РТ

1

Эффективностьаналитическихработ


Контекст

ИД

ИИИИ

ЛПРЭксперты

Потребители

Аналитик


Качество требований1. Входящие требования зафиксированы как

есть2. Достаточно для

a) Учета объема системыb) Оценки работ (указанной точности)c) Приемки и разработки системыd) Тестирования

С ростом качества стоимость разработки и поддержки растет нелинейно.


Документ vs контекст

Команда Заказчик

Общий контекст

Документы


Эффективность коммуникации

Заказчик 1

Заказчик 2

Заказчик 2

Группа разработки 1

Группа разработки 2

Тест лаб.

Аналитическийпроцесс


Разделение роли аналитика• Менеджер проекта• Владелец системы/представитель

заказчика/менеджер продукта• Архитектор/разработчик/тестировщик –

кросс-функциональные игроки


Выделенный аналитик• Очень много (десятки) заинтересованных лиц вне

проекта, мнения которых надо сводить воедино (когда МП не хватает)

• Очень большая команда (десятки) с отчетливым разделением ролей

• Необходимость контрактирования и организации сдачи-приемки

• Большие потоки изменений, требующие управления• Сложная концептуальная проработка• Разработка сложной технологии применения ИТ• Необходимость создания центра экспертизы


Чтобы аналитик был эффективен• Адекватный заказ от менеджера проекта

(компетенция МП не всегда позволяет применить аналитика эффективно)

• Вовлечение всей команды в управление требованиями

• Вложение полной стоимости в разработку требований

• Обеспечение неразрывности потока информации

Летний Аналитический

Фестиваль

г. Иваново23-24 июня 2012

conf.uml2.ru

All you need is …

Technology

Эффективность аналитических работ. Юрий Химонин и Сергей Нужненко