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

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

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

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

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

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

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

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

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

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

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

Устанавливайте границы между командами в соответствии с законом Конвея