Безкоштовна онлайн-конференцiя з Python від fwdays. 14 грудня. Реєструйся!
×Закрыть

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

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

Метод оценки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Feature Estimate
Login page24mh— оцениваем
Single sign-onNOT ESTIMATED— оценим позже, когда будет понятнее
Sign-up linkOut of scope— не собираемся оценивать и делать

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

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

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

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

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

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

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

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

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

  1. Login page
    • 1.1. UI
    • 1.2. Login
    • 1.3. Logout
  2. Order page
    • 2.1. UI
    • 2.2. Create order
    • 2.3. Confirm order
    • 2.4 Cancel order
    • 2.5. Search and filtering
  3. 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%.

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

Заключение

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

  1. Тщательно описывайте рамки оцениваемого проекта, предположения и риски.
  2. Найдите, обучите квалифицированных оценщиков и боритесь с оптимизмом всех участников оценки.
  3. Хорошо оформите оценку и постоянно общайтесь со всеми стейкхолдерами.
  4. Проверяйте себя, используя чек-листы и помощь коллег.
Качественная оценка — необходимое, но недостаточное условие успеха. Следование лучшим практикам управления проектом и изменениями на всех его стадиях абсолютно необходимы. При этом хорошо выполненная и структурированная оценка может сильно помочь в последующих проектных активностях. Надеюсь, что этот материал улучшит жизнь многим руководителям, проектам, командам и компаниям.
LinkedIn

71 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

кстати мультик уже можно сказать классический только надо думать малоизвестный

youtu.be/xDp6xKOVJYE

Это неприемлемо — это же совок.
Хотя именно совок развил всю эту теорию планирования и проектирования. Планирование — это была идя фикс и под нее загрузили кучу математиков советских.

А капиталисты. Я еще помню, как в своих учебниках им было запрещено писать фамилии Колмогоров, Смирнов и подобных советских. Помню в германии нужно было вспомнить по матстатистике некоторые места, пошел в библиотеку и охреневал с их учебника. Это был 1998 год.

Александр! Скажите, а что вы думаете о средней гармоничной величине? Например разраб называет MIN и MAX срок для выполнения задачи. Мы на базе этих данных считаем среднюю гармоническую (2/(1/X+1/Y) и получаем Оптимум. Пробовали?

Назови ее очаровательно гармонической и юзай. Причем тут она. Среднее хоть какой-то смысл выше иметь может,

По вашему ответу я понял мало, но спасибо большое! ;)

По вашему ответу я понял мало

именно это он и имел в виду ))

Не уверен, что она применима здесь. studme.org/...​rednyaya_geometricheskaya

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

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

Тут вопрос, как вычислить параметры суммарного распределения. Для отдельных задач я, всё-таки, придерживаюсь мнения, что бета-распределение (медиана для которого и высчитывается по всем известной PERT-формуле) вполне имеет смысл.

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

Пуассоновское — это распределение времени наступления событий. У него один параметр.

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

Ну и желательно не забывать о доверительных интервалах оценок. А то берут часто среднее из [1 2 1000000] и пользуются и после удивляются, что фигня выходит.

Чтобы вычислить параметры суммарного — надо знать параметры каждого слагаемого и их зависимости... Так что лучше уже нормальное и еще немного добавить под помидорчики.

ну мы так и делаем — нормальное и доверительный интервал, в который попадает 99% площади под кривой распределения

(медиана для которого и высчитывается по всем известной PERT-формуле)

Вроде бы все же МО, а не медиана.

It is a transformation of the four-parameter Beta distribution with an additional assumption that its expected value is
{\displaystyle \mu ={\frac {a+4b+c}{6}}.}{\displaystyle \mu ={\frac {a+4b+c}{6}}.}

Медиана будет левее, т.е. оптимистичнее.

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

Все верно, продажа — игра и отдельная. Но для себя-то хоть надо реалистичную картину знать, чем рискуешь.

Хорошая статья, спасибо автору

И мне таки не удалось приятно удивиться. Снова Planning poker, как улучшатель оценок и без доказательств реальной его эффективности (или хотя бы ссылок на исследования, а не анекдотов из жизни). Магические константы всюду — +50%, +70%.

Также не каждый разработчик знает и понимает, что такое математическое ожидание.

И снова только разработчики не умеют в математику.

Методы Three-point estimation и PERT стары как мамонты и были придуманы из воздуха в районе 1950-1960 годов. После чего успешно кочуют из книги в книгу без желания авторов подтвердить их хоть каким-то исследованиями. Вот немного из критики:

herdingcats.typepad.com/...​7/06/pert-analysis-r.html

Или из pubsonline.informs.org/...​i/pdf/10.1287/ited.6.1.21
«PERT is obviously a very useful network based model for project management. However, as the foregoing examples have shown, PERT approximations of project duration — and the associated probability statements derived from those approximations — are, at best suspect and at worst, probably downright misleading.»

«In light of the bias long-documented in professional literature, and the nature and extent of PERT approximation errors illustrated for the simple examples explored in this paper, it seems clear that prevailing introductory PERT discussions fall short of this important objective»

Центральная предельная теорема, как Вы сами указали, относиться только к «слабо зависимых случайных величин» это кривой перевод из вступления в русской википедии. А вот математическое определение дается для «независимых одинаково распределённых случайных величин». Задачи в ИТ легко могут иметь вероятность близкую к 100% зависимости оценки одних задач, от оценок/выполнимости других задач. Т.е это теорема вообще говоря не применима для нас даже близко. Натягивание совы на глобус — очень хочется применить, вот и применяете.

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

Эти допущения в подавляющем случае ошибочны и невыполнимы. Смотри выше.

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

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

Ох....

Добавлю чуток позитива :) тут много и полезных советов и хорошая структура для пошаговой проверки себя. Вот за это действительно спасибо (и за ваши чек-листы)!

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

Ну, если у вас есть применимые совы, кроме #NoEstimates, то делитесь.

Насчет википедии — my bad, надо было глянуть во что-то посерьезнее.

Эти допущения в подавляющем случае ошибочны и невыполнимы.
Ваши сигмы справедливы для нормального распределения, а как мы знаем оно точно совсем не такое

Когда внедрял методы оценки проектов у нас в Сигме, стоял ровно перед такой же дилеммой.

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

Поэтому, пошли по тому же пути, что и автор, с PERT для отдельных пунктов WBS и центральной предельной теоремой с доверительными интервалами для итоговой оценки.

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

видимо потому что на этапе коммерческого предложения оценка делается очень грубая настолько что все стороны в общем понимают это и признают? ))

ЗЫ: карочи я вас всех полюбил я вас всех научу основная цель этой всей математики это её сходимость в процессе уже разработки т.е. фактически математика должна быть функцией уже по времени процесса и вычисляться периодически и эта функция должна сходиться в чём и есть её основное предназначение видеть конец если функция в процессе не сходится соотв. конец увидеть нельзя соотв. ценности её нет соотв. функция неправильная либо что-то не так в процессе всё ))

Тогда принял для себя решение, что считать всё абсолютно по-честному с точки зрения математики и теории вероятности — будет непосильной задачей

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

Есть большое подозрение, что очень грубые оценки дают результат не хуже, чем эти сложные методы получения оценок. И в некоторых областях те же #NoEstimates это демонстрируют. И что менеджеры подсознательно «подстраивают» цифры под их предыдущих опыт на похожих проектах. И гораздо лучше, когда они это осознают и делают явно (нет ничего плохо в использовании опыта предыдущих проектов), чем когда они придумывают сложную эвристику как случайную функцию ошибок поверх их опыта. Где хорошие результаты это просто богатый личный опыт, а не эффективность эвристики используемой менеджером.

Рекомендую почитать Эдвардс Деминга. econ.wikireading.ru/63266

«Эксперимент Монте-Карло с воронкой. Если начать настраивать стабильный процесс, пытаясь скомпенсировать нежелательные результаты или гонясь за сверхвысокими результатами, ситуация на выходе станет хуже, чем если бы процесс протекал без вмешательств (приписывается Уильяму Лацко).»

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

У нас был ровно обратный опыт: на грубых быстрых оценках получали неприемлемо большую ошибку.

Ни в коем случае не говорю, что сложные методы идеальны, но, всё же, при качественных исходных данных они дают куда лучшее приближение к реальности.

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

Это хорошо, когда есть релевантный предыдущий опыт :) ИМХО системное использование исторических данных могут себе позволить компании, которые специализируются на небольшом количестве предметных областей, а это, обычно, не про украинский аутсорс.

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

Либо компании, которые могут себе позволить купить консультацию либо пригласить на работу специалистов с релевантным опытом.

на грубых быстрых оценках получали неприемлемо большую ошибку.

=>

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

читай вы (здесь обобщение) оцениваете то что оценивать да и вообще делать не умеете и соотв. как результат очень странно при этом ставить под подозрение саму методику да? ))

Впервые встречаю нормальное изложение по этой теме. Главное, более менее показано «подкапотное пространство», рассказывающее почему именно так.

Можно было бы еще явно про управление ресурсами пояснить, на тему того, что 1 час сеньера != 1 час мидла, про «затраты» на погружение в контекст (откуда следует, что смена исполнителя — дополнительные расходы) и т.д. Хотя это уже ликбез о тонкостях, важные при подготовке/оценке менеджмента проекта.

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

Лично мне никогда не хватало терпения объяснять «очевидное» (для меня) кому то еще «нормальными словами» ))) вариант «ты че, д*бил» нормальным как бы не является ) *утрирую

А вот если по 7 разу и одному и тому же человеку?

объяснять маме на вопрос «у меня опять это не работает» — ацкий экспириэнс )

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

У меня был прикол, когда я одну и туже презу одним и тем же начальникам 5 раз рассказывал с течении года и они каждый раз что-то обсуждали активно. На 5 раз я не вставая и водя указкой по экрану побубнил и они, как в первый раз по 5-му кругу еще 2 часа обсуждали всё тоже самое, что и в первый раз, немного другими словами. Ну а я эти 2 часа просто подремал с открытыми глазами.
6-го раза уже не было, я сменил начальников. На очередном месте они оказались таким же.

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

Но применяют его чаще в других случаях ))

А еще я младенцев на завтрак ем.

З.Ы. От нонешнего безумия фантазий здесь я в шоке.

И в итоге у него получится еще одна толстая книжка, которую никто читать не будет. Тут уже даже в этой статье объем большой вышел.

А очень неплохо. Но ты же понимаешь, что это 3 месяца работы, а груши трясти нужно уже вчера.
Так что большинство почитает. Поцокает языком, как всё круто и продолжит трясти грушу по принципу, «хотели как лучше, а получилось, как всегда».

Ну меньшинство-то задумается. На него вся надежда :)

Спасибо за статью!

Очень неплохая статья для строительства Днепрогэса

Вообще-то она идеально подходит практически для любого проекта, где есть до старта понимание процентов 60 требований.

Днепрогэс, видимо один из таких )

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

Сейчас в постсовке никто не сможет днепрогес построить, просто не сможет. Для подобного строительства в лучшем случае пригласят англичан или американцев. В типичном просто распилят бабло. Как пример, посмотри на новый космодром, что в РФ строят.

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

Не хочется флеймить, но Днепрогэс-то американцы и строили...

Вот блин. Так что мы в совке и постсовке, как не умели, так и не научились толком. Наверное и не научимся.
Вот как часто ты делаешь проекты в соответствие со своими 2-мя статьями выше? Только честно.

Статьи на основе проектов и написаны. Ну и факапов. Так что все свое

Ты пришел к тому же,что и 100500 умных людей до тебя.

Хотя не, вру. Была возможность много наблюдать со стороны. Не все свое.

Ты пришел к тому же,что и 100500 умных людей до тебя

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

Более того, если полезть в соответсвующие учебники по обсуждаемой теме, то всё, что ты написал выше, ты найдешь там.

Да, все придумано до нас, но повторять надо снова и снова.

Ну, у тебя большой плюс. Четко и сжато основы изложены. Для желающего разобраться отличная точка старта.

60% понимание требований — редкость.
60% понимание как реализовать эти требования — тоже редкость
Если перемножить — еще менее оптимистично

Не редкость. Просто тупость миллиона мух и не способность понять требования.
Большинство проектов, если подумать, всегда покрыты требованиями на процентов 60-70.
Но так как мухи думать не могут, то они осиливают только доли процента для понимания.

Ну вот ты на сколько % понимал, как будет сделан и сколько понадобится времени на проект с распознаванием, когда ставилась задача проекта?
У меня вот телефонию думал за год сделать, а оно уже 5 лет тянется.

На эти 60-70%. Я обычно не начинаю что-то делать, пока не ясно что, на эти 60-70%.
И да к исследовательским задачам также требования ставятся, четко и ясно, если есть желание и потребность в результате.

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

А вы свои 5 лет больше бабло заказчика пилите, чем что-то полезное делаете, хотя, понятно все и всё время в мыле.

А вы свои 5 лет больше бабло заказчика пилите, чем что-то полезное делаете, хотя, понятно все и всё время в мыле.

Ну тут 2 раза ошибся)

Ладно поясню. Да, часто заказчик не может их все сходу сформулировать ясно и четко. И вот тут появляется бизнес-аналитик, как роль и работая с заказчиком четко и ясно формулирует эти 60-70% требований.

А потом заказчик получает что-то, играется, и хотелки растут.
И ты либо вносишь в проект новую функциональность, либо посылаешь заказчика.

И тут я ощутил себя, что я оказался в старшей группе детского сада. Или младшей?

У меня почасовка)

Во я и дожил, когда разумные вещи называют «жестью».

И это тоже. Сейчас для 99% максимум по сложности — это выбор из 1-3 простых картинок. Но лучше, когда есть только одна кнопка с надписью «Сделать пиздато».

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

Планировочный покер — это и есть геймифициованный wide-band Delphi метод :)

Поработать над проектом неделю как будто он начался и потом уже оценивать

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

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

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

По Покер=Делфи в принципе согласен. Надо было написать Покер(Делфи).

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

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

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

Любопытно, почему эти обсуждения всегда воспринимались командой как бессмысленные? В конце-концов, лид тоже человек и может ошибиться — неужели команда не видела смысла в том, чтобы получить второе «подстраховочное» мнение?

Ну, я там сам непосредственно не участвовал. Но рискну предположить, что в 90% случаев оценка была либо очевидна, либо обсуждение существенно большей точности не привносило — требования были достаточно детальны. А стоило оно при этом: кол-во членов команды Х количество часов обсуждения, т. е. немало.

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

Если действительно так, то нет повести печальнее на свете, чем карго-культ, навязанный клиентом.

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

тут неплохой обзор техник оценок (аджайл, в основном)
www.linkedin.com/...​ile-safe-framework-samir

Подписаться на комментарии