Текст книги "Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях"

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

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

Как отметил Кристофер Литл, технический администратор и один из самых первых летописцев DevOps, «антропологи описывают инструменты как культурные артефакты. Любое обсуждение культуры после приручения огня должно также сопровождаться обсуждением инструментов». Точно так же в потоке создания ценности DevOps мы используем инструменты для укрепления культуры и ускорения желаемых изменений поведения.

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

Действуя таким образом, разработчики и IT-отдел могут в конечном счете создать общую очередность работ, вместо того чтобы каждый использовал свою систему (например, разработчики используют JIRA, а отдел эксплуатации – ServiceNow). Значительное преимущество такого решения в том, что инциденты на производстве регистрируются в той же системе, что и текущая работа, и очевидно, что при наличии в системе инцидентов следует прекратить другую деятельность, особенно если мы используем доску канбан.

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

Другие технологии, укрепляющие общие цели, – чаты, например IRC, HipChat, Campfire, Slack, Flowdock и OpenFire. Чат позволяет быстро обмениваться информацией (в отличие от заполнения форм, обрабатывающихся с помощью предварительно определенных рабочих процессов), дает возможность пригласить других специалистов по мере необходимости и вести журналы истории, заполняющиеся автоматически. Они могут быть проанализированы при разборе событий.

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

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

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

Заключение

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

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

Глава 7. Как проектировать организацию и ее архитектуру, не забывая о законе Конвея

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

В этой главе мы начнем разбираться, как лучше организовать себя для достижения целей потока создания ценностей. В конце концов то, как мы организуем команду, повлияет на то, как мы будем работать. В 1968 году доктор Мелвин Конвей провел известный эксперимент в контрактной исследовательской организации. Восьми сотрудникам было поручено написать компиляторы языков COBOL и ALGOL. Он отметил: «После некоторых первоначальных оценок сложности и необходимого времени пять человек были назначены на написание компилятора COBOL, и три – компилятора ALGOL. В результате компилятор COBOL выполнял компиляцию в пять проходов, компилятор ALGOL – в три».

Эти наблюдения послужили основой того, что сейчас называют законом Конвея, гласящего: «Организации, проектирующие системы… производят их, копируя структуры коммуникаций, сложившиеся в этих организациях… Чем крупнее организация, тем менее она гибкая и тем сильнее выражен характер этого явления». Эрик Реймонд, автор книги The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, придумал упрощенный (и сейчас более известный) вариант закона Конвея, изложенный в словаре Jargon File[46]46
  Сетевой энциклопедический словарь хакерского сленга на английском языке. Содержит более 2300 словарных и обзорных статей по хакерскому сленгу и хакерской культуре. Первым составителем словаря был Рафаэль Финкель. В настоящее время Jargon File поддерживается Эриком Реймондом. Прим. перев.


[Закрыть]: «Организация программного обеспечения и организация команды разработчиков программного обеспечения будут совпадать»; обычно упрощается до «если над компилятором работают четыре группы, то получите четырехпроходный компилятор».

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

Пример того, как закон Конвея может либо препятствовать достижению целей, либо способствовать этому, можно найти в технологии Sprouter, разработанной компанией Etsy. Etsy начала использовать DevOps в 2009 г. Сейчас она одна из наиболее уважаемых организаций с DevOps, в 2014 г. получила доход в размере почти 200 миллионов долларов и успешно провела IPO в 2015 г.

Первоначально разработанная в 2007 г., Sprouter соединяла людей, процессы и технологии. Способы соединения нередко приносили нежелательные результаты. Sprouter, сокращение английской фразы stored procedure router (маршрутизатор хранимых процедур), была первоначально разработана для облегчения жизни разработчиков и групп, поддерживающих базы данных. Как заявил во время своей презентации на конференции Surge 2011 Росс Снайдер, старший инженер компании Etsy, «Sprouter была разработана, чтобы команды разработчиков могли писать код PHP для приложений, а администраторы баз данных – запросы SQL в Postgres и Sprouter помогала бы им встретиться на середине этих процессов».

Sprouter размещался между фронтэнд-приложениями PHP и базой данных Postgres, обеспечивая централизованный доступ к базе данных и скрывая реализацию БД от приложений прикладного уровня. Проблема в том, что внесение любых изменений в бизнес-логику приводило к значительным трениям между разработчиками и администраторами баз данных. Как заметил Снайдер, «почти для любой новой функциональной возможности сайта требовалось, чтобы администраторы баз данных написали для Sprouter новую хранимую процедуру. В результате каждый раз, когда разработчики хотели добавить новые функциональные возможности, им было необходимо содействие администраторов баз данных, а его нередко нельзя получить, минуя множество бюрократических процедур». Другими словами, существует зависимость разработчиков, создающих новые функциональные возможности, от администраторов баз данных. Задачи, порожденные этой зависимостью, должны в списке приоритетных быть скоординированы с разработчиками и осуществляться во взаимодействии с ними. В результате работа ждет своей очереди, время тратится на совещаниях, а итог появляется намного позже, чем мог бы. Это происходит из-за того, что Sprouter создал тесную взаимосвязь между разработчиками и администраторами баз данных, не давая разработчикам возможность самостоятельно разрабатывать, тестировать и развертывать их код в производство.

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

Обе проблемы связаны со Sprouter, и их возможное решение может быть объяснено законом Конвея. В компании Etsy первоначально было две команды, разработчики и администраторы баз данных. Каждая отвечала за два уровня служб: уровень логики приложений и уровень хранимых процедур. Две группы работали над двумя уровнями именно так, как предсказывает закон Конвея. Sprouter был предназначен для облегчения жизни обеим командам, но он работал не так, как ожидалось: стоило бизнес-правилам измениться, как вместо изменений на двух уровнях потребовались изменения в трех (приложение, процедуры, а теперь еще и в Sprouter). В результате сложность координации и определения приоритетности между тремя командами значительно возросла и вызвала проблемы с надежностью.

Весной 2009 г. в ходе того, что Снайдер называл «великим культурным преобразованием в компании Etsy», к компании в качестве технического директора присоединился Чад Дикерсон. Дикерсон привел в движение множество вещей, включая крупные инвестиции в стабильность сайта, дал разработчикам возможность самостоятельно выполнять развертывание кода в производство, а также начал занявшую два года ликвидацию Sprouter.

Для этого команда решила переместить всю обработку бизнес-логики из уровня базы данных на уровень приложений, устраняя необходимость Sprouter. Исполнители создали небольшую группу, написавшую на языке PHP уровень объектно-реляционного сопоставления (ORM – Object Relational Mapping)[47]47
  Помимо прочего, ORM выполняет абстрагирование базы данных, что позволяет разработчикам выполнять запросы и манипулировать данными, как если бы эти данные были просто еще одним объектом в языке программирования. Среди популярных ORM – Hibernate для Java, SQLAlchemy для Python и ActiveRecord для Ruby on Rails. Прим. авт.


[Закрыть], что позволило разработчикам внешнего интерфейса обращаться непосредственно к базе данных и сократило число команд, задействованных в изменении бизнес-логики, с трех до одной.

Как описывал Снайдер, «мы начали использовать ORM для любых новых областей сайта и постепенно переносили небольшие части нашего сайта из Sprouter в ORM. Нам потребовалось два года для переноса всего сайта и отключения Sprouter. И хотя все это время мы недовольно ворчали на Sprouter, он, несмотря на это, оставался в производственной среде».

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

Sprouter был удален из производственной среды и репозиториев версионного контроля компании Etsy в 2001 г. Как сказал Снайдер, «класс! Отличные ощущения!»[48]48
  Sprouter был одной из многих технологий, использовавшихся в процессах разработки и производства, которые были отброшены компанией Etsy в ходе преобразований. Прим. авт.


[Закрыть].

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

Архетипы организационной структуры

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

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

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

• Организации, ориентированные на рынок, нацелены быстро реагировать на потребности клиентов. Как правило, структура таких организаций плоская, состоящая из нескольких кросс-функциональных направлений (например, маркетинга, проектирования и т. д.), что зачастую приводит к потенциальной избыточности во всей организации. Именно такой метод применяется во многих известных компаниях, внедривших принципы DevOps. Яркие примеры – Amazon и Netflix: каждая команда одновременно отвечает и за реализацию функций доставки, и за поддержку[49]49
  Однако, как будет пояснено позднее, другие не менее известные компании, такие как Etsy и GitHub, имеют функциональную ориентацию. Прим. авт.


[Закрыть].

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

Проблемы часто бывают вызваны чрезмерно функциональной ориентацией («оптимизацией затрат»)

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

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

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

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

Тупиковая ситуация препятствует достижению важных целей организации, что зачастую значительно перевешивает стремление к сокращению расходов[50]50
  Адриан Кокрофт отметил, что «для компаний, которые в настоящее время отказываются от пятилетних контрактов на IT-аутсорсинг на внешний подряд, это выглядит, как если бы они были заморожены на эти годы, одни из наиболее прорывных в технологии». Другими словами, IT-аутсорсинг – это тактика экономии затрат через обусловленное контрактом помещение в стазис, с твердой фиксированной ценой, предусмотренной графиком ежегодного сокращения расходов. Однако часто это приводит к тому, что организация оказывается не в состоянии реагировать на меняющиеся потребности бизнеса и технологий. Прим. авт.


[Закрыть].

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

Создать условия для команд, ориентированных на рынок («оптимизация скорости»)

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

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

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

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


[Закрыть].

Создание функционально ориентированной работы

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

Рис. 12. Сравнение функциональной и рыночной ориентаций.

Слева: функциональная ориентация – все рабочие потоки проходят через централизованный отдел IT-эксплуатации; справа: рыночная ориентация – все продуктовые команды могут самостоятельно развертывать в производство свои компоненты, слабо связанные с другими (источник: Humble, Molesky, and O’Reilly, Lean Enterprise, Kindle edition, 4523 & 4592).

Например, высокая производительность с функционально ориентированной и централизованной IT-группой возможна, если сервисные команды гарантированно и быстро получают то, что им необходимо (в идеале – по первому требованию), и наоборот. Многие из наиболее известных организаций, использующих DevOps, в том числе компании Etsy, Google и GitHub, сохраняют функциональную ориентацию отдела эксплуатации.

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

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

Как писал Майк Ротер в уже упоминавшейся книге «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов», «как бы соблазнительно это ни казалось, нельзя реорганизовать путь к постоянному совершенствованию и приспосабливаемости. Решающий фактор – не форма организации, а то, как люди действуют и реагируют. Корни успеха компании Toyota лежат не в организационной структуре, но в развивающихся возможностях и особенностях ее работников. Это удивляет многих, обнаруживающих, что компания Toyota в основном организована традиционно – как система функциональных отделов». Развитие привычек и возможностей у отдельных инженеров и у персонала в целом будет рассматриваться в следующих разделах.

Тестирование, эксплуатация и безопасность – повседневная работа каждого

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

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

С учетом общих целей и разработчиков, и отдела эксплуатации технический директор компании Ticketmaster Джоди Малки заявил: «Почти 25 лет я использовал метафоры из американского футбола для описания разработчиков (Dev) и эксплуатации (Ops). Вы знаете, что Ops – это оборона, не дающая пропускать голы, а Dev – нападение, старающееся голы забивать. И в один прекрасный день я понял, как ошибочна эта метафора: они никогда не играют одновременно. Фактически они даже не одна команда!»

Он продолжает: «Теперь я использую другие аналогии. Ops – игроки нападения, а Dev – квотербеки и принимающие игроки, чья деятельность заключается в перемещении мяча по полю. Задание Ops – обеспечить Dev достаточно времени для надлежащего проведения игры».

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

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

Каждый член команды может стать универсалом

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

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

Одна из контрмер – поощрять стремление каждого члена команды стать универсалом. Мы делаем это, предоставляя инженерам возможность приобрести навыки, необходимые для создания систем, за которые они отвечают, путем регулярной ротации сотрудников по разным ролям. Термин «специалист по комплексной разработке» (full stack engineer) в настоящее время часто используется (иногда как богатая тема для пародий) для описания специалиста широкого профиля, знакомого со всем набором используемых приложений (например, языком, на котором написаны коды приложений, баз данных, операционных систем, сетевых решений, облаков) или по крайней мере имеющего понимание всего этого на базовом уровне.

Таблица 2. Сравнение узких специалистов с универсалами и с «Е-образными» сотрудниками (опыт, знания, исследования и выполнение)

Источник: Scott Prugh, страница Continuous Delivery на сайте ScaledAgileFramework.com, 14 февраля 2013 г., https://www.scaledagileframework.com/guidance-continuous-delivery/.

Скотт Праф писал, что компания CSG International претерпела трансформацию, обеспечившую нужные ресурсы для создания и запуска продукта в рамках одной команды, включая анализ, проектирование, разработку, тестирование и внедрение в производство. «Благодаря кросс-профессиональной подготовке и улучшающимся инженерным навыкам универсалы могут выполнять заказы с большим объемом, чем их коллеги-специалисты, а также увеличивают общий поток задач благодаря устранению очередей и времени ожидания». Этот подход идет вразрез с традиционной практикой найма, но, как объясняет Праф, оно того стоит. «Традиционные руководители будут часто возражать против найма на работу инженеров с универсальным набором навыков, утверждая, что они обходятся дороже и что гораздо разумнее нанять двух администраторов серверов вместо одного инженера-универсала. Однако преимущества, которые дает бизнесу возможность ускорения протекания потока деятельности, перевешивают». Кроме того, как отмечает Праф, «вложения в кросс-профессиональное обучение правильны для карьерного роста сотрудников и делают работу каждого более приятной».

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

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

Как писал Джейсон Кoкс, директор по разработке систем в компании Disney, «в отделе эксплуатации мы должны были изменить методы найма. Мы искали людей, обладавших “любопытством, мужеством и откровенностью”, которые могут быть не только универсалами, но также теми, кто отвергает общепринятые взгляды… мы хотим поощрять положительные потрясения, с тем чтобы наш бизнес не топтался на месте, а мог двигаться в будущее». Как мы увидим в следующем разделе, то, как мы вкладываемся в команды, тоже влияет на результаты.

Финансируйте не проекты, а сервисы и продукты

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