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

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

О(n²): Совещание равноправных участников. n человек обсуждают вопрос, причем для достижения взаимопонимания, каждому участнику нужно пообщаться с каждым. Всего будет осуществлено n*(n-1)/2 социальных взаимодействий (эквивалентно задаче подсчета числа рукопожатий в группе из n человек), т.е сложность алгоритма О(n²). Казалось бы, за счет того, что общение одновременно могут осуществлять n/2 пар людей, оценка по времени – О(n), однако на реальных совещаниях в один момент времени говорит только один человек, поэтому оценка для худшего случая — О(n²). Если время взаимодействия – 5 минут и для достижения полного взаимопонимания в группе требуется две итерации, то совещание трех человек продлиться 30 минут, четырех – час, пятерым потребуется 1 час 40 минут для нахождения общего решения (что подозрительно похоже на правду). Если же число итераций зависит от числа участников, мы получаем еще более печальные оценки.

Но не все так плохо!

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

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

В этой статье я хотел бы

— поделиться сделанными выводами
— порекомендовать проект, если вы хотите присоединиться к нему в качестве разработчика/инвестора
— выложить техническую документацию, если вы захотите сделать форк

Я написал этот пост отчасти в попытке оправдать перфекционизм, в который иногда впадаю, и отчасти – чтобы пояснить коллегам, о чем я думаю, когда работаю над очередным проектом.

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

Некоторое время назад меня заинтересовала задача определения пола человека по его ФИО. В тот момент я работал в области медицинского страхования, где эта проблема была действительно актуальна – расходы на одного застрахованного, а значит и тарифы, по которым людей принимали на страхование, в зависимости от пола клиента, могли отличаться в несколько раз. Большая часть договоров – корпоративные, застрахованные являются сотрудниками работодателя.

Мы никогда не видели большинство из них в глаза, все, что мы имели – списки застрахованных, где пол иногда был указан (с большим количеством ошибок), но чаще – не указан вообще. Большинство компаний имеют свою специфику работы и профессиональные традиции, в силу чего, в их коллективах преобладают люди одного пола. Даже небольшая ошибка могла сделать потенциально прибыльный договор убыточным (или наоборот, но на такое, по странному стечению обстоятельств, случалось с нашими клиентами гораздо реже). В целом, при объеме портфеля договоров в несколько миллиардов, и характерном количестве ошибок около процента, цена корректного определения пола по ФИО была в районе нескольких десятков миллионов.