Прочитал крутую книгу: Управляя общим. Эволюция институтов коллективной деятельности | Остром Элинор

Общее(то чем управляют) в этой книге - это какой-то ограниченный ресурс, который доступен какой-то группе людей. Например, пастбище, которое доступно всем жителям деревни. Разумное использование ресурса может принести пользу всей группе, а неразумное - вред. В ИТ общим ресурсом может быть, например, технический долг. Разумное его использование принесет пользу всем, а неразумное разрушит проект.

Есть 3 основные проблемы в управлении общим, описываются такими теоретическими моделями:

1. Трагедия общих ресурсов
2. Диле́мма заключённого
3. Логика коллективного действия

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

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

Логика коллективного действия - это про иррациональность человека. Даже если человек знает, что если совершаемые им действия принесут пользу группе и ему лично, он не будет их совершать без принуждения. Точнее человек склонен их не совершать.

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

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

1й - либеральный путь - приватизация ресурса в частные руки. Частник будет заинтересован в контроле над своим ресурсом. В нашем мире - разделиться на небольшие команды, какждой команде назначить лида или менеджера и поручить ему полный контроль.

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

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

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

Изучая сотни примеров успешных и неуспешных систем, автор обнаружил общие для успешных систем законы. Мне показалось это очень интересным и от части(а может и полностью) применимым в управлении ИТ проектами:

Попробую перефразировать комментарии автора книги к принципам, при этом я буду фантазировать, что речь не про пастбище, а про технический долг:

• Четко определенные границы

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

• Соответствие между правилами присваивания и снабжения и местными условиями

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

• Механизмы коллективного выбора

Большинство лиц, которых касаются действующие правила, должны участвовать в их модификации. Правила могут меняться участниками.

• Moниторинг

Лица, осуществляющие мониторинг состояния долга и поведения команды, должны быть подотчетны команде или сами быть теми кто страдает от долга. Члены команды должны быть уверенны, что другие не нарушают правила, это очень важно.

• Градуированные санкции

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

• Механизмы решения конфликтов

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

• Mинимальное признание права на организацию

Компания где вы работаете, не должна мешать вам устанавливать правила.

• Институции-«матрешки» («вложенные» институции)

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

Вывод:

Автор приводит убедительные доказательства жизнеспособности таких систем. Эффективность зашкаливает, нет необходимости в дорогом мониторинге - все участники следят за всеми, коллективные решения учитывают интересы всей группы. Принцип мониторинга и прозрачности, возможно, самый применимый в этой истории. Еще до книги это заметил как такая простая вещь влияет на результат. В нашей ИТшечке, например - продукт овнер хочет впихнуть побольше, прожект менеджер хочет взять в план поменьше, команда хочет писать свой красивый СОЛИД, а технической поддержке нужно чтобы их не доставали юзеры.
Построение социализма в отдельно взятой компании спасет всех. Ура, товарищи!