Почему сформировались именно такие три комбинации? Почему нельзя зафиксировать всё? Ведь самое простое – зафиксировать бюджет, объём работ, дату релиза и внутреннее качество системы, подписать договор (если заказчик внутренний, то пройти процедуру согласования у стейкхолдеров) и выполнить работу с точным попаданием во все четыре величины. Как показывает практика, есть фундаментальная проблема, которая не даёт с лёгкостью пройти этот путь без искажений.

Ни у кого не возникает проблем с расчётом бюджета, довольно легко высчитать дату релиза и есть множество метрик и чек-листов, чтобы задать конкретный уровень качества IT-продукта. Всё просто, если вы можете точно оценить объём работ. Другими словами, если есть детальный список задач и точная оценка этого объёма работ, то остальные три величины считаются легко. И наоборот, если точной оценки нет, то остальные величины тоже будут неточны, потому что основываются на оценке объёма работ.

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

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

Третий фактор заключается в отсутствии критериев для определения достижения полноты объёма работ. Иными словами, написание ТЗ невозможно закончить, его можно только остановить (раздел l, глава 5).

Надо оговориться, что всё это справедливо, если вы работаете в достаточно сложной области: в Cynefin framework это области Complex и Complicated. Если же ваш проект попадает в Obvious и при этом он довольно короткий, то объём работы вы, скорее всего, оцените очень точно.

Итого: корень проблемы в неточной оценке объёма работ и практической невозможности сделать эту оценку точной. Поэтому:

1. В Fixed price-проектах жертвуют внутренним качеством системы, ведь попасть в оценку с тремя фиксированными вершинами почти невозможно. Либо в тех же Fixed price-проектах перезакладывают в бюджет столько рисков, чтобы покрыть вообще любые неточности оценки, что является неэффективным.

2. В T&M легко уйти в неэффективное управление ресурсами, ведь постоянно отслеживать раздувание объёма работ и обрезать его довольно сложно. Нужны правильные инструменты и очень сильные Product Owner'ы.

3. FFF заранее принимает, что объём работы не предсказать, но исходит из предварительных цифр в сроках и бюджете, чтобы избежать проблем T&M.