Оценка аутсорсинговых проектов

Оценка аутсорсинговых
проектов
Наталья Желнова
(nzhelnova@teamcit.ru)

В чем специфика?
АУТСОРСИНГ

Аутсорсинг: в чем специфика?
• Мы должны точно оценить проекты до их
начала
• Часто контракты заключаются на условиях
fixed time and budget
• Оценки должны быть реалистичными

Зачем, когда и как?
ОЦЕНКА ПРОЕКТА

Оценка проектов: когда и зачем?
Когда?
• Формирование предложения клиентам
• Оценка стоимости проекта для заказчика и для
себя
• Принятие решения для начала или
продолжения работы над проектами
• Начало планирования

Оценка проектов: когда и зачем?
Зачем?
• Принятие управленческих решений
• Формирование бюджета
• Оперативное управление
• Планирование проекта
• Контроль за ходом проекта

Оценка и контроль проекта
Оценка проектов тесно связана с процессами контроля и
планирования
Приоритезация, планирование, контроль – это
процессы, зависящие и зависимые от оценивания
На основании оценок мы принимаем обязательства о
поставке запланированной функциональности к
установленному сроку, обеспечивая оговоренное
качество

Контроль проекта:
• Удаление некритичной для достижения цели
функциональности
• Переопределение требований
• Замена неквалифицированного персонала более
квалифицированным
… и т.д.

Что такое «хорошо»?
Менеджер, хорошо оценивающий проект – это не тот, кто
хорошо угадывает, сколько времени займет проект и
какова будет его стоимость. Это человек, который
может привести проект к успеху в заданные сроки.

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

Рабочий критерий хорошей оценки
Хорошая оценка – это такая оценка, которая обеспечивает
достаточно ясное понимание ситуации в проекте, чтобы
руководство могло принимать правильные решения и
достичь целей проекта

Цена хорошей оценки
Недооценка и переоценка

Цена хорошей оценки
Враги хороших оценок – нереалистичные цели проекта,
завышенные ожидания и слишком высокие
обязательства
Точные оценки требуют дополнительных затрат на:
• Регулярные пересмотры целей и рабочих планов
• Регулярное выполнение процедур проектного контроля

Недооценка или переоценка?
Аргументы против завышенной оценки:
• Давление со стороны топ-менеджмента и акционеров
• Люди привыкнут к такому темпу работы, и в следующем
проекте их будет трудно заставить повысить
производительность
• Прокрастинация команды, которой нечем занять свое
время

Аргументы против заниженной оценки:
• Проектные планы теряют точность и ценность
• Ошибки в планировании времени задач
• Ошибки в планировании размера команды
• Потеря координации между группами участников проекта
• Вероятность выполнить проект в срок без превышения
бюджета существенно снижается
• Экономия на проработке архитектуры и других
технических деталей
• Потеря качества
• Постоянные опоздания снижают мотивацию команды

Что ждет команду при заниженной оценке:
• Постоянные совещания с целью установить контрольь над
проектом и вернуть его в начальные временные рамки
• Постоянные корректировки планов, которые учитывают
опоздания
• Возможность подготовки промежуточных релизов (для демо-
версий и выставок, к которым мы не успеваем)
• Продолжительные дискуссии о том, какую функциональность
еще можно исключить из следующего релиза, чтобы успеть к
сроку
• Проблемы и ошибки, которые необходимо устранить из-за
непродуманных временных решений, которые были приняты
в условиях сжатых сроков (стоимость «костылей»)

Нелинейная зависимость при заниженной оценке:
• Затраты на перепланирование
• Увеличенное число ошибок и стоимость их исправлений
• Решения, которые повышают риски

Откуда берется ошибка оценки?

Источники ошибок оценки
• Неточная информация об оцениваемом проекте
• Неточная информация об организации, которая будет
выполнять проект, и о проектной команде
• Слишком много усилий тратится на достижение как можно
более точной оценки (мы ловим ускользающую цель)
• Погрешности самой оценки

Примеры источников ошибок оценки
Система, автоматизирующая процесс приема заказов:
1. Ввод телефонного номера: нужна ли заказчику проверки правильности введенного
номера?
2. Если проверка нужна: какая именно проверка необходима? (Существующие стандартные
варианты: (1), (2), (3) , срок реализации: 2 человекочаса, 2 человекодня и 2
человеконедели)
3. Если заказчик определился с вариантом проверки телефонного номера, не передумает
ли он в дальнейшем?
4. Можно ли использовать стандартные готовые решения при реализации проверки
телефонного номера?
5. Каков будет дизайн функции проверки телефонного номера? (существует более 10
стандартных вариантов с разными уровнями сложности)
6. Сколько времени займет реализация проверки телефонного номера?
7. Нужна ли интеграция проверки телефонного номера и проверки адреса?
8. Каков необходимый уровень качества для проверки телефонного номера? (в
зависимости от реализации, число ошибок может различаться в 10 раз)
9. Сколько времени потребуется на отладку и исправление ошибок проверки телефонного
номера? (индивидуальные показатели у различных программистов отличаются в 10 раз)

Влияние источников ошибок оценки
Для одной функции: число источников неопределенности оценки –
порядка 10
Для 100 и более функций: в 100 раз больше
Даже если учесть все факторы, вносящие неопределенность, для
каждой функции, то не всегда можно учесть взаимное влияние
всех неопределенностей.
Чем больше проект, тем больше неопределенность

Конус неопределенности
Вертикальная ось: степень ошибки в оценке, сделанной опытными специалистами
Горизонтальная ось: время
Контрольные точки на графике: фазы проекта

Конус неопределенности
Сам по себе конус неопределенности не сужается: влияние
плохого контроля на оценки

Что увеличивает неопределенность?

Хаотический процесс разработки
• Требования не были определены и проанализированы
• Плохая проработка архитектуры и дизайна,
приводящая к множеству ошибок
• Неквалифицированный персонал
• Неплоное и неточное планирование проекта
• Отказ от планирования проекта под давлением сжатых
сроков
• Отсутствие тестирования

Хаотический процесс разработки: что
делать?
• Прежде чем приступать к оценкам, необходимо устранить хаос
• Устранение наиболее дестабилизирующего фактора хаоса дает
больший результат, чем попытка борьбы на всех фронтах
одновременно

Изменение требований
• При нестабильных требованиях неопределенность не удается
уменьшить
• Изменения в требованиях не всегда достаточно точно
учитываются
• При изменении в требованиях не всегда выполняется анализ
влияния изменений
• Добавленные/удаленные требования влияют на время и
стоимость проекта

Изменение требований
Насколько может увеличиться объем требований? – оценки NASA's
Software Engineering Laboratory: 40%

Изменение требований: что делать?
• При нестабильных требованиях нужно уделять пристальное
внимание контролю хода проекта, а не только оценке
• Рекомендуется попробовать выбрать другую стратегию
контроля и оценки

«Забытые» задачи
Одна из самых частых причин ошибок оценки:
При оценке объема и времени работ, разработчики
пропускают 20%-30% задач, что приводит к ошибке 20-30%
«Забытые» задачи можно разделить на три категории:
• пропущенные требования
• пропущенные задачи, относящиеся к разработке ПО
• пропущенные задачи, не относящиеся к разработке ПО

Требования, которые часто не
учитываются при планировании
работ
Функциональные требования Нефункциональные требования
Автоматизация процесса установки/настройки Точность
Утилиты преобразования данных Совместимость
Справочная система/документация Модифицируемость
Автоматизация процесса развертывания Производительность
Интерфейсы взаимодейтсвия с внешними
системами
Переносимость
Надежность
Время отклика/Быстродействие
Возможность повторного использования
Расширяемость
Защищенность/Безопасность
Доступность
Требования к удобству использования

Пропущенные требования: что делать?
Резервируйте время, которое потребуется для реализации
пропущенных требований, и включайте его в оценку

Пропущенные задачи, относящиеся
к разработке ПО
Время, необходимое для «акклиматизации»
новичков
Техподдержка существующих систем во время
выполнения проекта
Обучение новичков Время недоступности систем, которые
используются в проекте / интегрируются с
разрабатываемым продуктом
Координация и встречи Время на устранение ошибок
Перенос/развертывание систем Улучшение производительности
Преобразование данных Изучение новых инструментов
Установка Административная работа в процессе
устранения ошибок
Кастомизация/Настройка Координация с тестировщиками (разработчики)
Уточнение требований Координация с разработчиками (тестировщики)
Администрирование ПО контроля изменений Ответы на вопросы тестировщиков и службы
качества
Поддержка и автоматизация процесса сборки Разработка и контроль качества документации
Поддержка кода автоматического теста перед
сборкой
Демонстрация рабработанного продукта
пользователям

Пропущенные задачи, относящиеся
к разработке ПО
Установка ПО на пользовательских рабочих
местах для пользовательского тестирования
Демонстрация ПО на выставках
Создание наборов данных для тестирования Демонстрация готовых прототипов
Менеджмент программы бета-тестирования Взаимодействие с пользователями
Участие в процедурах пересмотра и улучшения
кода, дизайна, архитектуры (reviews)
Поддержка бета-версий продукта на рабочих
местах пользователей
Работы, связанные с интеграцией Пересмотр планов проекта
Работа с запросами на изменение Пересмотр архитектуры
Время на митинги по утверждению
изменений/выпуску пробных версий продукта
Пересмотр и изменение тестовых сценариев
Координация с субподрядчиками Обновление документации

Пропущенные задачи, относящиеся к
разработке ПО: что делать?
Составляйте проверочные листы и исследуйте их на полноту
Включайте в оценку время, необходимое для всех работ,
связанных с разработкой ПО, а не только чистое время на
разработку и тестирование

Пропущенные задачи, не
относящиеся к разработке ПО
Время отпуска членов проектной команды Общие собрания компании
Выходные и праздничные дни Собрания отделов
Время болезни Установка нового ПО на рабочие станции,
замена рабочих станций
Обучение Устранение неисправностей в работе ПО и
аппаратуры

Пропущенные задачи, не относящиеся к
разработке ПО: что делать?
• Составляйте проверочные листы
• Если продолжительность проекта более месяца, включайте в
оценку время, необходимое для учета всех поправок во
времени, не связанных с разработкой ПО: отпуска, больничные,
обучение и т.д.

Необоснованный оптимизм
Van Genuchten, Michiel, 1991. "Why Is Software Late? An Empirical
Study of Reasons for Delay in Software Development." IEEE
Transactions on Software Engineering SE-17, no. 6 (June): при
оценке затрат, разработчики уменьшают оценку по
сравнению с реальным временем на 20-30% (по материалам
обзор более 300 проектов)
Обычные предпосылки для оптимизма:
• Производительность в этом проекте будет выше, чем в
предыдущем
• В предыдущем проекте мы допустили множество ошибок. В
этот раз все будет совсем не так!
• В прошоый раз у нас было меньше опыта, в этот раз мы мы
уже набили шишки и управимся значительно быстрее

Необоснованный оптимизм: что делать?
• Устраняйте ошибки в оценках, связанных с пропущенными
задачами
• Не уменьшайте оценки, которые дают разработчики: они и так
чересчур оптимистичны

Субъективизм и систематическая ошибка
оценки
• Субъективизм – следствие разного опыта (сознательного и
бессознательного)
• Методы борьбы с субъективизмом: предположение, что чем
сложнее техника оценки, чем больше параметров
учитывается, чем больше контрольных точек, тем точнее
оценка. Это в корне неверно: чем больше параметров в
оценке и больше контрольных точек, тем сильнее фактор
субъективной оценки
Cocomo II: 17 поправочных коэффициентов и 5 коэффициентов,
учитывающих масштаб. В каждом случае выбор цифр –
субъективное мнение выполняющего оценку.

оценки
 Оценка с множеством факторов, включающих субъективную
оценку

оценки
Оценка с одним фактором, включающим субъективную оценку

Другие источники ошибок
 Незнакомая предметная область
 Неосвоенная технология
 Некорректное преобразование из оценки времени на задачу в
продолжительность проекта (например, предположение, что
проектная команда будет работать в режиме 12x7)
 Неправильная интерпретация статистических результатов
(например, использование только «наилучших» и «наихудших»
значений)
 Ошибки планирования проекта при точной оценке
 Упрощение оценки и методов управления, связанных с ней
 Давление на команду в условиях сокращенных бюджетов
проекта

Что влияет на оценку?

Факторы, влияющие на оценку
 Размер проекта
 Вид разрабатываемого ПО
 Человеческий фактор
 Используемые технологии (языки программирования)
 Другие факторы

Размер проекта: влияние на оценку
 Для стандартных бизнес-приложений

Размер проекта: влияние на оценку
 Размер проекта – фактор, наиболее влияющий на стоимость
проекта
 Однако:
 К оценкам стоимости, трудозатрат и времени обычно приступают
раньше, чем будет известен размер проекта
 Стоимость, трудозатраты и время не увеличиваются с ростом
размера проекта
 Добавление строки кода в проект размером 100000 LOC и
10000000 LOC займет разное время

Человеческий фактор: влияние на
оценку
Производительность – не постоянная величина
• Разброс в значениях производительности может
достигать 10-22 раз
Влияние человеческого фактора связано с размером
проекта (большие проекты дают большую
неточность оценки)
Основные факторы, влияющие на
производительность:
• Наличие опыта
• Сплоченность команды
• Скорость ротации персонала
• Качество менеджмента

Человеческий фактор: влияние на
оценку

Другие факторы: влияние на
оценку
Поправочные коэффициенты Cocomo II
Диапазон коэффициентов
Фактор Очень
низ
кий
Низ-
кий
Номина
льный
Высо
кий
Очень
высо
кий
Сверх-
высо
кий
Влия
ние
Опыт в
определенной
предметной
области
1.22 1.10 1.00 0.88 0.81 1.51
Размер БД 0.90 1.00 1.14 1.28 1.42
Повторное
использование
компонентов
0.95 1.00 1.07 1.15 1.24 1.31

оценку
низ
кий
Низ
кий
Номина
льный
Высо
кий
Очень
высо
кий
Сверх-
высо
кий
Влия
ние
Ротация персонала 1.29 1.12 1.00 0.90 0.81 1.59
Объем
необходимой
документации
0.81 0.91 1.00 1.11 1.23 1.52
Техническая
компетенция
(языки,
инструменты)
1.20 1.09 1.00 0.91 0.84 1.43

оценку
низ
кий
Низ
кий
Номина
льный
Высо
кий
Очень
высо
кий
Сверх-
высо
кий
Влия
ние
Развертывание
разрабатываемого
ПО на нескольких
узлах
1.22 1.09 1.00 0.93 0.86 0.78 1.56
Опыт работы с
платформой
1.19 1.09 1.00 0.91 0.85 1.40
Изменения
платформы
0.87 1.00 1.15 1.30 1.49
Сложность
продукта
0.73 0.87 1.00 1.17 1.34 1.74 2.38

оценку
Диапазон коэффициентов оценки
низ
кий
Низ
кий
Номина
льный
Высо
кий
Очень
высо
кий
Сверх-
высо
кий
Влия
ние
ПО
0.82 0.92 1.00 1.10 1.26 1.54
Производитель
ность группы
аналитиков
1.42 1.19 1.00 0.85 0.71 2.00
Ограничения
хранилища
1.00 1.05 1.17 1.46 1.46

оценку
Диапазон коэффициентов оценки
низ
кий
Низ
кий
Номина
льный
Высо
кий
Очень
высо
кий
Сверх-
высо
кий
Влия
ние
Производитель
разработки
1.34 1.15 1.00 0.88 0.76 2.00 1.76
Ограничения по
времени
1.00 1.11 1.29 1.63 1.63
Использование
специализированн
ого ПО
(инструменты)
1.17 1.09 1.00 0.90 0.78 1.50

Влияние различных факторов на
оценку

Поправочные коэффициенты
(COCOMO II)
Фактор Коэф-
фици-
ент
Критерий
Опыт в
предметной
области
1.51 Отсутствие/наличие опыта в предметной области
Снижение
архитектурных
рисков
1.38 Управление архитектурными рисками/пренебрежение
архитектурными рисками
Размер БД 1.42 Размер и сложность БД
Повторное
использование
компонентов
1.31 Возможность повторного использования

(COCOMO II)
фици-
ент
Критерий
Разработка
документации
1.52 Объем необходимой документации
Техническая
компетенция
(языки,
инструменты)
1.43 Отсутствие/наличие опыта
Развертывание
ПО на нескольких
узлах
1.56 Число узлов, на которых нужно развернуть ПО
Ротация
персонала
1.59 Частота ротации

(COCOMO II)
фици-
ент
Критерий
Изменения
платформы
1.49 Стабильность платформы;
Число изменений и их влияние на проект
Наличие
прецедентов
1.33 Число прецедентов
Зрелость процесса 1.43 Уровень зрелости
Сложность
продукта
2.38 Тип разрабатываемого продукта
Уровень сложности продукта
Производитель-
разработчиков
1.76 Скорость разработки

(COCOMO II)
фици-
ент
Критерий
Изменения
платформы
1.49 Стабильность платформы;
Число изменений и их влияние на проект
Наличие
прецедентов
1.33 Число прецедентов
Зрелость процесса 1.43 Уровень зрелости
Сложность
продукта
2.38 Тип разрабатываемого продукта
Уровень сложности продукта
разработчиков
1.76 Скорость разработки кода

(COCOMO II)
фици-
ент
Критерий
ПО
1.54 Степень надежности разрабатываемого ПО
аналитиков
2.00 Скорость разработки требований
Гибкость
разработки
требований
1.26 Жесткость требований, наличие разных вариантов
реализации трбований
Ограничения
хранилища
1.46 Наличие ограничений по размеру хранилища данных

(COCOMO II)
фици-
ент
Критерий
Сплоченность
команды
1.29 Степень сплоченности команды;
качество коммуникаций
Ограничения по
времени
1.63 Наличие и степень ограничений по времени
Использование
специализирован
ного ПО
1.50 Применение ПО, повышающего эффективность работы

Как мы оцениваем проект?
ТЕХНИКА ОЦЕНКИ

Применимость разных методов
оценки
Применимость методов оценки:
Групповые оценки и
пересмотр
Калибровка и данные,
относящиеся к
конкретному проекту
Параметры оценки Размер, трудозатраты,
план проекта, свойства
продукта
Размер, трудозатраты,
план проекта, свойства
продукта
Размер проекта Средний, большой Маленький, средний,
большой
Стадии проекта Ранние - средние Средние – поздние
Итеративная /
Последовательная
разработка
Итеративная и
последовательная
Итеративная и
последовательная
Точность оценки Средняя - высокая Высокая

На чем базируется оценка
Оценки по аналогии
Предположения
Подсчеты (и источники цифр)
Чем точнее источник, тем вернее оценка?

Задача на оценку - офис
Оценить: сколько
человек работает
в офисе?

Задача на оценку - офис
• 5 помещений
• 8 столов в каждом
помещении
• 4 места за столом

Задача на оценку – офис
160 человек?
От 140 до 180 человек?
От 140 до 160 человек?
Другие цифры?

162 человека

165 человек

Какие параметры брать в основу
оценки?
• Те,которыепозволяютоценитьразмер
создаваемогопродукта
• Те,которыедоступнынараннихстадиях
разработкиибудутуточненынаболее
позднихстадиях
• Те,которыебудутдаватьвам
достовернуюинформацию
• Те,которыедадутвамответнавопросыо
прогрессепроектаиокачествепродукта

Параметры, используемые для
оценки
Параметр Данные, которые собираются для оценки
Бизнес-требования:
трудоемкость
Среднее число человеко-часов, необходимое для
реализации бизнес-требования
независимого тестирования реализованного бизнес-
требования
разработки и документирования бизнес-требования
разработки системных требований, связанных с
бизнес-требованием
Ключевые свойства
продукта (featires):
трудоемкость
реализации ключевого свойства продукта

оценки
Функциональные точки
(function points)
реализации/тестирования/документирования на
одну функциональную точку
Среднее число функциональных точек, которые
возможно реализовать за неделю/месяц
Запросы на изменения
(change requests)
реализации/тестирования/документирования
одного запроса на изменение (в зависимости от этой
величины, запросы на измнение можно разделить
на мелкие, средние, крупные)
Web-страницы / формы Среднее число человеко-часов, необходимое для
верстки одной страницы
Среднее число человеко-часов в объеме всего
проекта, необходимое для разработки 1 страницы

оценки
Отчеты Среднее число человеко-часов, необходимое для
реализации/тестирования/документирования на
один отчет
Таблицы БД Среднее число человеко-часов, необходимое для
создания, изменения, заполнения данными 1
таблицы
Среднее число человеко-часов в объеме всего
проекта, необходимое для создания, изменения,
заполнения данными 1 таблицы

оценки
Классы Среднее число человеко-часов, необходимое для
реализации, на один класс
тестирования, на один класс
инспекции кода, на один класс
Затраты на
конфигурационное
управление
Среднее число часов, необходимое для реализации
одного конфигурационного изменения

оценки
Число строк кода (LOC) Среднее число дефектов на строку кода
инспекции одной строки кода
Среднее число строк кода, добавленное в проект
между двумя релизами
Затраты на
конфигурационное
управление
Среднее число часов, необходимое для реализации
одного конфигурационного изменения
Сценарии тестирования Среднее число человеко-часов, необходимое для
реализации одного сценария тестирования
Покрытие кода тестами

Итоги
• Устранение хаоса
• Регулярный пересмотр оценок
• Планирование и контроль
• Использование измеряемых показателей
для оценки и планирования

Спасибо за внимание
Наталья Желнова
nzhelnova@teamcit.ru

Оценка аутсорсинговых проектов

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Оценка аутсорсинговых проектов

Similar to Оценка аутсорсинговых проектов (20)

More from SQALab

More from SQALab (20)

Оценка аутсорсинговых проектов