ивен, поскольку автоматически адаптируется к изменениям в поведении. В некоторых случаях анализ всех команд может показаться слишком грубым, и лучше провести сравнительный анализ с небольшой группой команд. Например, вы можете захотеть определить когорты для интерфейсных, серверных и инфраструктурных команд, с учетом того, что у них очень разные профили затрат.
5. Побуждение: Как только вы создадите контекст с помощью данных, чтобы люди могли их интерпретировать, следующий шаг – начать подталкивать их к действию! Панели мониторинга очень эффективны для анализа, но проблема с базовыми показателями заключается в том, что люди не думают о них большую часть времени, а значит, могут и полностью забыть. Я нашел эффективной отправку уведомлений, обычно по электронной почте, командам, чьи показатели недавно изменились, как с точки зрения абсолютных изменений, так и с точки зрения их показателей по сравнению с когортой. Это гарантирует, что каждый раз, когда вы отправляете письмо команде, оно содержит важную информацию, на основании которой они должны действовать! Самое мощное в побуждении то, что простая констатация изменения подталкивает к действию, и для этого не требуется никаких организационных полномочий. (Подробнее об этой теме читайте в «Nudge. Архитектура выбора» Ричарда Х. Талера и Касса Р. Санстейна[15].) (21)
6. Базовые показатели: В лучшем случае вам удастся добиться необходимого организационного воздействия с помощью контекстуализированных побуждений, но иногда их недостаточно. Следующим шагом станет работа с ключевыми командами по согласованию базовых показателей их эффективности. Это полезно, поскольку гарантирует, что базовые показатели находятся в центре внимания, а также дает командам мощный инструмент для обсуждения приоритетов со всеми заинтересованными сторонами. В некоторых случаях это действительно требует определенных организационных полномочий, но я обнаружил, что люди повсеместно хотят быть ответственными. Пока вам удается выделить время, чтобы встретиться с ключевыми командами и объяснить важность цели, это не потребует больших организационных полномочий.
7. Обзор: Заключительный этап, на который, надеюсь, вам не нужно будет переходить – это проведение ежемесячного или ежеквартального обзора, в рамках которого анализируется производительность каждой команды, и обращение к командам с требованием пересмотреть приоритеты. Если они не достигают согласованных базовых показателей. Обычно тут требуется куратор, потому что работа с командами, которые не достигают базовых показателей, почти всегда имеет приоритет перед другими целями, и им нужна ваша помощь, чтобы объяснить всем заинтересованным сторонам важность изменений.
Я видел, как этот подход работает, и, что более важно, я обнаружил, что его легко масштабировать. Он позволяет компании одновременно поддерживать множество базовых показателей, не перегружая команды. Во многом это связано с тем, что подход фокусируется на стимулировании целенаправленных изменений в ключевых показателях/драйверах, требуя участия лишь небольшой подгруппы команд для любого заданного показателя. Этот подход также эффективен, поскольку пытается свести к минимуму управление сверху вниз в пользу предоставления информации, чтобы побудить команды самостоятельно корректировать свои приоритеты.
3.6 Технический переход: Единственное масштабируемое решение проблемы технического долга
Самым интересным переходом, в котором я участвовал, был переход Uber от сервисов, управляемых с помощью Puppet[16], к полностью автономной модели предоставления услуг, в которой любой инженер компании мог запустить новую услугу в два клика. Они не только могли, но и делали это, создавая по несколько сервисов каждый день к моменту завершения обслуживания, и каждый недавно нанятый инженер мог запустить сервис с нуля в первый же день.
Рисунок 3.5. Этапы технического перехода.
Что сделало этот переход интересным, так это масштаб. Когда мы начинали, подготовка нового сервиса занимала около двух недель рабочего времени и около двух дней чистого технического времени, и с каждым днем мы отставали все больше. И да, стресс был серьезный, но в итоге получилась идеальная среда для изучения того, как выполнять крупномасштабные переходы с одного программного обеспечения на другое. Переход был такой серьезный, что мы ясно видели даже небольшие сдвиги, и достаточно долгий, чтобы мы могли экспериментировать с подходами.
ТОТ ФАКТ, ЧТО ЧТО-ТО ПЕРЕСТАЕТ РАБОТАТЬ ПРИ ЗНАЧИТЕЛЬНО УВЕЛИЧЕННОМ МАСШТАБЕ, ЯВЛЯЕТСЯ ПРИЗНАКОМ ТОГО, ЧТО ОНО БЫЛО СПРОЕКТИРОВАНО СООТВЕТСТВЕННО ПРЕДЫДУЩИМ ОГРАНИЧЕНИЯМ, А НЕ ПЕРЕРАЗМЕРЕННО.
Технические переходы становятся необходимыми, и их частота удручающе растет по мере старения кодовой базы и роста бизнеса: большинство инструментов и процессов поддерживают рост только на один порядок (22), прежде чем становятся неэффективными, поэтому быстрый рост превращает переходы в образ жизни. Это происходит не потому, что у вас плохо организованы процессы или вы используете неправильные инструменты – совсем наоборот. Тот факт, что что-то перестает работать при значительно увеличенном масштабе, является признаком того, что оно было спроектировано соответственно предыдущим ограничениям, а не переразмеренно (23).
В результате вы часто меняете инструменты, и ваша способность переходить на новое программное обеспечение может стать определяющим ограничением для общей скорости развития. Несмотря на их важность, мы не очень-то часто говорим о переходах. Так давайте исправим это!
3.6.1. О важности переходов
Переходы важны, потому что они, как правило, являются единственным доступным способом добиться существенного прогресса в решении технических проблем.
Инженеры ненавидят технический долг. Если есть простой проект, которым они могут заняться сами и довести его до конца, чтобы сократить технический долг, то они возьмут его на себя. Ведущие инженеры тоже ненавидят технический долг. Если есть простой проект, который их команда может выполнить самостоятельно, они возьмут его в работу. В совокупности это приводит к динамике, где мало очевидных возможностей для сокращения технического долга, и большинство оставшихся вариантов требуют совместной работы большого количества команд. Результат – переход.
ПЕРЕХОД – ЭТО ЕДИНСТВЕННЫЙ МЕХАНИЗМ ЭФФЕКТИВНОГО УПРАВЛЕНИЯ ТЕХНИЧЕСКИМ ДОЛГОМ ПО МЕРЕ РОСТА КОМПАНИИ И УСЛОЖНЕНИЯ КОДА.
Каждый переход направлен на создание технических преимуществ (вы больше не должны использовать один сервер для всех задач!) или сокращение технического долга (код после апрува гарантированно сохранится, даже при масштабном сбое!). При этом формально у таких преимуществ шаткие позиции: снижение непосредственного вклада сегодня в обмен на увеличение мощностей завтра. Это затрудняет планирование перехода, и по мере того, как ваши системы становятся больше, растет и цена перехода. У сотрудников Google есть присказка «бежать, чтобы оставаться на месте», описывающая команду, все возможности которой расходуются на обновление зависимостей и шаблонов, так что группа не может продвигаться вперед в работе по продукту/системе, которой она владеет. Тратить все свое время на переходы – это крайность, но у каждой компании среднего размера есть длинная очередь переходов, которые она не может выполнить: переход от виртуальных машин к хранилищам, развертывание автоматического отключения, переход на новый инструмент сборки… список можно продолжать бесконечно.
Переход – это единственный механизм эффективного управления техническим долгом по мере роста компании и усложнения кода. Если вы не добьетесь успеха в переходе программного обеспечения и систем, то в конечном итоге погрязнете в технических долгах. (И вам все равно придется сделать это позже, просто тогда, вероятно, нужно будет уже полностью переписывать систему.)
3.6.2. Правильное выполнение переходов
Есть и хорошая новость. Хотя переход является сложной задачей, существует стандартная схема действий, которая работает на удивление хорошо: снизьте риск, внедрите инструменты и закончите переход.
Первый этап перехода заключается в том, чтобы снизить его риск, причем сделать это как можно быстрее и дешевле. Напишите проектный документ и распространите его среди тех команд, которым, по вашему мнению, будет труднее всего перенести переход. Повторите. Редактируйте его при работе с командами, у которых есть нетипичные шаблоны и крайние случаи. Повторите. Протестируйте его на основе плана на следующие шесть-двенадцать месяцев. Повторите.
После того как вы доработали проектный документ, следующий шаг – внедриться в одну или две наиболее сложные команды и работать бок о бок с ними над созданием новой системы, ее развитием и переходом на нее. Не начинайте с самых простых переходов, которые могут сформировать ложное чувство безопасности.
Эффективное снижение рисков очень важно, потому что каждая команда, которая одобряет переход, делает ставку на вас, надеется, что вы доведете эту чертову инициативу до конца, а не бросите их на полпути и им не придется возвращаться к старой заброшенной системе. Если вы оставите один переход частично завершенным, люди будут крайне подозрительно относиться к следующему.
После того как вы проверили решение, которое поможет устранить предполагаемую проблему, пришло время «заточить» инструменты. Многие люди начинают переход с создания тикетов контроля для внедрения командами, но лучше притормозить и разработать инструментарий для программного перехода на 90 % (24). Это радикально снижает затраты на переход для организации в целом, что повышает вероятность успеха и создает больше возможностей для перехода.