OnAgile Learning Hub 💎
2.6K subscribers
224 photos
3 videos
178 links
Канал об Agile и связанных с ним изменениях в крупных компаниях.
onagile.ru | OnAgile Consulting
Обучение и методологическая помощь во внедрении Agile, Scrum, Kanban, LeSS, SAFe
Download Telegram
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Крайне интересный факт, если это правда. Похоже, самый длинный контракт на разработку ПО в истории.

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

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

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

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

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


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

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

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

Как вам такое? 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
В апреле 1970 года космический корабль «Аполлон-13» отправился к Луне — это должна была стать третья в истории пилотируемая посадка на её поверхность. Внутри были трое астронавтов.

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

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

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

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

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

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

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

Тем не менее, эта часть миссии тоже оставалась предсказуемой, пусть для неё и не сущестовало стандартных решений. В следующем посте мы расскажем, что же произошло в момент самой аварии.
Please open Telegram to view this post
VIEW IN TELEGRAM