gifts2017

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

Опубликовал Антон Степанов (Stepa86) в раздел Управление - Управление проектом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочее

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

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

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

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


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

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

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

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

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

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

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

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

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

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

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

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

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