"Бессмысленно требовать точных формулировок, если вы даже не знаете, о чем идет речь."
Джон фон Нейман
В предыдущих сериях: Введение
Ошибки, закрадывающиеся в оценки идут из четырех общих источников
- Неточная информация об оцениваемом проекте.
- Неточная информация о возможностях организации, которой будет поручено исполнение проекта.
- Чрезмерное усердие, направленное на получение точной оценки (то есть попытки оценить изменяющиеся цели).
- Неточности, обусловленные самим процессом оценки.
Источники неопределенности в оценках
Сколько стоит построить новый дом? Это зависит от дома. Сколько будет стоить внедрение 1Ски? Зависит от внедрения. Пока все специфические особенности не будут понятны – невозможно оценить стоимость.
Допустим, в заказы необходимо вводить телефонные номера. Вот что может повлиять на оценку:
- Проверять номер на действительность?
- Можно ли воспользоваться готовой системой для проверки или нужно писать свою?
- Если готовую, то подороже или подешевле?
- Если клиент выбрал подешевле, то не захочет ли он потом переключиться на подороже?
- Как будет спроектирована система проверки? (разные проектные версии одной функции могут отличаться по сложности на порядок и больше)
- Сколько времени потребуется на программирование? (разным программистом нужно разное время)
- Нужно ли интегрировать эту проверку в подсистему контактной информации? И сколько займет времени эта интеграция?
- Какой уровень качества необходим?
- Сколько уйдет времени на багфикс и тестирование?
И это только по одному требованию, а когда их сотни и тысячи – неопределенность на проекте становиться весьма значительной.
Конус неопределенности
Чем больше мы делаем проект, тем меньше неопределенности остается.
Как видно из графика, оценки, созданные на очень ранней стадии проекта, подвержены высокой степени ошибок. Оценки, созданные на стадии исходной концепции, могут отличаться в большую или меньшую сторону до 4 раз. То есть полный диапазон от верхней до нижней оценки 4х/0.25х = 16 раз!
Но не надо думать, что это правдивые цифры. Это средняя температура по больнице. У вас разброс может быть как больше, так и меньше. Причем диапазон разброса характеризуется уровнем технологий. Поэтому у вас легко может быть на одном проекте старт с 2/0.5 и нормальный финиш, а на другом конус расширяется вообще (а может у вас CMMI 5го уровня и вы тут вообще ржоте от таких коэффициентов)…
Руководство и клиенты могут задать вопрос: «Если дать еще неделю на оценку, сможете ее уточнить так, чтоб снизить степень неопределенности?». Вопрос, конечно, логичный, но ответ «Нет». Оценку получится уточнить только уменьшив неопределенность, а не посидев побольше с текущей неопределенностью.
И не надейтесь, что конус будет сужаться сам по себе. Для того, чтоб он сужался, нужно уменьшать неопределенность на проекте – нужно принимать решения, уточнять, что продукт должен делать, а что не должен делать…
При оценке задач можно использовать коэффициенты конуса: определить наиболее вероятный срок и внести поправки, соответствующие текущему этапу проекта или определить наиболее оптимистичный и пессимистичный варианты и с помощью конуса скорректировать их, получив еще и наиболее вероятное.
Ну и классическая ошибка: давать обещания на ранней стадии конуса неопределенности. Слишком велики риски промахнуться (где то в 4 раза в каждую сторону).
Хаотические процессы разработки
Конус показывает динамику неопределенности в хорошо управляемых проектах. Плохое управление проектом добавляет дополнительную неопределенность – факторы хаоса. Типичные примеры:
- Поверхностный анализ требований
- Отсутствие участия конечного пользователя в постановке требований
- Плохое проектирование
- Плохая методология программирования
- Недостаточная квалификация персонала
- Неполное или неумелое планирование проекта
- Отказ от планирования из-за давления
- Отсутствие автоматизированной системы контроля исходных кодов
- Итп
Источники хаоса обладают двумя общими признаками: каждый из них порождает неопределенность, затрудняющую оценку и возникающие под их воздействием проблемы лучше всего решать на уровне управления проектом, а не на уровне оценки.
Нестабильные требования
Одна из самых часто называемых причин несостоятельности оценки. Нестабильные требования создают 2 специфические проблемы:
- Это разновидность хаотических факторов. Если требования не удастся стабилизировать – конус неопределенности не сузится.
- Часто изменения не учитываются и проект не подвергается переоценке. И может получиться ситуация: оценка правильная, но из-за нестабильности требований мы продолбали все сроки.
Тут опять же нужно не улучшать способы оценки, а стабилизировать требования и научиться ими управлять.
Пропущенные операции
Оценки часто некорректны, потому что мы тупо не все учли…
Наиболее часты забывания:
Необоснованный оптимизм
Стандартные проявления оптимизма:
- Над этим проектом мы будем работать более эффективно, чем над предыдущим
- В последние дни все шло наперекосяк. В этом проекте проблем будет меньше.
- Проект начался медленно, и мы прошли трудный начальный период. Тем не менее мы многому научились на своих ошибках, и ближе к концу мы будем работать гораздо эффективнее.
И это не говоря о том, что все программисты-оптимисты.
Субъективность и политика
Субъективность проникает в оценки в форме оптимизма или в форме опыта, сознательного или бессознательного. Субъективизм выражается обычно одной фразой: люди не умеют оценивать.
С политикой все понятно – наврятли клиент попросит увеличить время выполнения проекта и бюджет.
Ну и к субъективизму относятся различные регуляторы и коэффициенты, которые мы подставляем в формулу. Типа уровень компетенции, риски, коммуникации итп. Чем больше таких регуляторов, тем точнее оценка. Наверное. Но на самом деле нет. Каждый такой регулятор вносит долю субъективности и только размазывает оценку. В итоге оценка получается менее точной.
Импровизированные оценки
Идете вы с чашечкой кофе в кабинет, а вас по пути останавливают и спрашивают «Сколько займет времени вкатить подсистему файлов из нового БПС в базу нашего любимого клиента, с которым ты еще не работал?». Вы отвечаете «Ну хз, наверно за день. Надо бы хоть посмотреть, что там и как.» и идете пить кофе. После приятного кофепоглощения с тортиком открываешь базу этого самого клиента и охереваешь от того, что там наворочено, потом смотришь БСП, смотришь все завязки и ссылки на подсистему... В общем выкатить подсистему получится в лучшем случае за месяц, а лучше вообще отказаться от этой затеи. Идешь искать РП… а он выходит счастливый из переговорки и говорит «Так как работа всего на день, мы уже согласовали с клиентом работы и они хотят уже послезавтра показать своему ген. диру новые возможности. Можешь приступить к выкату немедленно?».
Вывод: никогда не давайте поспешных оценок.
Это кажется странным, но это одна из самых частых причин ошибок при оценки.
Четкость и точность
Давая более четкую оценку (количество значащих цифр) мы даем понять, что оценка получена точной. Но далеко не всегда это так.
Например, запись Пи = 3.37883 обладает высокой четкостью, и тот, кто не знает истинного значения Пи решит, что вот оно… Но на самом деле точность этой записи всего лишь один знак.
Если сказать клиенту, что проект займет 395.7 дня, то клиент будет уверен, что через 396 дней у него будет готовый проект. Но это как то сомнительно. Если же сказать «один год» или «13 месяцев», то ожидания будут скорректированы намного лучше.
Прочее
Так же ошибки могут прийти по следующим путям:
- Незнакомая область деятельности
- Незнакомая технологическая область
- Неверное преобразование оцениваемого времени в проектное (например, предположение, что все будут работать на проект 8 часов в день, 5 дней в неделю)
- Неверное понимание статистических концепций
- Бюджетные процессы, подрывающие эффективную планку (особенно когда нужно согласовать бюджет в широкой части конуса)
- Завышенные ожидания от применения новых средств или методов
- Упрощение оценки при передаче на верхние уровни управления.
- Итд
Еще раз дам ссылку на смертные грехи при оценке проектов
Далее: Факторы влияющие на оценки
