Найти тему
47 подписчиков

Цена ошибки


Почему в разных сферах разные процессы разработки, разные принципы работы и так далее? Дело в разных целях и в разной цене ошибки. Допустим возьмём для примера корпорации. У них цена ошибки заоблачная. Если DoDo лежит четыре часа (как было недавно) — это большие потери в деньгах. Поэтому процессы в корпорациях дорогие, медленные, с кучей проверок. Условно классический путь задачи можно описать так.

Фича придумана —> Архитектор вписал её в систему —> её отдали в разработку —> разработка декомпозировала фичу на таски —> под каждую таску делается новая ветка —> есть ветка "релиза фичи" куда льются таски (и проходят ревью и автоматические тексты) —> релиз ветка проверяется тестерами —> релиз ветка проверяется внутренним заказчиком фичи —> релизветка проверяется финальный раз автотестами —> релиз ветка заезжает в мастер

Там конечно есть куча нюансов и по возврату, и в конкретике каждой компании деталей и нюансов. Но +- работает это так. И это очень длинный путь. При этом даже простой фиче нужно пройти этот путь, так как она может положить прод — а это очень дорого.

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

Проект придуман —> разработка декомпозирует её на таски —> разработка делает таски и выкатывает промежуточные релизы —> релизы идут в тестирование —> заказчик смотрит промежуточные релизные сборки —> собирается финальный релиз —> тестируется тестерами —> смотрится заказчиком и идёт в прод

Тут нет архитектора, тут нет автотестов, тут нет ревью и пулл реквестов, то есть тут нет девопсов. Тестеры тут тоже немного другие. В аутсорсе многие не знают банально, что такое Smoke test, хотя многие и делают то только его. Все процессы упрощены. И цены получаются другие. И всё дело в цене ошибки. Если баг не критический условно сломанный на час проект — это не смертельная проблема. Поэтому цена ошибки другая.

У нас крайне редко на релизе что-то ломалось. Чаще наша цена ошибки "что-то ломается в руках заказчика". И это вполне удовлетворительная цена ошибки. Просто чаще всего очень трудно кому-то объяснить, что дело не в "профессионализме", а в процессах. Можно построить процесс, в котором ошибки будут крайне редкими и баги "пресловутый SLA 99%". Но это просто дорогой процесс, который меняет косты на проект космически.

Тот же TDD подход к разработке. Мне он очень нравится. Перед написанием функционала пишем к нему тест. Но он дорогой, ему нужно обучать людей, особенно как вообще в Unity пишутся тесты, прогоняются, настраивается тест среда. Плюс по хорошему это нужно сразу вплетать в гит с мержем веток, в CI&CD и так далее. Поэтому он просто дороже, чем другие подходы к разработке. Хотя стабильность системы растёт в разы. И так далее.

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

#мысли
2 минуты