Михаил, а посчитать/прикинуть сколько клиент теряет на этом косяке можно?

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

у нас был такой случай, отправили большую систему на расчет и пошли курить, в принципе, всем участникам было ок))

Тут наверное больше была идея переноса вопроса принципов принятия решения (если для нас важно качество предоставления "сервиса"), по аналогии с внутренней службой. когда  в первую очередь делаются изменения непосредственно влияющие на стоимость/ценность, а во вторую очередь и в управляемом реиме на фенички влияющие на субъективные качества...

- 1 случай?🤓
- нуу.. в неделю))

Ну тогда изнач неэффективная архитектура продукта отнесется как раз к ценности, а ее "исправляют" только разговорами саппорта)

Есть же олдскульные монолит-сервисы в нишах МИС и в HR  - они скорей потонут чем признают что 100500 тыщ строк кода можно заменить микросервисной облачной архитектурой, верно? Собсно поэтому условный Медеск и Хантсфлоу так быстро успешно зашли в эти ниши

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

ну я про то что для клиента (а значит и в итоге для компании) это мб на текущ момент не доп.фенечки, а отрицательная ценность core-product и ее надо как-то повышать)

О, еще пример негативной ценности: допустим вы пользуетесь б2б-сервисом у которого не было кое-какого функционала и вы его реализовали другим способом или самописно. И однажды, не спрашивая и не предупреждая сервис радостно выкатывает апдейт.. В общем аналитику и все остальное приходится заново

так если вдруг окажется, что меняь архитектуру дорого, ну совсем дорого, то можно попробовать пойти другим путем, проанализировать возможность "сворачивания"  этой функции.

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

Любой клон рано или поздно становится ветошью :)

С другой стороны, бухгалтерский софт - даже если это архитектурный франкенштейн - там ж ничего не "свернешь")

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

на noSQL /graphQL ?

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

👍🏻 скок времени заняло?

Сворачиваются функции, а объекту либо выпадают либо остаются... в бухгалтерском софте тоже можно сворачивать операции, точнее убирать их от бухгалтеров...

а что ты имеешь под "убирать от бухгалтеров"?

где-то сроки выросли на несколько месяцев (2-3) переделок, сама система была готова, поэтому и столкнулись с проблемой, поэтому вначале поменяли взгляд на хранение данных и потом начали менять запросы.. формы, бизнес логика осталась старой....