Жаль, что вы, вместо того, чтобы попросить посоветовать литературу по архитектуре баз данных, если вам это действительно интересно, начали попытки поймать меня на незнании темы. Причем, задавая вопросы, ответы на которые уже были даны, и оправдываясь "промаргиванием". Ни запрос, ни транзакция - не обладают самосознанием. Они о себе знают приблизительно ничего. Это просто текст. Во что-то осмысленное, такое как план выполнения, который вы можете посмотреть эксплейном, они превращаются после работы профайлера. Не того, который показывает результат SHOW PROFILE FOR QUERY, а того, кто этот результат готовит, и использует на уровне движка. Причем он определяет и порядок выполнения подзапросов, и использование индексов, и первичные ограничения, если страничные данные. И много чего еще, включая оптимизацию запроса. И он сразу поймет, что запрос типа UPDATE Table SET Table.col = Table.col FROM Table - чушь собачья, которая поменяет данные ровно никогда, вернет только результат ОК. И выполнять он его будет... Хотя, лучше посмотрите его explain-он сами. И, если это единственный запрос транзакции - он благополучно поставит этой транзакции статус "коммутативна", что означает "данная транзакция никогда, никак и ни про каких обстоятельствах не будет влиять на результаты других транзакций, можно выполнять параллельно с ними". В Оракле это строго так, в мускуле - не знаю точно, нужно проверять (поскольку UPDATE). Транзакция на чтение-запись - всегда "НЕ коммутативна". По определению. А значит - строго последовательно, если есть хоть малейшее подозрение на влияние на уже выполняемую. Чтение в представленной мной схеме, где данные не изменяются апдейтом никогда, а уровень изоляции стоит в READ COMMITED - всегда коммутативная операция. Результат чтения никак не зависит от выполняющихся транзакций с записью, он всегда возвращает актуальный датасет.
После того, как вы не смогли объяснить, как транзакция ещё только при открытии узнаёт, что она "пишушая" и не должна давать другим транзакциям читать те данные, которые читает она
А вот это - просто ваша откровенная ложь. Такого я нигде не утверждал.
как транзакция в момент открытия понимает, пишущая она, или нет?
Читать научитесь собственные сообщения, чтобы не задавать глупых вопросов. Вы задали вопрос - я на него ответил. Потом перечитайте чуть выше, про коммутативные транзакции. Потом вообще почитайте про транзакции, в том числе коммутативные. Последний ответ в рамках сегодняшнего ликбеза: транзакция пишущая, если по результатам есть запись в transaction log. При этом, ничего не мешает завернуть в транзакцию обычный SELECT. Транзакция откроется? Да. Транзакция либо закоммитится, либо роллбек? Да, к примеру - нет такой таблицы. Транзакция была? Была. Изменения есть? Нет. Запись в transaction log есть? Нет. Транзакция не пишущая. И да, в некоторых базах это действительно используется, в том числе для избегания конкурентных запросов.
Понимает это не транзакция, а профайлер, который под транзакцию готовит планы выполнения, и отправляет их в кэш. Что делает и с обычными SELECT-запросами. Не пишущая транзакция - транзакция, не изменяющая состояния данных. Да, в мускуле их особо не особо, а вот в Оракле, с его гетерогенными службами, кластерами и остальным богатством - дофига. Как вариант: создание материализованных представлений из удаленных источников, потом селект.
Отлично. Вы сами себе что-то придумали, а потом начали с этим спорить, требуя конкретики. Ну или просто немного не в курсе темы про транзакции...
Наша транзакция изменения баланса состоит из двух операций - чтения (чтобы проверить возможность списания), и записи (актуализация баланса). На все остальные чтения, параллельные и перпендикулярные, нам плевать.
Операции чтения-записи не коммутативны (non permutable), планировщик никогда не запустит 2 такие транзакции в параллельные процессы. Тем более, профайлер прекрасно видит, что транзакции зависят от одних и тех же данных (даже план выполнения для получения этих данных не будет переделывать, а возьмет из кэша). Вторая транзакция начнет выполнение, только когда произойдет коммит или роллбек первой.
А теперь огромная просьба рассказать, как вы собираетесь добиваться вот этого:
Первая транзакция прочитала сумму, и убедилась, что списание не выходит из лимита.Вторая транзакция по вашему сценарию прочитала сумму, и убедилась, что списание не выходит из лимита.Первая транзакция добавила строку и закоммитилась.Вторая транзакция добавила строку и закоммитилась.
при том, что в данной ситуации я даже не представляю как это технически возможно. У вас либо ПОЛНОСТЬЮ выполняется первая транзакция, и денег на вторую не хватает, либо первая НЕ выполняется, выполняется вторая, первую не перевыполнить. Все списания правомерны, в минус не ушли. И не надо придумывать поведения систем под свои хотелки. Это так не работает, насколько подробно не объясняй первоначальный сценарий.
Ну так об этом и речь. А в случае успешного завершения транзакции прочитанное значение станет невалидным, и позволит выйти из лимита.
А вот теперь от вас чуть больше конкретики: как вы выйдете из лимита, при том что параллельное списание невозможно? Подробно, плиз. Пока это что-то у вас общие слова про "состояние гонки". Непонятно кого с кем и за какой приз.
Получается что да, мы можем, наверное, залочить на чтение не всю таблицу, а только записи данного пользователя, прочитать верхнюю строчку, посмотреть в РНР
Зачем вы собираетесь лочить пользователя, если вам нужно прочитать только одно поле его последней записи (мой вариант)? Причем не сканом по всей таблице, а по индексу? Без агрегаций. При этом, сама запись остается открытой для чтения, и в случае параллельного чтения другой, не пишущей транзакцией, в случае отката нашей, та вернет актуальные данные! Если вы еще не поняли, нам тут блокировки вообще не нужны. И их НЕТ, что не получится при агрегации (ваш вариант)! Нам нужна очередь из транзакций с insert. И если ее организовать другим способом, нам тут вообще и сами транзакции будут не нужны.
Если я правильно понял этот сумбур, там списания хранятся отдельно от поступлений, и возможно отдельно списания от списаний вождения. Но тут без гарантии.
Пожалейте себя и окружающих. Судя по самой статье, картинкам интерфейса и описанию процессов, на который вы выше обратили внимание, там такой ад, что глаза промывать ацетоном придется. Но факт наличия статьи действительно радует, а то в фиде одни ИИ и HR.
Странно... Вообще я не карман новый пришивать предложил, а не выпускать зажигалку из рук, если следовать Вашей терминологии. И нет, хранить поле остатка - это достаточное условие для избавления от дополнительных агрегаций, но не необходимое в данном конкретном проекте. Да, это отход от третьей нормальной формы через добавление избыточности данных, но почему-то делают именно так.
В данной ситуации атомарный апдейт - это отсутствующая величина, по той простой причине, что хронологически связанные данные (как и графы состояний) не апдейтят. Изменение данных происходит только инсертами, и защита от двойных списаний реализуется обычной транзакцией, у которой по умолчанию невозможны грязные чтения, потерянные обновления, а фантомные чтения, при правильной реализации даже местами полезны, поскольку последний выбранный датасет всегда правильный. Что позволяет еще и уровень изоляции снизить для производительности. Если же вы говорите о банальном дабл-клике - достаточно в форму оплаты скрытым полем добавить "код операции" (генерится заранее), добавить это поле в указанную таблицу, повесить на него unique. Но это уже совсем другая история.
А зачем вы считаете 3 суммы, если можно получить одну запись? ))) А если вам нужно показать пользователю все операции по счету в хронологическом/другом порядке? Вы будете делать простыню из юнионов? В биллинговых системах это обычно хранят как хронологию изменения счета. Пользователь - Причина изменения - Дата - Сумма изменения - Актуальный остаток. Собственно, актуальный остаток последней по времени записи и есть текущий баланс. Иногда добавляются дополнительные поля, типа зарезервированных средств. Да, если у пользователей нет миллионов транзакций, можно не париться, но зачем делать плохо, если можно сделать хорошо?
Так как я был на тот момент еще недостаточно компетентен, я придумал еще более уникальное решение — сделал доп. таблицу, в которую вносилась запись при ожидании подтверждения =). Ну то есть, человек выбрал время — сделался INSERT в таблицу, и другие не смогут уже выбрать это время в течении 2–3 минут. И каков был результат? Конечно дубликаты записей сохранились. Люди так же записывались по 2–3 записи на 1 занятие.
А решили-то как? ))))
В предыдущем релизе, стоимость вождения вносилась в сразу в таблицу с занятиями. Теперь все эти записи будут суммироваться и вычитаться из поступлений. Таким образом будет теперь считаться баланс у учеников — просто одним большим запросом.
Очень плохое решение. Достаточно в каждом поступлении/списании хранить еще поле остатка. Потом просто делать SELECT balance FROM table WHERE user_id = ... ORDER BY date DESC LIMIT 1. И не забывать про транзакции.
Дело в том, что тут какой нейминг для статьи не придумай - все будет не так. Ситуации - сравнение теплого с мягким. Как метод матрицы Эйзенхауэра для приоритезации задач в рамках спринта (приоритеты исполнитель сам расставляет? А так можно было?) можно сравнивать с метриками и многоработностью? Начало - о принципах развития в ширь и в глубь, а в итоге: как я выбираю работу, где про эти принципы ни слова. Ну и про "помогаем заработать бизнесу" из заголовка в статье ни слова.
А я оцениваю уже содержание заголовка. Если вдруг вы не поняли, его прямой посыл: или вы берете вторую работу и упахиваетесь чтобы иметь больше денег, или вы упахиваетесь, чтобы было больше денег у дяди, и возможно он с вами поделится (см. пункт 4).
Попробуйте перечитать еще раз все, что я писал. В особенности вот это:
"А я хочу, чтобы объем организованных мной процессов и взятой ответственности прямо коррелировал с объемом полученных мной денежных знаков". Заметьте, я нигде не прошу платить мне больше, за просто так.
Эффективная модель, это когда работодатель, особенно если это крупная корпорация, делится акциями с "вовлеченными" сотрудниками. И они, своей вовлеченностью, начинают работать в том числе и на себя. Все остальное - морковка для ослика. И нет, я не собираюсь сопереживать никакому бизнесу, если от него не зависит мое личное благополучие. Работа - это просто место, где вы обмениваете свои знания и время на деньги. Все остальное - благотворительность.
Вам рассказать про зарплаты шахтеров в СССР, где никакого бизнеса вообще в помине не было? Это не к тому, что в СССР хорошо было, а просто контраргумент у Вашим "пререквизитам". Капиталистические отношения возникают там, где есть работник и работодатель. И ПРЯМАЯ задача работодателя - платить работнику как можно меньше, поскольку все, что он не заплатит работнику - возьмет себе. Это основа капитализма, который у нас за окном в полный рост. Поэтому, Ваш тезис "тогда и деньги на высокие з/п появятся" несостоятелен от слова "совсем". А "успех бизнеса" - это осознанный риск бизнесмена, который, в случае этого успеха, будет получать не плохие такие прибыли. В отличии от Вас, обычного наемного работника.
Нет, народ решил что вы потакаете боту. Регистрация меньше месяца, только одна статья, 13 комментариев исключительно под ней, причем комментарии близки к односложным, из серии "что вы вообще делаете в моем личном пространстве". Конструктива - ровно 0 (NULL)... В общем, просто посмотрите профиль этой "Вероники".
А в Вашей статье очень размыто понятие "вовлекаться". Как и "думать с позиции бизнеса". Думать с позиции бизнеса, это думать о том, как увеличить прибыль, попутно снижая расходы и издержки. Все остальное - либо вторично, либо производные от первого. И вся беда в том, что лично Вы не можете ни при каких условиях значительно влиять на эти показатели в рамках целого банка. Делать свою работу хорошо - это правильная и честная позиция. Выпрыгивать из штанов, чтобы показать всем эту позицию - на мой взгляд лишнее. Вы, даже следуя по матрице Эйзенхауэра, не сможете со 100% вероятностью определить, какая из этих "важных" или "не важных" задач принесет больше денег конечным бенефициарам, так с чего Вы решили, что в принципе в состоянии думать с точки зрения данного, конкретного бизнеса?
ПС: если Вы будете продуктивно овертаймить по 16 часов в сутки за те же деньги, это с точки зрения бизнеса ОЧЕНЬ хорошо. Все еще хотите думать с точки зрения бизнеса?
Действительно не очень корректно сформулировал... Давайте так: "сколько раз вы общались с принимающим решения по Вашей зарплате в ситуациях, когда разговор об ее повышении был бы уместен?" В том банке, где я работал, департамент - основная структурная единица, которых было всего 12. Директор департамента - высший менеджмент, большая часть которого в совете директоров. Застолбить 20 минут "на потрындеть в тимсе" - точно не вариант. При этом, никаких "тебе 20 тысяч, Васе - 30", есть четкая зарплатная сетка с коэффициентами. Пересмотреть мою зарплату - пересмотреть ее всему департаменту, а значит из области фантастики. Возможности вертикального роста - только в случае кончины кого-то выше, и то, скорее всего возьмут со стороны. Горизонтального - а зачем за те же деньги? Да, есть опция сидеть на премиях, показывая высокий KPI, только это как раз совсем не про активную позицию, да и выше писал что: "Выплата премии и ее размер остается на усмотрение руководства". После "усмотрения" руководства об отсутствии годовой премии у всего IT второй год подряд - смена работы. Для более четкого понимания всего бюрократического трындеца: после устройства в этот банк я ждал рабочий комп две с половиной недели. Со своим ноутом нельзя, доступы к боевым контурам, ИБ не спит. После получения компа, почти месяц писал докладные записки о необходимости тестового контура для работы. Мораль, точнее три: кровавый интерпрайз бывает разным; не все процессы хороши, даже если они есть; не всем нужна ваша позиция вообще, и проактивная в частности. Иногда нужны просто взаимозаменяемые винтики в механизм, а все разговоры про "новый грейд когда-нибудь" - не более чем морковка для ослика.
Корпорации хотят сотрудников, которые могут организовать процессы и брать на себя ответственность.
А я хочу, чтобы объем организованных мной процессов и взятой ответственности прямо коррелировал с объемом полученных мной денежных знаков, на которые я куплю семье еды, и желательно вкусной.
Будешь более вовлечен, легче работать будет.
А вот тут вы серьезно промахнулись. Особенно, если речь идет о корпорациях. Работать вам будет легче, если вы будете плевать в потолок, выполняя необходимый минимум работы. Поскольку в положении о премировании (да, я тоже работал в банке из топ-10), который является прямым продолжением Вашего трудового договора, последним пунктом, после зубодробительных формул расчета той самой премии, четко написано, что: "Выплата премии и ее размер остается на усмотрение руководства".
Если все правильно обсудил с руководством, то залутаешь грейд в перспективе.
А теперь скажите честно, сколько раз Вы лично общались с тем самым руководством (я не про линейного руководителя, если что, а про того, кто может на прямую влиять на Ваш персональный доход)? Работая в банке начальником отдела внедрения службы одного окна, руководителя своего департамента я видел 4 раза за 2 года, общался с ним ровно 0 раз. И да, уже к тому моменту я лет 10 работал на руководящих должностях. Грейд на перспективу - это гдейд к пенсии, мало интересно.
Жаль, что вы, вместо того, чтобы попросить посоветовать литературу по архитектуре баз данных, если вам это действительно интересно, начали попытки поймать меня на незнании темы. Причем, задавая вопросы, ответы на которые уже были даны, и оправдываясь "промаргиванием". Ни запрос, ни транзакция - не обладают самосознанием. Они о себе знают приблизительно ничего. Это просто текст. Во что-то осмысленное, такое как план выполнения, который вы можете посмотреть эксплейном, они превращаются после работы профайлера. Не того, который показывает результат SHOW PROFILE FOR QUERY, а того, кто этот результат готовит, и использует на уровне движка. Причем он определяет и порядок выполнения подзапросов, и использование индексов, и первичные ограничения, если страничные данные. И много чего еще, включая оптимизацию запроса. И он сразу поймет, что запрос типа UPDATE Table SET Table.col = Table.col FROM Table - чушь собачья, которая поменяет данные ровно никогда, вернет только результат ОК. И выполнять он его будет... Хотя, лучше посмотрите его explain-он сами. И, если это единственный запрос транзакции - он благополучно поставит этой транзакции статус "коммутативна", что означает "данная транзакция никогда, никак и ни про каких обстоятельствах не будет влиять на результаты других транзакций, можно выполнять параллельно с ними". В Оракле это строго так, в мускуле - не знаю точно, нужно проверять (поскольку UPDATE). Транзакция на чтение-запись - всегда "НЕ коммутативна". По определению. А значит - строго последовательно, если есть хоть малейшее подозрение на влияние на уже выполняемую. Чтение в представленной мной схеме, где данные не изменяются апдейтом никогда, а уровень изоляции стоит в READ COMMITED - всегда коммутативная операция. Результат чтения никак не зависит от выполняющихся транзакций с записью, он всегда возвращает актуальный датасет.
А вот это - просто ваша откровенная ложь. Такого я нигде не утверждал.
Читать научитесь собственные сообщения, чтобы не задавать глупых вопросов. Вы задали вопрос - я на него ответил. Потом перечитайте чуть выше, про коммутативные транзакции. Потом вообще почитайте про транзакции, в том числе коммутативные. Последний ответ в рамках сегодняшнего ликбеза: транзакция пишущая, если по результатам есть запись в transaction log. При этом, ничего не мешает завернуть в транзакцию обычный SELECT. Транзакция откроется? Да. Транзакция либо закоммитится, либо роллбек? Да, к примеру - нет такой таблицы. Транзакция была? Была. Изменения есть? Нет. Запись в transaction log есть? Нет. Транзакция не пишущая. И да, в некоторых базах это действительно используется, в том числе для избегания конкурентных запросов.
Понимает это не транзакция, а профайлер, который под транзакцию готовит планы выполнения, и отправляет их в кэш. Что делает и с обычными SELECT-запросами. Не пишущая транзакция - транзакция, не изменяющая состояния данных. Да, в мускуле их особо не особо, а вот в Оракле, с его гетерогенными службами, кластерами и остальным богатством - дофига. Как вариант: создание материализованных представлений из удаленных источников, потом селект.
Отлично. Вы сами себе что-то придумали, а потом начали с этим спорить, требуя конкретики. Ну или просто немного не в курсе темы про транзакции...
Наша транзакция изменения баланса состоит из двух операций - чтения (чтобы проверить возможность списания), и записи (актуализация баланса). На все остальные чтения, параллельные и перпендикулярные, нам плевать.
Операции чтения-записи не коммутативны (non permutable), планировщик никогда не запустит 2 такие транзакции в параллельные процессы. Тем более, профайлер прекрасно видит, что транзакции зависят от одних и тех же данных (даже план выполнения для получения этих данных не будет переделывать, а возьмет из кэша). Вторая транзакция начнет выполнение, только когда произойдет коммит или роллбек первой.
А теперь огромная просьба рассказать, как вы собираетесь добиваться вот этого:
при том, что в данной ситуации я даже не представляю как это технически возможно. У вас либо ПОЛНОСТЬЮ выполняется первая транзакция, и денег на вторую не хватает, либо первая НЕ выполняется, выполняется вторая, первую не перевыполнить. Все списания правомерны, в минус не ушли. И не надо придумывать поведения систем под свои хотелки. Это так не работает, насколько подробно не объясняй первоначальный сценарий.
А вот теперь от вас чуть больше конкретики: как вы выйдете из лимита, при том что параллельное списание невозможно? Подробно, плиз. Пока это что-то у вас общие слова про "состояние гонки". Непонятно кого с кем и за какой приз.
Зачем вы собираетесь лочить пользователя, если вам нужно прочитать только одно поле его последней записи (мой вариант)? Причем не сканом по всей таблице, а по индексу? Без агрегаций. При этом, сама запись остается открытой для чтения, и в случае параллельного чтения другой, не пишущей транзакцией, в случае отката нашей, та вернет актуальные данные! Если вы еще не поняли, нам тут блокировки вообще не нужны. И их НЕТ, что не получится при агрегации (ваш вариант)! Нам нужна очередь из транзакций с insert. И если ее организовать другим способом, нам тут вообще и сами транзакции будут не нужны.
Надеюсь так более понятно.
Ээээ... А зачем нам блокировать таблицу? Мы же про InnoDB? Почитайте плиз: https://habr.com/ru/articles/238513/
И у нас READ COMMITED идет, напоминаю.
Если я правильно понял этот сумбур, там списания хранятся отдельно от поступлений, и возможно отдельно списания от списаний вождения. Но тут без гарантии.
Пожалейте себя и окружающих. Судя по самой статье, картинкам интерфейса и описанию процессов, на который вы выше обратили внимание, там такой ад, что глаза промывать ацетоном придется. Но факт наличия статьи действительно радует, а то в фиде одни ИИ и HR.
Странно... Вообще я не карман новый пришивать предложил, а не выпускать зажигалку из рук, если следовать Вашей терминологии. И нет, хранить поле остатка - это достаточное условие для избавления от дополнительных агрегаций, но не необходимое в данном конкретном проекте. Да, это отход от третьей нормальной формы через добавление избыточности данных, но почему-то делают именно так.
В данной ситуации атомарный апдейт - это отсутствующая величина, по той простой причине, что хронологически связанные данные (как и графы состояний) не апдейтят. Изменение данных происходит только инсертами, и защита от двойных списаний реализуется обычной транзакцией, у которой по умолчанию невозможны грязные чтения, потерянные обновления, а фантомные чтения, при правильной реализации даже местами полезны, поскольку последний выбранный датасет всегда правильный. Что позволяет еще и уровень изоляции снизить для производительности. Если же вы говорите о банальном дабл-клике - достаточно в форму оплаты скрытым полем добавить "код операции" (генерится заранее), добавить это поле в указанную таблицу, повесить на него unique. Но это уже совсем другая история.
А зачем вы считаете 3 суммы, если можно получить одну запись? ))) А если вам нужно показать пользователю все операции по счету в хронологическом/другом порядке? Вы будете делать простыню из юнионов? В биллинговых системах это обычно хранят как хронологию изменения счета. Пользователь - Причина изменения - Дата - Сумма изменения - Актуальный остаток. Собственно, актуальный остаток последней по времени записи и есть текущий баланс. Иногда добавляются дополнительные поля, типа зарезервированных средств. Да, если у пользователей нет миллионов транзакций, можно не париться, но зачем делать плохо, если можно сделать хорошо?
А решили-то как? ))))
Очень плохое решение. Достаточно в каждом поступлении/списании хранить еще поле остатка. Потом просто делать SELECT balance FROM table WHERE user_id = ... ORDER BY date DESC LIMIT 1. И не забывать про транзакции.
Дело в том, что тут какой нейминг для статьи не придумай - все будет не так. Ситуации - сравнение теплого с мягким. Как метод матрицы Эйзенхауэра для приоритезации задач в рамках спринта (приоритеты исполнитель сам расставляет? А так можно было?) можно сравнивать с метриками и многоработностью? Начало - о принципах развития в ширь и в глубь, а в итоге: как я выбираю работу, где про эти принципы ни слова. Ну и про "помогаем заработать бизнесу" из заголовка в статье ни слова.
А я оцениваю уже содержание заголовка. Если вдруг вы не поняли, его прямой посыл: или вы берете вторую работу и упахиваетесь чтобы иметь больше денег, или вы упахиваетесь, чтобы было больше денег у дяди, и возможно он с вами поделится (см. пункт 4).
Попробуйте перечитать еще раз все, что я писал. В особенности вот это:
"А я хочу, чтобы объем организованных мной процессов и взятой ответственности прямо коррелировал с объемом полученных мной денежных знаков". Заметьте, я нигде не прошу платить мне больше, за просто так.
Эффективная модель, это когда работодатель, особенно если это крупная корпорация, делится акциями с "вовлеченными" сотрудниками. И они, своей вовлеченностью, начинают работать в том числе и на себя. Все остальное - морковка для ослика. И нет, я не собираюсь сопереживать никакому бизнесу, если от него не зависит мое личное благополучие. Работа - это просто место, где вы обмениваете свои знания и время на деньги. Все остальное - благотворительность.
Вам рассказать про зарплаты шахтеров в СССР, где никакого бизнеса вообще в помине не было? Это не к тому, что в СССР хорошо было, а просто контраргумент у Вашим "пререквизитам". Капиталистические отношения возникают там, где есть работник и работодатель. И ПРЯМАЯ задача работодателя - платить работнику как можно меньше, поскольку все, что он не заплатит работнику - возьмет себе. Это основа капитализма, который у нас за окном в полный рост. Поэтому, Ваш тезис "тогда и деньги на высокие з/п появятся" несостоятелен от слова "совсем". А "успех бизнеса" - это осознанный риск бизнесмена, который, в случае этого успеха, будет получать не плохие такие прибыли. В отличии от Вас, обычного наемного работника.
Нет, народ решил что вы потакаете боту. Регистрация меньше месяца, только одна статья, 13 комментариев исключительно под ней, причем комментарии близки к односложным, из серии "что вы вообще делаете в моем личном пространстве". Конструктива - ровно 0 (NULL)... В общем, просто посмотрите профиль этой "Вероники".
А в Вашей статье очень размыто понятие "вовлекаться". Как и "думать с позиции бизнеса". Думать с позиции бизнеса, это думать о том, как увеличить прибыль, попутно снижая расходы и издержки. Все остальное - либо вторично, либо производные от первого. И вся беда в том, что лично Вы не можете ни при каких условиях значительно влиять на эти показатели в рамках целого банка. Делать свою работу хорошо - это правильная и честная позиция. Выпрыгивать из штанов, чтобы показать всем эту позицию - на мой взгляд лишнее. Вы, даже следуя по матрице Эйзенхауэра, не сможете со 100% вероятностью определить, какая из этих "важных" или "не важных" задач принесет больше денег конечным бенефициарам, так с чего Вы решили, что в принципе в состоянии думать с точки зрения данного, конкретного бизнеса?
ПС: если Вы будете продуктивно овертаймить по 16 часов в сутки за те же деньги, это с точки зрения бизнеса ОЧЕНЬ хорошо. Все еще хотите думать с точки зрения бизнеса?
Действительно не очень корректно сформулировал... Давайте так: "сколько раз вы общались с принимающим решения по Вашей зарплате в ситуациях, когда разговор об ее повышении был бы уместен?" В том банке, где я работал, департамент - основная структурная единица, которых было всего 12. Директор департамента - высший менеджмент, большая часть которого в совете директоров. Застолбить 20 минут "на потрындеть в тимсе" - точно не вариант. При этом, никаких "тебе 20 тысяч, Васе - 30", есть четкая зарплатная сетка с коэффициентами. Пересмотреть мою зарплату - пересмотреть ее всему департаменту, а значит из области фантастики. Возможности вертикального роста - только в случае кончины кого-то выше, и то, скорее всего возьмут со стороны. Горизонтального - а зачем за те же деньги? Да, есть опция сидеть на премиях, показывая высокий KPI, только это как раз совсем не про активную позицию, да и выше писал что: "Выплата премии и ее размер остается на усмотрение руководства". После "усмотрения" руководства об отсутствии годовой премии у всего IT второй год подряд - смена работы. Для более четкого понимания всего бюрократического трындеца: после устройства в этот банк я ждал рабочий комп две с половиной недели. Со своим ноутом нельзя, доступы к боевым контурам, ИБ не спит. После получения компа, почти месяц писал докладные записки о необходимости тестового контура для работы. Мораль, точнее три: кровавый интерпрайз бывает разным; не все процессы хороши, даже если они есть; не всем нужна ваша позиция вообще, и проактивная в частности. Иногда нужны просто взаимозаменяемые винтики в механизм, а все разговоры про "новый грейд когда-нибудь" - не более чем морковка для ослика.
Золотые слова.
А я хочу, чтобы объем организованных мной процессов и взятой ответственности прямо коррелировал с объемом полученных мной денежных знаков, на которые я куплю семье еды, и желательно вкусной.
А вот тут вы серьезно промахнулись. Особенно, если речь идет о корпорациях. Работать вам будет легче, если вы будете плевать в потолок, выполняя необходимый минимум работы. Поскольку в положении о премировании (да, я тоже работал в банке из топ-10), который является прямым продолжением Вашего трудового договора, последним пунктом, после зубодробительных формул расчета той самой премии, четко написано, что: "Выплата премии и ее размер остается на усмотрение руководства".
А теперь скажите честно, сколько раз Вы лично общались с тем самым руководством (я не про линейного руководителя, если что, а про того, кто может на прямую влиять на Ваш персональный доход)? Работая в банке начальником отдела внедрения службы одного окна, руководителя своего департамента я видел 4 раза за 2 года, общался с ним ровно 0 раз. И да, уже к тому моменту я лет 10 работал на руководящих должностях. Грейд на перспективу - это гдейд к пенсии, мало интересно.
На мой скромный взгляд, пропущен главный пункт: "Как моя забота о бизнесе будет влиять на мое личное благосостояние?"