Pull to refresh

Comments 9

скорость принятия решения обратно пропорциональна времени, отведенному на обсуждение
Обсуждение 20% проблем занимает 80% времени совещания, а остальных 80% проблем — другие 80% совещания.
Из чего можно предположить, что совещание состоит из своего времени на 75%. :)
Настолько идея статьи понравилась, пошарил в соцсетях. Кстати, если добавить содержание обсуждения к рассмотрению, как тут выше пишут, то может также получиться интересная картина.

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

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

Ещё как встречаются. Нужно выработать решение и каждый планирует убедить других в правильности своего. После n^2 взаимодействий часть людей решит, что консенсус все же нужен (и появляется небольшой шанс его найти), а общая сложность алгоритма будет nnlog(n) и выше.

А как оценить трудозатраты на консенсус, какой у него алгоритм?

Вроде бы достаточно добавлять последовательно по одному участнику в группу, он за константное время будет принимать или отклонять позицию группы. Т.е. это процесс O(n).
Иногда это действительно работает, но опыт подсказывает, что иногда консенсус — трудозатратная штука и не всегда достижим, а значит алгоритм выше не всегда работает.

Как оценить затраты на консенсус, когда исходно есть две противостоящие группы и никто не хочет уступать?

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


Порядок цифр на достижение общего консенсуса (не по одному вопросу, а в целом) между странами можно оценить по расходам на армии. Если когда-нибудь найдут более дешёвый алгоритм и внедрят его — расходы на армии сильно сократятся.

Тут ещё есть тонкость с числом Паркинсона (адекватное обсуждение и консенсус возможны только если число договаривающихся не более 9) и стремлением избыточного контроля, например, все договора и распоряжения проходят по всей линейной цепочке снизу доверху, а потом обратно в соседнее подразделение той же линии.
Мне кажется, такие вещи нужно моделировать как маршрутизацию в сети, с учетом задержек, потерь и искажений.
Мне кажется число 9 как верхнее ограничение — следствие сложности О(n^2) ))
Sign up to leave a comment.

Articles