Оценка, цель и обязательство
Оценка– прогноз относительно того, сколько времени или денег потребуется для реализации проекта/задачи. Но оценку постоянно путают с целью и обязательством.
Оценка - это как некоторая функция от задания, если на входе задание1, то на выходе оценка1, задание2 - оценка2. Больше никакие параметры не участвуют. Оценка не зависит от харизматичности консультанта или программиста, не зависит от сроков проекта и нетерпеливости РП/Клиента, не зависит и от мотивации и демотивации. Это всего лишь результат подсчета.
Цель - это то, куда нам надо прийти (что сделать), чтоб получить профит, это сдача макета 20го числа, это получение рабочей сборки продукта в конце этого месяца, это ускорение отчета в 2 раза, это необходимость уложится в бюджет итп. Обычно цель слабо зависит от задания и вообще сперва появляется цель, а уже потом образуются задания.
Обязательство - обещание предоставить требуемую функциональность на согласованном уровне качества к конкретной дате/за конкретное количество часов/конкретное количество денег. Обязательство может совпадать с оценкой, быть больше (добавляем риски, закладываем прибыль) или меньше (политика) и в общем случае оценка и обязательство не равны.
Если у нас происходит такой диалог:
- за сколько сделаешь этот отчет?
- дня за 4
- а чо как долго то? Клиенту он нужен после завтра
- ну я постараюсь успеть, но не могу обещать, что будет работать прям стабильно
Оценки в данном примере нет. Цель – послезавтра, а взятое исполнителем обязательство – сперва 4 дня, а потом - успеть к послезавтра.
Почему нет оценки? Оценка - это всегда вероятностное значение. Шансов, что отчет будет сделан ровно за 4 дня немного (с точки зрения математики вероятность сделать за 4 дня = 0%).
График оценки выглядит вот так:
И когда исполнитель принимает решение, какая вероятность его устраивает и по срезу говорит время – это превращение оценки в обязательство.
Что же делать, если оценка, цель и обязательства расходятся?
Если оценка меньше цели, то все нормально.
Если оценка больше цели, то стоит смотреть диапазон. Быть может мы успеем к цели с вероятностью 70%, что нас может устроить и это и берем за обязательство. Но может быть, что вероятность закончить к цели = 0%. Тут нужно менять задачу, не оценку, а именно задачу, потому что оценка это всего лишь производная от задачи. Нужно дать больше информации по задаче (чтобы уменьшить диапазон), найти альтернативы или готовые компоненты/решения. При невозможности изменить задачу придется менять цель – сдвигать срок, договариваться с клиентом или еще что-нить.
Повторюсь. Если оценка нас не устраивает то мы можем:
1) Принять на себя риски и принять вероятность завершения пониже (меняем обязательство)
2) Изменить входные условия, изменить задачу, найти готовое (меняем оценку через изменение задачи)
3) Договориться с клиентом (изменить цель)
Но что не стоит делать, так это продавливать оценку. Все-таки чаще всего оценку дают программисты – интроверты с проблемами в коммуникациях, а спрашивают консультанты и РП – в рабочие обязанности которых входит проведение совещаний и продавливание своего решения. И получается, что более корректные оценки дают те, кто менее убедителен.
Про другие смертные грехи в оценке можно прочитать тут.
О точности оценки.
Что лучше недооценить задачу или переоценить?
Очевидно, что лучше получить точную оценку, но когда это сложно…
Аргументы против переоценки:
Закон Паркинсона – работа занимает все отведенное ей время
Студенческий синдром – если времени много, то можно попрокрастинировать слегка
Создание давления на разработчиков. При горящих сроках работают вроде б быстрее
Аргументы против недооценки:
Снижение эффективности планирования – возникают ошибки в планировании команды, сроков, контрольных точек, координации.
Сплошь оптимисты – по статистике разработчики оценивают объем работы на 20-30%, если еще и недооценивать это…
Плохая техническая база – начинаем торопиться на начальных этапах, плохо подготавливаясь к проекту, плохо собирая требования, плохо анализируя возможные решения, в итоге страдает архитектура и есть шансы потом все переделывать
Доп. действия при отставании – приходится тратить больше времени на пересогласования, на отчеты перед руководителями, переоценки, выбор требований, которые попадут в релиз, вместо того, чтоб сделать все, переделка…
Сравнивая аргументы достаточно очевидно, что лучше перебздеть, чем недобздеть. Особенно учитывая, что закон Паркинсона не доказан научно, и не несет доп. ущерба, студенческий синдром можно срезать с помощью буферов, а давить на разработчиков - плохо.