Некоторое время назад, я понял, что к оценке сложности социальных взаимодействий, можно применять те же подходы, что и к оценке сложности алгоритмов – а значит можно увидеть их плюсы, минусы и области применения. Ниже краткий список наиболее частых вариантов, с которыми я имел дело.
О(n2): Совещание равноправных участников. n человек обсуждают вопрос, причем для достижения взаимопонимания, каждому участнику нужно пообщаться с каждым. Всего будет осуществлено n*(n-1)/2 социальных взаимодействий (эквивалентно задаче подсчета числа рукопожатий в группе из n человек), т.е сложность алгоритма О(n2). Казалось бы, за счет того, что общение одновременно могут осуществлять n/2 пар людей, оценка по времени – О(n), однако на реальных совещаниях в один момент времени говорит только один человек, поэтому оценка для худшего случая — О(n2). Если время взаимодействия – 5 минут и для достижения полного взаимопонимания в группе требуется две итерации, то совещание трех человек продлиться 30 минут, четырех – час, пятерым потребуется 1 час 40 минут для нахождения общего решения (что подозрительно похоже на правду). Если же число итераций зависит от числа участников, мы получаем еще более печальные оценки.
Но не все так плохо!
— Во-первых, не все участники совещания могут быть независимы и равноправны, они могут образовывать группы интересов (например, начальник и двое его подчиненных), тогда обсуждение происходит не между индивидуальными участниками, а между группами, представителем которой всегда является один человек. Представитель может меняться в ходе обсуждения, но он всегда только один. В таком случае, сложность социального взаимодействия — О((n/m)2), где m – среднее число участников каждой группы, присутствующей на встрече.
— Во-вторых, О(n2) – худшая оценка. Может оказаться, что каждая сторона высказывает свою позицию по очереди, а каждый следующий строит свое высказывание с учетом всего услышанного ранее. Последний участник предлагает вариант решения проблемы – и все участники обсуждения соглашаются с ним или вносят свои незначительные изменения. В таком случае, для принятия решения достаточно всего лишь 2n действий. Мораль: подготовленное выступление и модератор, определяющий порядок обсуждения, могут сэкономить очень много времени.
О(n*log(n)): выработка командного решения через делегатов. Зачастую для принятия решения требуется привлечь действительно много людей. Решение может охватывать технически сложную область или для реализации могут требоваться усилия большого числа людей. После того, как задача поставлена, каждый из участников предлагает решение своей части задачи, излагая его делегату (например, руководителю своего отдела). Делегат обобщает полученные предложения и излагает их делегату второго уровня (выбранного среди делегатов первого уровня), который, в свою очередь, суммирует полученные предложения и излагает их делегату третьего уровня – и так далее. Продолжив рекурсивно алгоритм и дойдя до человека принимающего финальное решение, мы получим вариант, который, в той или иной степени, будет учитывать мнение каждого из участников. Причем получим мы его достаточно быстро – за счет того, что общение с делегатом отлично параллелится, мы получаем ответ за O(m*logm(n)), где m-характерное число людей в группе.
О(n): цепочка согласований. Зачастую решение уже есть, нужно просто пройти стандартизированную процедуру его согласования. Например – согласовать добавление нового товара на полку. Здесь сложность одной попытки будет равна n, где n – число инстанций, которые нужно будет пройти. Да, число попыток никак не ограниченно, но, т.к. требования заранее известны, оно, обычно, мало.
О(n): оповещение. Идеально подходит для ситуаций, когда нужно довести какую-то информацию в неизменном виде до большого числа людей. Каждый из группы потратит время на ознакомление, таким образом трудозатраты составят n социальных взаимодействий. В плохих случаях способ может принимать вид «прошу ознакомиться с приказом и принять к исполнению», в хороших — это просто проверка на корректность данных, прописанная в коде. Различия между этими случаями – в числе людей, которые реально столкнутся с оповещением (во втором – значительно меньше), а также в различиях в требованиях к памяти исполнителя (во втором – не требуется помнить хоть что-то до момента, когда ограничение сработает). Но, лично мне нравится в данном подходе то, что он О(1) по времени для отправителя – трудозатраты останутся неизменны вне зависимости от числа людей, которые сообщение получат. Темная сторона того же правила – письма с десятками человек в копии.
О(log(n)): оповещение через делегатов. Используется когда нужно оповестить только одного человека, но не известно – кого именно. Пример – задача, которая спускается на управление, потом передается руководителю отдела, потом – непосредственному исполнителю. Альтернативный путь – создание «единого окна» через которое принимаются все задачи/распоряжения/пожелания. Такой способ постановки задачи по-прежнему является константным по сложности для отправителя, но гораздо менее трудозатратен для принимающей стороны, поэтому именно принимающая сторона, как правило, является инициатором смены способа обмена с «оповещения» на «оповещение через делегатов».
О(1): решение проблемы через стандартный интерфейс. Идеальная ситуация к которой, на мой взгляд, надо стремиться. Проблема известна, как и пути ее решения, а значит – можно создать интерфейс, который поможет человеку решить его проблему без каких-либо контактов с другими людьми, причем скорость решения проблемы никак не зависит от количества людей, которые с ней столкнулись. Можно сказать, что это то же «оповещение», но уже с точки зрения отправителя, а реальные затраты со стороны пользователей – все еще О(n). Это так, но я решил выделить данный способ, поскольку, несмотря на математическую эквивалентность, он дает новый взгляд на проблему.
Есть ли способы взаимодействия со внешним миром со сложностью хуже, чем О(n2)? Определенно да – по аналогии с болотной сортировкой можно придумать варианты, которые будут ужасно непрактичным. Полагаю, что они не встречается на практике только потому, что все реальные задачи решаются менее трудозатратными алгоритмами.
Если есть подходы, при которых проблема решается за константное время – зачем тогда нужны все остальные методы? Полагаю, что основная причина – в свободе принятия решений. Вместе с улучшением асимптотики свобода постепенно уходит. В совещании равноправных участников, диапазон решений ограничен только полномочиям людей участвующих в совещании. Этот инструмент хорошо подходит для принятия важных уникальных решений. При использовании же стандартных интерфейсов диапазон решений значительно сужается.
Практические следствия:
— не зовите на совещания равноправных участников больше 5 человек. Если время одного взаимодействия между людьми – 5 минут, скорее всего, вы не уложитесь в 1 час обсуждения.
— не зовите на совещания неравноправных участников больше 15 человек (5 начальников+2 подчиненных с каждой стороны) – одного часа вам опять не хватит
-не зовите на совещания людей, от которых нужен только «ок» — пишите протокол по результатам встречи и просите его согласовать
— распоряжения, указания, информационные сообщения (и, возможно, последующие голосования) – единственный эффективный способ общения, если заинтересованных сторон больше нескольких десятков
— если в отделе больше 10 человек – создайте «единое окно» куда будут поступать стандартные требования/пожелания/запросы.
— если вы или ваши сотрудники не успевают выполнять задачи, которые к ним приходят – подумайте, можете ли вы улучшить асимптотику изменив способ взаимодействия с внешним миром.
P.s. К сожалению, скорость взаимодействия между людьми, не удваивается каждые два года.
Оптимизируйте свое общение и будьте счастливы.
Комментарии (9)
S_A
22.08.2017 07:56+1Настолько идея статьи понравилась, пошарил в соцсетях. Кстати, если добавить содержание обсуждения к рассмотрению, как тут выше пишут, то может также получиться интересная картина.
Например, обсуждать дизайн продукта и стратегию предприятия могут в обоих случаях 4 человека, но в одном случае это займет час-день, а во втором — день-неделю-месяц (месяц вместе с подготовкой).
Важность меняет уровень детализации, и при изменении даже мелких деталей может понадобиться новая итерация обсуждения «от печки».
Hardcoin
22.08.2017 09:37+1можно придумать варианты, которые будут ужасно непрактичным. Полагаю, что они не встречается на практике
Ещё как встречаются. Нужно выработать решение и каждый планирует убедить других в правильности своего. После n^2 взаимодействий часть людей решит, что консенсус все же нужен (и появляется небольшой шанс его найти), а общая сложность алгоритма будет nnlog(n) и выше.
giffok Автор
25.08.2017 22:14А как оценить трудозатраты на консенсус, какой у него алгоритм?
Вроде бы достаточно добавлять последовательно по одному участнику в группу, он за константное время будет принимать или отклонять позицию группы. Т.е. это процесс O(n).
Иногда это действительно работает, но опыт подсказывает, что иногда консенсус — трудозатратная штука и не всегда достижим, а значит алгоритм выше не всегда работает.
Как оценить затраты на консенсус, когда исходно есть две противостоящие группы и никто не хочет уступать?Hardcoin
26.08.2017 14:53Оценка сверху — это затраты на победу одной из сторон в войне на уничтожение. Но возможны, конечно, множество оптимизаций, что бы до такого не доводить.
Порядок цифр на достижение общего консенсуса (не по одному вопросу, а в целом) между странами можно оценить по расходам на армии. Если когда-нибудь найдут более дешёвый алгоритм и внедрят его — расходы на армии сильно сократятся.
Gryphon88
22.08.2017 12:43+1Тут ещё есть тонкость с числом Паркинсона (адекватное обсуждение и консенсус возможны только если число договаривающихся не более 9) и стремлением избыточного контроля, например, все договора и распоряжения проходят по всей линейной цепочке снизу доверху, а потом обратно в соседнее подразделение той же линии.
Мне кажется, такие вещи нужно моделировать как маршрутизацию в сети, с учетом задержек, потерь и искажений.giffok Автор
25.08.2017 22:19Мне кажется число 9 как верхнее ограничение — следствие сложности О(n^2) ))
AnneSmith
скорость принятия решения обратно пропорциональна времени, отведенному на обсуждение
hdfan2
Обсуждение 20% проблем занимает 80% времени совещания, а остальных 80% проблем — другие 80% совещания.
h0tkey
Из чего можно предположить, что совещание состоит из своего времени на 75%. :)