Вступление
К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (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]
- Выявить как можно больше требований и ограничений к проекту. Не забудьте выявить требования к:
a. Документации. Если вы не знаете, какая документация к ПО бывает – можно обратиться, например, к ГОСТ (ЕСПД) 19.101-77 «Виды программ и программных документов» [3] или спецификациям других методологий, и исходя из этого предложить заказчику перечень, из которого он сможет выбрать нужное
b. Нефункциональным требованиям [4], которые, например, могут включать: локализацию, резервное копирование, мониторинг, протоколирование, безопасность, миграция данных, первоначальная заливка данных, требования к установке, требования к конфигурированию.
Такую информацию можно получить у служб ИТ-поддержки заказчика и безопасности. - Протестировать полученные требования [1]
- Как можно детальнее распишите перечень задач, так чтобы каждая задача имела вполне измеримые сроки выполнения. Например, на этапе оценки проекта задачи разбивать и оценивать можно до дня
- В оценке должны участвовать специалисты по разным направлениям: руководитель проекта, разработчик, тест-инженер, специалист по развертыванию и внедрению, специалист по удобству использования, специалист по управлению продуктом (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 |
|
тест инженер |
1 |
|
480 |
|
специалист по тестированию или архитектор |
1 |
80 |
80 |
Тестирование на стороне заказчика |
|
|
|
|
|
архитектор |
1 |
|
40 |
|
архитектор |
1 |
10 поставок по 8 часов |
80 |
|
Разработчики |
2 |
|
300 |
Внедрение |
|
|
|
|
|
архитектор |
|
|
40 |
|
Аналитик |
1 |
3 х 4 |
12 |
|
Аналитик |
|
|
|
|
Часть аналитик, часть архитектор |
|
135 дней по 3 страницы |
1080 |
|
Тест инженер |
|
30% от ее написания |
320 |
Итого |
|
|
|
4680 |
Дополнительно |
|
|
|
|
|
|
|
10% от разработки |
120 |
|
|
|
10% от разработки |
120 |
|
Руководитель проекта |
|
15% от проекта |
700 |
Всего |
|
Приблизительно 5620 часов |
Исходя из полученных данных, оценка непосредственно задач разработки (1200 часов) намного меньше полных трудозатрат (более чем в 4 раза).
Большое количество времени уходит на тестирование и оптимизацию кода, написание документации, введение в проект специалистов (включая установку среды для работы) и управление проектом.
Заключение
Повторюсь, что данные выкладки — это мои практика и наблюдения относительно определения трудоемкости (напомню, что в статье не рассматривается оценка длительности проекта и его бюджет) и, соответственно, у вас могут быть свой опыт и свои методы и рекомендации по оценке трудоемкости работ
С удовольствием выслушаю критические отзывы и замечания для улучшения данной методики.
Надеюсь, что данная статья поможет вам более обосновано и более четко давать оценки по проектам, и вовремя учитывать как можно больше «мелочей», которые могут повлиять на трудозатраты в ваших проектах.
Что можно посмотреть еще по теме? Смотрите раздел ссылки.
Ссылки
1. Сергей Мартыненко «Написание тестов, как вид тестирования требований» http://vimeo.com/13803733
2. Сергей Бережной «My Story: «Путь овертаймов»
3. ГОСТ (ЕСПД) 19.101-77 «Виды программ и программных документов» http://www.rugost.com/index.php?option=com_content&task=view&id=48&Itemid=50
4. Наталья Желнова. Нефункциональные требования к ПО: как их определять и откуда брать цифры
akiselev87.wordpress.com/2011/07/14/наталья-желнова-нефункциональные-тр
5. С. Архипенков “Оценка трудоемкости и сроков разработки ПО” http://www.arkhipenkov.ru/resources/sw_project_estimation.pdf
6. Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения http://leopard.in.ua/2010/03/22/desyat-smertnyx-grexov-v-ocenke-trudoyomkosti-razrabotki-programmnogo-obespecheniya/
7. Михаил Острогорский «Подход к оценке сроков создания технической документации» http://www.philosoft.ru/metrics-idea.zhtml
8. Сергей Поволяшко «Трудозатраты и планирование при тестировании» http://qaclub.com.ua/wp-content/uploads/d/qaclub6_19-02-10/QAClub_TestEffortsPlanning.pdf