​​ Стоимость ошибки и изменений… Ошибки любят списывать на р | noTieinIT - Об IT без галстуков

​​ Стоимость ошибки и изменений…

Ошибки любят списывать на разработчиков или QA. Это сделать проще всего. Таким поведение грешат менеджеры, ведь проще всего обьяснить своему же руководству о пофейленном проекте или задаче взвалив это на разработчиков. Нетехническим топам рассказать о том, что “разработчики козлы” проще всего, ведь они не могут вникнуть глубоко в суть и разобраться в проблеме. Можно еще уволить исполнителей и взять новых… чтоб наверняка.

В современной статьях и литературе (в основном про Agile) приводят вот этот график, который очень упрощен и не показывает истинную трагичность. Всего-то выпилили значения по шкалам… Еще продавцы гибких методологий любят продавать историю, что использование XP практик делает “график плоским”, потому чтоб не профакапить, то юзайте XP.

Происходит это за счет уменьшения времени обратной связи на ошибки. Работая по TDD от момента написания кода до понимания что тесты попадали пройдет несколько минут, потому исправить такую ошибку проще. Это действительно правда, писали об этом Кент Бек и Мартин Фаулер, кстати, но это лишь часть правды.

Сегодня восстанавливаю справедливость! К этому посту я приатачил давно забытый график, но он не утратил актуальность даже спустя 40 лет!. Его автор - Barry Boehm и он опубликовал этот график в книге Software Engineering Economics. На этом графике отображены все этапы в разработке: от формулировки бизнес требований до исправлений в продакшне.

Расшифрую суть графика на примере. Если на этапе формирования требований к продукту ошибку в требованиях можно предотвратить и доработать за 1 час, то исправление во время разработки уже будет стоить примерно 10 часов. Если проморгать проблему и код ушел на тестирование, то ее исправление может затянуть на 20-50 часов, а если ошибка уехала в релиз, то и вовсе до 1000 часов!

Еще раз. Исправление ошибки на этапе проектирования в 100-1000 раз ниже, чем после выпуска релиза!

Сразу сделаю оговорку, что огромное число в 1000 раз применимо для продуктов с редкими релизами и доставкой софта на физических носителях (в те времена это были дискеты или ленты). Потому можете представить боль, когда клиентам приходилось слать обновления на физических носителях по месяцу и еще обучать персонал как обновление накатить. Сейчас стало чуть проще и накатить фикс можно по интернету и довольно быстро. Но цена все еще высока и это x100 от цены исправлений на этапе составления требований и архитектуры системы.

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