Могут ли проекты с фиксированной стоимостью быть гибкими?

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

Для некоторых организаций это реальность. В других, часто приходится бороться с:

• Проектами с фиксированной датой, при которых новый или улучшенный продукт должен быть доставлен к определенной дате.

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

Возможно ли быть гибким (в статье под гибкостью понимается термин agile. Он в большей степени описывает не гибкость как таковую, а адаптивность подходов и образа мышления - прим. пер.), когда ключевые элементы не в зоне вашего влияния? По-моему, это возможно - команды могут быть гибкими, когда срок, содержание или оба могут быть фиксированными.

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

Причина этого в разнице контекста. Для второго проекта несомненно потребуется произвести больше документации; гораздо строже контролировать (или хотя бы документировать) изменения; делать другие вещи, которые снизят гибкость команды.

И это нормально.

Быть гибким- это как быть здоровым. Относительное понятие, на которое влияет множество факторов. Команда может быть более гибкой или менее гибкой, как и вы можете быть более здоровым или менее здоровым.

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

Так как я не могу этого сделать, моя цель - быть настолько здоровым, насколько я могу в рамках моего контекста. Agile команда должна стремиться быть настолько гибкой, насколько позволяет её контекст.

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

Эти проекты не так гибки, как могли бы быть. Но они все равно могут быть гибкими в рамках этого контекста.

Были бы команды, работающие на этих проектах более успешными и способными превысить ожидания клиентов без контрактов, гарантирующих срок поставки объем или и то, и другое? Вполне вероятно. Но это не их контекст. Нельзя закрывать глаза на реальность.

Давайте посмотрим, как проекты с фиксированной стоимостью соотносятся с ценностями Agile Manifesto.

Люди и взаимодействие важнее процессов и инструментов

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

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

Работающее ПО важнее исчерпывающей документации

Вторая ценность Agile Manifesto - работающее ПО важнее исчерпывающей документации. Проекты заказной разработки почти наверняка будут иметь больше документов, чем не контрактные.

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

Сотрудничество с клиентом важнее согласования условий контракта

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

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

Реагировать на изменения важнее следования плану

Последняя ценность Agile Manifesto, "реагировать на изменения важнее следования плану", описывает место, где сотрудничество жизненно важно.

То, как команда и стейкхолдеры обращаются с неожиданными изменениями (или тем, что не было известно на старте), является важным фактором, определяющим будет проект признан успешным или провальным. Мы хотим строить и следовать процессу управления изменениями; это критично важно как для Agile, так и для успешных проектов с фиксированным сроком и содержанием.

Принципы Agile Manifesto

Помимо ценностей, Agile Manifesto включает двенадцать принципов, которые составляют основу ценностей. Я утверждаю, что каждый из двенадцати принципов подходит для проектов с фиксированным сроком и содержанием. Два из них достойны того, чтобы раскрыть подробнее.

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

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

Надо ли говорить, что через несколько месяцев я покинул ту фирму, как только нашел компанию, более заинтересованную в партнерских отношениях с клиентами.

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

Приветствуйте изменения требований

Думаю, один из наиболее важных принципов Manifesto это "Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества".

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

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

Итак, такие проекты гибкие?

Да, они могут быть гибкими.

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

Считайте ограничения пространством, определяющим решение, в котором действует команда. Конечно, есть точка, в которой при слишком большом количестве ограничений, даже Agile не поможет участникам команды найти решение.

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

Каково ваше мнение? Могут ли проекты с фиксированными стоимостью, сроком, содержанием, быть гибкими? Приходилось ли вам работать в составе Agile-команды, работающей над такими проектами? Пожалуйста, поделитесь мыслями в комментариях.