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

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 07.11.2023

Просмотров: 411

Скачиваний: 25

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Глава 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
прерывают других ораторов, становятся доминантными в групповых дискуссиях.
Такие люди также могут убеждать других людей не своими ценными идеями, а лишь потому, что их собеседники менее убедительны и не склонны прерывать других. Всего лишь один доминантный член группы, склонный прерывать других, может изменить динамику общения всей группы. В подобной обстановке другие люди будут вынуждены чаще прерывать собеседников, чтобы «вставить свои пять копеек».
Группы также часто заимствуют стиль общения лидеров, будь то менеджер либо человек, имеющий авторитет и уважение в группе. Если лидеры не умеют хорошо общаться, мало общаются либо используют стили общения, которые неприем- лемы в совместной рабочей среде, они послужат плохим примером для других сотрудников. Поэтому не забывайте о стандартах, устанавливаемых лидерами в организации.
Во многих организациях часто ведутся дискуссии по поводу того, как и сколько общаться. Как мы уже упоминали ранее, разные средства в той или иной степени лучше подходят для разных типов общения. При выборе средств учитываются такие факторы, как достижимость, срочность, контент и т. п. С учетом этих разных факторов и персональных предпочтений зачастую трудно выработать рекоменда- ции, которые всем понравятся. Как бы там ни было, но лучше общаться слишком часто, чем очень редко.
Сказанное выше особенно верно для средств коммуникации, для которых отно- сительно легко настроить отдельные фильтры, соответствующие предпочтениям людей. Клиенты электронной почты позволяют автоматически фильтровать со- общения электронной почты по разным папкам, а программы чата обеспечивают настройку слов-предупреждений. Естественно, что это не единственное реше- ние — допускается изрядное количество отдельных настроек. Также не допу- скается создание впечатления сознательного сокрытия информации, поскольку это будет способствовать формированию бункеров и отношений «в группе/вне группы».
Также учитывайте распределение людей и команд в организации. Как только коман ды начинают перемещаться между местоположениями и часовыми поясами, становится все труднее включать всех в процесс общения между людьми. После приобретения привычки к общению на расстоянии, например, с помощью элек- тронной почты и текстового чата, по умолчанию не только сохраняются записи о ваших переговорах, но и преодолевается изоляция как для отдельных людей, так и для целых команд.
Общение в кризисных ситуациях
В кризисных ситуациях общение может оказаться нестабильным, например при
«падениях» сайта. Тогда как общение в подобных специфических ситуациях яв- ляется относительно новым объектом исследований, эффективное общение в кри- зисных ситуациях, задействующее много людей и команд, в более общем смысле