Не совсем.

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

Когда функция несколько раз подряд ставит внутренний порядок выше потерь бизнеса, руководитель обязан быстро вернуть людей в реальность.

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

То есть это была не эмоция, а управленческое вмешательство в уже повторяющуюся проблему.

Стоп. Подождите. Вы какую роль играли? CDTO/CTO/CIO, верно?

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

Так это ваше упущение как CTO, если ваш owner или вы, как owner, не отразили в бэклоге важное для заказчика условие, которое, я подчеркну-уже в релизной версии содержало мажорные баги. Значит у вас же с qa также было упущено на предрелизе. Значит и в архитектуре до этого это лежало. И команда тут не при чем. Это конкретно ваш факап, факап вашего овнера и вашего qa. И хоть эта история и очевидно выдуманная, ибо ни один внятный специалист не позволит в своем отношении подобных выкидонов, но даже будучи фантазией автора показывает стопроцентную некомпетентность. Если результат задачи не обеспечен ничем, кроме надежды на морально волевое давление и интонацию, то и вместо решения можно получить в ответ только интонацию.

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

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

Но сам кейс был не про поиск виноватого за баг, не про безошибочную систему и не про руководителя, который всё предусмотрел. Он был про момент, когда становится видно реальную управленческую проблему: бизнес уже нес потери, а функция всё ещё считала, что “всё по плану”. Именно это для меня тогда и стало главным управленческим выводом.

Имхо, по собственному опыту. Причина почти всегда в исполнителе. А бизнес несет убытки из за собственной жадности.

Если пресейл не нашел слов, чтобы объяснить заказчику необходимость затрат на тестирование и архитектуру-заказчик сам становится тестировщиком. И всё что падает в релиз с прода приводит к убыткам. Только в том случае, если риск стоит меньше бага это оправдано. Но тогда, будучи отраженным в условиях, это не становится ответственностю команды.

Команду надо защищать, а не унижать.

Согласен с одной частью: команду руководитель обязан защищать.

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

Именно про этот второй момент у меня и был кейс.

Спасибо. Именно так.

Как только ИТ(да любая на самом деле функция) начинает жить своей внутренней логикой, оно перестаёт поддерживать бизнес и начинает обслуживать само себя.

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

Зрелая функция защищает результат, а не собственный комфорт.

это никак не снимает ответственности с бизнеса, понимать где их слабые места. Если вы заказываете ПО, чтобы продавать скоропортящиеся продукты, так проверяйте, продаёт ли оно их.