Очень смешная история. Но вообще я поработал в свое время в таких компаниях и в целом понимаю, как понимать такие ситуации. Ну с позиции Software Architect.
Расскажу как программист с опытом оптимизации процессов в крупной компании.
Сеть офисов любой крупной компании можно представить как распределенную систему серверов с плохим и нестабильным “железом”. Каждое отделение в этой концепции работает по своей программе, являющейся в целом клоном одной общей программы или ее регионального варианта. Каждая такая программа на месте работает со своим набором данных, и данные эти все кривые и косые. Соответственно, программа эти ошибки в данных должна учитывать и не ломаться.
Любые ошибки в коде такой общей программы болезненны, потому что страдает вся сеть. Уходят годы на полировку.
Насколько хорошо такие программы-процессы должны покрывать всякие нештатные или редкие ситуации? Понятно, что все ситуации не предусмотришь, поэтому ждут, пока число инцидентов превысит некоторый threshold, а затем начинают это системно решать. Если не превышает, то дешевле забить. Иначе сложность процессов будет такой, что в них будут ошибаться на местах чаще.
Если же превысило threshold, нужно выпускать и распространять “патч”. Этот патч может починить одно, но сломать другое. Поэтому патч нужно тестировать на маленькой сети отделений, а потом постепенно распространять на более крупные. Это все довольно долго, потому что нужно собрать статистику и фидбэк, понять, ничего ли важного не ломает и т.д.
Ну и в такой системе всегда есть огромный перечень фич, который нужно имплементировать и внедрить. Фактически это очень длинный бэклог. Поставьте себя на место владельца такой сети – вы скорее выберете фичу, которая положительно влияет на выручку (плюс 0.05%) или фичу, которая влияет на удовлетворенность 0.05% клиентов?
Плюс очень часто выходит так, что неудобства и проблемы просто не пересекают этот threshold просто потому, что не налажена нормально система обратной связи. Клиенты не жалуются, потому что “оно всегда так было” и потому что “не с чем сравнивать, они тут вообще одни в городе”. Сотрудники не жалуются, потому что и так работает, чего себе работы прибавлять.
Кроме всего, такую распределенная система постоянно подвергается “атакам” и “взломам”. Не только со стороны конечных пользователей, но и со стороны ее операторов – сотрудников отделений. Это когда слабости начинаются использоваться для собственной выгоды. Часто это даже не незаконно. Как и в ситуации с “оптимизацией налогов”, тут просто включается русская смекалка – как использовать слабости в процессах себе на пользу. И получается как со стульями в Икее, которые берут на выходные на пикник, чтобы вернуть в понедельник обратно в магазин.
Любая очень большая система просто полна таких проблем. Решить их можно только раздроблением системы на куски меньшего размера, которые бы между собой конкурировали за качество обслуживания. Так устроены франшизы – взять тот же Макдональдс. Также важно, чтобы на одном поле работало более одной компании – конкуренция все исправит. Это бы починило “Почту России”, которая монополист.
Being in America 