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

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

Меня зовут Александр Катруша, я работаю Senior Engineering Manager в компании Innovecs. Большую часть своей карьеры я занимался разработкой и внедрением ERP-систем, а также оценкой и управлением соответствующих проектов. И хотя тема оценки проектов неисчерпаема, как атом, надеюсь, мой опыт пригодится многим коллегам. Особо ценны будут советы, что делать и чего не делать, как избежать типичных ошибок в оценке и ее коммуникации.

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

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

Терминология

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

  • скоуп (англ. scope) — содержание проекта, рамки проекта, объем работ;
  • assumptions — допущения, предположения;
  • contingency — риск.

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

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

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

Когда и зачем нужна оценка проектов

Неопределенность

Одна из базовых проблем оценки — противоречие между принципиальной неопределенностью будущих параметров проекта и необходимостью принятия решений здесь и сейчас. Мы живем в мире годовых бюджетных циклов, тендеров, ROI, time-to-market и прочих практик и концепций, которые вынуждают принимать инвестиционные решения как можно раньше в жизненном цикле проекта, то есть именно тогда, когда риски недооценки или переоценки самые большие.

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

Когда нужна оценка

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

  1. Переговоры с клиентом о новом проекте либо фазе проекта.
  2. Ответ на RFP либо участие в тендере.
  3. Планирование бюджета и прочих ресурсов организации, например, календарное.
  4. Расчет ROI проекта в ходе принятия принципиального решения о его запуске.

Если оценка нужна прямо сейчас

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

  1. Используя свой опыт предыдущих проектов, описать и оценить максимальный теоретически возможный скоуп, вплоть до легкой степени абсурдности. Но так, чтобы за каждым числом было пусть и слабое, но обоснование. После легкого шока, как правило, заказчик оценки становится более сговорчивым насчет предоставления необходимых входных данных, времени и ресурсов на оценку.
  2. Дать интервал оценки от и до, подчеркивая неопределенность и уровень риска, присущий проекту на этой стадии. Это позволит стейкхолдерам проекта принимать более осмысленные решения по принятию рисков.
  3. Двигаться итеративно, по пути уточняя прогнозные цифры.

Цели

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

  1. Определить и ограничить рамки проекта (scope) и зафиксировать предположения (assumptions), при которых оценка актуальна.
  2. Определить цену и себестоимость проекта на основе трудозатрат.
  3. Обосновать бюджет проекта перед внешними либо внутренними спонсорами.
  4. Получить входные данные для других процессов, таких как:
    • продажа;
    • планирование;
    • наем сотрудников;
    • бюджетирование.

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

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

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

На более же высоком уровне, по утверждению Steve McConnell в его великолепной книге Software Estimation, основная цель оценки — определить, являются ли цели проекта достаточно реалистичными для достижения, то есть стоит ли вообще браться за проект.

Эксперимент

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

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

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

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

Оценщики и исполнители

Идеальный оценщик

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

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

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

Когнитивные искажения, влияющие на оценку

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

Ошибка планирования и оптимизм

Нам хочется думать, что мы лучше других. Поэтому своим задачам, как правило, даем более оптимистичную оценку, чем похожим задачам других людей. Хороший оценщик должен адекватно оценить свои силы и быть готовым сопротивляться приемам психологического давления вроде вопросов «почему так долго?!», спокойно аргументируя свою позицию.

Также всем, даже опытным разработчикам, присущ оптимизм в оценке задач. По эмпирическим данным, разработчики в среднем дают оценки, заниженные по крайней мере на 30%. И этот оптимизм, к сожалению, находит поддержку у менеджеров и других стейкхолдеров проекта.

Ошибки в оценке вероятностей

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

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

Эффект привязки (якорение)

Люди подсознательно стремятся к услышанным или подсказанным кем-то числам. Об этом отлично знают, например, маркетологи. В нашем контексте это может значить, что:

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

Исполнители

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

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

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

Единицы измерения

Трудоемкость vs длительность

Я предпочитаю все задачи и проекты оценивать по трудоемкости (в человеко-часах), а не по длительности (в днях или неделях) по следующим причинам:

  1. На момент оценки команда может быть не набрана или ее состав может измениться в будущем.
  2. Команды часто отвлекаются на другие проекты или задачи.
  3. Из трудозатрат относительно легко получить примерную оценку длительности простым делением на доступные ресурсы.

Длительность при этом более интуитивна и удобна при стабильной команде на коротких отрезках времени.

Человеко-часы, -дни, -недели, -месяцы

Человеко-часы, на мой взгляд, более оптимальны, и вот почему:

  1. Разные люди, страны и компании работают по разным календарям. Рабочие дни и недели могут содержать разное количество рабочих часов, а кто-то из членов команды может работать неполный рабочий день. Это особенно актуально для распределенных команд.
  2. Ставки на разработку на мировом рынке аутсорсинга принято указывать для человеко-часов. Таким образом, простым умножением оценки на ставку можно получить примерный бюджет на работу в деньгах.
  3. Учет рабочего времени, если он есть, ведется в часах. Так будет намного удобнее сопоставлять план с фактом.
  4. Оценки в днях по определению менее точны, чем в часах, и позволяют разработчикам менее ответственно относиться к оценке.

Степени двойки

С учетом выбора человеко-часов в качестве единицы измерения представляется целесообразным использовать степени двойки для оценки конкретных задач. Они достаточно интуитивны, хорошо соответствуют рабочему времени восьмичасового рабочего дня и удобны в расчетах:
  • 0,5–1 ч — время для минимально возможной задачи;
  • 2 ч — время, которое можно комфортно провести за монитором без отвлечения внимания;
  • 4 ч — половина рабочего дня;
  • 8 ч — рабочий день;
  • 16 ч — два рабочих дня;
  • 32 ч — «почти неделя».

При надобности можно использовать и промежуточные числа: 6, 12, 40. Выше 40 ч оценка выглядит не совсем надежной, а задача плохо контролируемой. В таком случае желательно разбиение на подзадачи.

Рабочие часы vs эффективные часы

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

Моя рекомендация — все же оценивать проект в рабочих, то есть астрономических, а не эффективных часах. И главная причина тут проста: сложно объяснить заказчику, почему он платит вам за восемь часов, а работаете вы только шесть... Даже если ваш заказчик — ИТ-компания и «тоже так делает», не стоит давать ему лишний козырь в потенциальных спорах, особенно судебных, которые могут возникнуть в течение жизни проекта. Кроме того, с рабочими часами проще планировать: не нужно вводить дополнительные коэффициенты.

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

Структура оценки

Как мы выяснили в первой части статьи, цель оценки — не только найти трудозатраты, но и описать скоуп, риски, а также правильно преподнести их всем стейкхолдерам проекта. А потому документ «Оценка проекта» как минимум должен содержать:

  1. Скоуп. Что мы оцениваем в виде списка требований, работ и того, что в скоуп не входит.
  2. Предположения и риски. При каких условиях оценка актуальна, и что, по нашему мнению, может пойти не так.
  3. Числа. Сколько трудозатрат потребует сделать 1 при условиях 2.
  4. Упаковка. Last but not least. Правильно преподнести оценку не менее важно, чем качественно оценить, особенно в процессе продажи.

Заметьте, что собственно оценка в виде чисел только на третьем месте, поскольку качественное определение скоупа и предположений намного важнее для успеха проекта, чем точность оценки. Числа неотделимы от того, что и при каких условиях они оценивают. Ошибка в оценке индивидуальной задачи может составить 5%, 10%, пусть даже 50%, и это может быть некритичным для проекта. В то время как неправильная оценка скоупа и рисков может увеличить трудоемкость работ в несколько раз.

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

Заключение

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

LinkedIn

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

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

Спасибо. Примеры из книги Даниила Канемана так удачно вписались.. и таки сразу напоминают примеры из реальности.

Очень хочется прочитать во второй части как эту структуру оценки использовать в неидеальных реальных условиях:
— стоит ли давать оценку, если скоуп меняется почти каждый день? если да, то как?
— как оценивать что не входит в скоуп? насколько широкое это понятие
— на какие риски стоит обратить внимание, а какие игнорировать? если закладывать все-все из предидущего опыта, то задачу на 1 час можно оценить в 40 часов. Уменьшать риски, а потом оценивать или же оценивать с таким огромным разбросом?
— как оценивать задачи, распределенные между разными командами или имеющие зависимости от тех, кто в оценке не участвует?

И будет очень интересно прочитать, что же включают в оценку проекта помимо фазы реализации.
Как оценить запуск, мониторинг проекта, завершение, поддержание и др.

Юля, см. часть 2, можем обсудить что непонятно :)

Саша — ты молодец что взял и написал !

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

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

forasoft.github.io/software-estimation

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

rixtrema.com/...​dent Normal Variables.pdf

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

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

Вадим, спасибо за комментарий. Математика — во второй части, в т. ч. про распределения. Судя по комментарию, близко к вашим рассуждениям. Будет интересно подискутировать. В первой я пока еще ничего не складывал и не вычислял :)

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

В первой я пока еще ничего не складывал и не вычислял :)

Я буду рад приятно удивиться :) К сожалению, я не знаю ни одного инструмента (трекеров типа JIRA, etc), которые бы пытались делать правильную математику. И не видел менеджеров, которые бы пытались это учитывать корректно, а не домножением на пи... Вся индустрия так работает. Но может оно и лучшему, так как правильно это делать не получиться, осталось научиться признавать случайность процессов и жить с этим. Детальней в ответе Денису ниже.

Ну гемблинг в оценках — теперь уже достаточно очевидная вещь (#noestimates, cone of uncertainty). Хотя и гемблинг подчиняется теорверу.
Вопрос только в том, кто возьмет на себя риски — заказчик или исполнитель.

Мы пытались — вернее, почему пытались? — сделали :) правда, в Excel шаблоне.

Будет интересно почитать вторую часть и сравнить наш подход с тем, что предложит Александр.

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

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

www.youtube.com/watch?v=QVBlnCTu9Ms

Процесс очень простой — бейте работу на сравнительно малые таски/сторисы и умножайте число задач на среднее время обработки таски (взятое оценочно или на основание истории работы команды). Всё! Это оценка на 90% совпадает с тем, что люди получают играясь в покеры или требуя детально эстимировать каждую задачу.

Разбить на мелкие таски можно только то, что уже пару раз делал ранее. Если проект RnD — таски очень крупные и неопределенные до того, как их взяли в работу. А оценивать объем проекта как-то надо, хоть с потолка.

ИМХО весьма наивно со стороны Allen Holub делать проекцию по кол-ву сторей. Выполненная сторя != сторя в беклоге. В процессе работы они, как правило, дробятся.

Ниже стало понятно о чем ты. Скажу сразу чушь это.
Вот не надо пытаться для понтов присобачить не подходящую математику туда, где она по определению неприменима. Точнее применима и даже может позволить тебе оценить ошибку оценки. Но что тебе с с этого если ошибка оценки в 10-100 раз больше самой оценки?

Кратко — гибкие методологии прижились именно потому, что они гибкие и ничего более, в отличие от негибкого вотерфола. А прижились потому, что мир постоянно меняется и даже в локальных промежутках времени.

Дякую, сподобалося.
Все так і буває: якщо скоуп більш/менш зрозумілий — помилка в оцінці проекта на ~500 годин (в мене) не перевищує 10%.

Норм выжимка.

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

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

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

По сути — аджайл/срам — это вотерфал на 2-х недельных промежутках. Это уже предельная и часто идиотская реализация процесса разработки.

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