Оценка программного проекта. Введение

Оценка, цель и обязательство

Оценка– прогноз относительно того, сколько времени или денег потребуется для реализации проекта/задачи. Но оценку постоянно путают с целью и обязательством.

Оценка — это как некоторая функция от задания, если на входе задание1, то на выходе оценка1, задание2 — оценка2. Больше никакие параметры не участвуют. Оценка не зависит от харизматичности консультанта или программиста, не зависит от сроков проекта и нетерпеливости РП/Клиента, не зависит и от мотивации и демотивации. Это всего лишь результат подсчета. 

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

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

 

Если у нас происходит такой диалог:

— за сколько сделаешь этот отчет?

— дня за 4

— а чо как долго то? Клиенту он нужен после завтра

— ну я постараюсь успеть, но не могу обещать, что будет работать прям стабильно

Оценки в данном примере нет. Цель – послезавтра, а взятое исполнителем обязательство – сперва 4 дня, а потом — успеть к послезавтра.

Почему нет оценки? Оценка — это всегда вероятностное значение. Шансов, что отчет будет сделан ровно за 4 дня немного (с точки зрения математики вероятность сделать за 4 дня = 0%).

График оценки выглядит вот так:

 

И когда исполнитель принимает решение, какая вероятность его устраивает и по срезу говорит время – это превращение оценки в обязательство.

Что же делать, если оценка, цель и обязательства расходятся?

Если оценка меньше цели, то все нормально.

Если оценка больше цели, то стоит смотреть диапазон. Быть может мы успеем к цели с вероятностью 70%, что нас может устроить и это и берем за обязательство. Но может быть, что вероятность закончить к цели = 0%. Тут нужно менять задачу, не оценку, а именно задачу, потому что оценка это всего лишь производная от задачи. Нужно дать больше информации по задаче (чтобы уменьшить диапазон), найти альтернативы или готовые компоненты/решения. При невозможности изменить задачу придется менять цель – сдвигать срок, договариваться с клиентом или еще что-нить.

Повторюсь. Если оценка нас не устраивает то мы можем:

1)      Принять на себя риски и принять вероятность завершения пониже (меняем обязательство)

2)      Изменить входные условия, изменить задачу, найти готовое (меняем оценку через изменение задачи)

3)      Договориться с клиентом (изменить цель)

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

Про другие смертные грехи в оценке можно прочитать тут.

 

О точности оценки.

Что лучше недооценить задачу или переоценить?

Очевидно, что лучше получить точную оценку, но когда это сложно…

Аргументы против переоценки:

Закон Паркинсона – работа занимает все отведенное ей время

Студенческий синдром – если времени много, то можно попрокрастинировать слегка

Создание давления на разработчиков. При горящих сроках работают вроде б быстрее

Аргументы против недооценки:

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

Сплошь оптимисты – по статистике разработчики оценивают объем работы на 20-30%, если еще и недооценивать это…

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

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

 

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

 

Далее: Откуда берутся ошибки в оценке