Оценка программного проекта. Откуда берутся ошибки в оценках.

26.11.13

Управление проектом

Продалбливать оценки свойственно не только в области IT. Вспомним хотя бы строительство объектов олимпиады или строительство стадиона для одной команды из Спб, когда проекты только дорожали из года в год. Откуда же берутся ошибки в оценке?

"Бессмысленно требовать точных формулировок, если вы даже не знаете, о чем идет речь."

Джон фон Нейман

В предыдущих сериях: Введение

Ошибки, закрадывающиеся в оценки идут из четырех общих источников

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

Источники неопределенности в оценках

Сколько стоит построить новый дом? Это зависит от дома. Сколько будет стоить внедрение 1Ски? Зависит от внедрения. Пока все специфические особенности не будут понятны – невозможно оценить стоимость.

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

  • Проверять номер на действительность?
  • Можно ли воспользоваться готовой системой для проверки или нужно писать свою?
  • Если готовую, то подороже или подешевле?
  • Если клиент выбрал подешевле, то не захочет ли он потом переключиться на подороже?
  • Как будет спроектирована система проверки? (разные проектные версии одной функции могут отличаться по сложности на порядок и больше)
  • Сколько времени потребуется на программирование? (разным программистом нужно разное время)
  • Нужно ли интегрировать эту проверку в подсистему контактной информации? И сколько займет времени эта интеграция?
  • Какой уровень качества необходим?
  • Сколько уйдет времени на багфикс и тестирование?

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

Конус неопределенности

Чем больше мы делаем проект, тем меньше неопределенности остается.

Как видно из графика, оценки, созданные на очень ранней стадии проекта, подвержены высокой степени ошибок. Оценки, созданные на стадии исходной концепции, могут отличаться в большую или меньшую сторону до 4 раз. То есть полный диапазон от верхней до нижней оценки 4х/0.25х = 16 раз!

Но не надо думать, что это правдивые цифры. Это средняя температура по больнице. У вас разброс может быть как больше, так и меньше. Причем диапазон разброса характеризуется уровнем технологий. Поэтому у вас легко может быть на одном проекте старт с 2/0.5 и нормальный финиш, а на другом конус расширяется вообще (а может у вас CMMI 5го уровня и вы тут вообще ржоте от таких коэффициентов)…

Руководство и клиенты могут задать вопрос: «Если дать еще неделю на оценку, сможете ее уточнить так, чтоб снизить степень неопределенности?». Вопрос, конечно, логичный, но ответ «Нет». Оценку получится уточнить только уменьшив неопределенность, а не посидев побольше с текущей неопределенностью.

И не надейтесь, что конус будет сужаться сам по себе. Для того, чтоб он сужался, нужно уменьшать неопределенность на проекте – нужно принимать решения, уточнять, что продукт должен делать, а что не должен делать…

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

Ну и классическая ошибка: давать обещания на ранней стадии конуса неопределенности. Слишком велики риски промахнуться (где то в 4 раза в каждую сторону).

Хаотические процессы разработки

Конус показывает динамику неопределенности в хорошо управляемых проектах. Плохое управление проектом добавляет дополнительную неопределенность – факторы хаоса. Типичные примеры:

  • Поверхностный анализ требований
  • Отсутствие участия конечного пользователя в постановке требований
  • Плохое проектирование
  • Плохая методология программирования
  • Недостаточная квалификация персонала
  • Неполное или неумелое планирование проекта
  • Отказ от планирования из-за давления
  • Отсутствие автоматизированной системы контроля исходных кодов
  • Итп

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

Нестабильные требования

Одна из самых часто называемых причин несостоятельности оценки. Нестабильные требования создают 2 специфические проблемы:

  1. Это разновидность хаотических факторов. Если требования не удастся стабилизировать – конус неопределенности не сузится.
  2. Часто изменения не учитываются и проект не подвергается переоценке. И может получиться ситуация: оценка правильная, но из-за нестабильности требований мы продолбали все сроки.

Тут опять же нужно не улучшать способы оценки, а стабилизировать требования и научиться ими управлять.

Пропущенные операции

Оценки часто некорректны, потому что мы тупо не все учли…

Наиболее часты забывания:

 

Необоснованный оптимизм

Стандартные проявления оптимизма:

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

И это не говоря о том, что все программисты-оптимисты.

Субъективность и политика

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

С политикой все понятно – наврятли клиент попросит увеличить время выполнения проекта и бюджет.

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

Импровизированные оценки

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

Вывод: никогда не давайте поспешных оценок.

Это кажется странным, но это одна из самых частых причин ошибок при оценки.

Четкость и точность

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

Например, запись Пи = 3.37883 обладает высокой четкостью, и тот, кто не знает истинного значения Пи решит, что вот оно… Но на самом деле точность этой записи всего лишь один знак.

Если сказать клиенту, что проект займет 395.7 дня, то клиент будет уверен, что через 396 дней у него будет готовый проект. Но это как то сомнительно. Если же сказать «один год» или «13 месяцев», то ожидания будут скорректированы намного лучше.

Прочее

Так же ошибки могут прийти по следующим путям:

  • Незнакомая область деятельности
  • Незнакомая технологическая область
  • Неверное преобразование оцениваемого времени в проектное (например, предположение, что все будут работать на проект 8 часов в день, 5 дней в неделю)
  • Неверное понимание статистических концепций
  • Бюджетные процессы, подрывающие эффективную планку (особенно когда нужно согласовать бюджет в широкой части конуса)
  • Завышенные ожидания от применения новых средств или методов
  • Упрощение оценки при передаче на верхние уровни управления.
  • Итд

Еще раз дам ссылку на смертные грехи при оценке проектов

Далее: Факторы влияющие на оценки

Управление проектом Оценка Прогноз Планирование

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2776    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14308    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5854    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4703    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2749    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4188    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10676    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13093    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. poyson 27.11.13 13:03 Сейчас в теме
Гуд. Спасибо. Примем к сведению. Вроде бы полезно...
2. pumbaE 27.11.13 13:13 Сейчас в теме
Хаотические процессы разработки
...
Отсутствие автоматизированной системы контроля исходных кодов
...


Это про 1С или просто в целом статья?
4. Stepa86 1521 27.11.13 13:20 Сейчас в теме
(2) Это вольный пересказ книги Макконнелла "Сколько стоит программный проект".
Автоматизированный контроль исходников и в 1С применим, как встроенной проверкой конфигурации, так и с помощью конфигурации "Автоматизированная проверка конфигураций". Просто распространения нет
3. tanselja 4 27.11.13 13:16 Сейчас в теме
5. mikmike 8 27.11.13 14:11 Сейчас в теме
Особенно понравились ссылки - прям крупно печатать и вешать на стены :):)
Жду продолжения.
6. DAnry 8 27.11.13 18:55 Сейчас в теме
Интересная и познавательная статья. Поддерживаю.
7. pro-rok 295 27.11.13 20:43 Сейчас в теме
Статья интересная,но у меня только один вопрос, что вы говорите клиентам,когда Вас спрашивают "сколько будет стоить этот проект"??
8. Wooster 27.11.13 22:39 Сейчас в теме
(7) pro-rok, согласно книге Макконнелла и кучи других книг по технологиям разработки ПО и управлению проектами, на такие вопросы следует отвечать :

"Неизвестно :-(".

Сколько таких книг не читал, всяких "дедлайнов, вальсирующих с медведями", там везде один посыл : люди все чудаки, всегда косячат и ошибаются, потому что отовсюду им мешают всяческие риски, потом идет интеллектуальная жвачка, какие именно эти 100500 рисков, потом умные формулы ни о чем, а сколько займет проект- так это фиг его знает :)

Ибо длительность проекта можно оценить только после его окончания.
9. pro-rok 295 28.11.13 08:21 Сейчас в теме
(8) Wooster, (8) Wooster, Я прекрасно понимаю, что следует отвечать, ибо сделал не один проект, но до клиента это донести очень сложно, особенно если лицо принимающее решение не ИТ специалист, а экономист. Они привыкли приобретать товары и услуги для своей компании как в супермаркете, есть описание и стоимость. В такой ситуации существует большой риск упустить интересный проект, так как конкурент может обозначить срок и стоимость, хоть и ошибочно, но он это сделает, заполучит проект и в процессе существует вероятность отжать у клиента дефицит бюджета. Для клиента это тоже не очень приятно, ибо остается чувство что тебя разводят, а коней как известно на переправе не меняют. Вот и получается дилемма, скажи правду и тебя не поймут, наври и получи в последствии недовольного клиента но это в лучшем случае, в худшем придется работать за тот бюджет который обозначил изначально.
Я думаю будет очень полезно придумать маршрут проведения клиента от мысли "Мне нужны сроки и стоимость", до мысли "Я понимаю возникающие неопределенности, каким образом мы можем от них уйти".

Если честно то, вспоминается фильм "Начало", жаль что у нас нет подобных технологий.
10. Stepa86 1521 28.11.13 08:39 Сейчас в теме
(9) цикл статей и книга в целом о том, как оценить размер проекта, бюджет и сроки, а не о том, как вести переговоры с клиентом.

Знать затраты на проект (хотя бы примерно) и исходя из этого договариваться о цене все же лучше, чем торговаться, не представляя, а сколько это на самом деле стоит.
12. Wooster 28.11.13 12:01 Сейчас в теме
>Я прекрасно понимаю, что следует отвечать

(9) pro-rok, коллега, я ничему не пытаюсь учить или объяснять, я написал мнение о книге. Заметьте, эта статья- вторая часть пересказа конкретной книги конкретного автора.

Так вот, про книги. Думаю, что значимость таких книг сильно переоценена. Тут, под первой частью статьи, на хабре, различных других ресурсах, айтишнеги и управленцы любят приводить книги в пример, ссылаться на них, как на некий авторитет и т.д. На мой взгляд, все они- приятная интеллектуальная жвачка для мозга аналитика, прикладного значения в них 0. Как у балета "Лебединое озеро". 1снегу нравится "Лебединое озеро", но оно не спасает его от факапов при внедрении УПП. Спасает только свой предыдущий негативный опыт.

Я считаю, что личный опыт Stepa86, pro-rok и других реальных пацанов в конкретных ситуациях гораздо ценнее, чем эти американские гуру, пишущие красиво и без конкретики,засоряющие голову выдуманными графиками и формулами, которые в жизни не понадобятся.

Вот verter.me (Анлрей Акулов) написал, как его развели с офисом или как лично он проводит обследования, и такого рода кейсы- это 90% того, что реально случается с одинэснегом, а не придуманные американские идеальные теории.

P.S. Это был пост ненависти к книгам, слишком много жизненного времени потерял, читая их, можно было и денег заработать, и собственные скиллы прокачать:)
13. Stepa86 1521 28.11.13 14:05 Сейчас в теме
(12) ну вот именно Макконнелла я считаю тем автором, который всех больше прокачал меня своими книгами. "Совершенный код" вывел мой посредственный уровень программирования на высокий, "Сколько стоит..." научил оценивать, "Профессиональная разработка ПО" прокачала менеджерские навыки...

Опыт и практика крайне важная штука, но без знания теории можно прокачиваться не в ту сторону.

Книги не научили меня всему тому, что я знаю и умею, но они позволили набирать опыт наааамного быстрее, чем это было без них.
14. pro-rok 295 03.12.13 12:05 Сейчас в теме
(12) Wooster, Согласен на 100% с вами.
Я просто высказал мысль, что было бы мне (думаю и многим другим) интересно узнать из опыта других людей.
11. soap 65 28.11.13 10:01 Сейчас в теме
Последнее время клиенты, особенно крупные склонны проводить тендеры на разработку абсолютно всего, при этом четкими т.з. даже и не пахнет. Так что вопросы почем и когда становятся первыми и ни какой формулой с конусом этого не учтешь.
15. oleg212 03.01.14 11:37 Сейчас в теме
Интересная и познавательная статья. Поддерживаю.
Оставьте свое сообщение