Стратегия горизонтального переноса опыта

Мутации и секс далеко не единственные существующие в природе способы, позволяющие биологическим видам передвигаться по адаптивным ландшафтам. В частности, существует третья стратегия, чья роль в эволюции многоклеточных организмов до последнего времени недооценивалась, хотя, по-видимому, в мире бактерий она всегда играла существенную роль. Имеется в виду горизонтальный перенос генов (ГПГ).

Микробы обмениваются друг с другом генной информацией, выбрасывая геномный материал. Исследования показывают, что 10% геномов бактерий заимствованы у других видов бактерий, и это типичный показатель. Известный микробиолог Карл Вёзе даже полагает, что горизонтальная генная передача была доминирующей формой эволюции до тех пор, пока у многоклеточных организмов не закрепилось половое размножение [Buchanan 2010: 34–37]. Считается, что беспорядочное распространение генетического кода среди разных видов позволило создать «объединенный генетический механизм», что в свою очередь позволило с большей легкостью видам делиться друг с другом инновациями.

Бактерии крайне расточительны и неразборчивы в том, что касается обмена генами — они практикуют истинный генетический коммунизм. <…> Иногда бактерии занимаются «сексом», обмениваясь генетическим материалом через межклеточные «мостики». В других случаях просто происходит выброс содержащих генный материал плазмид и вирусоподобных фрагментов, адресованных «всем и никому конкретно». В том и другом случае результатом становится свободный обмен генной информацией. Одно из следствий такого обмена генами — гораздо бóльшая коллективная адаптивность[100].

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

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

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

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

Вы хотите сказать, что состав команд должен постоянно меняться? Вообще-то нет, я несколько преувеличил. Первый год может быть посвящен оптимизации структуры команд, следующий — стандартным процессам, а затем оптимизации уровней управления или бизнес-единиц. В здоровой организации какие-то из ее частей всегда находятся в стадии (ре)формирования. Я не хочу сказать, что состав команд должен постоянно меняться. Это противоречит требованию, что команды должны оставаться стабильными достаточно протяженный промежуток времени, о чем более подробно сказано в главе 13.

Компьютерные симуляции показывают, что комбинация мутаций, кроссинговера и горизонтального переноса — прекрасный способ достичь глобального оптимума эффективности [Buchanan 2010: 36]. Мы имеем право предположить, что то же самое применимо к командам и организациям. Используйте метод мутаций, чтобы создавать инновации. Пользуйтесь горизонтальным переносом, чтобы копировать инновации у других команд. И применяйте метод кроссинговера для создания новых практик путем комбинирования уже известных.

Но биологические виды далеко не то же самое, что бизнес! Это правда. Биологические изменения — ненаправляемые, в то время как оптимизация в бизнесе — направляемая (см. конец главы 14 «Ландшафт изменений»). Биологические виды производят потомство с большим запасом, чтобы из него одна или две особи в конце концов пошли в нужном направлении. В бизнесе для достижения аналогичных результатов мы можем воспользоваться прогнозированием. При этом как биологические виды, так и бизнес могут процветать, а могут и потерпеть неудачу. С точки зрения практических результатов я не вижу разницы между ненаправляемыми и направляемыми изменениями.

Не копируйте улучшения

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

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

Примеры?

«Не надо заключать контракты с фиксированной ценой и фиксированным объемом разработки, потому что…»

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

«Не нужно начинать с объемных и детализированных требований к продукту, поскольку…»

Возможно, но клиент только что вручил мне технические требования на 500 страниц и готов платить за то, чтобы я их реализовал. Советуете мне отказаться от этого проекта?

«Команды должны быть кросс-функциональными и располагаться в одном помещении, при этом в них должны быть собраны специалисты всех необходимых профилей, потому что…»

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

«Продолжительность итераций должна составлять две недели, потому что…»

Да, но в чем польза от этого совета, если у меня краткосрочный проект, который продлится как раз две недели?

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

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

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

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

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