Материал: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Глава 9. Формирование близости между отдельными сотрудниками и командами
177
в командах, с которыми работают новички, генерируются новые идеи. Эти идеи вряд ли появились бы при других условиях.
Процесс перемещения людей между командами часто называют ротацией. В не- которых организациях или командах ротацию опытных специалистов принято выполнять раз в год, Этот процесс планируется заранее, чтобы избежать негатив- ных последствий из-за временного отсутствия людей на привычных рабочих ме- стах. Причем ротация должна быть достаточно гибкой, вплоть до того, что члены команды сами избирают людей, с которыми им предстоит работать. В результате выполнения ротации люди получают разнообразный опыт, который позволяет им работать не по специальности. Например, эксплуатационный инженер может ра- ботать в отделе разработки мобильных приложений либо в команде разработчиков внешних интерфейсов. В результате обеспечивается возможность освоения новых областей и технологий, к которым они вряд ли получили бы доступ.
Работа в другой команде обеспечивает те же преимущества, что и программа назначения специалистов из других команд. Но в этом случае создается более се- рьезный фундамент для эмпатии и понимания. Также формируются точки сопри- косновения между разными членами группы. Если руководство не дает добро на проведение полномасштабной ротации, возможно, оно согласится на выполнение локальной ротации. Например, можно в течение нескольких часов создать возмож- ности для парной работы над проектами, задействовав людей из разных команд.
Например, на основе согласия, полученного от сотрудников, можно организовать парную работу инженеров над списком требований к ПО или над малобюджетны- ми программами из категории внутренних продуктов или проектов с открытым кодом. Эти программы используются в компании либо поддерживаются этой компанией.
Ротации во вспомогательных командах
Как уже упоминалось ранее, описанные в книге принципы могут применяться не только по отношению к командам разработчиков и эксплуатации. Кроме того, расширение области применения этих принципов позволит сформировать более сильную компанию и промышленную культуру. Многие компании, специализиру- ющиеся в технических областях, особенно стартапы, оценивают своих инженеров очень высоко, но в то же время с пренебрежением относятся к персоналу вспо- могательных подразделений. В то время как инженеры щеголяют в фирменных толстовках с капюшонами и ездят на конференции за счет фирмы, другие сотруд- ники прозябают в забвении. Естественно, что эти сотрудники начинают ощущать дискриминацию, вызывающую у них негативные настроения.
Один из основных факторов, способствующих возникновению движения devops, — необходимость в достижении более глубокого понимания, в выполнении адек- ватной оценки и в формировании эмпатии по отношению к эксплуатационным инженерам, системным администраторам и ИТ-специалистам в целом. В резуль- тате остальные сотрудники компании осознают ценность этих областей, а также

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

Глава 9. Формирование близости между отдельными сотрудниками и командами
179
деятельность не приведет к ослаблению конкурентных позиций компании, а ско- рее будет способствовать усилению отрасли в целом.
Конечно, успех этих видов программ зависит от обмена знаниями и обучения.
Если в одной компании инженеру по обмену разрешается принимать участие в качестве полноценного участника команды и выполнять реальную работу, в то время как его «коллега по обмену» будет ограничиваться лишь просмотром доку- ментации, подобная связь будет односторонней. Возвращаясь к имевшей место ранее дискуссии, посвященной «трагедии общин» и факторам, способствующим коллективному поведению, отметим, что санкции за поведение, несовместимое с групповой работой, могут вынудить компании отказаться от участия в програм- мах обмена с организациями-нарушителями. В результате уменьшается объем информации, которую плохие исполнители будут получать в будущем.
Для организаций, ищущих способы улучшения эмпатии как в целом, так и меж- ду командами, важно исследовать не только способы взаимодействия разных команд и групп, но и ценности, как реальные, так и воспринимаемые разными группами. Традиционно такие отделы, как ИТ и поддержка, рассматриваются как центры затрат, которые не приносят прямую прибыль, а лишь увеличивают затраты на управление компанией. Хотя движение devops начало улучшать от- ношение к эксплуатационным командам в целом, для осуществления кардиналь- ных перемен в этой области нужно пройти длинный путь. Сотрудники центра затрат часто занимают неблагодарные рабочие места и получают более низкую зарплату. Центры затрат характеризуются более высокими показателями товаро- оборота и повышенным риском сокращения во времена кризиса. И хотя центры затрат воспринимаются как нижние ступеньки на корпоративной лестнице, при наличии нужных людей, обучения и ресурсов они могут давать невероятную прибыль в таких областях, как потребительская лояльность или стабильность инфраструктуры.
Расширяя понятие devops в целях учета этих команд и их воздействия на бизнес в целом, необходимо отказаться от иерархической лестницы. Эта лестница явля- ется чрезмерно упрощенной моделью, которая не только приводит к неверным представлениям о служебном росте, но и затрудняет проявление эмпатии к другим людям, которые находятся «ниже» по лестнице. Как уже упоминалось в других главах, перемещение из инженерного отдела в отдел менеджмента является из- менением в карьере, а не карьерным ростом. Такая модель игнорирует способы, с помощью которых группы связаны и взаимозависимы.
А теперь представим вместо лестницы веревочную пирамиду, которую иногда устанавливают на детских площадках. Эта пирамида представляет собой набор натянутых разноцветных канатов, по которым могут подниматься и играть дети
(рис. 9.1). Несмотря на то что эта модель является иерархической, с ее помощью легче вообразить такие роли, как ИТ и поддержка, которые находятся в основании других частей пирамиды. При рассмотрении этой модели нетрудно понять, что без прочной основы стабильность и успешность структуры находятся под угро- зой. Лестница может утратить нижнюю ступень и по-прежнему применяться по

180
Часть III. Близость назначению. Поэтому нижние ступени лестницы рассматриваются как центры за- трат, от которых нужно избавляться в первую очередь. Но прежде чем избавлять- ся, нужно обращать внимание на связанные с ними ценности, которые далеко не всегда оцениваются в денежном выражении. Но если вы обрежете один из нижних канатов веревочной пирамиды, вся конструкция потеряет стабильность.
Исполнительный директор уководство енеджмент енедж- мент енеджмент
Инженеры
Инженеры
Отдел качества
Отдел качества
ИТ
ИТ
Поддержка
Поддержка
Исполнители
1   ...   13   14   15   16   17   18   19   20   ...   39
Рис. 9.1. Иерархия, представленная в виде лестницы и пирамидыУлучшение общения между командамиПомимо проявления взаимной эмпатии для обеспечения хорошей совместной работы нужно наладить эффективное общение между командами. Продолжая дискуссию о стилях общения и типах переговоров, которая была начата в части II, рассмотрим в этом разделе применение этих же методик на межкомандном уровне. Именно хорошо налаженное общение позволяет получать преимущества от вне- дрения devops не только на уровне отдельных команд или инженерного отдела, но и на уровне всей организации или бизнеса.На простейшем уровне общение в группе формируется на основе общения меж- ду отдельными людьми, входящими в группу. Среди различных стилей обще- ния, используемых в группе, побеждают наиболее доминантные стили. Зачастую это завершается тем, что люди, которые говорят громче всех, дольше всех или

Глава 9. Формирование близости между отдельными сотрудниками и командами
181
прерывают других ораторов, становятся доминантными в групповых дискуссиях.
Такие люди также могут убеждать других людей не своими ценными идеями, а лишь потому, что их собеседники менее убедительны и не склонны прерывать других. Всего лишь один доминантный член группы, склонный прерывать других, может изменить динамику общения всей группы. В подобной обстановке другие люди будут вынуждены чаще прерывать собеседников, чтобы «вставить свои пять копеек».
Группы также часто заимствуют стиль общения лидеров, будь то менеджер либо человек, имеющий авторитет и уважение в группе. Если лидеры не умеют хорошо общаться, мало общаются либо используют стили общения, которые неприем- лемы в совместной рабочей среде, они послужат плохим примером для других сотрудников. Поэтому не забывайте о стандартах, устанавливаемых лидерами в организации.
Во многих организациях часто ведутся дискуссии по поводу того, как и сколько общаться. Как мы уже упоминали ранее, разные средства в той или иной степени лучше подходят для разных типов общения. При выборе средств учитываются такие факторы, как достижимость, срочность, контент и т. п. С учетом этих разных факторов и персональных предпочтений зачастую трудно выработать рекоменда- ции, которые всем понравятся. Как бы там ни было, но лучше общаться слишком часто, чем очень редко.
Сказанное выше особенно верно для средств коммуникации, для которых отно- сительно легко настроить отдельные фильтры, соответствующие предпочтениям людей. Клиенты электронной почты позволяют автоматически фильтровать со- общения электронной почты по разным папкам, а программы чата обеспечивают настройку слов-предупреждений. Естественно, что это не единственное реше- ние — допускается изрядное количество отдельных настроек. Также не допу- скается создание впечатления сознательного сокрытия информации, поскольку это будет способствовать формированию бункеров и отношений «в группе/вне группы».
Также учитывайте распределение людей и команд в организации. Как только коман ды начинают перемещаться между местоположениями и часовыми поясами, становится все труднее включать всех в процесс общения между людьми. После приобретения привычки к общению на расстоянии, например, с помощью элек- тронной почты и текстового чата, по умолчанию не только сохраняются записи о ваших переговорах, но и преодолевается изоляция как для отдельных людей, так и для целых команд.
Общение в кризисных ситуациях
В кризисных ситуациях общение может оказаться нестабильным, например при
«падениях» сайта. Тогда как общение в подобных специфических ситуациях яв- ляется относительно новым объектом исследований, эффективное общение в кри- зисных ситуациях, задействующее много людей и команд, в более общем смысле
Источник: https://files.student-it.ru/previewfile/170498