Глава 21. Выделите время для обучения и улучшений
Одна из методик, входящих в производственную систему Toyota, носит название блиц-обучения (или иногда kaizen blitz): это короткий промежуток времени, полностью посвященный решению одной конкретной проблемы, иногда длиной в несколько дней. Спир объясняет: «…блицы часто проходят так: собирается группа из нескольких человек, и они концентрируются на каком-нибудь проблемном процессе… Штурм длится несколько дней, его цель — улучшение процесса, средство для достижения цели — помощь коллег вне процесса коллегам внутри него».
Спир отмечает: часто результат блиц-обучения — возникновение нового подхода к решению проблемы. Например, появляется новая схема размещения оборудования, новый способ передачи информации, лучше организованное рабочее пространство или стандартизация деятельности. Также итогом иногда бывает список возможных изменений: их стоит ввести в обозримом будущем.
Пример блиц-обучения — программа ежемесячного испытания в додзё DevOps компании Target. Благодаря Россу Клэнтону, директору по эксплуатации Target, переход на систему DevOps прошел быстро. Одним из основных механизмов этого был центр технологических инноваций, более известный как додзё DevOps.
Додзё DevOps занимает площадь примерно в 1700 квадратных метров офисного пространства, где тренеры DevOps помогают командам улучшать свои навыки. Самый интенсивный формат называется «тридцатидневными испытаниями». За это время команды разработки работают в додзё с профильными коучами и инженерами. Команда формулирует проблему, с которой долгое время пыталась бороться, цель испытания — за 30 дней совершить прорыв в решении.
Весь месяц группа интенсивно работает с тренерами над решением выбранной задачи, каждые два дня составляя план, выполняя запланированную работу и фиксируя промежуточные результаты. Когда 30-дневное испытание завершается, члены группы возвращаются к обычной работе не только с решением важной проблемы, но и с новыми знаниями. Ими они могут поделиться со своей командой.
Клэнтон пишет: «На данный момент тридцатидневные испытания могут проводить не более восьми команд одновременно, поэтому мы фокусируемся на самых стратегически важных проектах компании. Через додзё уже прошли самые важные подразделения, включая группы, занимающиеся POS-терминалами, товарно-материальными запасами, ценообразованием и рекламными кампаниями».
Благодаря тому что участие в испытании занимает все рабочее время и участники концентрируются только на одной задаче, найденные решения часто оказываются просто поразительными.
Рави Пандей, менеджер по разработке Target, прошедший через эту программу, поясняет: «В прежние времена, чтобы получить тестовую среду, нам приходилось ждать шесть недель. Теперь же мы получаем ее за минуты и работаем рука об руку с инженерами эксплуатации. Они помогают нам действовать более продуктивно и создают нужные нам инструменты, чтобы нам было проще достигать поставленных целей. — Клэнтон продолжает: — Не так уж редко команды за несколько дней решают проблемы, которые раньше заняли бы у них от трех до шести месяцев. На данный момент через додзё уже прошло примерно 200 сотрудников. В общем они завершили 14 тридцатидневных испытаний».
В додзё также есть менее интенсивные модели работы, например Flash Build, где команды собираются на один-три дня, чтобы разработать минимально жизнеспособный продукт (minimal viable product, MVP) или минимально жизнеспособную функциональность (minimal viable capability, MVC). Кроме того, в компании каждые две недели проводят дни открытых дверей: все желающие могут прийти в додзё, чтобы поговорить с тренерами, посмотреть на результаты работы команд или пройти тренинг.
В этой главе мы опишем эти и другие способы, как выделять время на обучение и улучшения, делая их частью повседневной работы.
Создайте ритуалы для погашения технического долга
В этой части мы опишем ритуалы, помогающие разработчикам и инженерам эксплуатации выделять время на улучшение текущей работы, например на автоматизацию, введение нефункциональных требований и так далее. Один из самых простых способов — запланировать и регулярно выполнять блиц-обучение длиной в один день или одну неделю, когда вся команда (или вся организация) занимается наиболее волнующими проблемами и никакая работа над компонентами функциональности не разрешается. Это может быть проблемный участок кода, среда, архитектура, инструмент и так далее. Для блиц-обучения команды могут собираться из представителей всей производственной цепочки, например из разработки, IT-эксплуатации и службы информационной безопасности. Тех, кто обычно не работает вместе, объединяют навыки и усилия, чтобы улучшить работу в выбранной области и затем продемонстрировать результаты всей компании.
Помимо таких терминов бережливого производства, как kaizen-blitz и блиц-обучение, методика ритуалов по улучшению работы также называется весенней или осенней генеральной уборкой (spring или fall cleaning) или неделями инверсии очереди задач (ticket queue inversion weeks). Иногда используются и другие термины, например хакатон (hack day, hackaton) или 20 % времени на инновации (20 % innovation time). К сожалению, конкретные ритуалы часто предназначены для совершенствования готовых продуктов и создания прототипов новых продуктов, а не для улучшения повседневной работы и, что еще хуже, методики используют только разработчики, что очень далеко от целей блиц-обучения.
Во время блиц-обучения целью должно быть не просто экспериментирование ради проверки новых технологий, а стремление улучшить повседневную работу. Хотя эксперименты и могут приводить к таким улучшениям, все же суть состоит в том, чтобы сконцентрироваться на одной конкретной каждодневной проблеме.
Мы можем запланировать недельные блиц-обучения, во время которых разработка и эксплуатация работают вместе над какой-то одной задачей. Управлять таким мероприятием легко: выбирается одна неделя, и все в технологической цепочке вместе работают над одной и той же проблемой. В конце периода каждая команда устраивает презентацию коллегам и рассказывает о задаче и об итоговом решении. Такая методика укрепляет культуру: инженеры работают над проблемами во всем потоке создания ценности. Кроме того, этот подход поощряет решение проблем в ходе повседневной работы и показывает, что мы ответственно подходим к важным, но не срочным делам.
Сила блиц-обучений в том, что они вдохновляют непрерывно выявлять и решать проблемы без посторонних стимулов. Представьте, что наша сложная система — это паутина, переплетающиеся в ней нити постоянно ослабевают и рвутся. Если порвется определенная комбинация отдельных нитей, то всей паутине придет конец. Нет управления сверху, чтобы указывать рабочим, какие нити и в каком порядке нужно чинить. Вместо этого нужно создать организационную культуру и нормы, побуждающие сотрудников самим находить и исправлять слабые места системы в процессе ежедневной работы. Как отмечает Спир, «неудивительно, что пауки заделывают разрывы в паутине, как только они появляются, а не ждут, когда их станет слишком много».
Хороший пример успешного воплощения блиц-обучений описан Марком Цукербергом, генеральным директором Facebook. В интервью Джессике Стиллман, размещенном на сайте , он рассказывает: «Каждые несколько месяцев мы проводим хакатон, где все желающие создают прототипы для новых идей. В конце мероприятия вся команда собирается вместе и смотрит, что получилось. Многие из наших самых успешных продуктов появились именно во время хакатонов, в том числе Timeline, чат, видео, среда разработки для мобильных приложений и некоторые компоненты инфраструктуры, например компилятор HipHop».
Компилятор PHP HipHop особенно интересен. В 2008 г. у Facebook появились серьезные проблемы с работоспособностью: число активных пользователей превысило отметку в 100 миллионов и продолжало расти, из-за чего у технических служб были большие проблемы. Во время хакатона Хайпин Жао, старший инженер по работе с серверами в Facebook, начал экспериментировать с конвертацией кода на PHP в компилируемый код на C++, надеясь увеличить работоспособность их инфраструктуры. За следующие два года небольшая команда создала то, что потом будем названо компилятором HipHop, и перевела все сервисы Facebook с интерпретируемого PHP-кода в компилируемые двоичные файлы на C++. Новый компилятор позволил платформе Facebook выдерживать в шесть раз большие нагрузки, чем раньше.
В интервью с Кейдом Метцем, журналистом издания Wired, Дрю Пароски, один из инженеров, работавших над проектом, отметил: «Был такой момент, когда, если бы не HipHop, мы оказались бы в очень сложной ситуации. Чтобы обслуживать сайт, нам понадобилось бы больше машин, чем имелось на тот момент. Это был отчаянный шаг, но он сработал».
Позже Пароски и его коллеги Кейт Адамс и Джейсон Эванс решили, что могут улучшить производительность компилятора HipHop и убрать некоторые ограничения, снижавшие производительность разработчиков. В результате появился проект виртуальной машины HipHop (HHVM), использовавшей принцип динамической компиляции. К 2012 г. HHVM полностью заменила HipHop в эксплуатации. В разработке проекта приняло участие около 20 инженеров.
Регулярно проводя блиц-обучения и хакатоны, мы помогаем всем сотрудникам в потоке создания ценности создать что-то такое, чем они могли бы гордиться. И мы непрерывно интегрируем улучшения в нашу систему, делая ее еще более безопасной, надежной и способствующей обучению.
Позвольте каждому учить и учиться
Динамическая культура, ориентированная на обучение, создает такие условия, в которых все могут не только учиться сами, но и учить других, используя при этом как традиционные подходы (например, занятия, тренинги), так и практические (конференции, семинары, наставничество). Один из способов содействовать развитию этих методик — выделить для них специальное время.
Стив Фарли, директор по информационным технологиям компании Nationwide Insurance, отмечал: «У нас 5000 профессионалов. Мы называем их партнерами. С 2011 г. мы работаем над созданием культуры обучения. Ее часть — так называемые учебные четверги: каждую неделю мы выделяем время для того, чтобы наши партнеры могли учиться. В течение двух часов каждый партнер должен или учиться, или учить. Темы — все что угодно, о чем хотят узнать партнеры: о технологиях, о новинках в разработке, или о методиках улучшения процессов, или даже о том, как строить карьеру. Самое ценное, что может сделать партнер, — научить кого-то тому, что сам умеет, или научиться чему-то новому».
Как было неоднократно показано, некоторые навыки становятся все более нужными не только разработчикам, но и всем остальным инженерам. Например, инженеры эксплуатации и тестировщики должны быть знакомы с навыками, ритуалами и методиками разработки, с системами контроля версий, автоматизированным тестированием, конвейером развертывания, управлением конфигурациями и автоматизированием процессов. Знакомство с техниками разработки помогает инженерам эксплуатации быть в курсе текущих изменений, когда компания внедряет принципы и методики DevOps.
Перспектива изучения чего-то нового может быть пугающей или вызывать тревогу и стыд. Так быть не должно. В конце концов, мы учимся всю жизнь, и один из лучших способов делать это — учиться у коллег. Картик Гэквад, участвовавший в переходе компании National Instruments на принципы DevOps, сказал: «Для тех, кто работает в эксплуатации, погружение в автоматизацию не должно быть чем-то страшным — просто попросите знакомого разработчика, он будет рад помочь вам».
Мы также можем обучить людей новым навыкам, если коллеги будут наблюдать, как проходит рецензирование кода. Еще один пример — если инженеры разработки и эксплуатации работают вместе над решением небольших проблем. Так, разработчики могут показать инженерам эксплуатации, как аутентифицировать приложение, входить в систему и выполнять автоматизированные тесты, чтобы проверить работоспособность важных компонентов (ключевого функционала приложения, транзакций в базах данных, очереди сообщений). Затем можно интегрировать новые автоматизированные тесты в конвейер развертывания и время от времени запускать их, посылая результаты в системы наблюдения и оповещения, чтобы вовремя заметить возможные сбои.
Гленн О’Доннелл, работающий в компании Forrester Research, в презентации на конференции DevOps Enterprise Summit в 2014 г. колко заметил: «Поскольку все профессионалы, любящие инновации, также любят и перемены, нас ждет прекрасное, яркое, но бедное будущее безработных, уволенных после внедрения инноваций».
Делитесь опытом с DevOps-конференций
Во многих организациях, сосредоточенных на контроле операционных расходов, часто препятствуют тому, чтобы инженеры посещали конференции и учились у коллег. Чтобы создать культуру обучения, мы должны поощрять посещение конференций (это касается инженеров и разработки, и эксплуатации), участие в них и, если нужно, организацию внутренних или внешних учебных мероприятий.
На данный момент DevOpsDays предлагает одну из самых захватывающих серий конференций. На этих мероприятиях рассказывается о тонкостях многих новых методик DevOps. Участие в них бесплатно или почти бесплатно, а проведение поддерживается активным сообществом профессионалов, регулярно применяющих методики на практике.
Конференция DevOps Enterprise Summit впервые состоялась в 2014 г., чтобы технические руководители могли делиться своим опытом внедрения и применения принципов DevOps в крупных организациях. Программа мероприятия строится на основе презентаций руководителей о своем опыте работы с DevOps, а также на основе докладов экспертов в разных областях на выбранные сообществом темы.
Практический пример
Внутренние технологические конференции в Nationwide Insurance, Capital One и Target (2014 г.)
Наряду с участием во внешних конференциях многие компании, в том числе описанные в этой секции, проводят внутренние конференции для своих сотрудников.
Организация Nationwide Insurance — ведущий поставщик финансовых и страховых услуг, работающий в высокорегулируемых сферах. Среди ее предложений — страхование автомобилей и жилья. Кроме того, компания — один из крупнейших поставщиков услуг по государственному пенсионному планированию и страхованию домашних животных. На 2014 г. капитал составлял 195 миллиардов долларов, а доход — 24 миллиарда долларов. С 2005 г. компания начала вводить принципы Agile и бережливого производства, чтобы улучшить результаты работы 5000 своих сотрудников и позволить им вводить инновации по своей инициативе.
Стив Фарли, директор по информационным технологиям, вспоминает: «В то время начали появляться интересные конференции, например Национальная конференция по гибкой разработке (Agile national conference). В 2011 г. руководство Nationwide согласилось, что мы должны создать свою конференцию, получившую название TechCon. Организовывая это мероприятие, мы хотели улучшить методики обучения, а также сделать так, чтобы все на этой конференции происходило в контексте нашей компании, вместо того чтобы посылать сотрудников на другие конференции».
Банк Capital One, один из крупнейших в США, чей капитал в 2015 г. составлял 298 миллиардов долларов, а доход — 24 миллиарда долларов, поставил перед собой цель — создать технологическую организацию мирового уровня. В 2015 г. банк провел первую внутреннюю конференцию по разработке программного обеспечения. Ее задача заключалась в том, чтобы построить культуру сотрудничества, наладить связи между профессионалами внутри компании и ускорить обучение. У конференции было 13 учебных программ и 52 сессии, принимало участие более 1200 сотрудников.
Тапабрата Пал, сотрудник Capital One и один из организаторов мероприятия, пишет: «У нас даже был выставочный зал с 28 стендами, где команды Capital One показывали потрясающие вещи. Мы специально решили, что там не должно быть других поставщиков программного обеспечения, потому что мы хотели, чтобы фокус был на целях Capital One».
Организация Target — шестая по размеру компания розничной торговли США, в 2014 г. ее доход составлял 72 миллиарда долларов, в 1799 магазинах, разбросанных по всему миру, работало 347 сотрудников. Росс Клэнтон и Хизер Микман, директор по разработке Target, с 2014 г. организовали шесть внутренних мероприятий DevOpsDays, проведенных по образцу конференции DevOpsDays 2013 г. компании ING. В них приняло участие более 975 сотрудников технологического сообщества Target.
После того как Микман и Клэнтон посетили конференцию DevOps Enterprise Summit в 2014 г., они провели собственную внутреннюю конференцию, пригласив докладчиков из других фирм: те могли бы поделиться своим опытом с руководством фирмы. Клэнтон отмечает: «Именно в 2015 г. мы смогли обратить на себя внимание руководителей и раскрутить наше дело. После этого мероприятия к нам подходило много людей, спрашивавших, как они могут присоединиться к нам и чем могут помочь».
Используйте наставничество и внутреннее консультирование для распространения практик
Создание внутренней структуры, занимающейся консультированием и наставничеством, — один из самых известных методов распространения знаний внутри организации. Эта идея может воплощаться разными способами. В Capital One у профильных специалистов есть свои приемные часы, когда любой желающий может проконсультироваться с ними, задать вопросы и так далее.
Ранее в этой книге мы рассказывали о том, как групплет тестирования (Testing Grouplet) создал в Google культуру автоматизированного тестирования мирового уровня. История на этом не закончилась: сотрудники продолжили совершенствовать систему автоматизированного тестирования с помощью таких инструментов, как блиц-обучения, наставничество и даже внутренняя программа сертификации.
По словам Бланда, в то время в Google была принята политика выделения 20 % времени на инновации. Разработчики могли тратить примерно один день в неделю на проекты Google, не связанные с их основным кругом задач. Некоторые инженеры объединились в групплеты — спонтанно сложившиеся группы единомышленников. Они хотели вместе использовать свои 20 % времени для концентрированных блиц-обучений.
Основателями первого тестового групплета были Бхарат Медиратта и Ник Лесецки. Цель — продвижение автоматизированного тестирования в Google. Хотя у них не было своего бюджета или формального начальства, но, как сказал Майк Бланд, «не было и никаких явных ограничений. И мы этим воспользовались».
Для внедрения команда пользовалась несколькими механизмами, но самым известным из них стало «тестирование в уборной» (Testing on the Toilet, TotT), их еженедельный журнал. Каждую неделю почти во всех уборных Google по всему миру появлялась почтовая рассылка. Бланд замечал: «Целью было распространение знаний о тестировании по всей компании. Вряд ли обычная онлайн-рассылка смогла бы заинтересовать кого-то до такой степени».
Бланд продолжает: «Один из самых значимых релизов TotT назывался Test Certified: Lousy Name, Great Results («Аттестация в тестировании: дурацкое название, отличные результаты»), в нем описывались два мероприятия, внесших огромный вклад в распространение автоматизированного тестирования».
В поэтапном плане Test Certified (TC) описывались шаги по улучшению автоматизированного тестирования. По словам Бланда, «Нашим намерением было использовать культуру Google, сфокусированную на наблюдении за разными показателями… и преодолеть первое страшное препятствие — непонимание того, откуда или как начать. На уровне 1 нужно было быстро определить основной показатель, на уровне 2 — сформулировать стратегию и выполнить план по покрытию тестами, целью уровня 3 было достижение долговременной цели по полноте охвата».
Второй важный шаг заключался в том, чтобы каждая команда могла воспользоваться помощью или советами наставника по программе TC или тест-наемников (команды штатных коучей и консультантов компании), работающих непосредственно с командами над улучшением качества кода и тестов. Для этого наемники применяли знания, инструменты и методики групплета тестирования к коду команд, используя TC и как руководство, и как конечную цель. Сам Бланд был руководителем этого групплета с 2006 по 2007 г. и одним из тест-наемников с 2007 по 2009 г.
Бланд отмечает: «Нашей целью было привести все команды на уровень 3, участвовали ли они в нашей программе или нет. Мы также тесно сотрудничали с командой по разработке внутренних инструментов тестирования, давая им обратную связь по сложным ситуациям, знакомым по ситуациям в других командах. Мы были главной наступательной силой в этой борьбе, упорно продвигая наши инструменты, и в итоге фраза: “У нас нет времени на тестирование” перестала быть оправданием».
Далее он продолжает: «Уровни TC использовали культуру метрической системы Google — три уровня тестирования, то, что люди могли обсуждать между собой и чем они могли хвастаться во время обзора эффективности работы. Групплет тестирования в итоге смог выбить финансирование для тест-наемников, штатной команды внутренних консультантов. Это важный шаг, потому что руководство теперь полностью на нашей стороне, не только с указаниями, но и с настоящим финансированием».
Другим важным шагом было внедрение блиц-обучений «исправь это» (FixIt), охватывающих всю компанию. Бланд описывает блиц-обучения так: «Когда обычные инженеры с идеей и чувством долга вербуют всех инженеров Google на однодневные интенсивные исправления кода и внедрение новых инструментов». Он организовывал четыре таких мероприятия, охватывавших всю компанию: два блица в тестировании и два блица, связанных с инструментами. В последнем приняло участие более 100 добровольцев из более чем 20 филиалов в 13 странах. Он также возглавлял групплет «Исправь это» с 2007 по 2008 г.
Узконаправленные блиц-обучения «исправь это», по словам Бланда, должны проводиться в самые важные моменты, чтобы воодушевлять и давать энергию людям на решение важных проблем. С каждым значительным вложением сил масштабная цель изменить культуру компании становится все ближе и ближе.
Польза культуры тестирования очевидна: достаточно посмотреть на потрясающие результаты компании Google, многократно описанные в этой книге.
Заключение
В этой главе рассказывалось о создании ритуалов, помогающих укреплять отношение к жизни как к непрерывной учебе и понимание того, что улучшения в ежедневной работе ценнее, чем сама работа. Мы добиваемся этого, выделяя время на важные дела, создавая форумы, где все желающие могут учиться сами и учить других, как внутри нашей организации, так и снаружи. Мы помогаем командам находить экспертов и учиться у них, с помощью коучинга и консультирования или просто с помощью специально выделенных приемных часов, когда сотрудники могут получить ответы на вопросы у знатоков своего дела.
Когда все помогают друг другу учиться в ходе повседневной работы, компания начинает быстро опережать конкурентов и в результате отвоевывает рынок. Но важнее все-таки то, что мы помогаем друг другу раскрыть свой истинный потенциал.
Заключение к части V
На протяжении части V мы изучили методики для создания в компании культуры обучения и экспериментирования. Обучение на ошибках, создание единых баз знаний и обмен опытом крайне важны, когда мы работаем в сложных системах; это делает нашу культуру более беспристрастной, а наши системы — более безопасными и устойчивыми.
В части VI мы рассмотрим, как расширить и усилить поток ценности, обратную связь, обучение и экспериментирование, используя их для достижения целей информационной безопасности.
