Не мечта ли любого владельца компании управлять IT-продуктом так, чтобы поставлять продукт в срок, обгоняя конкурентов, и делать это с высоким качеством, радуя пользователей? Хотелось бы найти серебряную пулю для управления и, кажется, она есть. Не такая уж серебряная и не такая уж пуля, но довольно надежный и обкатанный годами подход к управлению, который можно назвать FFF: Fix Time and Budget, Flex Scope.

Почему и когда стоит выбрать FFF? Давайте посмотрим.

1. Три комбинации

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


Конкретная комбинация создает определенные условия работы, имеет плюсы и минусы:

1. Fixed price
   
   
   • Зафиксированы три точки проектного треугольника: срок, деньги и объем работы.
   • Основные риски берет на себя исполнитель и, как следствие, эти риски отражаются на оценке. Кроме этого создаются риски и для заказчика, об этом я писал в статье 12 проблем при работе по техническому заданию в IT-продукте.
   • Большим плюсом этого подхода является предопределенные до начала работ параметры проекта. Очень часто бизнесу/государству нужно прописать в договоре срок, деньги и объем работы.
   • Внутреннее качество при этом редко фиксируют. Зато почти всегда именно качеством жертвуют, чтобы в нашем изменчивом мире умудриться попасть в срок с фиксированным объемом работы. Почему так происходит и что является корнем проблемы, обсудим чуть дальше.
   • Оплата происходит в конце проекта с возможной предоплатой в начале.
2. Time and Materials (T&M)
   
   
   • Зафиксированы деньги и внутреннее качество системы, хотя вторым частенько пренебрегают из-за халатности или неопытности с обеих сторон.
   • Заказчик берет в аренду ресурсы исполнителя по фиксированной ставке и управляет ими по своему усмотрению.
   • Исполнитель отвечает за то, чтобы дать максимально качественный продукт за счет своей компетенции.
   • Оплачивается при этом время, которое сотрудники исполнителя были заняты на проектах заказчика. Это происходит в конце отчетного периода, например, раз в месяц.
   • Основные риски берет на себя заказчик.
   • Если у заказчика есть четкое понимание задач и организован контроль работы (в том числе собственных ресурсов, особенно Product Owner'а), то это самый оптимальный и быстрый вариант управления, потому что он наименее бюрократизирован, соответственно, все занимаются только разработкой без лишних отвлечений на ритуалы согласований.
3. Fix Time and Budget, Flex Scope (FFF)
   
   
   • Зафиксированы три точки проектного треугольника: срок, деньги и внутреннее качество системы.
   • Оплата происходит в конце проекта с возможной предоплатой в начале.
   • В контракте описываются задачи, но достаточно высокоуровнево, чтобы можно было флексить объем работы без переписывания контракта.
   • Объем работы обговаривается в начале проекта, но является предметом для изменения.
   • Во время разработки нужно следить за сжиганием бюджета, приближающимся сроком релиза и оставшимися задачами, чтобы всё самое важно успеть к сроку. Глубина проработки задач и конечный список этих задач могут менять во время работы прямо на планированиях или стендапах.
   • Риски делятся поровну: разработчики обязуются поставить ценность в срок и бюджет, а заказчик старается выбрать/урезать задачи, исходя из приоритетов бизнеса и текущей ситуации.
   • Внутреннее качество системы становится очень важным, т.к. объем работ может поменяться при этом срок и бюджет двигать никто не собирается. Поэтому код, тесты, внутренний дизайн, архитектура и автоматизация должны быть высокого качаства, иметь гибкость и, в итоге, помогать быстро подстраиваться под любые изменения.

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

2. Корень проблемы

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

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

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

Подробнее об этой проблеме я писал в статье Customer satisfaction для программистов: Все программисты — оптимисты. Там есть ссылка на доклад 36 от Вадима Макишвили, где он предлагает просто умножать оценку на 3. С помощью метафоры прокладывания и прохождения маршрута написано в статье Почему проекты в IT занимают в 2-3 раза дольше, чем планируется?.

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

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

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

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

• В Fixed price проектах жертвуют внутренним качеством системы, ведь попасть в оценку с тремя фиксированными вершинами почти невозможно. Либо в тех же Fixed price проектах перезакладывают в бюджет столько рисков, чтобы покрыть вообще любые неточности оценки, что является неэффективным.
• В T&M легко уйти в неэффективное управление ресурсами, ведь постоянно отслеживать раздувание скоупа и обрезать его довольно сложно. Нужны правильные инструменты и очень сильные Product Owner'ы.
• FFF заранее принимает, что объем работы не предсказать, но при этом «забивает колышки» на сроке и бюджете, чтобы избежать проблем T&M.

3. А может вообще не оценивать?

Если оценить объем работ нельзя с достаточной точной, то может вообще этим не заниматься? Есть такое движение #NoEstimates. Если коротко, то мы организуем процесс разработки так, чтобы максимально эффективно проводить задачи от этапа идеи до выкатки в прод и при этом сохранять высокое внутреннее качество. Организовывать процесс предлагают по Kanban с отслеживанием метрик обработки потока и особым вниманием к улучшению процесса доставки новых фич. Преждевременные оценки считаются вредными, оценка и грумминг бэклога – потеря времени.

Где узнать больше о #NoEstimates:

1. Об этом много рассказывает Дэвид Андерсон, например, в выступлении The Alternative Path to Enterprise Agility.
2. Рассказывал Асхат Уразбаев на AgileDays в выступлении #NoEstimates: Безоценочная разработка.
3. Писал об этом Рон Джеффрис в статье Some Thoughts on Estimation.
4. На Хабре об этом писал Денис Стебунов в статье Об оценках сроков в разработке ПО.

Я двумя руками за этот подход. Он мне нравится, как инженеру и как руководителю. Но жизнь так устроена, что владельцам бюджета нужна оценка, хотя бы на первых этапах работы, хотя бы примерная. В Byndyusoft мы иногда переходим к #NoEstimates, но только после довольно длительных отношений с заказчиком и происходит это далеко не всегда.

4. FFF – баланс гибкости и предсказуемости

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

Первый раз я увидел описание FFF в книге Getting Real от 37signals в главе Fix Time and Budget, Flex Scope. На данный момент в моей компании это самый популярный подход к работе, им довольны и заказчики, и мы.

5. Внутреннее качество системы

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

Почему не стоит забывать о внутреннем качестве, написано в блоге Мартина Фаулера в статье Is High Quality Software Worth the Cost?. Я писал об этом в статье Определение провала IT-проекта. Если сказать коротко, то при FFF предполагаются изменения в направлении развития продукта, а это подразумевает достаточную гибкость системы. Если качество системы низкое, то каждый «поворот» будет замедлять разработку и увеличивать ее стоимость, вплоть до полной остановки проекта.

Если вы хотите работать по FFF, то заложите критерии качества в контракт, чтобы зафиксировать их наверняка.

6. Мотивация заказчика и исполнителя

Работа по FFF дает правильную мотивацию со стороны заказчика и исполнителя. В отличие от Fixed Price, где заказчик и исполнитель общаются через интерфейс контракта, и в отличие от T&M, где заказчик может потерять границы и потратить больше, чем нужно; в FFF всем приходится вкладываться в коммуникации и «жить» в проекте, чтобы сделать самое важное и при этом удовлетворить условия контракта.

7. Выбираем FFF

Fixed price и T&M имеют свои преимущества в определенных контекстах:

1. Если вы участвуете в тендере и обязуетесь выполнить конкретную работу за оговоренное время и деньги, при этом коммуникация по большей части выстроена через договор подряда, скорее всего, лучшим вариантом будет Fixed price.
2. Если заказчик точно знает, что ему нужно, и умеет эффективно выстраивать процесс работы, то ему достаточно купить ресурсы по T&M и распоряжаться ими на свое усмотрение.

Тем не менее, при прочих равных мы стараемся выбирать FFF. Этот подход кажется наиболее сбалансированным: он снижает риски заказчика и исполнителя, создает нужную мотивацию с обеих сторон и заботится о внутреннем качестве системы.

Ссылки:

1. Как и какое техническое задание писать при работе по Agile.
2. Принцип управления проектами в дизайн-бюро Артёма Горбунова.