что такое длительность проекта
Оценка срока проекта. Почему она почти всегда сильно занижена и что с этим делать
При расчёте срока проекта традиционно мы оцениваем длительность промежуточных шагов, затем их суммируем и прибавляем буфер на всякие случайности. Затем руководство режет нам этот срок вдвое. В рамках данной заметки автора будут интересовать наши расчёты, потому что даже руководитель проектов с большим опытом зачастую понимает, что рассчитанный срок слишком короткий и сильно, иногда в разы, расходится с его личной экспертной оценкой. Да, он поправит оценки сроков проекта и промежуточных шагов до своей экспертной оценки и при истинном мастерстве с некоторыми переработками уложится в срок с точностью до 15%, но осадочек останется.
Данная заметка объясняет причину расхождения экспертной и теоретически рассчитанной оценок. Также рассмотрено, почему “завышенная” экспертная оценка обычно оказывается занижена, если она не делается на основе статистических данных по выполнению аналогичных проектов. Под конец раскрыто как корректно посчитать срок проекта и объяснить ситуацию заинтересованным лицам до начала проекта или в ходе проекта.
Корень ошибки
Когда мы оцениваем срок реализации кусочка работы, мы определяем наиболее вероятную цифру. Это может быть экспертная оценка по одной точке или по трём точкам, как в PERT. В сложном проекте это может быть параметрическое моделирование. Во всех вариантах мы совершаем одну и ту же ошибку. Дело в том, что во всех классических методах оценки предполагается, что у нас нормальное распределение оцениваемой величины — по Гауссу. Теоретики очень любят это распределение.
Нормальное распределение означает, что проект с корректно оценённой длительностью 6 месяцев с равной вероятностью завершится через 9 месяцев или через 3 месяца. На равных расстояниях от центра распределения вероятность завершения проекта равна — такова особенность кривой Гаусса. С другой стороны, на практике мало кто видел IT-проект, завершившийся в два раза быстрее (через 3 месяца), зато проекты затянувшиеся в полтора раза по срокам (9 месяцев) мы видим регулярно. Кроме того, при нормальном распределении половина проектов у нас заканчивалась бы до оценённого срока, а половина — после. Но этого на практике тоже не наблюдается. Это говорит о том, что нормальное распределение для оценки сроков неприменимо. То есть у нас не нормальное распределение, а какое-то иное, с разной вероятностью завершения до наиболее вероятного срока и после.
Рассмотрим в качестве примера подобного распределения логнормальное. Оно нам покажет особенности данного класса распределений. Для логнормального распределения медиана и математическое ожидание находятся существенно дальше пика:
На представленном графике пик показывает наибольшую вероятность срока завершения проекта В план проекта обычно вписывается эта цифра плюс некий запас. Медиана указывает на точку разделения при которой половина проектов завершится до этого срока, а вторая половина — после. Математическое ожидание указывает среднее значение длительности проекта. Для фрагмента работы распределение будет иметь те же самые особенности: большую разницу между наиболее ожидаемым сроком реализации фрагмента работы (на основе него традиционно строятся планы) и средним значением срока.
Чтобы спрогнозировать длительность проекта, мы определяем самую длинную по времени цепочку и складываем длительности её фрагментов. Если мы складываем так величины, распределённые по Гауссу, то в среднем должен получиться корректный итоговый срок. Ведь половина фрагментов работы завершиться раньше срока, половина позже и эти неоднородности взаимно скомпенсируются. Чем больше фрагментов, тем точнее скомпенсируются неоднородности. Плюс мы можем посчитать погрешность и чуть сдвинуть срок на сигму-другую в зависимости от последствий срыва сроков.
Но у нас не распределение Гаусса. У нас удлинение срока выполнения каждого фрагмента работы значительно вероятнее, чем укорачивание на такую же величину. В итоге, если мы складываем сроки наиболее вероятного завершения каждого фрагмента работы, то у нас неоднородности по срокам выполнения не компенсируются, а усиливаются. Причём усиливаются в сторону удлинения реального среднего срока проекта по сравнению с оценкой. Что мы и наблюдаем в реальной жизни: если первый срок просрочен, то будут просрочены и все остальные сроки, при этом просрочка будет только расти. Лишь прикладывая дополнительные усилия можно остановить рост отставания проекта.
Особенностью данного способа подсчёта является известный факт: чем мельче дробить работы для оценки срока проекта, тем менее точной оказывается оценка. Хотя по теории должно быть ровно наоборот. Причина этого в том, что наша экспертная оценка для всей работы и для составляющих её частей берётся из опыта. Опыт оценивает каждый элемент независимо, а не исходя из арифметики, согласно которой длительность работы должна быть суммой длительностей составляющих её частей. Арифметика здесь не работает, так как сумма наиболее вероятных сроков завершения частей не даёт наиболее вероятный срок завершения всей работы — корректно суммировать можно только математические ожидания.
Если мы пытаемся чуть сдвинуть оценённый срок для всего проекта или его частей на сигму-другую, считая распределение нормальным, то это не сильно помогает, так как хвост распределения сильно толще, чем у кривой Гаусса. В итоге, за счёт такого увеличения оценки срока не удаётся дойти даже до медианы, не говоря уже о среднем значении длительности проекта в виде математического ожидания.
Что делать
С одной стороны, складывать следует математические ожидания. С другой стороны, мы не математики. Мы из реальной жизни и понимаем проблемность расчёта параметров графиков даже когда на это есть время и какая-то накопленная статистика. Но есть другие пути. В конце-концов, проблеме оценки сроков не один десяток лет и с этим практики работать научились.
Метод Брукса: считаем срок реализации программы “в лоб” (пользователем выступает сам программист) и умножаем на 3 для программного продукта (пользователем выступает неограниченный круг лиц) или программного комплекса (в текущих реалиях — набор микросервисов) и на 9 для системного программного продукта (в текущих реалиях — набор связанных инфраструктурных компонентов). Откуда берутся такие коэффициенты хорошо теоретически обосновано в первой главе книги Брукса “Мифический человеко-месяц” и это описание 1975 года хорошо перекладывается на текущие реалии.
Метод Скрама: вводим абстрактную промежуточную единицу трудоёмкости реализации функционала, смотрим статистику реализации командой измеренного в данных единицах функционала, просим команду оценить трудоёмкость задач проекта, переводим единицы в Скрам-итерации (спринты) известной длины и получаем оценку сроков для данной команды разработки. Так как мы работаем с реально собранной статистикой и команда отвечает за свои оценки по трудоёмкости, то привязка длительности к единице трудоёмкости является математическим ожиданием и поэтому половина спринтов будет заканчиваться чуть раньше, половина чуть позже. На практике в половине итераций Скрама придётся у команды забрать часть задач, а в половине добавить незапланированных, чтобы длина спринта оставалась постоянной.
Задача переноса Скрам-оценки одной команды на другую команду является искусством. Они не переносятся простым введением коэффициента перевода единиц трудоёмкости одной команды в единицы трудоёмкости другой команды. Дело в том, что одна команда имеет в своём составе хорошего фронтендера, но в ней нет хорошего специалиста по базе, а другая команда имеет хорошего специалиста по базе, но фронтовые задачи для неё повышенной сложности. Отличия в специализации разработчиков приведут к тому, что относительно бэкендовых задач у одной команды будет перегиб по сложности в сторону задач по базе данных, а у другой — по фронту. Кроме того, команда сама определяет необходимый уровень внутреннего качества продукта и разные команды определяют его несколько иначе, чем соседние команды, что также затрудняет пересчёт единиц трудоёмкости. То есть можно перевести промежуточные единицы одной команды в промежуточные единицы другой команды сравнивая оценки схожих задач, но эти задачи должны браться из разных типов деятельности, с учётом сильных и слабых сторон команд и с учётом особенностей настройки их Скрамов.
Метод функциональных элементов: вводим промежуточную единицу трудоёмкости, составляем список функциональных элементов (экраны в браузере, микросервисы, настраиваемые элементы инфраструктуры и т.д.), оцениваем трудоёмкость работы над каждым функциональным элементом в промежуточных единицах. После этого по своему экспертному опыту работы с конкретной командой разработчиков оцениваем переводной коэффициент промежуточной единицы во время. Лично я ещё независимо оцениваю переводные коэффициенты для разных видов деятельности: аналитики, проектирования, написания постановок задач, написания кода, вёрстки, тестирования, интеграции и т.д. После этого следует учесть порядок операций, характерное время задержки между завершением предыдущей операции и началом новой и определить длительность проекта методом критического пути.
До сих пор мы работали с внутренними факторами проекта. Но у нас есть и внешние: внешние подрядчики, смежные подразделения, поставщики и клиент. Проблемы с ними ровно те же самые: они в два раза быстрее делают или отвечают сильно реже, чем в полтора раза дольше наиболее вероятного значения. То есть там тоже нет нормального распределения по срокам. Это тоже следует закладывать и учитывать на основе статистики работы с клиентами, подрядчиками и смежными подразделениями и, по возможности, защищаться с помощью штрафных санкций.
Обоснование сроков
И вот, мы оценили прогнозную длительность проекта. Как обосновать полученный срок? На основе проделанных расчётов. Например, автор заметки для не-Скрам проектов обычно делает в Google Sheets большую многострочную наглядную таблицу с детальным расчётом методом функциональных элементов. Расчёт опирается на практику, все коэффициенты и параметры наглядны, а практика для заинтересованных лиц обычно является сильным и хорошим аргументом, даже если получился неудобный для тех или иных лиц срок. Особенно практика наглядная и полученная в рамках текущей компании.
Согласятся ли заинтересованные лица, например руководство, с хорошо проделанной и донесённой оценкой по срокам? Далеко не всегда даже если заинтересованные лица полностью понимают и осознают, что оценка корректная. Иногда оценка неприемлема по внешним причинам, но это уже боль заинтересованных лиц, выливающаяся в трудном решении руководства по срокам. И тем не менее, видя опирающиеся на опыт расчёты, руководство и иные заинтересованные лица имеют возможность предсказуемо повлиять на итоговый срок проекта выделением дополнительных ресурсов и полномочий. Иногда понявшее ситуацию со сроками руководство будет продолжать резать сроки без выделения дополнительных ресурсов и полномочий. Как с этим жить — тема отдельной заметки.
Какие бывают дни: трудозатраты, длительность, сроки
Накопленный опыт взаимодействия с командами и смежными руководителями проектов все больше отражает печальную картину, что многие специалисты не понимают различие между рабочими, календарными и человеко-днями (часами). Попробую разобрать действительно простые понятия, в качестве достоверного источника для определений буду ссылаться на PMBoK.
Определения
Работа (Activity) – составная часть проекта, выполняемая в ходе его реализации. Каждая работа обычно характеризуется ожидаемыми длительностью, затратами на ее выполнение и потребностями в ресурсах. Работа может быть разбита на отдельные задачи.
Затраты на выполнение работы/задачи = Трудозатраты (Effort) – затраты, необходимые для выполнения работы или иного элемента проекта. Обычно выражается в человеко-часах, человеко-днях или человеко-неделях. Не следует путать трудоемкость работы с ее длительностью.
Длительность (Duration) – число календарных единиц, требующихся для завершения работы или иного элемента проекта без учета выходных и других нерабочих дней. Обычно выражается в рабочих днях или неделях. Иногда ошибочно приравнивается к затратам времени (трудозатратам).
Календарные сроки – сроки, устанавливаемые указанием на какой-либо период времени либо календарную дату. Необходимо четко разделять, что календарная неделя и трудозатраты человеко-неделя – разные понятия, их нельзя использовать как одинаковые временные рамки. Определение календарных сроков приведено из правового поля, PMBoK не дает определения календарным срокам и разнице между рабочими и календарными днями.
Просто о сложном на примере
Допустим, разработчику Васе необходимо написать приложение научного калькулятора для мобильного устройства (не будем вдаваться в подробности ОС, моделей и языков программирования). Помимо обычных функций сложения, умножения нужны еще функции степеней, извлечение корней и т.д. По оценке Васи ему необходимо 16 человеко-часов на написание такой функциональности.
Почему для оценки используется понятие человеко-часа? Человеко-час — единица учёта отработанного (или планируемого) времени, соответствует одному часу работы одного человека. К слову, обычно один человеко-день – это 8 человеко-часов, значит оценка Васи – 2 человеко-дня.
Вася понимает, что многие функции калькулятора не связаны между собой и их можно делать параллельно, если позвать кого-то на помощь, например, с такой же продуктивностью. Если мы разделим всю работу Васи поровну между ним и его помощником, то по длительности они смогут написать калькулятор за 1 рабочий день, а по трудозатратам потратят все те же 2 человеко-дня (16 человеко-часов).
Такой подход в PMBoK и других классических методологиях называется быстрым проходом (Fast Tracking) или распараллеливанием – для сокращения сроков работ / проекта можно на одни и те же трудозатраты привлекать дополнительное количество ресурсов. Трудозатраты остаются без изменений, длительность сокращается. В обратную сторону при сокращении количества доступных ресурсов, но том же объеме работ трудозатраты остаются неизменными, длительность вырастает.
Если вдруг у помощника возникнет другая срочная задача, и он сможет уделять только 50% своего времени на написание калькулятора, а перераспределять объем работ Вася и его помощник не захотят, то длительность работ снова станет 2 дня, трудозатраты останутся без изменений. Вася сделает свои 8 человеко-часов за 1 рабочий день, а помощник – свои 8 человеко-часов за 2 рабочих дня. Аналогично будет и при снижении доступной загрузки Васи до 50%, трудозатраты не изменятся, длительность будет 2 рабочих дня.
1 с загрузкой 100%,
1 с загрузкой 50%
Быстрый проход является одним из основных методов сжатия длительности работ проекта. Сжатие (Crashing) – проведение мероприятий, направленных на сокращение общей длительности проекта на основе анализа нескольких альтернатив и выбора той из них, которая дает максимально возможное сжатие длительности проекта при заданной его стоимости.
При использовании инструментов снижения длительности работ никогда нельзя забывать о наличии зависимостей между работами и ключевыми вехами. Существуют задачи, которые невозможно выполнить до завершения предыдущих или наступления определенных событий. Зависимость работ (в PMBoK логическая зависимость) – взаимосвязь между двумя или несколькими работами в составе проекта или между работой и вехой. Существует 4 типа логических зависимостей:
финиш-старт – начало последующей работы зависит от завершения предшествующей;
финиш-финиш – завершение последующей работы зависит от завершения предшествующей;
старт-старт – начало последующей работ зависит от начала предшествующей;
старт-финиш – завершение последующей работы зависит от начала предшествующей.
Зачем все это знать
Отвечая на вопрос заинтересованных людей, зачем при оценках работ разделять трудозатраты и длительность, когда достаточно сказать «это можно сделать за 15 дней», напомню, что помимо команд, которые делают продукт, есть еще сидящие рядом менеджеры, которым нужно считать деньги, называть сроки и рисовать презентации с графиками (и это тоже полезная работа).
В настоящее время есть большая вариативность инструментов оценки будущей функциональности и много способов «сообщить» результат такой оценки. И даже если ваша команда сделает какую-то классную фичу всего за 15 дней, из такой оценки даже самому крутому и продвинутому менеджеру далеко не всегда будет понятно сколько денег и сроков нужно нарисовать на графике. Для единого понимания и прозрачного выстроенного процесса важно всегда синхронизироваться в понятиях, используемых при оценке. На мой взгляд, придумывать велосипед и изобретать свои системы счисления не стоит, да и вообще нет ничего лучше, чем использование классического и подтвержденного мировым опытом подхода по разделению трудозатрат, длительности и сроков на раздельные составляющие.
В противном случае при использовании способов оценки «наша команда сделает за 15 дней» всплывает известная задача про землекопов. Чтобы не сотрясать воздух, привожу «живой» пример от менеджера команды из недавних переписок:
Проблемы этого письма:
Менеджер команды путает календарные и человеко-месяцы, для справки: в одном квартале действительно 3 месяца, но в среднем это 63 рабочих дня, а никак не 90.
90 человеко-дней – это уже 4,2 человеко-месяца, которые можно уместить в один квартал, если несколько ресурсов будут работать параллельно.
Полная неразбериха в трудозатратах и длительности и нулевая информативность оценки: сколько ресурсов и их процентная доступность, сложно рассчитывать бюджет.
И «на десерт» был план такой оценки:
План не привязан к календарю (невозможно понять сроки старта и окончания работ, не учтены возможные сдвиги из-за календарных праздников и внезапных нерабочих дней).
Отсутствует разбиение блоков работ на атомарные работы для осуществления возможного сжатия проекта по длительности.
Отсутствуют зависимости между задачами и вехами работ также для осуществления возможного сжатия проекта по длительности.
Отсутствует информация о количестве ресурсов и их доступности.
В таком исполнении оценки и последующего плана оценка команды имеет нулевую ценность и информативность, невозможно корректно рассчитать бюджет проекта, его календарные сроки и ограничения, так как разные 90 дней по-разному влияют на бюджет и сроки. И это не занудство менеджера, которому больше нечем заняться, а грамотное проектное управления и планирование работ.
Модные понятия
Ни в коем случае не хочу накидывать на вентилятор в сторону Agile-команд, я их люблю и работаю с ними, но все-таки упомяну новомодное понятие, с которым приходится сталкиваться – командо-дни.
Если вдаваться в подробности происхождения, то это выдуманное понятие, аналогичное человеко-дням, только вместо человека целая команда. Вместе с этим вам несколько «НО»:
PMBoK, PRINCE2 и прочие взрослые методологии не вводят таких понятий, хотя давно уже дружат с Agile. Не потому, что методологии отсталые (ни в коем случае!), а потому что командо-дни – не унифицированная единица измерения.
Великий Google ничего не выдает толкового по запросам «командо-дни проекта», «командо-дни agile» и так далее. А Google знает все, ну или почти все.
Такая абстрактная единица подходит только для сугубо внутреннего использования команд или для оценок команд универсалов, где все делают всё и взаимозаменяемые. Как только у вас происходит функциональное разделение команды по ролям, а если еще присутствует разделение финансовых ставок по ролям, то командо-дни – это очень сложно конвертируемое оценочное измерение.
Вместо заключения
Качество поставляемых продуктов и услуг всегда зависит от базового фундамента и выстроенных процессов, которые способны обеспечить должный уровень удовлетворения конечного потребителя или пользователя. Уровень качества оценки отображает уровень зрелости процессов управления и планирования разрабатываемых продуктов, и этот уровень невозможно создать без понимания и применения базовых понятий.
Надеюсь, если ваши оценки длительности раньше были в человеко-днях, после прочтения вы сможете делать их корректнее и радовать своих менеджеров и спонсоров проекта.
Как оценить длительность IT-проекта, а когда это вообще не стоит делать
Все хотят знать, сколько времени займёт проект. В этой статье мы объясним, как предоставить менеджеру одновременно точный и неопределённый прогноз, используя время цикла и подсчёт историй, а также дадим советы, когда следует вообще избегать оценки.
Селеста чувствовала давление. Её менеджер Барри хотел составить квартальный прогноз работы её команды. Задача усложнялась тем, что группа Селесты работала не над одним продуктом: Барри хотел получить прогноз сразу по трём. Каждый из них являлся частью другого проекта.
У программистов из группы Селесты не было достаточно информации для составления хоть какого-нибудь прогноза, тем более на целый квартал.
Селеста решила признаться Барри и посмотреть, к чему они придут. Она назначила встречу на следующий день и собрала данные.
Девушка прибыла в офис Барри ровно в 10 утра. Когда она постучала в дверь, Барри всё ещё говорил по телефону. Он жестом попросил её войти и поднял один палец, чтобы дать понять: он будет готов через минуту.
Она села в кресло для посетителей напротив его стола.
Барри повесил трубку и повернулся: «Что ж, обсудим сроки проектов, так?»
Селеста кивнула и сказала: «Да. Кажется, вот что можно сделать в такой ситуации».
Барри нахмурился: «Кажется? Мне нужны конкретные обязательства. Никаких „кажется”!»
Селеста села поудобнее: «Барри, на тебя давят, чтобы выпустить эти три продукта?»
«Как ты узнала? — Барри покачал головой. — Если послушать ребят из продаж и маркетинга, то случится катастрофа, если мы сейчас их не выпустим. Не знаю, что им ответить, кроме того, что всё будет».
«Но в прошлом месяце вы же обсуждали портфель проектов, — напомнила Селеста. — Я думала, продукт А был главным приоритетом».
«Так и есть, — сказал он. — И продукты B и C тоже являются главным приоритетом».
Селеста закатила глаза: «Но ты же знаешь, что может быть только один главный приоритет, не так ли?»
«Я это знаю, и ты знаешь, — сказал он. — Но мои коллеги не знают. Мне нужен прогноз, что ты можешь сделать — ну, обязательства — и тогда можно будет немного вздохнуть спокойно».
«Над каким продуктом нам работать в первую очередь?», — спросила Селеста.
«Продукт А, конечно, — сказал он. — Он самый окупаемый».
«Хорошо, вот что мы сделаем, — сказала Селеста. — Мы напряжёмся и выпустим А в течение месяца. Ваша задача — заставить этих милых людей посещать наши презентации каждую неделю. Они должны увидеть, что мы делаем за неделю. Если они не придут на демо, я отказываюсь давать им какую-либо информацию».
Барри откинулся назад: «Погоди. Я понял насчёт демо. А что в остальные два месяца? И почему ты не дашь им никакой информации?»
Селеста сказала: «Если бы мы работали только над одним продуктом, я могла бы рассчитать оценку на основе нашего цикла разработки. Для продукта А мы выпускаем три-четыре истории [код для пользовательских задач] в неделю. Но мы не знаем реального цикла разработки для продуктов B и C».
Барри кивнул: «Почему нет?»
«Продукты B и C запланированы через два и три месяца, — сказала Селеста. — Это довольно далеко для маркетинга. Проблема в том, что чем дальше работа, тем меньше „времени” отдел маркетинга работает с владельцем продукта для уточнения историй. Мы понятия не имеем, какие функции нужно будет реализовать через два и три месяца. Нам пришлось бы делать научно обоснованные предположения на пустом месте (scientific wild-ass guess, SWAG). Это нормально, мне нравится заниматься этим со своими ребятами, но нам нужно больше конкретики. Которой нет».
«Так почему ты ничего им не скажешь, если они не придут на демонострацию?» — спросил Барри.
«Если для них недостаточно важно наблюдать наш прогресс и обеспечить обратную связь, то им не слишком важна оценка по срокам, — сказала Селеста. — Они хотят, чтобы мы взяли на себя обязательства, не давая своих обязательств взамен. Почему я должна тратить время на оценку, если они не хотят вносить свой вклад?»
Барри согласился «продать» месячный «таймбокс» менеджерам, которые давят на него по установке сроков. Селеста будет следить, что команда сосредоточилась только на продукте A. И она назначила еженедельные встречи для демонстраций, чтобы команда показала свою работу и получила обратную связь.
Был бы у вас соблазн сделать всё иначе?
Оценка сроков — нетривиальная работа
Оценка сроков — это тоже работа. Многие команды закладывают проведение такой проуедуры в свой регулярный рабочий график. Тем не менее, точная оценка на квартал часто требует больше часа или двух работы.
Есть как минимум две проблемы оценки квартальной работы. Слишком часто требования не полностью определены и, как с командой Селесты, проведение оценки отрывает команду от срочной работы над проектом.
Проблема в том, что планирование разработки ПО не похоже на планирование дорожной поездки. Если в вашем городе больше одного светофора, то вы знакомы с колебаниями трафика. Я живу в пригороде Бостона, откуда поездка в аэропорт может занять и 20, и 90 минут. Чаще всего от 30 до 45 минут. Это существенная вариация для 13-километровой поездки.
И в такой поездке нет никаких инноваций. Я много раз ездила в аэропорт и знаю несколько способов добраться туда. У меня есть мобильные приложения, которые помогают найти самый быстрый маршрут даже по пути. Хотя некоторые варианты чуть более предсказуемые, ни один из них не может гарантировать, что эта конкретная поездка завершится за 20 минут.
Поездка в аэропорт происходит по предопределённому маршруту и с хорошо понятными препятствиями. Но разработка продукта — совсем другое дело. Это инновации. Другими словами, раньше мы не делали ничего подобного. Если бы было иначе, то нам не пришлось бы писать новое приложение или обновлять устаревшую систему — мы бы использовали старую.
Для разумной оценки у нас несколько вариантов. На самом деле три:
Какой прогноз нужен менеджеру?
Я заметила, что менеджерам часто нужна оценка порядка величины. В этом случае команда может сделать прогноз и сообщить его следующим образом:
«Мы считаем, что этот проект займёт пять месяцев с 50% уверенностью в точности этого прогноза. В оценке восемь месяцев мы уверены на 80%. Десять месяцев — это 90% уверенности».
Это помогает менеджерам понять, что существует диапазон доверия. Если они хотят 100% уверенности, то для этого может потребоваться срок более 14 месяцев.
Можете использовать метод спирали: «Мы ориентируемся на первый квартал следующего года. Не знаем, когда именно в первом квартале, но думаем, что справимся». По мере продвижения проекта уточняете: «Обновляем оценку на срок где-то между серединой января и серединой марта». Узнав ещё больше, говорите: «Где-то в феврале, если не случится метели». Потом в январе можете сказать: «Третья неделя февраля».
Я бы ещё рекомендовала диапазон из трёх дат: «Оптимистичная дата — январь. Самая реалистичная — конец февраля. Самая пессимистичная — конец апреля».
В любом случае никогда не давайте однозначной оценки. Это искушает Святого Мерфи (из закона Мерфи) заняться вашим проектом и наделать гадостей.
В некоторых случаях и в некоторых командах заказчику могут потребоваться дополнительные сведения. Здесь вы можете обсудить с ним конкретные реализуемые функции, чтобы понять неопределённости.
Используйте время цикла вместо оценки
Я вообще не люблю прогнозы по сроку выполнения программных проектов или других IT-проектов, особенно Agile. Вместо этого предпочитаю, чтобы команда выпускала очень маленькие истории или оценивала работу по времени цикла.
Если вы не знакомы с терминологий:
В случае Селесты она знала, что команда может выпускать от трёх до четырёх историй в неделю для продукта A. Для многих команд подсчёт историй работает так же, как другие методы оценки.
Если команда никогда не работала над подобным продуктом, то предыдущее время цикла не будет применимо к этому новому продукту. Команда может не знать, как уточнять и дробить истории, чтобы выпускать по нескольку в неделю. Кроме того, она может не знать о состоянии кода и наличии достаточного количества тестов. Если ваша команда работает над историями больше трёх дней, не утруждайте себя прогнозом. Сосчитайте истории и не пытайтесь сделать больше, чем обычно.
Когда команда начала справляться с историями за один-два дня, вы тоже не обязаны делать оценку. Часто простой подсчёт легче и более точен.
Почему бы не использовать скорость?
Вы заметили, что я рекомендую время цикла и подсчёт историй, а не скорость работы для оценки времени проекта. Потому что скорость — суррогатная величина.
Например, я каждый день хожу пешком, чтобы поддерживать себя в форме. Я иду по тому же маршруту каждый день, отслеживая свою относительную скорость. В хороший солнечный день я прохожу около 5,6 км в час. В дождливый или жаркий и влажный день скорость падает до 4 км/ч. В снег или гололёд могу вообще не выйти на улицу, в этом случае моя скорость равна 0.
Я иду по тому же маршруту. (Да, это скучно, но это моя проблема). Хотя я прохожу одинаковое расстояние, дорога занимает разное время в зависимости от условий. Здесь условия аналогичны кодовой базе и тестам вашей команды.
Если истории достаточно малы, скорость соответствует времени цикла. Но слишком часто менеджеры пытаются дать оценку для проектов с очень большими историями. Подсчёт будет проще: «Мы можем закончить одну или две истории за цикл. Какую одну или две истории вы хотите выбрать?»
Отказаться от оценки — это не обман
Когда Барри обсудил вопросы с коллегами, один из них заявил: «Отказаться от оценки сроков — это жульничество!»
Барри ответил: «Неправда. Вы же хотите, чтобы мы выпустили продукт, верно?»
Ответ был «Конечно. И B, и C».
«Проблема в том, что их нужно делать по очереди, — ответил Барри. — Если вам так нужен продукт А, какой смысл делать прогноз по остальным? Мы можем приступить к работе и показать наш прогресс. Когда мы сделаем достаточно, то повторим процедуру для B и C. К тому же, у вас будет время уточнить требования для B и С, чтобы подготовить нам истории».
Команда Селесты завершила основную часть проекта А за один месяц. Выпуск продукта B занял больше времени — ближе к двум месяцам. И поскольку компания получила достаточный доход от выпуска продуктов А и В, то снизила давление по выпуску продукта С.
Знайте, какая оценка нужна вашему менеджеру. Преподнесите её так, как ему нужно. И если у вас мало времени, приступайте к работе.