Текст книги "Элегантная головоломка. Системы инженерного менеджмента"

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

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

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

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

Рисунок 2.5. Прибыль при консолидации инвестиций по сравнению с распределением инвестиций.

2.3. Аргументы против глобальной оптимизации сверху вниз

После того как я опубликовал исследование под заголовком «На пути к высокопроизводительным командам»[1]1
  Staying on the Path to High-Performance Teams.


[Закрыть] (8), многие задавали мне один и тот же вопрос: «Как только команда погасит технический долг, не должны ли лишние работники перейти в другие подразделения?»

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

Это важная проблема, требующая решения!

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

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

МОРАЛЬ ЗАКЛЮЧАЕТСЯ В ТОМ, ЧТО НУЖНО УЧИТЫВАТЬ ЗАТРАТЫ НА ОТЛАДКУ РАБОЧИХ ПРОЦЕССОВ ПОСЛЕ ВНЕДРЕНИЯ ИЗМЕНЕНИЙ, А НЕ В ТОМ, ЧТО ИЗМЕНЕНИЙ НЕ ДОЛЖНО БЫТЬ ВОВСЕ.

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

Иногда хочется расти быстрее, чем позволяет сплоченная команда, и это нормально! Мораль заключается в том, что нужно учитывать затраты на отладку рабочих процессов после внедрения изменений, а не в том, что изменений не должно быть вовсе. Вот почему в предложенной модели (9) рекомендуется в первую очередь нанимать персонал в команды, обремененные техническим долгом, а не в команды, занимающиеся инновациями. Это позволяет избежать затрат на повторную адаптацию высокопроизводительных команд.

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

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

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

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

Рисунок 2.6. Постоянные затраты на управление командой.

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

ЧТОБЫ ПОБУДИТЬ ЛЮДЕЙ К ОПТИМИЗАЦИИ ГЛОБАЛЬНОЙ ЭФФЕКТИВНОСТИ, ТРЕБУЕТСЯ БОЛЕЕ ГЛУБОКОЕ ПОНИМАНИЕ ТОГО, КАК ДОСТИГАЕТСЯ ПРОИЗВОДИТЕЛЬНОСТЬ КОМПАНИИ И ЧЕМ ОНА ОТЛИЧАЕТСЯ ОТ ЛИЧНОЙ ПРОДУКТИВНОСТИ.

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

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

«Цель. Процесс непрерывного улучшения» Элияху М. Голдратта и Джеффа Кокса[2]2
  Элияху М. Голдратт, Джефф Кокс. «Цель. Процесс непрерывного улучшения». Минск: Попурри, 2021. 400 с.


[Закрыть] (10) и «Азбука системного мышления» Донеллы Х. Медоуз[3]3
  Д. Медоуз. «Азбука системного мышления». М.: Манн, Иванов и Фербер, 2021. 272 с.


[Закрыть] (11) – феноменальные книги на эту тему.

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

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

РАСШИРЕНИЕ СФЕРЫ ДЕЯТЕЛЬНОСТИ РАБОТАЕТ ЛУЧШЕ, ЧЕМ ПЕРЕВОД ИЗ КОМАНДЫ В КОМАНДУ, ПОТОМУ ЧТО ПОЗВОЛЯЕТ ИЗБЕЖАТЬ ЗАТРАТ НА АДАПТАЦИЮ СОТРУДНИКОВ И СОХРАНЯЕТ ПАТТЕРНЫ ПОВЕДЕНИЯ В СИСТЕМЕ.

Другой действенный метод, в чем я убедился лично, заключается в ротации людей на определенный период в зоны, где нужна помощь. Фиксированный срок позволяет временным сотрудникам сохранить свою идентичность и принадлежность к нынешней команде, полностью сосредоточившись на оказании помощи, вместо того чтобы разделять свое внимание между выполнением работы и попыткой влиться в новый коллектив. К тому же это безопасный способ понять, какой на самом деле излишний потенциал есть в команде (из которой переводится на время сотрудник).

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

2.4. Продуктивность в эпоху гиперактивного роста

Термин «гиперрост» (12) теперь не так часто употребляют, как пару лет назад. Примерно раз в неделю вы можете услышать о нем. Но если обратитесь к Techmeme[4]4
  Techmeme – агрегатор технологических новостей. Веб-сайт был описан как «одностраничное, агрегированное, отфильтрованное, архивируемое резюме почти в режиме реального времени о том, что нового и вызывающего обсуждение».


[Закрыть] – не увидите ни одного упоминания скачкообразного роста, что можно считать глобальным откатом в старые добрые времена. Только если речь не о единорогах[5]5
  «Единорог» – это термин, используемый в индустрии венчурного капитала для описания частной стартап-компании стоимостью более 1 миллиарда долларов. Впервые термин был популяризирован венчурным капиталистом Эйлин Ли, основателем Cowboy Ventures, фонда венчурного капитала начального этапа, базирующегося в Пало-Альто, в Калифорнии.


[Закрыть] (13).

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

Когда я начинал работать в Uber, у нас было почти 1000 сотрудников, и каждые 6 месяцев становилось вдвое больше. Один мой давний коллега резюмировал: «Мы растем так быстро, что каждые полгода становимся новой компанией». Другой сразу заключил: «Вот почему наш бизнес-процесс с учетом роста персонала всегда отстает от желаемого результата на два квартала».

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

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

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

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

Представим картину: обучение нового сотрудника отнимает у инженера около 10 часов в неделю, а производительность новичков на треть ниже, чем у опытных. В результате на диаграмме 2.8 (по общему признанию, это наихудший сценарий) на двух неподготовленных приходится один обученный. Хуже того, производительность этих троих суммарно равна производительности 1,16 профи (2 х 0,33 для начинающих плюс 0,5 х 1 для обучающего).

Рисунок 2.7. Темпы роста персонала быстрорастущих компаний.

Также необходимо учитывать время, затраченное на найм новых сотрудников.

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

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

Однако затраты не ограничиваются только обучением и наймом:

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

2. Каждые 10 инженеров нужно объединять в новую команду, что требует большей координации (14).

Рисунок 2.8. Больше сотрудников, больше клиентов, больше проблем.

3. Каждый инженер добавляет обязательств в общую копилку. Это увеличивает суммарный объем работы, от чего растет нагрузка на инструменты разработки.

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

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

Попробуем включить эти факторы в общие расчеты.

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

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

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

Иногда очень низкая ценность означает отрицательная!

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

Понимание общего воздействия растущей нагрузки сводится к нескольким важным тенденциям:

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

2. Если штат удваивается каждые полгода, то нагрузка увеличивается на порядок каждые 18 месяцев. (А порой появление новых функций или продуктов увеличивает сложность работы гораздо быстрее.)

3. Количество поддерживаемых решений растет с течением времени по мере того, как добавляются команды, а «тривиальные» системы превращаются из неподдерживаемых второстепенных идей в фокусные точки для целых команд, поскольку достигают плато масштабирования (например, ApacheKafka[6]6
  ApacheKafka – распределенный программный брокер сообщений, проект с открытым исходным кодом, разрабатываемый в рамках фонда Apache. – Прим. пер.


[Закрыть], доставка почты, Redis[7]7
  Redis – резидентная система управления базами данных класса NoSQL с открытым исходным кодом, работающая со структурами данных типа «ключ – значение». Используется как для баз данных, так и для реализации кэшей, брокеров сообщений. Ориентирована на достижение максимальной производительности на атомарных операциях. – Прим. пер.


[Закрыть] и т. д.).

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

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

Если для компоновки команд из восьми человек вы проводите по четыре перевода за год, каждый из которых занимает неделю, то общая производительность компании уменьшится примерно на 1 %. Иногда ротация занимает около месяца или возможно перемещение лишь небольшого числа подготовленных инженеров (за чье рабочее время и так ведется жесткая борьба). Тогда воздействие становится более заметным.

Стоит также упомянуть: быстро развивающиеся компании часто работают в рамках жестких, сжатых сроков реализации важных проектов. Такие организации вынуждены переходить на несколько центров обработки данных и действовать по схеме «активный-активный» в новых регионах по всему миру. Но я думаю, что мы в целом достаточно поговорили о том, как увеличение нагрузки на систему может стать препятствием для общей инженерной пропускной способности.

Основной вопрос состоит в том, что нам со всем этим делать?

Из книги «Проект “Феникс”» Джина Кима, Кевина Бера и Джорджа Спаффорда (15) я почерпнул такую идею: вы получаете профит от проектов только тогда, когда они заканчиваются. Чтобы добиться прогресса, прежде всего нужно убедиться, что хотя бы какие-то начатые проекты вы довели до финала.

Легко сказать – но трудно завершить проекты, когда все силы уходят на решение иных задач.

Давайте остановимся на найме персонала, поскольку он с обучением часто отнимает у команды больше всего времени.

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

ЕСЛИ УЖ КОМПАНИЯ РЕШИЛА МАСШТАБИРОВАТЬСЯ, ТО ОСТАНОВИТЬ РОСТ НЕЛЬЗЯ, НО ЕГО ТОЧНО МОЖНО ОБУЗДАТЬ ТАК, ЧТОБЫ В КОМАНДАХ ПЕРИОДЫ РАСШИРЕНИЯ ЧЕРЕДОВАЛИСЬ С ПЕРИОДАМИ АДАПТАЦИИ.

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

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

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

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

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

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

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

Рисунок 2.9. Соискатели получают офферы, становятся новыми сотрудниками, а затем проходят обучение.

Есть конкретный инструмент, который я нахожу чрезвычайно полезным – создание реестра владельцев проектов и ответственных за задачи. Он помогает найти, кому принадлежит проект, разобраться, кто за что в ответе, устраняет частые вопросы типа: «Кого спросить по поводу X?» Его наличие пригодится и при привлечении временных сотрудников, так что вы можете извлечь двойную выгоду!

ЛУЧШИЙ СПОСОБ ИЗБАВИТЬСЯ ОТ ОТВЛЕКАЮЩИХ ФАКТОРОВ – ЭТО КУЛЬТУРА ВЕДЕНИЯ НОРМАТИВНОЙ БАЗЫ, ЧТЕНИЯ И ПОИСКА НУЖНЫХ МАТЕРИАЛОВ, КОТОРЫЕ ДЕЙСТВИТЕЛЬНО ПОЛЕЗНЫ.

Аналогичный вариант – запросы на проведение незапланированных встреч. Оптимально выделять по несколько больших временных отрезков каждую неделю, когда вы точно будете доступны и не будете заняты другими важными делами. Способ выделения может варьироваться: удаленная работа по четвергам, отключение оповещений по понедельникам и средам во второй половине дня, отключение сообщений каждое утро с 8 до 11. Поэкспериментируйте немного и найдите то, что вам подходит.

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

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

На мой взгляд, вероятно, самое важное – сделать разработку программного обеспечения адаптивной. Я описал это как «сбой политики открытия и слоя». Лучшее изменение системы – то, которое не произошло. Если вы сможете избежать принятия произвольных решений, часто меняющихся с течением времени, у вас будет гораздо больше шансов продолжать использование системы в долгосрочной перспективе.

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

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

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

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