ДонНТУ   Портал магистров
Назад

Оценка трудозатрат выполнения проекта по разработке ПО: практика в условиях украинской реальности

Авторы: А. Анисимов

Источник: http://habrahabr.ru/company/infopulse/blog/134719/

Вступление



К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
В статье я описываю свой личный опыт оценки проектов, и,
конечно же, у вас могли быть другие ситуации и свои методы и
рекомендации оценивания.
Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:
  • выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
  • и презентацию Сергея Бережного
    «My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.

Статья содержит такие разделы:


  • Украинские реалии при выполнении проекта
  • Проблемы и их решения
  • Подготовка к оценке
  • Перечень работ для оценивания
  • Оценка работ по написанию кода
  • Цифры и коэффициенты из практики
  • Пример расчета


Украинские реалии при выполнении проекта


На отечественном рынке преобладают проекты с фиксированной ценой (когда бюджет и сроки планируются заранее, при заключении договора). При оценке проекта, команда кроме стандартных рисков и проблем должна учитывать «современный и эффективный» подход заказчиков, которые, хотят совместить:
  • С одной стороны, получение точных оценок по бюджету и срокам до написания ТЗ, включение их в договор, и далее, при выполнении проекта, жесткий контроль этого бюджета и сроков.
  • Со второй — гибкость со стороны команды разработчиков, реализацию всех появляющийся по ходу проекта требований заказчика (т.к. заказчик часто до середины проекта сам не знает, чего хочет).
  • С третьей – несмотря на непонимание, того, что и как должно быть реализовано, нещадно «режут» задачи плана проекта (для уменьшения стоимости) в том числе и функции, которые все равно придется выполнять команде.

При неудачном управлении проектом (если команда идет на поводу у заказчика) команда легко превышает сроки и бюджет, т.к. контракт подписан и бюджет согласован, далее работает в себе убыток.
Понятно, что винить только заказчика во всем – неправильно. Нужно понимать, что оценка проекта часто проводится без достаточного анализа требований, недостаточно и неправильно расписываются задачи, и очень часто, в оценку включается только программирование, в недостаточном количестве учитывается тестирование и управление. При подписании контракта продавцы идут навстречу заказчику, снижая цену, а в ходе проекта недостаточно жестко отстаивает свою позицию команда (руководитель проекта в первую очередь, но в данном случае стоит говорить «команда», т.к. все участники должны быть нацелены на результат и в случае участник видит/предвидит проблему должен ее доносить руководителю).
Кроме этого, есть еще один фактор – разнообразие проектов, систем и технологий, и недостаток квалифицированных специалистов. Это значит, что при планировании проекта архитектор или руководитель проекта могут не учесть, что могут в команду получить специалиста, который ранее не выполнял подобных задач или с специалиста с недостаточной квалификацией. Понятно, что в этом случае производительность будет ниже ожидаемой.
Как же можно поступить в этой ситуации? Как оценить проект так, чтобы предполагаемые трудозатраты были достаточно точными?
Для начала стоит рассмотреть проблемы и попытаться найти их решение.

Проблемы и их решения


1. Заказчик хочет знать точные цифры по стоимости и срокам проекта до подписания договора

Решение:
1.1. Выявить и сформулировать критерии приемки работ. Как это сделать? Посмотрите [1]. Суть в том, что нужно заказчику задать правильные вопросы: «Как вы узнаете, что проект успешен ?» и «Кто, кому и как будет сдавать систему?», а также у человека, который будет принимать решение получить ответ на вопрос «что нужно сделать, чтобы проект был принят»
1.2. Выявить как можно больше требований и, самое главное, ограничений к проекту (т.е. не только функциональные, но и не функциональные требования)
1.3. Протестировать требования. Если говорить более простым языком, требуется проверить, что написанные требования реалистичны, непротиворечивы, и сформулированы так, что можно однозначно проверить соответствует ли им решение. Опять же рекомендую посмотреть [1]
1.4. Исходя из этого, расписать как можно детальнее перечень задач (смотрите дальше в статье)
2. Заказчик хочет видеть более-менее детальный перечень работ, который при согласовании стоимости проекта, при первой же возможности режет самым неподходящими способами

Решение:
В плане работ важно выделять все задачи, а не только «видимые»
Например, есть требования пользователей по просмотру определенных данных. Команда выявила, какие задачи нужно реализовать и оценила общий объем работ в 56 часов, разбив их таким образом:
  • Возможность просмотра всех записей – 8 часов
  • Возможность фильтрации по полю 1 – 8 часов
  • Возможность фильтрации по полю 2 – 8 часов
  • сортировка по полю 1 – 8 часов
  • сортировка по полю 2 – 8 часов
  • группировка по полю 1 – 8 часов
  • группировка по полю 2 – 8 часов

Но в действительности под этими задачами есть базовая функциональность – создание таблиц в БД, хранимых процедур или представлений для выборки, создание бизнес-объектов, подключение их к модулю безопасности, подключение к модулю протоколирования, конфигурации и прочее.
Что будет, если заказчик скажет: нет это слишком долго. Давайте уменьшать, и уберет задачи по группировке и сортировке(минус 32 часов). При этом продавцу, который обсуждает работы по проекту «крыть нечем». А с другой стороны за 24 часа весь объем в принципе не успеть.
Поэтому я рекомендую выделить базовую функциональность, убрать которую можно только убрав всю задачу целиком. В данном примере — эта задача «Выборка данных из базы данных» занимает, допустим, 28 часов, а остальные задачи — по 4 часа.
Это позволит при торгах более правильно вести себя продавцу, не подставляя к тому же команду. Убрав ненужные функции, все равно останется достаточное количество времени на разработки.
3. Детальный анализ требований, написание ТЗ и более-менее четкая область работ по проекту происходит после подписания договора

Решение:
3.1. Выявить как можно больше требований и ограничений к проекту, которые требуется реализовать в системе и как каждое требование правильно сформулировать и проверить [1].
3.2. Очень часто получается так, что пункты, которые заказчик убрал, все равно всплывают и их приходится делать, и поэтому, чтобы защитить себя, в договор, кроме плана проекта, нужно вносить и пункт ограничивающий рамки проекта. В него следует внести все пункты которые заказчик убрал из предлагаемого плана, а также другие пункты, которые команда видит и считает явно выходящими из рамок проекта. Все методологии разработки ПО акцентируют на это внимание. Фактически это может быть оформлено как приложение к договору или как часть технического задания.
3.3. Очень важно определить работы, что должно быть выполнено силами заказчика. Это также требуется зафиксировать в договоре (приложении к договору, техническом задании) с указанием сроков выполнения
4. Практически до середины проекта заказчик сам не знает, чего хочет (не говоря о стадии сбора требований)

Решение:
4.1. Включить временные рамки возможных изменений (т.е. на каких этапах изменения, в принципе, возможны)
4.2. Запланировать периодические демонстрации (например, на этапах сбора требований и планирования – раз в неделю, на этапе разработки – раз в две недели ) в учитывать трудозатраты по их подготовке и проведению
Демонстрации следует проводить не только для бизнес-заказчиков, но и для сотрудников других подразделений заказчика, потенциально вовлеченных в проект (системные администраторы, ключевые пользователи, служба безопасности и т.п.)
Это позволит на ранних этапах получить замечания, обсудить проблемы, позволит пользователю привыкнуть к интерфейсу и функционалу
5. Заказчик хочет, чтобы команда гибко подходила к его пожеланиям (изменения, дополнения) и реализовывала их в рамках проекта, а не в рамках последующих доработок, и при этом заказчик категорически ничего не хочет слышать про изменение бюджета проекта

Решение:
5.1. В план проекта явно включаем время на возможные изменения (закладываем буфер по срокам и по бюджету, вне заложенных рисков), которые по требованию заказчика будут потрачены на нужные ему изменения и доработки. Это, во-первых, дает возможности по работе над изменениями в рамках проекта, а во вторых заставляет заказчика вдумчиво относиться к запросам на изменение, т.к. этот ресурс уже явно ограничен
5.2. Учесть возможность итерационного подхода к разработке и спланировать эти итерации. Учесть количество встреч, поставок, демонстраций и прочее.
5.3. Как написано выше, в договор (как приложение к договору, или в техническое задание) включаем пункт, описывающий все то, что выходит за рамки проекта и от чего заказчик явно отказался.
6. Заказчик хочет видеть множество документации по системе.

Решение:
Включаем в расчет стоимости проекта стоимость на создание документации (как вы увидите ниже, сумма может получиться существенная)
7. В случае, если проектная команда формируется заново, есть риск, что квалификация того или иного специалиста может оказаться ниже ожидаемой.
Решение
При планировании задач и времени на их выполнение, необходимо ориентироваться на специалистов на уровень ниже, чем ожидается привлечь к проекту
8. ИТ технологии и задачи становятся все сложнее, что все сложнее выявить подводные камни выбранных технологий на ранних стадиях проекта

Решение:
8.1. Нужно закладывать в план определенное время на риски, которое команда может использовать по своему усмотрению

8.2. Как можно раньше выполняем задачи, связанные с рискованными технологиями

С чего начать


  1. Как писал ранее, поймите, что нужно сделать, чтобы достигнуть цели проекта и сдать [1]
  2. Выявить как можно больше требований и ограничений к проекту. Не забудьте выявить требования к:
    a. Документации. Если вы не знаете, какая документация к ПО бывает – можно обратиться, например, к ГОСТ (ЕСПД) 19.101-77 «Виды программ и программных документов» [3] или спецификациям других методологий, и исходя из этого предложить заказчику перечень, из которого он сможет выбрать нужное
    b. Нефункциональным требованиям [4], которые, например, могут включать: локализацию, резервное копирование, мониторинг, протоколирование, безопасность, миграция данных, первоначальная заливка данных, требования к установке, требования к конфигурированию.
    Такую информацию можно получить у служб ИТ-поддержки заказчика и безопасности.
  3. Протестировать полученные требования [1]
  4. Как можно детальнее распишите перечень задач, так чтобы каждая задача имела вполне измеримые сроки выполнения. Например, на этапе оценки проекта задачи разбивать и оценивать можно до дня
  5. В оценке должны участвовать специалисты по разным направлениям: руководитель проекта, разработчик, тест-инженер, специалист по развертыванию и внедрению, специалист по удобству использования, специалист по управлению продуктом (product manager, им может быть то же аналитик)


Перечень работ для оценивания


Прежде, чем перейдем к конкретным цифрам и коэффициентам, рассмотрим какие задачи нужно не забыть включить в перечень задач
Этап анализа и сбора требований

  • Встречи с заказчиком для проведения интервью и доклада о результатах
  • Написание документа требований
  • Тестирование требований
  • Написание и согласование договора и других инициирующих проект документов

Проектирование решения

  • Написание ТЗ
  • Написание архитектуры решения
  • Тестирование ТЗ и архитектуры решения
  • Обучение специалистов предметной области
  • Установка сред разработки и тестирования
  • Написание тест-плана и вариантов тестирования системы
  • Встречи с заказчиком

Разработка и внутреннее тестирование

  • Еженедельные встречи разработчиков
  • Программирование
  • Улучшение кода
  • Демонстрации (подготовка и проведение)
  • Первая установка решения на среду тестирования
  • Прохождение тест кейсов

Тестирование на стороне заказчика

  • Первая установка в тестовую среду заказчика
  • Поставки бета версий
  • Доработка и исправление неисправностей

Внедрение

  • Установка на рабочий сервер
  • Обучение пользователей
  • Написание инструкций

Дополнительно

  • Время на риски
  • Время на изменения
  • Управление проектом

Первым делом следует оценить срок работ по программированию решения, после этого можно применять дополнительные коэффициенты и предположения для расчета полного срока проекта.

Оценка работ по написанию кода


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

* Для достижения цели проекта разбейте ее на пользовательские действия (User stories), которые разбейте на задачи, которые в свою очередь на подзадачи и т.д. И так до тех пор, пока каждая задача станет понятной человеку уровня младший специалист (Junior Developer), и будет иметь четкие критерии, как проверить ее реализацию

* Не забывайте выделять базовые задачи, которые нельзя исключать
Не забудьте учесть такие задачи:

  • Создание утилиты установки
  • Создание утилиты конфигурации (возможно, их будет несколько: первичная настройка, настройка системных параметров, настройка безопасности)
  • Создание утилиты первичной заливки данных и, возможно, утилиту миграции на новую версию
  • Создание утилит диагностики (утилиты, которые помогут проверить, все ли установлено правильно, и помогут выявлять неисправности)
  • Создание модуля протоколирования (логирования). Даже если заказчику он не нужен – он в значительной мере поможет выявлять ошибки и недостатки.
  • Создание модуля безопасности

Цифры и коэффициенты из практики


  • Для введения в проект нового человека и установку ему среды разработки, запланируйте не менее 40 часов (1 неделя)
  • Еженедельные встречи разработчиков – 4 часа каждую неделю для каждого разработчика
  • Первичная установка решения на тестовый сервер – запланируйте 80 часов (2 недели)
  • Для подготовки каждой демонстрации – 8 часов (время которое требуется архитектору для сборки и проверки модулей перед демонстраций; 8 часов если в проекте 3 разработчика, если разработчиков больше – то аналогично увеличиваем)
  • Встречи (демонстрации) с заказчиком – каждая встреча по 4 часа (на встречу по моему опыту лучше ездить троим: руководитель проекта, архитектор, аналитик или специалист по тестированию)
  • Первая установка в тестовую среду заказчика – 40 часов
  • Первая установка в рабочую среду заказчика – 40 часов
  • Подготовка и отправка каждой поставки – 8 часов (это включает компиляция, упаковка, написание процесса установки, помощь в установке)
  • Доработка и исправление неисправностей (refactoring) – 25% от разработки
  • Задачи по тестированию 30-50% от времени, потраченного на разработку (разработку документа требований, разработку ТЗ, функционала и прочее)
  • Время на риски – по крайней мере, 10% от общего времени
  • Время на изменения – по крайней мере, 10% от общего времени
  • Управление проектом – 15% от всего времени проекта
  • Доработка и исправление неисправностей – 25% от времени на разработку
  • Аналитик в среднем создает 3 страницы утвержденной документации в день

Пример расчета


Допустим, в результате оценки получились некоторые цифры
  • Проанализировав задачи на разработку (включая проектирование) у нас получилось 1200 человеко-часов.
    Принимаем решение, что задачи по разработке будут вести 3 разработчика. Тогда работы по разработке будут занимать 10 недель.
  • Требуется писать и согласовывать много документации, включающее требования, ТЗ, архитектуру решения, инструкции пользователям и прочее. Общий полезный объем на выходе – 400 страниц
  • Приложение имеет сложную бизнес-логику, поэтому тестирования много (поэтому берем 40% от разработки)
  • Планируем 5 встреч с заказчиком для выявления требований
  • Планируем 3 встречи с заказчиком для согласования видения и проекта решения
  • Планируем 4 демонстрации продукта заказчику на этапе разработки
  • Планируем 10 поставок на тестовую среду заказчика


Исходя из этого, принимаем решение, что для данной оценки будем ориентироваться на следующий состав команды:
  • 3 разработчика
  • 1 тест инженер
  • 1 бизнес — аналитик
  • 1 системный аналитик (архитектор, он же будет выполнять инфраструктурные задачи)
  • 1 руководитель проекта

Теперь распишем задачи и время на выполнение. При этом по задачам связанным с созданием документации и ее тестирования ячейки пустые, внизу таблицы единое поле, содержащее сводную информацию исходя из создания документов на 400 страниц.
Задачи


Роли


Количество человек


Время


Всего


Этап анализа и сбора требований

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

Руководитель, аналитик, архитектор

3

5раз х 4часа

60

  • Написание документа требований

Аналитик, архитектор

  
  
  
  • Тестирование требований

тест инженер

 
 
 
  • Написание и согласование договора и других инициирующих проект документов

Руководитель проекта

1

 
 
Проектирование решения

 
 
 
 
  • Написание ТЗ

Аналитик, архитектор

 
 
 
  • Написание архитектуры решения

архитектор

1

40

40

  • Тестирование ТЗ и архитектуры решения

тест инженер

 
 
 
  • Обучение специалистов предметной области

Все

7

40

280

  • Установка сред разработки

Архитектор, разработчики

4

16

64

  • Установка среды тестирования

тест инженер или архитектор

1

40

40

  • Написание тест-плана и вариантов тестирования системы

тест инженер

 
 
 
  • Встречи с заказчиком

Руководитель, аналитик, архитектор

3

3 раза х 4часа

36

Разработка и внутреннее тестирование

 
 
 
 
  • Еженедельные встречи разработчиков

Архитектор, разработчики

4

10 встреч по 4 часа

160

  • Программирование

Разработчики

3

400

1200

  • Улучшение кода

архитектор

1

3 х 100

300

  • Подготовка демонстрации

архитектор

1

4 демонстрации по 8 часов

32

  • Проведение демонстрации

Архитектор, руководитель проекта, аналитик

3

3 х 4

36

  • Задачи тест инженера (прохождение тест кейсов), 40% от разработки

тест инженер

1

 
480

  • Первая установка решения в среду тестирования

специалист по тестированию или архитектор

1

80

80

Тестирование на стороне заказчика

 
 
 
 
  • Первая установка в тестовую среду заказчика

архитектор

1

 
40

  • Поставки бета версий

архитектор

1

10 поставок по 8 часов

80

  • Доработка и исправление неисправностей (25% от разработки)

Разработчики

2

 
300

Внедрение

 
 
 
 
  • Установка на рабочий сервер

архитектор

 
 
40

  • Обучение пользователей (допустим 3 обучения по 4 часа)

Аналитик

1

3 х 4

12

  • Написание инструкций

Аналитик

 
 
 
  • Написание документации

Часть аналитик, часть архитектор

 
135 дней по 3 страницы

1080

  • Тестирование документации

Тест инженер

 
30% от ее написания

320

Итого


 


 


 


4680


Дополнительно

 
 
 
 
  • Время на риски

 
 
10% от разработки

120

  • Время на изменения

 
 
10% от разработки

120

  • Управление проектом

Руководитель проекта

 
15% от проекта

700

Всего


  


Приблизительно 5620 часов



Исходя из полученных данных, оценка непосредственно задач разработки (1200 часов) намного меньше полных трудозатрат (более чем в 4 раза).

Большое количество времени уходит на тестирование и оптимизацию кода, написание документации, введение в проект специалистов (включая установку среды для работы) и управление проектом.

Заключение


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

Надеюсь, что данная статья поможет вам более обосновано и более четко давать оценки по проектам, и вовремя учитывать как можно больше «мелочей», которые могут повлиять на трудозатраты в ваших проектах.