Сейчас я являюсь старшим инженером в Google, а до этого работал в качестве ведущего инженера в Amazon. Многие задачи, которыми я занимаюсь последние несколько лет, касаются того, как замотивировать людей что-то сделать. Больше всего мне приходится работать именно над человеческими (а не техническими) проблемами, и именно они имеют наибольшое значение. Я выбрал неруководящий путь лидерства, который подразумевает, что я веду команду за собой без формальных полномочий — поэтому для меня было очень важно разработать инструменты эффективного влияния.

Я создал и развил внутреннюю платформу для тестирования нагрузки и производительности в Amazon (TPSGenerator). Я начал работать над ней в 2013 году, а к моменту моего ухода в 2020 году её использовали десятки тысяч человек в критически важных для бизнеса приложениях; она выполняла сотни миллионов транзакций в секунду и поддерживалась командой отличных инженеров. Эта платформа помогла предотвратить сотни проблем в работе и сэкономить миллионы долларов.

В начале своей карьеры я читал книги исключительно на технические темы. Сейчас же я читаю литературу по трём категориям: те же книги на технические темы, бизнес-литературу, а также книги по психологии. Из третьей категории меня недавно впечатлила книга «Switch: Как изменить ситуацию, когда перемены трудны» Чипа Хита (профессора Стэнфорда) и его брата Дэна Хита (профессора Университета Дьюка). В ней изложена концепция изменения поведения. Дело в том, что мы склонны думать, будто в нашем распоряжении всего два инструмента: пряник и кнут — то есть замотивировать человека что-то сделать или прибегнуть к какой-то форме наказания, если он этого не сделает. Фреймворк Switch же гораздо сложнее. Что удивительно: я, ранее не слышав об этой книге, следовал данной формуле, причём органично и в основном интуитивно. И она отлично работала для меня.

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

Моя история началась ещё в далёком 2012 году. В «Чёрную пятницу», самый напряженный день для электронной коммерции в году, сервис, за который я отвечал, столкнулся с проблемами в работе из-за высокой нагрузки — и это повлияло на всю работу amazon.com. По моей вине произошёл многомиллионный перебой. Я буквально сгорал от чувства вины за произошедшее и решил как-то искупить её. Поэтому потратил месяцы на то, чтобы понять, как увеличение нагрузки влияет на распределённые системы в больших масштабах, и создал код и инфраструктуру для моделирования высокой нагрузки в целях тестирования. Я обнаружил и предотвратил серьёзные проблемы в работе в «Чёрную пятницу» в 2013 году, поэтому можно было считать, что я реабилитировался. Но к тому времени я как бы прозрел. У всех инженеров было намерение провести нагрузочное тестирование своего сервиса. Однако большинство из них не успевали этого делать — создание инфраструктуры для проведения тестов требовало слишком много времени. Предположим, люди этого не делали, потому что это занимало 3 недели. А если бы это заняло 3 дня? А что, если это займёт вообще 3 часа? Я полагал, что в какой-то момент смогу найти точку перегиба — когда какая-то важная задача, из-за стоимости выполнявшаяся редко, может стать просто ещё одной задачей, которая выполняется каждый день без особых усилий.

И я создал свой инструмент. Лихорадочно кодировал, в основном по выходным и по ночам, написал десятки тысяч строк на Java. Я делал это из своего интереса, но при этом чувствовал, что создал нечто особенное, и хотел бы, чтобы это понравилось и другим. Несколько первых последователей действительно увидели перспективу, а некоторые даже присоединились ко мне в процесе создания. В конце концов мы открыли его для широкого потребления на Amazon. Поначалу внедрение было скромным: его использовал случайный инженер то тут, то там. Я с гордостью вёл учёт и однажды показал результаты своему вице-президенту. Думаю, к тому времени у меня было около 25 клиентов. Однако вице-президент не оказался особенно впечатлен: «Твой график внедрения линейный. Это полная фигня. Приходи, когда он станет экспоненциальным!» Это было достаточно грубо, но он на самом деле был классным парнем и в конечном счёте был прав. Мне действительно стоило мыслить шире и делать более смелые шаги.

Вот тут мне на помощь и пришла концепция Switch. По сути, я столкнулся с нетехнической проблемой: мне нужно было, чтобы люди изменились, а меняться всегда трудно. Чтобы лучше понять концепцию Switch, прибегнем к визуальной метафоре: представьте себе наездника, ведущего слона по тропе (пути). По сути, вы можете влять на три фактора: [a] направлять Наездника, [б] мотивировать Слона или [в] формировать Путь. Наездник — это логическая часть нашего мозга: он рационален, он обдумывает и анализирует. Слон символизирует наши эмоции: он действует на основе инстинктов, боли или удовольствия. Кто же из них является лидером? Наездник весит 150 фунтов, а слон — 10 000 фунтов. Поэтому если наездник задаёт направление, то слон даёт энергию. Они должны в какой-то степени работать вместе.

Управление Наездником

Давайте поговорим о первом факторе. Есть три инструмента для управления наездником: [a] Определение светлых пятен, [b] Составление сценария критических движений и [c] Указание на место назначения.

Чтобы понять, что значит «определение светлых пятен», представьте себе классную комнату с кучей плохо ведущих себя детей. Учитель может прибегнуть к наказаниям, но это утомительно и часто не меняет их поведения. В качестве альтернативы учитель фокусируется на хорошо ведущих себя учениках и подчеркивает их достижения. Таким образом, принцип «поиска светлых пятен (положительных моментов)» позволяет переключить внимание с вопроса «Что сломалось и как это исправить?» на вопрос «Что работает и как это можно масштабировать?». В моём случае я много рассказывал о своей системе всем, кто меня слушал. Большинство людей улыбались и вежливо кивали, но не взаимодействовали с ней. Это немного деморализовывало. Но некоторые всё же решились. Какая-то часть из них действительно полюбила инструмент и добилась потрясающих результатов с его помощью. Например, они поняли, что их сервис излишне масштабирован, и сократили выделенные на него ресурсы (тем самым сэкономив деньги), или наоборот поняли, что их сервис недостаточно масштабирован, и исправили это (тем самым избавившись от операционных проблем). Я стал собирать эти истории успеха, и в конце концов у меня вышло целых двадцать страниц кейсов, которые говорили примерно следующее: «Я использовал этот инструмент, он мне очень понравился, и вот моя история». Я разместил ссылку на истории на главной странице документации по продукту, чтобы все желающие могли ознакомиться. Это был хороший артефакт для продвижения.

Чтобы понять, что такое «составление сценария критических движений», представьте себе два киоска на рынке. В одном из них 6 сортов варенья. В другом киоске 18 вкусов варенья — те 6 и 12 других. Какому киоску удаётся продать больше варенья? Удивительно, но киоск с 6 вкусами продаёт в 10 раз больше варенья, чем киоск с 18 вкусами. Как такое возможно? Ну, когда дорога неопределённа, у Наездника возникает паралич анализа, а Слон выбирает наиболее знакомый путь (который часто поддерживает статус-кво: ничего не делать).

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

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

Чтобы понять, что такое «Указание на место назначения», вспомните Джона Кеннеди, который в 1962 году выдвинул идею: «К концу десятилетия мы посадим человека на Луну». Это было смелое видение, но оно вдохновило целое поколение инженеров NASA, и в 1969 году мы действительно высадились на Луне. Билл Гейтс в 1980 году сказал: «Компьютер будет на каждом столе и в каждом доме», и это вдохновило несколько поколений инженеров Microsoft, включая меня, в девяностые годы. Указывая на место назначения (цель), вы делаете две вещи: [а] показываете Наезднику, куда вы двигаетесь, и [б] показываете Слону, почему путешествие стоит того. Мне не нравилось садиться в самолет с двумя маленькими детьми в Сиэтле и совершать пересадку в Далласе, но я знал, что через несколько часов буду сидеть на тропическом пляже на Ямайке и потягивать пина коладу. В моем конкретном случае на работе я указывал на такой пункт назначения — «Запуск нагрузочного тестирования за 2 дня». Эта цель была привлекательна для инженеров, которые не хотели тратить многие недели на эту работу.

Мотивирование Слона

Теперь перейдём к «мотивированию слона». Для этого есть три инструмента: [a] Пробуждение эмоций, [б] Упрощение и [в] Развитие людей.

Чтобы понять, что значит пробудить эмоцию, вспомните все кампании по борьбе с курением, которые вы когда-либо встречали. Курильщики прекрасно осознают, что курение вредно. Вам не нужно объяснять это Наезднику — вам нужно напугать Слона. Поэтому кампании по борьбе с курением в первую очередь направлены на эмоциональный отклик. Они показывают, как выглядят лёгкие после десятилетия курения. Или курильщика, которому удалили гортань, и он говорит через искусственный голосовой аппарат. В моём же случае я стремился вызвать чувство гордости. Инженеры гордятся эффективностью: это заложено в нашем мозгу и в обучении. Когда, будучи инженером, вы предотвращали операционную проблему из-за недостаточного масштабирования или могли уменьшить аппаратную нагрузку на излишне масштабированный сервис, вы испытывали гордость. Рассказывая о таких историях успеха, я не только находил положительные моменты, но и помогал потенциальным клиентам почувстовать эмоцию. Думаю, эти истории успеха вдохновили и побудили целое поколение амазонцев взять на вооружение мой инструмент.

Чтобы понять, что такое Упрощение, поразмышляйте о том, как заставить своих детей убраться в комнате. В комнате жуткий беспорядок, задача кажется им непосильной, поэтому они и не приступают к ней. Но если вы скажете, например: «Соберите за 10 минут 20 вещей!», это будет легко и выполнимо, верно? Слона легко деморализовать большими задачами, поскольку он ненавидит дела, не приносящие немедленной отдачи. Поэтому чтобы замотивировать людей, дайте им почувствовать, что они ближе к финишу, чем они могли подумать! В моём случае я поступил следующим образом. Во-первых, я сосредоточился на упрощении процесса регистрации и онбординга пользователей. Изначально процесс запуска среды нагрузочного тестирования был довольно запутанным; в итоге я свёл его к пяти текстовым полям и нескольким щелчкам мыши. Также изначально пользователю требовалось написать для генератора нагрузки кучу кода; затем я ввёл аннотации Java, которые убрали кучу шаблонов; в итоге я сделал платформу полностью совместимой с TestNG и JUnit, чтобы юзер мог использовать существующий код повторно. Я также организовал двухчасовой практический буткемп: люди приходили, слушали меня, выполняли несколько практических упражнений и через два часа уходили с работающим нагрузочным тестом. Ну правда, кто не может выделить на решение задачи всего два часа? На этом я не остановился и масштабировал идею буткемпа, найдя других людей, которые также могли преподавать на курсе — и к моменту моего ухода из Amazon мы обучили 1400 человек в 15 странах.

Итак, у вас есть люди и изменения, которые вы хотите провести. Если вы не можете упростить процессы, вы в любом случае можете развивать людей. Кеннеди, например, сделал это блестяще: «Не спрашивай, что твоя страна может сделать для тебя; спроси, что ты можешь сделать для своей страны?» — это было вдохновение, в котором нуждалась наша страна. Люди — стадные животные. Сталкиваясь с какой-то ситуацией, мы задаём себе три вопроса: [1] Кто я? [2] Что это за ситуация? И, самое главное, [3] Что бы сделал такой человек, как я, в подобной ситуации? Итак, мне нужно было обратиться к моим потенциальным клиентам с призывом стать тем человеком, который сможет провести нагрузочное тестирование их продукта. Это было несложно. Я вновь и вновь старался донести до них такое послание: «Вы — инженер Amazon. Amazon нанимает самых умных инженеров в мире для работы над самыми сложными проблемами масштабирования в мире; и амазонцы гордятся тем, что проводят нагрузочное тестирование своего продукта, чтобы убедиться, что он масштабируется так, как должны масштабироваться продукты Amazon». Я также откровенно и часто рассказывал свою историю неуспеха о том, как я не провёл нагрузочное тестирование продукта, и он потерпел неудачу в самый напряженный день покупок в году. «Не будьте как я, будьте другим человеком!» — это было сильное послание.

Формирование Пути

Итак, мы поговорили о Наезднике и Слоне. Третий фактор — «Формирование пути». Здесь вы также можете кое-что сделать.

Во-первых, вы можете Изменить окружение. Позвольте мне проиллюстрировать это на примере. Когда я путешествовал по Индии, меня завораживала динамика оживлённого перекрестка. Масса людей: машины, рикши, верблюды, слоны, велосипеды, мотоциклы, пешеходы — все они как-то ориентируются в этом хаосе. Выглядит это не особенно упорядоченно. После нескольких недель путешествия по Индии я возвращаюсь в США, и порядок на улицах становится для меня культурным шоком. Мы все люди; почему же одна группа людей ведёт себя иначе, чем другая? Подумайте обо всех мелочах в США, которые меняют эту среду: уличное освещение, знаки «стоп», полосы для разворота, использование водителями сигналов поворота, отдельные полосы для велосипедов, тротуары для пешеходов, светофоры и штраф за переход на красный свет. Настроив окружающую среду определённым способом, можно добиться от людей определённого поведения.

Скажу пару слов о том, как это воплощается в моей платформе для нагрузочного тестирования. Хотя изначально оно выполнялось с помощью инструмента командной строки, я сделал интеграцию с CI/CD инструментарием от Amazon, Pipelines — чтобы нагрузочное тестирование можно было легко добавить в качестве этапа в цикл выпуска релизов разработки. Pipelines организует весь цикл: пользователь сохраняет кусок кода, он автоматически собирается, автоматически развёртывается в промежуточной (staging) среде, интеграционные тесты автоматически запускаются в промежуточной среде, и, если они проходят, код развёртывается в продакшене. Pipelines уже использовали десятки тысяч разработчиков Amazon. Почему бы не добавить нагрузочное тестирование в качестве ещё одного этапа? Pipelines предоставлял пользовательский интерфейс для настройки тестов, планирование их выполнения, аппаратные ресурсы для проведения тестов, а также хранил и предоставлял логи. И всё это было сделано в той же форме, что и интеграционные тесты в Amazon, так что разработчики привыкли к этой модели. Мою платформу для нагрузочных тестов теперь тоже можно было легко найти, потому что она стала чекбоксом в привычном пользовательском интерфейсе. Я настроил среду.

Второй способ контролировать Путь — Выработать привычки. Это мощный способ, потому что когда мы находимся на поведенческом автопилоте, у Наездника меньше работы. Что касается того, как это связано с моим примером с нагрузочной платформой, то её интеграция в Amazon Pipelines сделала нечто удивительное. Раньше нагрузочное тестирование в большинстве сервисов Amazon проводилось в лучшем случае раз в год — как правило, за некоторое время до того, как инженеры ожидали пика трафика. После этого они забывали о его существовании. Поскольку это была нечастая задача, её было довольно больно выполнять. Я подумал, что если смогу превратить её в регулярную и повсеместную, это изменит культуру и сформирует правильные привычки. Добавление этой функции в качестве шага в CI/CD превратило мой продукт в «липкий» (то есть частоиспользуемый) продукт. Раньше это был инструмент командной строки, который запускался только тогда, когда люди об этом помнили; после этого инженеры могли блокировать все проверки кода, которые негативно влияли на пропускную способность или задержку продукта.

И наконец, «Сплочение стада». Люди — стадные животные. Мы склонны поступать так, как поступают другие члены сообщества. Вам знаком термин “Designated Driver”? (Прим. пер.: «”Назначенный водитетель” — человек, который берёт на себя ответственность за вождение автомобиля в группе, где другие участники могут быть под воздействием алкоголя»). На самом деле это была социальная рекламная кампания. Вместо того чтобы размещать рекламу, напрямую призывающую людей не садиться выпившими за руль, авторам идеи удалось встроить сюжетные линии про «назначенных водителей» в прайм-тайм шоу в период с 1988 по 1992 год. В конечном итоге это позволило снизить количество смертей вследствие вождения в нетрезвом виде с 24 тыс. в год до 18 тыс. в год. Зрители слышали термин «назначенный водитель» из шоу в шоу, и они наблюдали примеры ответственного поведения людей в своих любимых шоу, поэтому они решали тоже вести себя ответственно. В моём случае идея «сплочения стада» выражалась в различных формах создания сообщества. Я стал собирать заинтересованных этой темой, чтобы они могли обмениваться идеями о нагрузочном тестировании.

Я также создал страницу с историями успеха, где пользователи инструмента могли рассказать о своём опыте. Я сделал заветный патч для нагрузочного тестирования, который можно было прикреплять к информации о людях в Amazon phonetool. Я выступал на всех возможных внутренних конференциях, посвящённых нагрузочному тестированию. Я создал практический курс по нагрузочному тестированию, который за несколько лет мы провели для более чем тысячи инженеров. И я с энтузиазмом поощрял всех, кто проявлял интерес к сотрудничеству и добавлению новых функций в фреймворк. Так фреймворк нагрузки превратился из «инструмента, который сделал Карлос» в «инструмент, которым мы владеем все вместе». За эти годы десятки инженеров в свободное время добавляли новые классные функции, а я завязал удивительные дружеские отношения. Это живое сообщество стало фактором ускорения развития инструмента. Чем больше людей было вовлечено в сообщество, тем привлекательнее становилось быть его частью. Когда люди стали делать мемы о моей платформе, я понял — всё действительно получилось!

Заключение

Мне, совместно с командой отличных инженеров, пришлось решить тонну интересных технических проблем, чтобы запустить фреймворк нагрузочного тестирования в масштабе всего Amazon. Но даже если бы я писал самый красивый и совершенный код в мире, без понимания того, что есть ещё и чисто человеческий фактор, мой инструмент никогда бы не преуспел. Было интересно увидеть, что шаги, которые я предпринимал как бы бессистемно и органично, на самом деле вписывались в продуманную систему мышления — значительно более сложную, чем принцип кнута и пряника, которую сформулировали люди гораздо умнее меня. Часто мы забываем, что даже компаниям, занимающимся разработкой программного обеспечения, нужна помощь со стороны психологии: изменить культуру, помочь идеям закрепиться и изменить поведение людей.

Необходимые практические навыки по тестированию вы можете получить в рамках онлайн-курсов от экспертов отрасли.