Быстрая и точная оценка проекта
Быстрая оценка проекта — как фастфуд. Дешево, вредно, но порой необходимый атрибут профессиональной жизни.
Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех).
Я попробую изложить подход, который вы можете использовать, если обнаружите себя в подобной ситуации.
В этой статье я не даю 100%-ный способ оценки любых проектов за пару минут. Я рассматриваю проекты средней длины — от полугода до года. И даю только первоначальную оценку проекта. Что-то, что вы можете предоставить вашему сейлз-менеджеру быстро, и не потерять при этом спокойный сон.
Требования к оценке проекта
Дядя Боб сделал замечательное видео об эффективных оценках. И он подчеркнул 3 главных качества хорошей оценки проекта:
- честность;
- прецизионность;
- точность.
Честность
Как можно измерить честность оценки? Честность — что это вообще значит?
Честность в первую очередь перед самим собой.
Мое определение честной оценки: эта такая оценка проекта, за который ты бы сам взялся, если бы был слегка болен. Представь себе, что у тебя сезонная простуда, а тебе надо реализовать данный проект в оцененный тобой срок. Если возьмешься за это — оценка честная.
Прецизионность
Прецизионность — это значит, что если вы оценивали 3 похожих проекта, то вы должны получить 3 похожие оценки. Если одна CMS-ка средней руки займет 1 человеко-год имплементации, то разработка другой CMS-ки схожего функционала никак не может занять 3 собако-недели или 5 рабо-лет.
Убедитесь, что ваши цифры не противоречат друг другу и не вызывают сомнений в вашем профессионализме и здравом уме. Страничка с контактами не может занять дольше, чем главная страница вашего сайта. Простой RESTFull сервис не должен занять больше, чем самообучаемый AI сервис аналитики.
Нелогичные оценки могут подорвать доверие к вам, как к специалисту. А без доверия оценка проекта ничего не стоит.
Точность и условия оценивания проекта
Оценка сроков выполнения проекта должна быть точной. Это значит, что разница между предсказанным и реальным сроком выполнения проекта должна быть минимальной. Если вы говорите, что проект займет 3 месяца, то крайне желательно, чтобы это было 3 месяца. А не полгода. Или год.
И точность оценки — это очень крепкий орешек. В основном это вызвано:
- Временным ограничением. У вас обычно очень мало времени на оценку проекта. Особенно если вы работаете напрямую с сейлз-командой. Этим ребятам нужно все и сразу. Без исключений.
- Недостатком информации. У вас нет полной информации о списке функционала, целевой аудитории и т. д. Иногда все, что у вас есть, — это полпараграфа текста. А временами и исписанная вашим боссом салфетка из бара напротив. GoogleIT© может помочь. Но в основном вам придется работать в условиях крайне ограниченной информации о проекте.
А чтобы получить больше информации, вам нужно больше времени. Которого у вас нет.
Добавьте к этому следующее:
- Точность оценки в зависимости от трудозатрат растет логарифмически.
- Трудозатраты на повышение точности оценки проекта растут экспоненциально.
Это значит, что даже при наличии относительно большого количества времени на оценку проекта, ваш результат все равно будет содержать в себе погрешность. И достаточно большую.
Вероятностная сущность оценки сроков проекта
Это приводит нас к вероятностной сущности оценки сроков проекта.
Едва ли вы можете выразить предполагаемый срок проекта в одной цифре и быть при этом честными, прецизионными и точными одновременно.
Оценка срока реализации проекта — величина вероятностная.
Честный, прецизионный и точный способ представления оценки проекта звучит примерно так: «Проект займет 6 недель с вероятностью успеха 95 %. Или он займет 4 недели с вероятностью уложиться в срок 65 %». Можно еще представлять оценку проекта в виде диапазона значений с учетом 95 % вероятности успеха: «Скорее всего, проект займет от 4 до 6 недель».
Единица измерений
Перед тем как идти дальше, давайте определимся с единицами измерений сроков проекта. Довольно часто используется человеко-день, то есть сколько дней один человек будет делать задачу.
Этот способ измерения всегда для меня был немного обманчив. Я представлял себе полный
Как следствие, в этой статье я буду использовать Average Working Day (AWD) как единицу измерения.
Считайте, что 1 AWD — это количество работы, которую 1 программист в среднем может сделать за день, состоящий из 5 часов написания кода и 3 часов, потраченных не у монитора.
Вдобавок мы обычно не работаем в одиночку. Мы работаем в команде. И существует вековая проблема масштабирования команды согласно ожидаемого/желаемого срока разработки проекта. См. «9 женщин не могут родить ребенка за 1 месяц» и закон Брукса.
Но для простоты мы опустим эти детали и будем считать, что 2 человека могут справиться с задачей на 2 AWD за 1 день, 4 — за полдня и т. д.
Расчет диапазона срока выполнения проекта
Теперь обсудим, как именно рассчитывать вероятностное значение срока выполнения проекта.
Трехкратный метод
Идея проста: чтобы оценить проект, разбиваете его на задачи и даете оценку каждой задаче с помощью 3 величин:
- B — best case (оптимистическая) оценка срока, 95 % вероятности не уложиться в срок.
- N — nominal (номинальная) оценка срока, 50 % вероятности уложиться в срок.
- W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложиться в срок.
Считайте, что уложиться в оптимистичный срок можно, только если сам Один сядет за лэптоп и всей своей мудростью и силой затянет проект прямо в Вальхаллу. Оптимистичная оценка — это минимально необходимое время для реализации проекта при наилучших обстоятельствах. Задача наверняка будет выполняться дольше, чем рассчитано по best case. Также можете считать это вашей Big-Omega оценки срока.
Номинальная оценка — наиболее реалистичный срок. Это самое важное значение, так как оно имеет наибольший вес в дальнейших расчетах. Эта оценка должна быть умеренно оптимистичной при ваших обычных условиях работы. Считайте, что у вас есть 50%-ная вероятность не уложиться в номинальный срок. Также можете считать это вашей Big-Theta оценки срока.
Пессимистическая оценка дается исходя из того, что все пойдет не так. Ваш ноут утащила в нору офисная крыса. Ваш дизайнер оказался мартышкой-наркоманом. Вас призвали в армию за день до релиза. Это наихудшая оценка, которую вы можете дать задаче. И у вас только 5%-ный шанс не уложиться в этот срок. Также можете считать это вашей Big-O оценки срока.
Очевидно, что
B < N < W
Ваша пессимистическая оценка не может быть меньше номинальной. Извините.
Давайте рассмотрим трехкратный метод на примере.
Пример требований к проекту
The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.
Предположим мы разбили требования на 3 задачи:
| № | Work Item Name |
| 1 | User Login |
| 2 | Purchase Commodity |
| 3 | Purchase History |
Пример трехкратной оценки задач
| № | Work Item Name | B | N | W |
| 1 | User Login | 10 | 30 | 100 |
| 2 | Purchase Commodity | 15 | 40 | 150 |
| 3 | Purchase History | 2 | 10 | 20 |
Расчет СКО и среднего арифметического взвешенного
Среднее значение срока выполнения задачи (mean) рассчитывается как:
M = (B + 4N + W)/6
Почему коэффициент 4 для номинальной оценки? Потому что она наиболее реалистичная. И мы хотим выделить ее по сравнению с другими оценками. Почему именно 4, а не 6 или 8? Потому что Rocket Science.
Для вычисления общей средней продолжительности проекта мы суммируем среднюю продолжительность каждой задачи.
И получаем:
| № | Work Item Name | B | N | W | M |
| 1 | User Login | 10 | 30 | 100 | 38 |
| 2 | Purchase Commodity | 15 | 40 | 150 | 54 |
| 3 | Purchase History | 2 | 10 | 20 | 10 |
| Project Total Mean | 102 | ||||
Теперь давайте рассчитаем СКО (Standard Deviation) для каждой задачи:
S = (W — B)/6
И общее СКО для всего проекта:
Project Standard Deviation = SQRT(SUM(S)^2)
Для нашего проекта имеем:
| № | Work Item Name | B | N | W | M |
| 1 | User Login | 10 | 30 | 100 | 38 |
| 2 | Purchase Commodity | 15 | 40 | 150 | 54 |
| 3 | Purchase History | 2 | 10 | 20 | 10 |
| Project Total Mean | 102 | ||||
| Project Standard Deviation | 40.5 | ||||
СКО показывает вариативность вашей оценки. Чем оно больше — тем больше будет диапазон вашей оценки. Не говорите об СКО проекта людям с гуманитарным образованием :)
Эти значения нам понадобятся для аппроксимации наших данных с помощью бета-распределения. Что в свою очередь даст возможность получить вероятностное значение сроков выполнения проекта.
Бета-распределение
Для получения вероятности успешного выполнения проекта в оцененный срок я использовал бета-распределение. Потому что его применяли в PERT.
Детальное описание использования бета-распределения с трехкратным методом приведено здесь.
В общем мы рассчитываем вероятность успеть в срок исходя из среднего значения и СКО проекта.
Для нашего проекта получаем следующую функцию распределения:
Читается график так: «Проект будет завершен за 177 AWD с 95 % вероятностью».
Вот небольшая табличка шансов проекта на успех:
| Chance of Success | Effort (AWD) |
| 95 % | 177 |
| 70 % | 122 |
| 50 % | 98 |
Если вы сравните со средним значением продолжительности проекта (102 AWD), то поймете, почему не следует просто использовать среднее.
Вот мы и получили вероятностную оценку срока выполнения проекта.
Диапазон оценки
Если вы не уверены во всей этой вероятностной кухне, можете просто давать диапазон значений для срока выполнения проекта, пользуясь следующим правилом:
The 95 % confidence interval for the true project work time is approximately:Project Total Mean ± 2 × Project Standard Deviation
Коэффициент 2 основан на правиле 68-95-99.7.
Для нашего проекта получаем: «Проект займет от 21 до 183 дней».
Можем опустить нижнюю границу диапазона и сказать: «Проект займет от 102 до 183 дней».
Конечно, можно использовать коэффициент 1, получая:
Project Work Time = Total Mean ± 1 × Project Standard Deviation
Но следует учитывать, что в этом случае мы говорим о вероятности окончания проекта в срок, равной 68 %.
Excel Workbook для проекта
Здесь находится Excel Workbook с примером расчетов для нашего проекта. Юзайте с миром :)
Дополнительные требования
Постарайтесь разбивать проект на максимально независимые задачи. Рекомендуется использовать около 20 и более задач для получения более точного результата.
Вывод
Оценка проектов в мире IT далека от точной науки. И так будет продолжаться еще долго. Методология использования трехкратного метода с бета-распределением не идеальна. Но она может дать вам больше уверенности в ваших оценках. Уверенность поможет добиться доверия к вашим словам, а на доверии и держится весь процесс оценки проектов.
P. S.
После того, как я оценил несколько проектов, я решил посчитать точность моих оценок. Я хотел посчитать разницу между моими оценками и реальной продолжительностью проектов. Но не смог этого сделать. Некоторые из проектов так и не были запущены. Другие настолько изменились в ходе разработки, что в конце невозможно было сопоставить сделанные задачи с изначально запланированными.
У меня есть подозрение, что это не совпадение. Разработка программных продуктов — крайне волатильный процес. Очень редко в конце мы получаем то, что планировали изначально. Это делает расчет точности оценки практически невозможным. Для отдельных задач это еще реально, но для проекта в целом — едва ли.
Так как же оценивать проекты, чтобы получить верифицируемый результат? Хороший вопрос. Выше я описал несколько вариантов. Также здесь есть пару идей. Но для меня это все еще открытый вопрос.
