Недавно на блоге Эдварда Йордона натолкнулся на один весьма интересный документ: “Top Ten Software Engineering Concepts” и там в разделе “Peopleware” заинтересовался ссылкой: Google’s HR Strategy, которая и привела меня к статье “The Google Way: Give Engineers Room” by BHARAT MEDIRATTA; as told to JULIE BICK, New York Times, October 21, 2007. Оригинал статьи можно найти по этой ссылке, а здесь я хочу представить ее перевод.
Разработчикам Google разрешается использовать 20 процентов своего рабочего времени на задачи, связанные с работой компании, но интересные сотрудникам лично. Это значит, что если вас есть интересная идея, у вас всегда найдется время позаниматься ею.
Барат Медиратта (Bharat Mediratta) принимает участие в групплетах (grouplet meeting) в Google, которые отражают и подчеркивают возможность разработчиков тратить свое время на независимые проекты.
Это выглядит очевидным, что люди работают лучше, если они занимаются чем-то любимым, и множество отличных технологий нашли свое начало в этих 20 процентах рабочего времени, включая Gmail, Google News и даже Google shuttle, который возит людей на работу в штаб-квартиру компании в Маунтин-Вью, Калифорния.
Если идея, которая возникла при использовании 20 процентов свободного времени, это новый продукт, то обычно достаточно всего лишь найти несколько единомышленников и начать кодировать. Но когда то, над чем вы действительно хотите работать – это сделать серьезные изменения в целой организации, то вам нужно нечто совершенно новое – вам нужны «групплеты».
Такие групплеты не имеют отдельного бюджета и в них нет главенства при принятии решений. Они состоят из группы людей, преданных некоторой идее и готовых работать, чтобы убедить остальную часть компании принять ее.
Давайте рассмотрим группу разработчиков, желающих продвинуть «гибкое программирование» (“agile programming”) внутри компании. Гибкое программирование – это подход к разработке программного обеспечения, который включает в себя раннюю и частую обратную связь, и уже применялся в нескольких частях компании.
Групплет по гибкой разработке был основан в попытке распространения этой идеи по всей организации. Осуществлялось это путем создания максимального числа групп для обучения новому процессу. Они создали «Часы гибкой разработки», куда вы могли заглянуть и задать вопросы об этом процессе. Они раздавали книги и проводили откровенные беседы по этой теме. Они посещали собрания персонала и создали концепцию «Сафари гибкой разработки», в которой вы могли добровольно участвовать некоторое время в составе группы, использующей гибкую разработку, чтобы посмотреть на нее на практике.
Если вы двигаетесь так же быстро, как и Google, то у вас не всегда бывает возможность завершать мелкие вещи, которые со временем начинают мешать и беспокоить. Поэтому в добавок к усилиям нашей команды обеспечения качества, у нас есть групплет Исправь Это (Fixit), который координирует особые дни, когда наши разработчики сосредотачиваются на решениях определенных проблем. Иногда у нас проходят дни исправления документации (Documentation Fixits), когда все мы стараемся навести порядок во внутренней документации, о которой периодически забываем.
Или мой любимый: исправления пожеланий пользователей (Customer Happiness Fixit), когда мы исправляем те маленькие проблемы, которые достают и расстраивают наших пользователей, например, исправление неудачных горячих клавиш в мобильных телефонах. Многие из этих событий проходят со специальными футболками и подарками для разработчиков, которые посвящают слишком мало времени работе над этими проблемами.
В свои 20 процентов времени я начал групплет по тестированию. Побудила меня к этому идея (не моя), что если разработчики пишут автоматические тесты во время написания кода, этот код будет лучше подходить для этого. Меньшее время на исправлении ошибок дает большее время на разработку всякой всячины.
Мы начали вместе с инженерами из всей компании встречаться каждые пару недель для мозгового штурма. Медленно, со временем, мы стали превращаться в активистов, планирующих реально начать улучшать ситуацию.
Мы начали создавать лучшие инструменты и проводить непринужденные беседы с различными техническими группами. Мы начали создавать учебный план для Нуглеров (Nooglers), новичков Google, чтобы они начинали свою работу правильно. Нашими объединенными 20 процентами времени, мы медленно повернули организации на 90 градусов и сделали тестирование разработчиком обычной практикой.
Google работает вверх ногами. Если у вас есть отличная техническая идея, то вам не нужно, чтобы ваш вице-президент разослал служебную записку, приказывающую всем использовать ее. Вместо этого, вы излагаете ее своему коллеге и убеждаете его в том, что она хорошая. Хорошие идеи распространяются быстро, и этот подход оберегает нас от совершения технических ошибок. Но это также значит, что груз ответственности за распространение идеи ложится на ваши плечи.
В групплете по тестированию, наша идея была в том, чтобы разработчики начали писать свои собственные тесты. Но как бы мы не старались, мы не могли быстро дотянуться ко всем нашим разработчикам в нашей растущей организации. Однажды, в конце длительной мозговой атаки, мы пришли к идее вывешивания маленьких историй, размером с одну страницу, названные эпизодами, в туалете, с обсуждением новых интересных методик тестирования. Кто-то сразу же назвал их «Тестирование в туалете» и идея принялась.
Мы сформировали команду редакторов и воодушевленных писателей для написания множества эпизодов, и воспользовались подкупленными новичками с книгами и футболками для вывешивания эпизодов каждую неделю. Первые несколько эпизодов вызвали шквал отзывов с разных концов компании. Нас хвалили и ругали, но чаще всего мы слышали, что люди скучают и хотят, чтобы мы поторопились с выпуском очередного эпизода.
В конечном итоге, идея стала частью корпоративной культуры, даже корпоративной шуткой: «Простите, мне нужно пойти почитать про тестирование». Вот тогда мы поняли, что мы получили то, что хотели: способ опубликовать наше сообщение.
Конечно же, групплеты требуют руководства, чтобы гарантировать, что они совпадают с интересами компании. Наличие большого количества самоорганизованных людей может быть как положительным, так и отрицательным, и не каждая идея является хорошей. Чтобы помочь справиться с этим, организаторы групплетов собираются раз в неделю и убеждаются, что их интересы не противоречат друг другу.
Но когда вы даете разработчикам шанс применить свою страсть на благо компании, они могут делать удивительные вещи.
Барат Медиратта, разработчик программного обеспечения в Google.
