Гибкость, F F F и Agile

Уже несколько лет я пытаюсь поддерживать в аЗОН принципы FFF (fix time, fix budget, flex scope)

Фиксить и флексить придумали в IT компании 37 Signals, они хорошо рассказали об этом в книге Getting Real. Их идеи поддержали и развили в дизайн бюро Артема Горбунова. Вот их формула:
Фиксируем срок.
Если команда не успевает доделать проект вовремя, обычное решение — сдвинуть срок запуска. Но время — невосполнимый ресурс, недаром deadline происходит от слова «смерть». За отпущенное нам время мы успеем только то, что успеем. Чтобы не уходить в мрачные аналогии, мы сравниваем запуск проекта с наступлением Нового года. Отодвинуть его нельзя, даже если ты не успел купить подарки. Мы не сдвигаем срок.
Фиксируем бюджет.
Когда проблемы в проекте решают деньгами, это означает одно из двух: либо оплачивают дополнительное время, либо расширяют команду. Первое не подходит. А увеличение команды нередко снижает управляемость проекта и только усугубляет его проблемы.
Флексим.
Когда жертвовать сроком, бюджетом и качеством нельзя, методом исключения приходим к одному: жертвуем функциями, «флексим». Отрезаем то, что не успеваем сделать.

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

Теперь немного истории...
Помните отличный проект Алесандро Аравены Элементал, с которым он стал знаменитым?
С очень скромным бюджетом от города он предложил решение для строительства массового жилья малоимущим. Этот проект избавил город от криминального района и вдохнул новую волну в жизнь многих людей, особенно подрастающего поколения.
Идея проекта очень проста: строится минимально необходимая часть дома с коммуникациями. Оставляется незастроенной часть, которую потом уже сами хозяева делают по мере появления возможности. Выглядит совсем не монотонно и скучно как обычно в типовой застройке. Наоборот очень кастомизированно, при это суперорганизованно!

Так вот, Оказывается этот подход уже давно формализовали и практикуют в IT сфере.
Недавно я узнал в доступной форме пояснения «для дедушки» что такое Эджайл (agile). Это здорово и просто объяснила Наталия Бабаева в своём блоге.
Основная идея Эджайл в том, что при ограниченном времени, бюджете и ресурсах можно подготовить на первых порах минимальный жизнеспособный продуктMVP, затем развивать и растить его (груминг) и тд...

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


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


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