Микробы обмениваются друг с другом генной информацией, выбрасывая геномный материал. Исследования показывают, что 10 % геномов бактерий заимствованы у других видов бактерий, и это типичный показатель. Известный микробиолог Карл Вёзе даже полагает, что горизонтальная генная передача была доминирующей формой эволюции до тех пор, пока у многоклеточных организмов не закрепилось половое размножение [Buchanan 2010: 34–37]. Считается, что беспорядочное распространение генетического кода среди разных видов позволило создать «объединенный генетический механизм», что в свою очередь позволило с большей легкостью видам делиться друг с другом инновациями.
Бактерии крайне расточительны и неразборчивы в том, что касается обмена генами – они практикуют истинный генетический коммунизм. ‹…› Иногда бактерии занимаются «сексом», обмениваясь генетическим материалом через межклеточные «мостики». В других случаях просто происходит выброс содержащих генный материал плазмид и вирусоподобных фрагментов, адресованных «всем и никому конкретно». В том и другом случае результатом становится свободный обмен генной информацией. Одно из следствий такого обмена генами – гораздо бóльшая коллективная адаптивность
[100].
Существует ли способ распространить эту идею на команды разработчиков? Да, и, судя по всему, мы постоянно им пользуемся. Команды делятся друг с другом лучшими практиками, обмениваются сотрудниками, копируют и обсуждают свой опыт работы с теми или иными инструментами. Иногда это происходит в личных беседах, в других случаях информация распространяется в виде статей, блогов, презентаций или подкастов, «адресованных всем и никому конкретно». (Судя по всему, и эта книга – пример горизонтального переноса информации в действии!)
Недавние исследования показывают, что наиболее успешная стратегия – копирование идей. В ходе различных экспериментов выяснилось, что наиболее успешные агенты проводят почти все имеющееся у них время, наблюдая за другими агентами, а не занимаясь инновациями [McLeod 2010]. По-видимому, это означает, что командам следует инвестировать максимум времени, отводимого на обучение, копированию идей из разных источников. И лишь немного времени должно уделяться изобретению своих собственных идей.
Мне представляется очевидным, что организации должны применять все три стратегии для постоянного улучшения: мутации, кроссинговер и горизонтальную передачу. Мутации необходимы при осуществлении постепенных улучшений в неизвестных и потенциально опасных ландшафтах. Кроссинговер нужен для осуществления более радикальных изменений путем комбинирования методов и команд, которые уже достаточно эффективны. А горизонтальный перенос требуется для копирования практик между командами, что позволит им сдвигаться в «новых» направлениях, которые уже знакомы остальным (рис. 15.7).
Применение этих трех стратегий на практике означает, что вы должны разрешить командам использовать ретроспективы (или другие форматы) для исследования соответствующих адаптивных ландшафтов путем внесения изменений в функциональность, применяемые практики, инструменты, графики и бизнес-ценность. На другом уровне вы используете «постоянную реорганизацию» и комбинируете лучшие команды и проектные практики, пытаясь понять, можно ли этим путем создать «потомство», которое будет более эффективно. В рамках третьей стратегии для достижения более высокой глобальной эффективности происходит интенсивное копирование и обмен идеями, людьми и инструментами.
Вы хотите сказать, что состав команд должен постоянно меняться?
Вообще-то нет, я несколько преувеличил. Первый год может быть посвящен оптимизации структуры команд, следующий – стандартным процессам, а затем оптимизации уровней управления или бизнес-единиц. В здоровой организации какие-то из ее частей всегда находятся в стадии (ре)формирования.
Я не хочу сказать, что состав команд должен постоянно меняться. Это противоречит требованию, что команды должны оставаться стабильными достаточно протяженный промежуток времени, о чем более подробно сказано в главе 13.
Компьютерные симуляции показывают, что комбинация мутаций, кроссинговера и горизонтального переноса – прекрасный способ достичь глобального оптимума эффективности [Buchanan 2010: 36]. Мы имеем право предположить, что то же самое применимо к командам и организациям. Используйте метод мутаций, чтобы создавать инновации. Пользуйтесь горизонтальным переносом, чтобы копировать инновации у других команд. И применяйте метод кроссинговера для создания новых практик путем комбинирования уже известных.
Но биологические виды далеко не то же самое, что бизнес!
Это правда. Биологические изменения – ненаправляемые, в то время как оптимизация в бизнесе – направляемая (см. конец главы 14 «Ландшафт изменений»).
Биологические виды производят потомство с большим запасом, чтобы из него одна или две особи в конце концов пошли в нужном направлении. В бизнесе для достижения аналогичных результатов мы можем воспользоваться прогнозированием. При этом как биологические виды, так и бизнес могут процветать, а могут и потерпеть неудачу. С точки зрения практических результатов я не вижу разницы между ненаправляемыми и направляемыми изменениями.
Не копируйте улучшения
В предыдущей главе я предупреждал вас, что нельзя слепо копировать «лучшие» практики или следовать советам консультантов без учета конкретного контекста. Адаптивный ландшафт других команд может отличаться от вашего. Горизонтальный перенос – отличная стратегия, но он требует, чтобы вы удостоверились, что в вашей ситуации данные инновации имеют смысл.
Меня беспокоит, когда люди заимствуют мнения и аргументы других, не адаптируя их к своему локальному контексту. Некоторые забывают провести анализ ситуации, прежде чем применять скопированные идеи. А некоторые обвиняют других в том, что подход первых к разработке ПО неверен, не удосужившись проверить, смогут ли их собственные идеи выжить в контексте, в котором функционирует обвиняемый. Можно назвать это копипастом улучшений.
Примеры?
«Не надо заключать контракты с фиксированной ценой и фиксированным объемом разработки, потому что…»
Звучит разумно, но мне от этого не легче, поскольку мои клиенты заключают только такие контракты. Вы рекомендуете мне прикрыть свой бизнес?
«Не нужно начинать с объемных и детализированных требований к продукту, поскольку…»
Возможно, но клиент только что вручил мне технические требования на 500 страниц и готов платить за то, чтобы я их реализовал. Советуете мне отказаться от этого проекта?
«Команды должны быть кросс-функциональными и располагаться в одном помещении, при этом в них должны быть собраны специалисты всех необходимых профилей, потому что…»
