→
Как достичь консенсуса в плоских организациях
Публичный пост
19 апреля 2020
1052
Отличная статья о том, как продуктивно принимать спорные решения внутри команд.
Видел достаточно людей, неспособных разграничить "Not the best choice" и "fundamental flaws", которые превращали обсуждение любой спорной темы в многочасовой цирк просто из-за того, что им было важнее принятии их идеи, а не решение проблемы.
Основные моменты:
- IETF (те самые, которые "делают инторнет") принимают сложные технические решения, используя rough consensus[1]
- Основной смысл rough consensus -- не все должны быть в восторге от принятого решения, но все должны быть способными жить с этим решением. Люди могут предпочитать другие решения, но если предлагаемое работает для большинства и в нем нет фатальных недостатков - нужно его применять и двигаться дальше.
- Если ты высказываешь мнение, ты должен четко разделять "мне кажется, есть решение лучше" и "предложенное решение не может работать по причинам...". Первое не столь важно, если предложенное решение может работать и остальные члены команды с ним согласны. Второе должно быть блокером и нужно тратить энергию и время на убеждение остальных.
- И если решение принимаешь ты: If there is a good enough solution X, don’t ask people what they think about it. Instead, ask everyone if they can live with it and if not, why.
Ставь лайк если зашёл сюда после горизонтального веган-сейфспейса Фрик, посмотрим сколько нас!
//статья по ссылке норм, выжимка ещё лучше
Было бы очень круто, если бы ты выписал в описание краткий список тезисов из статьи. Поверхностно, но чтобы было ясно что авторы предлагают вообще.
Про humming в статье тоже написано неверно.
"In IETF, they sometimes hum instead of raising their hands when they need to vote" - нет, humming используется НЕ when they need to vote, заглянем снова в rfc7282: "However, more and more we see people who think that a hum is a sort of anonymous vote [...] This misses some really important points of using humming and is almost certainly misassessing the consensus. Hums should not be used as votes."
"While this approach can’t be replicated exactly on a remote team for obvious reasons [...]" (имеется в виду humming) - ietf как раз работает через mail lists, то есть удаленно.
В общем статья написана, чтобы попиарить doist и она не очень высокого качества. Почитайте оригинальный rfc, он клевый.
В статье кстати ошибка
"The Internet Engineering Task Force (IETF) is a membership-based organization of [...]"
Тогда как в rfc7282 как раз написано противоположное - "We don't vote in the IETF. In some ways, we can't vote: Since the IETF is not a membership organization, it's nearly impossible to figure out who would get a vote for any given question." (https://datatracker.ietf.org/doc/html/rfc7282#section-4)