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

Вступление

К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (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 раза).

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

Заключение

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

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