Нояб. 26

Оценка трудоемкости проектов разработки. Часть 2

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

Метод оценки

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

Шаг 1. Подготовка (Prerequisites)

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

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

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

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

4. Налаживайте взаимодействие с отделом продаж. Рассинхронизация между продавцами и исполнителями — весьма частая причина проектных проблем. Как правило, главный KPI продавцов — объем продаж, проблемы выполнения проектов их беспокоят намного меньше. Убедитесь, что вы знаете, что они продают, а они знают как вы собираетесь это выполнять.

Шаг 2. Опишите требования и рамки проекта (scope)

Четыре категории требований по степени известности

В момент оценки требования можно условно разделить на 4 части по степени известности, понятности и количеству рисков.

Known knowns. Заявленное в явном виде, понятное и достаточное для точной оценки. Что с этим делать? Оценить.
Unknown knowns. Косвенное заявленное либо не заявленное, но легко доступное. Не ленитесь прочитать требования и спецификации, «прокликать» гиперссылки в них, зайти на сайт клиента, спросить SME. Это не требует больших трудозатрат, но позволяет намного лучше понять требования и выявить скрытые риски. Что с этим делать? Найти, прочитать, спросить, прояснить, перевести в Known knowns, оценить.
Known unknowns. Недостаточные требования, неготовая документация и тому подобное. Например, заказчик знает, что будет интеграция с другими системами, но не знает протоколов, форматов и объемов обмена данными.
Что с этим делать? Прежде всего, решить, хотим ли мы брать на себя риски по оценке и выполнению этих требований. Если да, то неплохо бы сделать предположения насчет задач, которые мы не знаем, и добавить буфер времени на всякий случай. Если же нет, выписать явно, что эти требования не оценены либо остались вне рамок проекта.
Unknown unknowns. Практически во всех проектах происходит что-то, о чем и не подозревали вначале. Например, баги во внешних библиотеках, сюрпризы от поставщиков браузеров и операционных систем, сложности в требованиях либо реализации, упущенные требования. Изменения в требованиях сюда напрямую не относятся, но часто покрываются за счет этого буфера, поскольку запускать процедуры управления изменениями на каждый клиентский запрос весьма накладно. Мало что можно с этим сделать, кроме добавления буфера.

Действия по подготовке требований к оценке

Категоризируйте требования и все, что может ими считаться, как указано выше.
- Помимо спецификаций и официальных документов, стоит проанализировать также протоколы встреч, письма с намерениями, все вплоть до разговоров в курилках, «поскольку ожидания в будущем часто становятся требованиями либо влияют на них.
- Зафиксируйте ожидания, формальные и неформальные, функциональные и нефункциональные требования, ссылки на другие документы, спецификации и стандарты.
- По возможности проверьте актуальность предоставленной документации, поскольку нередки случаи оценки по устаревшим документам.
Постарайтесь подтвердить список требований и предположений с заказчиком. Это может выйти не сразу. В крайнем случае можно прибегнуть к приему «согласование по умолчанию»: высылайте письмо с просьбой подтвердить либо прокомментировать скоуп, аккуратно намекнув, что отсутствие ответа означает молчаливое подтверждение.
Явно опишите то, что в скоуп не входит: что вы не оцениваете и не собираетесь делать, поскольку любое, даже самое детальное описание подвержено различным интерпретациям, сознательным или несознательным. Типичный пример: клиент может ожидать бесконечной поддержки программы, которую вы пишете, если гарантийный период поддержки не прописан явно.

Если же вы по какой-то причине не оценили задачу, необходимо прямо написать об этом:

Feature	Estimate
Login page	24mh	— оцениваем
Single sign-on	NOT ESTIMATED	— оценим позже, когда будет понятнее
Sign-up link	Out of scope	— не собираемся оценивать и делать

Никогда не ставьте нулевую оценку, если вы не оценили задачу. Рано или поздно кто-то подумает, что задача не требует времени, в моей практике такие случаи были.

Идентифицируйте рискованные требования. Под рискованными я подразумеваю такие требования, как «сайт должен работать в любой точке мира и поддерживать все языки». Они часто формулируются одной строчкой, но могут увеличить трудозатраты вашего проекта на порядок. Как правило, заказчик не осознает всей сложности их реализации и ему не нужны «все языки». К сожалению, для выявления таких требований приходится внимательно перечитывать всю доступную документацию, поскольку эти «сокровища» могут быть раскиданы на сотнях страниц текста.
Соберите нефункциональные требования. Мало кто думает в начале проекта о них, потому стоит по крайней мере поставить вопрос, выбить из заказчика хотя бы приблизительные оценки количества данных, пользователей, доступности системы и внести их в предположения. Многие из этих параметров могут критически повлиять на ваши архитектурные решения, а следовательно, и на трудозатраты проекта.
Тщательно проанализируйте унаследованные артефакты (legacy). С началом проекта все они, к сожалению, могут стать вашими. Это касается не только кода, но и документации, данных, контрактов, сторонних библиотек и прочих вещей, составляющих проект. Часто проще переписать код, чем пытаться исправить его после предыдущих «специалистов», и лучше об этом знать заранее. Помимо технического долга, вам могут перейти прочие виды долгов, такие как зависимости от внешних компонент, контрактные обязательства, плохая документация, нецелостные данные и так далее.

«Сделайте так же, но лучше»

Важное предостережение по оценке проектов переписывания старых систем на новые платформы без формальных требований. Обычно такие задачи формулируются в виде: «Сделайте то же самое, только лучше и на новой платформе, поскольку все программисты на COBOL уже на пенсии или умерли». Мне неизвестны надежные способы оценки таких проектов. Доступ к старой системе и даже к ее исходному коду не спасает, поскольку комбинаторная сложность всех сценариев выполнения кода, входных данных, настроек системы и окружения не позволяет восстановить логику работы приложения за разумное время. Но большая проблема состоит в том, что вы никогда не сможете понять, закончена работа или нет, из-за неизвестного количества сценариев, которые должны работать одинаково либо схоже в двух системах.

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

Шаг 3. Создайте ИСР на базе требований

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

ИСР, основанная на декомпозиции по продукту (noun-oriented), проще для оценки по этому методу, чем основанная на разбиении по другим критериям.
Уровень детализации ИСР. Строки нижнего уровня не должны занимать более 40, максимум 80 часов.
Вопреки общепринятым рекомендациям покрывать 100% работ, наша ИСР может не содержать некоторые виды работ вроде встреч и менеджмента. Ниже будет понятно почему.

Например, для простейшей системы обработки заказов ИСР может выглядеть так:

Login page
- 1.1. UI
- 1.2. Login
- 1.3. Logout
Order page
- 2.1. UI
- 2.2. Create order
- 2.3. Confirm order
- 2.4 Cancel order
- 2.5. Search and filtering
Integration with payment
- 3.1. Outbound
- 3.2. Inbound

Шаг 4. Зафиксируйте предположения (Assumptions)

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

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

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

Кроме устранения разногласий в трактовках, другая роль предположений — это ограничения по реализации, в которые вы хотите вписаться. То есть описание того, при каких условиях ваши оценки остаются актуальными, например:

Definition of Done для задач и всего проекта. Фиксирует общее понимание критериев сдачи задач либо проекта.
«Срок годности» оценки. Все находится в постоянном изменении: рынок, бизнес, люди, технологии и наше представления о них. Если ваш клиент захочет вернуться к уже сделанной оценке через полгода, хорошо бы ее пересмотреть на предмет актуальности.
Версии. Для каких версий языков, браузеров, операционных систем, компонент, железа, фреймворков, других продуктов верны ваши оценки.
Доступ к внешним ресурсам. Если вы работали с большими корпорациями, то вам могут быть знакомы мучения с получением доступа к их серверам, системам и прочим ресурсам, которые могут повлиять на качество оценки.
При использовании, особенно первом, внешних компонент, API стоит внести предположение о том, что они будут работать так, как указано в документации, а их поставщик будет оперативно отвечать на ваши запросы.
Требования к железу и производительности. Стоит указать, на каком железе ваше система сможет показывать плановую производительность. Даже производительность сред разработки и сетевого соединения между ними, базой и рабочими станциями членов команды может серьезно повлиять на время разработки.
Если вы знаете, что оцениваете brownfield-проект, не имея доступа ко всем старым артефактам, напишите это в предположениях: «При получении доступа к старому коду оценка может быть пересмотрена».
Лицензирование, прочие ресурсы и расходы. Хорошо бы согласовать, что вам нужно будет для оценки, если это предоставляется клиентом либо третьей стороной.
Ожидаемый объем данных. Большие базы данных и файлы могут серьезно увеличить время любых операций с ними. Одно только копирование терабайтной базы на локальный компьютер может занять несколько дней или недель при плохом сетевом соединении.
Любые комментарии, сомнения, противоречия. На одном из проектов мы делали технический апгрейд систем на новую версию фреймворка. Нашей задачей было пройти стандартные шаги апгрейда, убедиться, что код компилируется и запускается и что целостность данных не нарушена. Клиент при этом ожидал полностью протестированную и функционирующую систему. Этот проект шел долго и трудно и в конце концов был закрыт с большими убытками.

Шаг 5. Оцените каждую задачу и проект в целом

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

Используемые в расчетах коэффициенты выведены на основе прошлых проектов разработки ERP-систем, в оценке и выполнении которых я участвовал. Коэффициенты могут и должны меняться в зависимости от предметной области, технологий, требований, опыта команды и прочих факторов. Весьма надежным источником коэффициентов могут быть данные систем учета рабочего времени по аналогичным проектам в разрезе затрат на разные категории работ (бизнес-анализ и дизайн, разработка, тестирование, встречи, менеджмент и прочее).

1. Договоритесь о том, что есть разработка

Перед началом непосредственной оценки задач неплохо бы договориться о том, из каких действий состоит разработка. Например, в виде такого списка:

Среднестатистический разработчик во время оценки, скорее всего, оценит только действия, выделенные красным. Понимание разработчика, менеджера и клиента о том, закончена ли разработка задачи, может отличаться кардинально, см. Definition of Done. Потому необходимо прийти к общему пониманию.

Далее, действия 2–5 выполняются для каждой строки ИСР, если соответствующий тип работ необходим.

2. Оцените время разработки

Для каждой строчки ИСР оцените реалистичное время разработки в выбранных единицах измерения. Учитывая присущий большинству людей оптимизм, после этого стоит провести мысленный эксперимент по моделированию худшего случая, когда все идет не так. Это поможет выявить скрытые риски и скорректировать реалистичную оценку в большую сторону. Оценка должна учитывать количество работы, сложность и риск.

Если различные виды разработки оцениваются отдельно в рамках одной задачи, например front-end и back-end, то их оценки необходимо сложить.

Будьте более пессимистичны в оценке больших задач и оптимистичны в оценке малых. Ошибки недооценки на больших задачах, очевидно, более рискованны. Кроме того, переоценка малых задач сильно бросается в глаза и создает впечатление непрофессионализма или сильной переоценки всего проекта, подрывая доверие к вам. При этом недооценка малых задач практически никакого риска для проекта не несет.

Если ваша команда сформирована и сработана, хорошие оценки может дать Planning poker, хотя это и относительно дорогая техника.

3. Добавьте время на работу с требованиями и дизайнами

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

4. Добавьте время на обеспечение качества

Добавьте время на работы по тестированию (написание тестовой документации и непосредственно ручное тестирование, включая интеграционное) — 50% от времени разработки. Если вы собираетесь использовать автоматизированное тестирование, отдельно добавьте время и на него.

5. Добавьте время на риски

Оцените степень риска (Contingency) по задаче. Это субъективный показатель того, насколько разработчик уверен в оценке и понимании задачи по следующей шкале:

+5% — полностью уверен, низкий риск;
+15% — средний риск;
+30% — риск высокий.

Выше 30% — слишком высокий риск, задача требует дополнительного исследования либо разбиения на подзадачи. Хотя на ранних стадиях проекта, в условиях высокой неопределенности, коэффициент риска может быть выше.

Степень риска затем умножается на полное время выполнения задачи (BA + DEV + TST).

6. Добавьте время на общепроектные задачи

Для всего проекта добавьте:

Время на встречи — 20% от времени разработки. Гибкие методологии могут потребовать и больше времени на встречи.
Время на менеджмент — 15% времени разработки. Включает в себя время тимлида на управление командой.
Время на управление инфраструктурой (DevOps) — 5–10% времени разработки.
Время на прочие работы вашего проекта (например, автоматизированное тестирование или командировки).
Проектный буфер — от 5 до 15% от суммарного времени, в зависимости от рисков, размера проекта, сложности предметной области и требований, степени взаимосвязи разных задач.

7. Сведите все вместе

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

BA & UI — Business analysis and UX/UI design
DEV — Development
TST — Test
Cont — Contingency

Красным цветом отмечены числа, которые необходимо получить от оценщиков. Остальные же вычисляются автоматически.

Округляйте оценку до целых часов, десятков, сотен, в зависимости от конечного результата. Число 1574,56 может создать у читателя ложное ощущение точности, в отличие от 1580 или 1600.

Заметьте, что трудоемкость всего проекта в три раза выше трудоемкости непосредственно разработки: 971 человеко-час против 312. Интересно, что это соотношение совпадает с выводом в классической книге Ф. Брукса по управлению проектами «Мифический человеко-месяц», написанной аж в 1975 году. Оно также может служить грубой проверкой полноты оценки.

Шаг 6. Оформите оценку

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

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

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

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

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

Чем выше начальство, принимающее решение, тем менее интересны ему детали и более — конечная сумма. Потому при представлении оценок топ-менеджменту стоит убедиться, что в них включено все, что можно более-менее обосновать. Уменьшить бюджет проекта легче, чем увеличить.

Чек-листы

Настойчиво рекомендую создавать, использовать и пропагандировать контрольные списки (чек-листы). Неважно, сколько вы проектов оценили в своей жизни, всегда есть шанс что-то упустить. Отличная книга по этой теме — The Checklist Manifesto: How to Get Things Right, в которой ее автор, Атул Гаванде, описывает, как чек-листы спасают здоровье и жизни в авиации и медицине. Этот дешевый и простой инструмент может однажды спасти и ваш проект.

Примеры пунктов, которые использовал я для самоконтроля, чтобы не забыть о времени:

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

Немного математики

В принципе, вышеизложенного достаточно для того, чтобы применять этот метод для оценки ваших проектов. Далее — немного математики «под капотом» и моих мыслей на тему оценки и выполнения проекта. Буду благодарен профессиональным математикам за комментарии и исправления неточностей.

Случайные величины

Время выполнения проекта, как и каждой его задачи, — величины случайные. Локальная цель оценки проекта — найти доверительный интервал трудозатрат проекта с высоким уровнем доверия.

Эмпирически мы знаем, что плотность распределения времени выполнения задачи можно смоделировать так, как показано на рисунке ниже, с длинным правым «хвостом» (своего рода следствие законов Паркинсона и Мерфи), поскольку количество негативных рисков, по сути, не ограничено. В отличие от позитивных рисков.

Источник

Для начала нам нужно найти математическое ожидание времени выполнения каждой задачи, составляющей проект (говоря строго, сделать его оценку, поскольку истинное распределение нам недоступно).

Критика метода трех точек

Классический метод нахождения оценки математического ожидания — это метод трех точек. В нем предлагается оценить некое оптимистическое, реалистичное и пессимистическое время на задачу:

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

Заметьте, что даже в общепринятых описаниях метода нет четких определений и различия между самым вероятным (most likely) и реалистичным. Также не каждый разработчик знает и понимает, что такое математическое ожидание.

Представим, что мы дали одну и ту же задачу 25 разработчикам примерно одинаковой квалификации. И получили фактические значения потраченного времени, как на диаграмме ниже. Математическое ожидание в таком случае будет равно 6,16, а наиболее вероятное время выполнения — 5. То есть при неправильной коммуникации реалистичной оценки можно «промазать» на 20–25%.

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

Придумывать три величины для каждой задачи достаточно трудоемко. На практике оптимистические и пессимистические оценки могут проставляться «от фонаря», особенно если задач десятки или сотни.
Неточность в определениях, что есть a, m, b, вносит неточность и в оценку.
«Риск задачи», на мой взгляд, намного более интуитивная категория, чем «три точки».

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

Центральная предельная теорема

Говоря строго, гипотеза о том, что оценка всего проекта равна сумме оценок всех его задач, требует доказательства. Итак, допустим мы получили математическое ожидание трудозатрат для каждой задачи. Далее нам поможет одна из самых полезных теорем математики, а именно центральная предельная теорема:

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

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

На практике считается, что слагаемых должно быть не менее 20.

Источник

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

Увеличиваем доверительный интервал

Итак, подойдет ли нам сумма оценок всех задач в качестве финальной оценки? Только в случае, если нас удовлетворит 50-процентная вероятность попадания в бюджет... Чтобы быть более уверенным в завершении проекта в срок и в рамках бюджета, необходимо добавить еще некоторую величину. При использовании трехточечного метода для всех задач ее возможно вычислить достаточно строго, например +3 сигмы для доверительного интервала в 99,7%.

В нашем же методе добавляем проектный буфер в размере от 5% до 15%, величина которого определяется выявленными рисками, взаимозависимостями между задачами, размером проекта, а также лояльностью клиента к такого рода перестраховкам:

5% — проект небольшой, требования понятны и стабильны, риски низкие;
15% — проект большой, требования и скоуп не до конца определены, есть сильные взаимозависимости между задачами, присутствуют риски, такие как использование новых технологий, наличие унаследованных артефактов, зависимость от внешних компонент или подрядчиков.

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

Таким образом, наш метод оценки получает некое нестрогое математическое обоснование.

Заключение

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

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

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