Прочитала тут пару статей – Don’t Blink! The Hazards of Confidence в NY Times и Coding, Fast and Slow: Developers and the Psychology of Overconfidence на Hut8Labs о том, почему IT-проекты так часто срывают сроки, и как люди приходят к работе по agile. Все расписано довольно хорошо, хотя местами – спорно. В любом случае – приведу краткую выжимку, полезно посмотреть на это дело под другим углом.
Основной посыл – все и всегда ошибаются при определении сроков, которые потребуются на разработку ПО, и ошибиться в 4 раза – это еще не предел. Причины этого:
- Написание ПО – это изучение чего-то, чего ты еще не знаешь, в процессе этого написания. Создать настолько детальные спецификации, чтобы они снимали все вопросы, были достаточны для того, чтобы объяснить компьютеру, как это делать, и обрабатывали все негативные ситуации, невозможно. Для этого придется именно написать ПО, а не спецификации.
- Самое интересное – все разработчики всегда наступают на эти грабли, но это их упорно ничему не учит. Экспертные оценки, как правило, настолько далеки от реальности, что практически бессмысленны. При этом эксперты, их выдающие, бесконечно уверены в правильности своих оценок, и поколебать эту уверенность невозможно. Даже если им все это рассказать и объяснить на пальцах, продемонстрировать все ранее допущенные ошибки – ничего не изменится.
- Оценками человека управляют 2 системы – аналитическое мышление (требующее громадного количества ресурсов) и мышление на основе опыта. И оценки чаще не делаются не на основе анализа, а на уровне «ощущения». Обычно у человека есть 2-3 персональных «уровня ощущений», например, 3 недели = «в принципе, я знаю как это сделать, много времени не займет», 3 месяца – «блин, выглядит сложным, не знаю, как сделать, но уверен, что за это время разберусь». Ну и в жизни потом 3 недели превращаются в 3 месяца, а 3 месяца – в 1-3 года.
И если вы думаете, что все так просто – надо только начать все анализировать, и оценки станут лучше – поздравляю, вы только что изобрели планирование методом водопада. И мы возвращаемся к тому, с чего начали – написать полную спецификацию и спланировать всю работу можно только после того, как работа сделана. Тем более, что уровень неопределенности в проектах разработки ПО так высок, что никакая аналитическая система с этим никогда не справится на 100%.
Как же можно все-таки использовать интуитивные экспертные оценки? Задайте 2 вопроса:
- Ситуация, в которой сделана оценка – достаточно обычная для того, кто эту оценку делает?
- Есть ли у него/нее возможность быстро получать обратную связь по поводу точности оценки?
Посмотрев на эти вопросы, можно точно сказать, что любой проект длительностью 6-18 месяцев под эти критерии не подходит. Такое окружение не может быть «обычным» и цикл обратной связи слишком длинный, чтобы позволить людям натренировать интуицию.
Практика показывает, что идеальный размер задач, который подходит под эти критерии – это задачи от 0 до 12 часов, которые выполняются немедленно. И тогда все работает по-другому:
- Несмотря на то, что вариабельность все еще высокая, надежды на стабильность окружения гораздо больше, чем в двух проектах по 6 месяцев каждый.
- Можно сделать сотни оценок и получить быструю обратную связь.
- При таком раскладе тренируется интуиция и следующие оценки становятся более достоверными.
Ну и на сладкое – возникает вопрос, почему можно сделать тысячи микро-оценок, но нельзя сложить их в одну и все-таки получить оценку проекта на 6-18 месяцев? Ведь количество задач приведет к усреднению уровня ошибки и в целом все будет похоже на правду? Однако проблема в том, что степень ошибки не ограничена, и она фактически может уйти в бесконечность. Казалось бы, разве может такое быть, что задача, оцененная на 4 часа, в итоге займет 1 или 2 месяца? Конечно, более того – это случается постоянно, например, оказывается другим протокол сервера и это превращается в трехмесячный проект. А ведь вначале это выглядело как задачка на 2 часа, да.
Что остается? Просто признать, что наши оценки всегда ошибочны, и окончательно испортить отношения с бизнесом, постоянно не сдерживая обещаний по срокам? Ключевая вещь, которую нужно понять – сделать точную долгосрочную оценку теоретически невозможно. Как только вы с этим смиритесь, вы сможете ставить реальные задачи, которые, хоть и с трудом, но могут быть достигнуты. А иначе как вы собираетесь требовать с команды разработки, чтобы они сделали то, что вы даже не можете адекватно спланировать?
Вот так мы и подходим к пониманию того, почему принципы гибкой (agile) разработки все больше захватывают мир.
От себя добавлю – описание интуитивных оценок очень хорошо перекликается с понятием «кредита у завтрашнего дня» и еще раз показывает, как хитро устроена наша психика, и почему это нужно учитывать, управляя проектом (любым, не только проектом разработки ПО).
Добавить комментарий