Программа назначения специалистов не только позволяет осуществлять эксплуатацию, но и обеспечивает другие преимущества. Например, назначенные команды по дизайну или пользовательскому опыту помогут гарантировать простоту и интуитивную понятность в использовании создаваемых продуктов. Команда, разрабатывающая внутренние инструменты, создает средства, которые будут использоваться на уровне всей организации. Если эта команда, как это часто бывает, состоит из людей, которые имеют опыт системного или серверного администрирования, скорее всего, они разработают инструмент командной строки, который будет привычен и понятен для них, но не для обычных пользователей. При наличии назначенного дизайнера или UX-специалиста можно создать инструмент, который был бы востребован широким кругом пользователей. Еще одна область, в которой могут принести пользу назначенные в команду инженеры, – обеспечение безопасности. Подобно эксплуатационным работам, процедуры по обеспечению безопасности не воспринимаются широкой общественностью. Тем не менее они должны внедряться на протяжении всего жизненного цикла продукта, а не в последний момент.
Учебные лагеря и ротации
Благодаря учебным лагерям и ротациям люди могут быстро включаться в состав других команд, расширять знания и навыки, формировать эмпатию.
Термин «учебный лагерь» используется для описания следующего подхода. Сотрудникам, только что принятых в команду, в течение нескольких недель приходится работать с другими командами. Как правило, сотрудники работают вместе с командами, тесно связанными с базовой командой. Например, разработчик одну неделю работает вместе с эксплуатационной командой, а еще одну неделю – вместе с командой обеспечения безопасности. Преимущества подобного подхода заключаются в том, что новички обычно не участвуют в проектах, связанных со многими людьми, поэтому отсутствуют жесткие ограничения по времени. Также у новичков отсутствует предвзятое мнение о других командах или о «типичных способах решения проблем». Благодаря непредвзятому взгляду на проблемы в командах, с которыми работают новички, генерируются новые идеи. Эти идеи вряд ли появились бы при других условиях.
Процесс перемещения людей между командами часто называют ротацией. В некоторых организациях или командах ротацию опытных специалистов принято выполнять раз в год, Этот процесс планируется заранее, чтобы избежать негативных последствий из-за временного отсутствия людей на привычных рабочих местах. Причем ротация должна быть достаточно гибкой, вплоть до того, что члены команды сами избирают людей, с которыми им предстоит работать. В результате выполнения ротации люди получают разнообразный опыт, который позволяет им работать не по специальности. Например, эксплуатационный инженер может работать в отделе разработки мобильных приложений либо в команде разработчиков внешних интерфейсов. В результате обеспечивается возможность освоения новых областей и технологий, к которым они вряд ли получили бы доступ.
Работа в другой команде обеспечивает те же преимущества, что и программа назначения специалистов из других команд. Но в этом случае создается более серьезный фундамент для эмпатии и понимания. Также формируются точки соприкосновения между разными членами группы. Если руководство не дает добро на проведение полномасштабной ротации, возможно, оно согласится на выполнение локальной ротации. Например, можно в течение нескольких часов создать возможности для парной работы над проектами, задействовав людей из разных команд. Например, на основе согласия, полученного от сотрудников, можно организовать парную работу инженеров над списком требований к ПО или над малобюджетными программами из категории внутренних продуктов или проектов с открытым кодом. Эти программы используются в компании либо поддерживаются этой компанией.
Ротации во вспомогательных командах
Как уже упоминалось ранее, описанные в книге принципы могут применяться не только по отношению к командам разработчиков и эксплуатации. Кроме того, расширение области применения этих принципов позволит сформировать более сильную компанию и промышленную культуру. Многие компании, специализирующиеся в технических областях, особенно стартапы, оценивают своих инженеров очень высоко, но в то же время с пренебрежением относятся к персоналу вспомогательных подразделений. В то время как инженеры щеголяют в фирменных толстовках с капюшонами и ездят на конференции за счет фирмы, другие сотрудники прозябают в забвении. Естественно, что эти сотрудники начинают ощущать дискриминацию, вызывающую у них негативные настроения.
Один из основных факторов, способствующих возникновению движения devops, – необходимость в достижении более глубокого понимания, в выполнении адекватной оценки и в формировании эмпатии по отношению к эксплуатационным инженерам, системным администраторам и ИТ-специалистам в целом. В результате остальные сотрудники компании осознают ценность этих областей, а также опасность, связанную с полным отказом разработчиков от процесса развертывания («У меня эта программа работала хорошо, все испортили техники по эксплуатации»). Слишком долго к эксплуатации относились плохо или полностью ее игнорировали. Теперь, когда это отношение во многом изменяется, крайне важно, чтобы эти изменения распространились на отношение к другим командам, с которыми мы «находимся в одной лодке».
Во многих компаниях в описанную выше категорию попадает клиентская поддержка. Хотя она не так престижна, как служба эксплуатации, ее сотрудники являются «лицом» компании. Точно так же, как системные администраторы выслушивают упреки в случае «падения» сети или неработающего принтера, эксплуатационные инженеры принимают на себя гнев пользователей, раздосадованных плохой работой программ. Если пользователь программы звонит в службу поддержки или пишет сообщение, скорее всего, он чем-то недоволен. В силу свойственной людям привычки обвинять посторонних людей в собственных несчастьях, крайними всегда окажутся специалисты из группы поддержки, даже если они ни в чем не виноваты. Поэтому в командах поддержки пользователей наблюдается повышенная текучесть кадров, а участники этих команд часто чувствуют себя недооцененными, несмотря на исполняемую жизненно важную роль.
Для уменьшения текучести кадров рекомендуется выполнять ротацию службы поддержки. В рамках ротации участники других команд по несколько часов в неделю отвечают на письма пользователей, адресованных службе поддержки, либо реагируют на жалобы заказчиков. Обычно в службу поддержки обращаются с однотипными вопросами, поэтому при наличии хорошей документации и заранее созданных шаблонов ответов работа в службе поддержки значительно упрощается. Конечно, это не означает, что не понадобятся навыки и терпение. Все это понадобится, если придется оказывать помощь в сложных ситуациях. Благодаря наличию документации и шаблонов работать в службе поддержки могут представители других групп, особенно при наличии инженерного образования. Участники других команд, работающие в службе поддержки пользователей, получат представление о типичных пользовательских проблемах. Как правило, эти проблемы отличаются от проблем, «живущих» в представлении разработчиков. Также они смогут осознать ценность службы поддержки для компании в целом и для выполняемой работы.
Помимо разрешения и поощрения переключения, а также ротации сотрудников между разными ролями внутри собственной компании, в некоторых организациях
