Почему сформировались именно такие три комбинации? Почему нельзя зафиксировать всё? Ведь самое простое – зафиксировать бюджет, объём работ, дату релиза и внутреннее качество системы, подписать договор (если заказчик внутренний, то пройти процедуру согласования у стейкхолдеров) и выполнить работу с точным попаданием во все четыре величины. Как показывает практика, есть фундаментальная проблема, которая не даёт с лёгкостью пройти этот путь без искажений.
Ни у кого не возникает проблем с расчётом бюджета, довольно легко высчитать дату релиза и есть множество метрик и чек-листов, чтобы задать конкретный уровень качества IT-продукта. Всё просто, если вы можете точно оценить объём работ. Другими словами, если есть детальный список задач и точная оценка этого объёма работ, то остальные три величины считаются легко. И наоборот, если точной оценки нет, то остальные величины тоже будут неточны, потому что основываются на оценке объёма работ.
С оценкой объёма работ всегда проблемы: методики, с помощью которой можно было бы сделать оценку с приемлемой точностью, не существует. Все методики опираются на предыдущий опыт команды, которая делала похожие вещи, что подразумевает неточности, потому что люди неточны: эмоциональны, оптимистичны, забывчивы. Отсутствие методики точной оценки – первый фактор, мешающий оценить объём работ.
По ходу работы над IT-продуктом меняются: список задач, глубина их проработки, подход к проектированию системы. Плюс воздействие внешней среды: изменения на рынке, в стратегии и политике компании, обратная связь от пользователей, новые вводные от тех, кто на этапе аналитики промолчал, а впоследствии решил высказаться, и так далее. Наша невозможность влиять на внешние воздействия – второй фактор, мешающий изначально попасть в оценку.
Третий фактор заключается в отсутствии критериев для определения достижения полноты объёма работ. Иными словами, написание ТЗ невозможно закончить, его можно только остановить (раздел l, глава 5).
Надо оговориться, что всё это справедливо, если вы работаете в достаточно сложной области: в Cynefin framework это области Complex и Complicated. Если же ваш проект попадает в Obvious и при этом он довольно короткий, то объём работы вы, скорее всего, оцените очень точно.
Итого: корень проблемы в неточной оценке объёма работ и практической невозможности сделать эту оценку точной. Поэтому:
1. В Fixed price-проектах жертвуют внутренним качеством системы, ведь попасть в оценку с тремя фиксированными вершинами почти невозможно. Либо в тех же Fixed price-проектах перезакладывают в бюджет столько рисков, чтобы покрыть вообще любые неточности оценки, что является неэффективным.
2. В T&M легко уйти в неэффективное управление ресурсами, ведь постоянно отслеживать раздувание объёма работ и обрезать его довольно сложно. Нужны правильные инструменты и очень сильные Product Owner'ы.
3. FFF заранее принимает, что объём работы не предсказать, но исходит из предварительных цифр в сроках и бюджете, чтобы избежать проблем T&M.
А может, вообще не оценивать?
Если оценить объём работ с достаточной точностью нельзя, то, может, вообще этим не заниматься? Есть такое движение #NoEstimates. Если коротко, то мы организуем процесс разработки так, чтобы максимально эффективно проводить задачи от этапа идеи до релиза и при этом сохранять высокое внутреннее качество. Организовывать процесс предлагают по Kanban с отслеживанием метрик обработки потока и особым вниманием к улучшению процесса доставки новых фич. Преждевременные оценки считаются вредными, оценка и грумминг бэклога – потеря времени.
Где узнать больше о #NoEstimates:
1. Об этом много рассказывает Дэвид Андерсон, например, в выступлении The Alternative Path to Enterprise Agility[50].
2. Рассказывал Асхат Уразбаев на AgileDays в выступлении #NoEstimates: Безоценочная разработка[51].
3. Писал Рон Джеффрис в статье «Some Thoughts on Estimation»[52].
Я двумя руками за этот подход. Он близок мне как инженеру и руководителю. Но жизнь так устроена, что владельцам бюджета нужна оценка, хотя бы на первых этапах работы, пусть даже примерная. В Byndyusoft мы иногда переходим к #NoEstimates, но только после довольно длительных отношений с заказчиком, и происходит это далеко не всегда.
FFF – баланс гибкости и предсказуемости
Оценки, хоть и портят жизнь и являются потерей времени, но без них сложно начинать работу. При этом ясно, что никакая оценка не будет точной. Получается, что лучший вариант – зафиксировать срок и бюджет, чтобы бизнес смог с этим жить, а объём работы оставить плавающей величиной. А ещё заказчик и исполнитель должны договориться: в каждый момент времени команда занимается только самыми важными и нужными задачами, а заказчик уделяет время выбору актуальных приоритетов.
Внутреннее качество системы
Как я писал выше, работать по FFF можно, если в компании есть компетентные разработчики, которые способны обеспечить высокое внутреннее качество системы. Обычно это достигается автоматизацией всего и вся, составлением чек-листов с лучшими практиками, постоянным ревью кода и архитектуры, всеми видами тестирования и, самое главное, набором правильных людей в команду.
Почему не стоит забывать о внутреннем качестве, написано в блоге Мартина Фаулера в статье «Is High Quality Software Worth the Cost?»[53] и девятой главе первого раздела данной книги. Если коротко, то при FFF предполагаются изменения в направлении развития продукта, а это подразумевает достаточную гибкость системы. Если качество системы низкое, то каждый шаг в сторону будет замедлять разработку и увеличивать её стоимость вплоть до полной остановки проекта.
Если вы хотите работать по FFF, то заложите критерии качества в контракт, чтобы зафиксировать их наверняка.
Мотивация заказчика и исполнителя
Работа по FFF даёт правильную мотивацию со стороны заказчика и исполнителя. В отличие от Fixed Price, где заказчик и исполнитель общаются через интерфейс контракта, и в отличие от T&M, где заказчик может потерять границы и потратить больше, чем нужно, – в FFF всем приходится вкладываться в коммуникации и жить в проекте, чтобы сделать самое важное и при этом выполнить условия контракта.
Выбираем FFF
Fixed price и T&M имеют свои преимущества в определённых контекстах:
1. Если вы участвуете в тендере и обязуетесь выполнить конкретную работу за оговорённое время и деньги, при этом коммуникация по большей части выстроена через договор подряда, скорее всего, лучшим вариантом будет Fixed price.
2. Если заказчик точно знает, что ему нужно, и умеет эффективно выстраивать процесс работы, то ему достаточно купить ресурсы по T&M и распоряжаться ими на своё усмотрение.
Тем не менее при прочих равных мы стараемся выбирать FFF. Этот подход кажется наиболее сбалансированным: он снижает риски заказчика и исполнителя, создаёт нужную мотивацию с обеих сторон и заботится о внутреннем