Крайне интересный факт, если это правда. Похоже, самый длинный контракт на разработку ПО в истории.

Конечно, его необходимо отменить, но интересно то, что его точно не следует заменять на модель оплаты по результатам (пожалуйста!).

Как мы все знаем, такие контракты не работают хорошо и, независимо от стиля управления, 100% приводят к низкому качеству продукта, продлению сроков и перерасходу бюджета.

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

Всегда есть место для изменений в требованиях, но оплата по результатам — это по сути контракт с фиксированной ценой и фиксированным объёмом работ.

Вот почему Agile подход здесь необходим и должен использоваться в любом случае.


Исходный текст со скриншота:
“Существует закономерность во всех государственных учреждениях, где контракты на "модернизацию" ИТ не оплачивают результаты/производительность; вместо этого они платят за время.
Следовательно, у подрядчиков есть стимул "никогда не заканчивать", что приводит к невероятным растратам.

Например, модернизация Налоговой службы США (IRS) началась в 1990 году с планируемым завершением в 1996 году. Сегодня работа не завершена, и подрядчики говорят, что до завершения ещё 5 лет. 29 лет отставания от графика и примерно 15 млрд долларов перерасхода бюджета.
Проигрывают все, кроме государственных подрядчиков. Это должно измениться.

На этой неделе IRS заморозила контракты на модернизацию на сумму около 1,5 млрд долларов, ни один из которых не влияет на подачу налоговых деклараций. Все эти контракты будут либо отменены, либо условия контрактов будут изменены на оплату по результатам.”

Как вам такое? 🙂

В апреле 1970 года космический корабль «Аполлон-13» отправился к Луне — это должна была стать третья в истории пилотируемая посадка на её поверхность. Внутри были трое астронавтов.

Но всё пошло не по плану, когда прямо во время полёта в одном из кислородных баллонов произошёл взрыв

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

Сегодня «Аполлон-13» — это классический пример того, что даже при самом тщательном планировании и проработке требований, невозможно предусмотреть всё заранее. Что-то всё равно придётся дорабатывать и начинать сначала, чтобы всё-таки высадиться на Луну.

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

Это была та часть миссии, где всё оставалось предсказуемо

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

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

Тем не менее, эта часть миссии тоже оставалась предсказуемой, пусть для неё и не сущестовало стандартных решений. В следующем посте мы расскажем, что же произошло в момент самой аварии.

Модель Киневин (Cynefin framework)

В прошлых постах мы рассказали, как развивалась история миссии «Аполлон-13», и сколько разных факторов пришлось учесть NASA при выполнении полёта, особенно в ситуации, когда на борту произошла авария.

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

Простая (Simple)

«Наблюдать— Классифицировать — Реагировать»

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

Сложная (Complicated)

«Наблюдать — Анализировать — Реагировать»

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

Запутанная (Complex)

«Провести эксперимент — Наблюдать — Реагировать»

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

Хаотическая (Chaotic)

«Действовать — Наблюдать — Реагировать»

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

Показательный момент хаотической среды в миссии «Аполлон-13» — это взрыв кислородного баллона. Высадка на Луну больше не имела смысла, когда главной задачей стало — срочно обеспечить возможность дышать. Астронавты, чтобы выжить, собрали самодельный углекислотный фильтр из того, что было под рукой и спаслись. И только после этого начали анализировать аварию и продумывать следующие шаги по возвращению домой.

Подробней о модели Киневин и о том, как она работает на примере реальных рабочих ситуациях, мы рассказываем на нашем курсе Certified Agile Professional.