Июнь 2019 — Заметка №12

Интересный подход к принятию решений в организации IETF (они придумывают разные интернет-стандарты): rough consensus. Можно почитать про это в блог-посте или подробно в этом RFC (английский)

Главный смысл этого подхода в том, что в первую очередь идет поиск не согласия, а несогласия. Вместо вопроса “всем ли ОК формат А?”, который конечно вызовет кучу разного фидбэка и возражений, задается вопрос “кто-то не может жить с форматом A?”. Это позволяет им отделить возражения вида “просто хотел бы по другому” (= это не идеальное решение) от “это абсолютно неприемлимо для меня” (= это плохое решение).

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

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

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

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

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