Кто виноват, если принимают решение единогласно?

Как хорошо что в клубе нет этих стереотипов про некропостинг. Какое сокровище попалось...

В вопросах ответственности я наблюдаю две крайности.

1. Расстрелять врага народов. Эту крайность раскрыл @vas3k в своем комменте. Что характерно, обычно как только речь заходит об личной ответственности, у подавляющего большинства встречающихся мне поклонников коллективной ответственности всплывает именно эта аналогия, из-за чего диалога не получается.

2. Мы креативный коллектив, как фиалки на клумбе - дружно цветем, когда все идет хорошо, и дружно чахнем всей клумбой когда что-то идет не так. Мы ответственны за все. Возможно это тоже какая то культурная особенность. Возможно это результат оджайл пропаганды. Не знаю. Но факт в том, что такая крайность ровно настолько же омерзительна, насколько омерзительна и первая. Когда за нечто ответственно более одного человека, на самом деле никто не несет ответственности. Это - аксиома. Иногда последствия неощутимы, и складывается ощущение что личная ответственность - фу, а команда рулит. Но в терминальной стадии следование этой крайности вырождается в бесконечные митинги, рост количества бессмысленных паразитных коммуникаций в почте, чатах и привате, падение качества проекта как следствие того, что никто (помним об аксиоме) не ответственен ни за код ревью, ни за пайплайн, ни за процессы, ни за дизайн-документацию, затягивание принятия решений, срыв сроков, факапы, нервотрепка. Спекуляция на командной безответственности в виде интриг, ИБД и guilt-менеджмента. Охота за токсичными ведьмами...

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

Ниже - ИМХО. Детали могут отличаться в зависимости от проекта и не столько существенны, сколько - суть.

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

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

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

Размер ответственности пропорционален полномочиям. Если человеку даны полномочия уровня "девелопер", глупо ожидать от него одного что процесы в команде наладятся. Если человеку даны полномочия "тимлид", нерационально растрачивать его ресурс на кодинг.

Два самых важных полномочия, которые должны быть доступны всем ролям: право на фидбэк (право высказываться о рисках и опасениях и быть услышанными), и право на эскалацию (право обратиться на уровень выше с запросом "рассудить", если на текущем уровне произошел сбой в распределении ответственности и полномочий). Без них будет больно, когда что-то пойдет не по плану - все скатится к крайности номер 1.

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

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

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

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

Вот здесь, мне кажется, в тебе включился человек твоей культуры. Той самой, где принято «находить и наказывать виновных». Вплоть до вендетты, ну мы помним.

Но есть и другие культуры, где виноватых искать не принято. Есть проблема — ее надо решать. Всё. Месть и поиски виновных — это лишние эмоции, которые вредят бизнесу. Яркий пример — современная Германия. То есть так можно и так работает.

В общем, всё это лишь культурные особенности.

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

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

В общем, из всех предыдущих опытов которые были, может быть полезных поинтов не так и много:

• при появлении "развилок" в технических решениях, если принято принимать коллективные решения, создавайте док с описанием проблемы, возможными путями решения, плюсами/минусами, ревью на уровне комментов и созвонов и голосованием с последующим занесением в тот же документ принятого решения, возможными последствиями и прочая. Дает немного исторического контекста для будущей команды при попытках осознать происходящее. К нам в команду не так давно подвезли более формализированные гайды по форматам в виде ADR.
• если плохое решение принимает единолично один человек и никакие эскалации/обсуждения не помогают, то все, на уровне организации тут или "сдаваться и уходить" или "свыкаться и терпеть" (ну и вариант "включаем подковерные интриги, саботируем и выживаем человека из ума команды"), а на уровне кода пытаться по максимуму абстрагировать необходимые чейнджи так, чтобы потом можно было наименее болезненно это все выкинуть (избегать вендор лок фичей, в любые чужие АПИ ходить только через какую-то прослойку, этс)
• мелкие тех. решения внутренние для сабкоманды (типа чего-то внутри бекенда или фронтенда), которые обычно на техлиде, если у него нет 100%го ответа или хотя бы "чуйки", при прочих равных возможно стоит обсудить/брейнштормить, и в отсутствии какого-либо вменяемого решения своими силами/по гайдам из интернета, отдавать на откуп того, кто будет имплементить (кто идею предложил => тот ее и имплементит). Возможны правда потом моменты "ах, Лёха, я тебе доверился, а ты все провтыкал", но это уже может быть индикатор других проблем (или техлид не опытен, или команда в целом, или редко происходят ревизии и предвосхищения факапов)

А вообще, делать говно не так страшно (все IT ведь говно), сколько осознанно жить в нем, не пытаясь сделать лучше.
Каждое плохое решение принятое кем-то единолично, является поводом меньше доверять суждениям этого человека в будущем.
Каждое хорошее непринятное решение с норм аргументацией, является поводом больше доверять суждениям автора в будущем.
Даже самые вменяемые решения от архитектов, которые идут вразрез с частью команды, могут понижать общую продуктивность и мораль команды.
Даже самые невменяемые решения, которые вся команда придумала и воодушевленно исполнила, могут быть ок. Ну да, могут быть проблемы в продакшене, но сколько вообще проектов доходит до продакшена? 20-40%?

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

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