Книга: Философия DevOps. Искусство управления IT

Поиск точек соприкосновения между командами

Поиск точек соприкосновения между командами

В этом разделе мы ответим на вопрос о том, каким образом формируется доверие, происходит обмен опытом и формируется инклюзивная организация, включающая более широкий круг людей с общими интересами.

В процессе сближения разных команд могут возникать следующие затруднения:

• различия в целях;

• разные способы оценки успеха;

• различные методики осуществления лидерства;

• различия в стилях общения.

Различные команды часто имеют разные цели (по крайней мере, декларируемые). Хотя, безусловно, цель каждой команды заключается в том, чтобы помочь компании добиться успеха. Беда в том, что каждая команда для достижения цели использует собственные методы, которые часто противоречивы.

Классический пример, иллюстрирующий эти концепции в пространстве devops, – цели команд разработчиков и эксплуатации. Команда разработчиков общается с заказчиками, пытаясь как можно быстрее внедрять новые функции и устранять обнаруженные ошибки. Главная цель эксплуатационной команды – обеспечение функционирования и доступности всех серверов и услуг. Эти цели могут вступать в конфликт разными способами. Требования к развертыванию или процессы, предназначенные для минимизации воздействия ошибок развертывания, относящиеся к целям эксплуатации, как правило, не совпадают с целями разработки, заключающимися в быстрой поставке продуктов. В подобной ситуации разработчики также могут конфликтовать с инженерами из отдела обеспечения качества, чьи цели по поиску и устранению дефектов приводят к замедлению циклов выпуска продуктов.

Даже если цели разных команд не конфликтуют, противоречия могут породить способы, применяемые командами для оценки достигнутого успеха. Ключевые показатели эффективности (KPI, key performance indicators), используемые для оценки прогресса и успеха организации, могут привести к падению производительности. Это произойдет в том случае, когда не учитываются факторы, способствующие развитию бизнеса (например, заказчики, без которых успех бизнеса немыслим).

В случае, когда успех деятельности разработчиков оценивается количеством развертываний программы либо, что еще хуже, числом написанных строк кода, это может привести к падению качества программ или к затратам времени на создание программ, не востребованных заказчиками.

Если же команда, отвечающая за обеспечение качества, оценивает свой успех в зависимости от количества найденных ошибок, это может привести к задержкам со сдачей проектов. Более того, реализация подобных намерений может войти в противоречие с целями бизнеса в целом.

Свой вклад в противоречия между командами также вносят различные стили лидерства. Существует широкий диапазон разных рабочих стилей и стилей управления, которые влияют на общение между людьми. Со временем люди, работающие в одной команде, формируют группы по интересам. Это происходит в силу стремления людей общаться и работать с себе подобными. В результате конфликты, связанные с разными рабочими стилями и стилями общения, перемещаются на межкомандный уровень.

Руководители, использующие разные стили менеджмента или исповедующие различные управленческие ценности, также могут вносить свой вклад в формирование противоречий между отдельными сотрудниками или командами. Менеджер, владеющий более практичным стилем менеджмента или даже стилем микроменеджмента, будет конфликтовать с менеджером, использующим автоматический подход к менеджменту либо с тем, кто склонен не придерживаться стиля отчетности. Руководители, которые в первую очередь ценят производительность и конечный результат, будут конфликтовать с теми, кто больше заботится о людях и культивировании отношений. Если в организации консенсус между разными менеджерами играет решающую роль при распределении проектов или в повышении по службе, вышеупомянутые конфликты будут иметь серьезные последствия.

Несмотря на упомянутые в этом разделе различия, существуют способы поиска точек соприкосновения между командами и группами, которые будут рассмотрены в следующих разделах.

Переход от конкуренции к сотрудничеству

Помимо команд, имеющих разные цели, существуют команды, которые конкурируют между собой. Команда, которая более успешна в достижении целей, получит большую часть бюджета организации, что позволит ей приобрести больше ресурсов для проектов либо нанять больше персонала. Сначала нужно ответить на вопрос о том, каким образом можно перейти от конкуренции к сотрудничеству при наличии ограниченного количества ресурсов.

Как упоминалось в части II, конкуренция возникает в тех случаях, когда отдельные люди или организации борются за право доступа к тому или иному ресурсу. Конкуренция имеет место на многих рынках, она вызвана потребностями быть быстрее, дешевле, лучше либо всем этим сразу. Она воспринимается как необходимое условие формирования свободного рынка.

Соблюдение честной конкуренции – залог развития рынков во всем мире. Принципы законодательства, регулирующего конкуренцию, заключаются в запрете соглашений или методов, которые ограничивают свободную торговлю. Также запрещается демонстрация оскорбительного поведения со стороны ведущих фирм и использование способов нечестной конкуренции. Помимо этого, осуществляется надзор над слияниями и поглощениями, которые угрожают конкурентным процессам. До некоторой степени конкуренция вдохновляет стороны на более тяжелую работу, на поиск более эффективных либо творческих решений проблем, а также предлагает дополнительные возможности заказчикам.

Учтите, что чрезмерная конкуренция может принести больше вреда, чем пользы. В данном случае наблюдается так называемая трагедия общин (tragedy of the commons), когда интересы отдельных людей вступают в противоречие с интересами группы, владеющей небольшим ресурсом общего пользования. Эта фраза использовалась в качестве названия эссе, написанного в 1968 году экологом Гарретом Хардином[34]. В этом эссе описывались последствия неупорядоченного выпаса овец на общинных или общественных землях. Отсюда и был позаимствован термин «общины».

Этот пример часто используется в теории игр, представляющей собой изложение принципов рационального выбора в условиях проблем, связанных с участием нескольких сторон, выполнения коллективных действий и принятия интерактивных решений. В 2012 году Флориан Дикерт, занимающийся исследованиями в области человеческих взаимоотношений и экономики, опубликовал статью «The Tragedy of the Commons from a Game-Theoretic Perspective» (Трагедия общин с точки зрения теории игр). В этой статье он утверждает, что этот сценарий с «трагедией общин» не соответствует реальному положению дел[35]. Флориан отмечает, что хотя в подобной ситуации сотрудничество затрудняется (особенно при увеличении доли акций, находящихся в собственности акционеров), трагедия, вызванная неограниченной индивидуальной свободой, не является неизбежной.

Американский специалист в области политэкономии и нобелевский лауреат Элинор Остром выявила несколько факторов, которые критически важны для успеха совместных усилий в сценарии с «трагедией общин»[36]. Она утверждает, что для успешного сотрудничества должны выполняться следующие условия:

• наличие средств управления членством во всей группе;

• доступ к социальным сетям;

• заметные действия со стороны всех вовлеченных в процесс;

• возможность применения постепенно нарастающих санкций;

• наличие ресурса, который не является чересчур изменчивым.

Термин бесплатная езда относится к людям, которые пожинают плоды трудов сообщества, ничего не вкладывая в само сообщество. Эта практика наносит вред в случае, когда препятствует поддержке и участию со стороны других людей. В качестве примера можно рассматривать так называемого вампира поддержки, который постоянно задает вопросы, а если не получает ожидаемых ответов, тут же сильно обижается. Если же санкции отсутствуют либо не применяются, уменьшается индивидуальный вклад участников сообщества. В случае, когда не преследуется неколлективное поведение, в соответствии с теорией игр люди выберут именно это поведение. Это связано с необходимостью защиты личных интересов, поскольку сообщество больше их не защищает.

Остром и другие исследователи в области теории игр отметили, что способность к санкционированию поведения оказывает существенное влияние на общее сотрудничество. Если неколлективное поведение осуждается группой, коллективное поведение становится самодостаточным. Например, если каждому члену команды указано на недопустимость прерывания выступления других людей, они осознают, что этот метод привлечения внимания слушателей неприемлем. В результате ваша команда постепенно откажется от практики прерывания выступающих ораторов. Если кто-то попытается прервать оратора, его попытку проигнорируют.

Отсюда следует, что для создания сообществ на рабочих местах, которые бы не конкурировали, а работали вместе, нужно обеспечить наличие некоторых факторов, описанных в статье Остром. Во-первых, факт принадлежности к группе контролируется при найме на работу. Во-вторых, социальные сети существуют в форме организационных и командных иерархий, а также в виде неформальных и формальных социальных взаимодействий. В-третьих, поведение отдельных людей и команд в некоторой степени контролируемо. Ну и в-четвертых, существуют различные санкции, такие как план улучшения производительности, исключения из желаемых проектов, сокращение бюджета, сокращения и увольнения.

Представляет интерес заключительный фактор – ресурсы, которые являются довольно стабильными. Этот фактор особенно важен для небольших стартапов, которые во что бы то ни стало пытаются начать работу. Он также имеет значение для больших компаний, которые сталкиваются со спадами и сокращениями, с конкурентным поведением отдельных сотрудников и команд, которые менее склонны к сотрудничеству, чем в более стабильной рабочей среде. Независимо от размера организации рекомендуется учитывать эти факторы при формировании и поддержке стабильной совместной производственной среды.

Формирование эмпатии в команде

Благодаря эмпатии инженеры из эксплуатационной группы могут оценить возможность быстро и без суеты «нажать нужную кнопку». Эмпатия позволяет разработчикам оценить проблемы, вызванные написанием слишком громоздкого, медленного или небезопасного кода. Благодаря эмпатии производители и операторы программ могут помогать друг другу в обеспечении наилучших возможных функциональных свойств и работоспособности, требуемых пользователями[37].

– Джефф Сассна

Один из основных принципов движения devops заключается в формировании эмпатии, причем не только по отношению к людям, находящимся по другую сторону «метафорической стены» или в других подразделениях компании, но и по отношению к заказчикам. Эмпатия и понимание идут рука об руку. Поэтому без глубокого осознания желаний клиентов и их проблем ваш бизнес вряд ли будет успешным.

Выделенные инженеры эксплуатации

Вот уже много лет инженеры эксплуатации и системные администраторы рассматриваются отдельно от других сотрудников компании. Эти угрюмые неприятные люди смотрят на всех свысока и в ответ на любые вопросы предпочитают говорить «нет». Чтобы добиться успеха, нужно искоренять подобное «токсичное» поведение и вырабатывать нетерпимое отношение к его носителям. Это особенно важно для современного бизнеса, когда деятельность ИТ-отдела и эксплуатационного отдела критически важна для успешного выпуска продуктов. Давно ушли в прошлое те времена, когда единственный системный администратор уединялся в серверной комнате и поддерживал сеть, используемую для обмена электронной почтой и обеспечения доступа к принтерам.

В сильно разрозненных средах команды были вынуждены бороться за получение услуг и поддержки от эксплуатационных команд. Некоторые ИТ-отделы передавали контроль над выполнением необязательных процессов другим людям либо отказывались от выполнения работ, которые расценивались как пустая трата времени (например, сброс пароля для одного пользователя как минимум один раз в месяц). Из-за нехватки ресурсов некоторые отделы не могли выполнять собственную работу, не говоря о возможности предложить помощь другим командам. Нестабильная инфраструктура вызывает большие затраты времени на «борьбу с пожарами». Это приводит к невозможности выполнения профилактики возникновения неприятных ситуаций.

Чтобы улучшить положение дел, можно назначить инженеров эксплуатации, уполномоченных для работы с командами. Если команда постоянно нуждается в оперативной поддержке, потребуется выбрать контактное лицо в эксплуатационной команде. Например, такой человек понадобится команде, разрабатывающей библиотеки API или интернет-приложения. В связи со спецификой работы эта команда нуждается в выполнении мониторинга, настройки производительности и планировании мощностей. Если же обязанности контактных лиц исполняют случайные люди, им придется объяснять суть возникших проблем, знакомить с контентом, выполнять ранее проделанные действия и т. п. Инженер из эксплуатационного отдела, ответственный за поддержание связей с командой, обычно приходит на собрания либо отслеживает ситуации, требующие оказания дополнительной поддержки. Пример подобной ситуации – разработка новых конечных точек API, которые создают дополнительную нагрузку на кластер API. Если в этом случае понадобится новое оборудование, лучше, чтобы эксплуатационный отдел был поставлен в известность как можно раньше.

Чтобы заставить этот подход реально работать, нужно принять во внимание несколько ключевых моментов.

Назначение не эквивалентно всецелому посвящению

Важно помнить, что инженеры из эксплуатационного отдела назначены для поддержания связи с соответствующими командами, но не являются собственностью этих команд. Следует понимать, что эксплуатационная команда выполняет свою работу, а ее члены не могут и, как следует ожидать, не потратят все свое время на оказание помощи другим командам. Выделенный эксплуатационный инженер не обязательно должен исполнять все обязанности по техподдержке для данной команды. Скорее он будет основным контактным лицом для данной команды и будет управлять или наблюдать за соответствующей работой. Для выполнения этой работы очень важны наличие времени и навыков управления проектами у персонала из эксплуатационного отдела. Поэтому удостоверьтесь в том, что у персонала имеется необходимое образование и навыки.

Численность эксплуатационной команды

Если ваша компания не настолько мала, чтобы ограничиваться одной инженерной группой малой или средней численности, желательно не экономить на эксплуатационной команде. Как только вам придется выполнять дополнительную работу, выходящую за рамки рутинных проектов и обязанностей, кадровые резервы окажутся нелишними. Подобный подход практикуется в компании Etsy. Здесь на несколько сотен обычных инженеров приходится около 15 эксплуатационных инженеров, хотя для выполнения текущей работы хватило бы 2–3 человек.

Учтите, что назначенные специалисты по эксплуатации работают в неравных условиях и выполняют разные обязанности. В одних командах эксплуатационным инженерам приходится работать весьма интенсивно, в других – маяться бездельем. Второй вариант характерен для команд, которые даже не могут сформулировать вопрос специалистам по эксплуатации. Чтобы обеспечить равномерную загрузку специалистов по эксплуатации, назначайте их в соответствии с выполняемыми проектами, не привязывая к конкретным командам.

Уделяйте внимание эксплуатационному персоналу

Эксплуатация традиционно считалась неблагодарной областью. Пока все идет хорошо, специалистов по эксплуатации практически не замечают, но как только возникают какие-либо технические проблемы, они превращаются в «козлов отпущения». Особенно сильно эта тенденция проявляется в упречных средах. Уделяйте больше внимания специалистам из эксплуатационной команды, и они обязательно ответят вам взаимностью. Приглашайте их на общекомандные мероприятия, на пикники, проводите с ними больше времени вне офиса.

Учеба – это улица с двусторонним движением

Оно из преимуществ доверительных отношений, сформированных между командами, заключается в возможности совместного обучения. В результате расширяются возможности по обмену знаниями и опытом, полученными в процессе обучения. Выделенный инженер эксплуатации, присутствующий на собраниях команды, обычно озабочен техническими вопросами. Его интересует, каким образом будет контролироваться какой-либо процесс, что означает «находиться в производстве», как планировать восстановление после сбоев и другие подобные вопросы. Постепенно эти проблемы начнут волновать остальных членов команды, ну а в идеале они постараются не допустить их появления. Подобное обучение также полезно самим инженерам из эксплуатационного отдела. Они начнут глубже понимать и адекватнее оценивать характер работы других команд. Они начинают ценить мотивацию и деятельность членов других команд, перестают относиться к ним как к безликим именам и адресам электронной почты. Постепенно эксплуатационные инженеры распространяют понимание и эмпатию на всех членов команд, начиная их рассматривать в качестве людей своего круга.

Программа назначения специалистов не только позволяет осуществлять эксплуатацию, но и обеспечивает другие преимущества. Например, назначенные команды по дизайну или пользовательскому опыту помогут гарантировать простоту и интуитивную понятность в использовании создаваемых продуктов. Команда, разрабатывающая внутренние инструменты, создает средства, которые будут использоваться на уровне всей организации. Если эта команда, как это часто бывает, состоит из людей, которые имеют опыт системного или серверного администрирования, скорее всего, они разработают инструмент командной строки, который будет привычен и понятен для них, но не для обычных пользователей. При наличии назначенного дизайнера или UX-специалиста можно создать инструмент, который был бы востребован широким кругом пользователей. Еще одна область, в которой могут принести пользу назначенные в команду инженеры, – обеспечение безопасности. Подобно эксплуатационным работам, процедуры по обеспечению безопасности не воспринимаются широкой общественностью. Тем не менее они должны внедряться на протяжении всего жизненного цикла продукта, а не в последний момент.

Учебные лагеря и ротации

Благодаря учебным лагерям и ротациям люди могут быстро включаться в состав других команд, расширять знания и навыки, формировать эмпатию.

Термин «учебный лагерь» используется для описания следующего подхода. Сотрудникам, только что принятых в команду, в течение нескольких недель приходится работать с другими командами. Как правило, сотрудники работают вместе с командами, тесно связанными с базовой командой. Например, разработчик одну неделю работает вместе с эксплуатационной командой, а еще одну неделю – вместе с командой обеспечения безопасности. Преимущества подобного подхода заключаются в том, что новички обычно не участвуют в проектах, связанных со многими людьми, поэтому отсутствуют жесткие ограничения по времени. Также у новичков отсутствует предвзятое мнение о других командах или о «типичных способах решения проблем». Благодаря непредвзятому взгляду на проблемы в командах, с которыми работают новички, генерируются новые идеи. Эти идеи вряд ли появились бы при других условиях.

Процесс перемещения людей между командами часто называют ротацией. В некоторых организациях или командах ротацию опытных специалистов принято выполнять раз в год, Этот процесс планируется заранее, чтобы избежать негативных последствий из-за временного отсутствия людей на привычных рабочих местах. Причем ротация должна быть достаточно гибкой, вплоть до того, что члены команды сами избирают людей, с которыми им предстоит работать. В результате выполнения ротации люди получают разнообразный опыт, который позволяет им работать не по специальности. Например, эксплуатационный инженер может работать в отделе разработки мобильных приложений либо в команде разработчиков внешних интерфейсов. В результате обеспечивается возможность освоения новых областей и технологий, к которым они вряд ли получили бы доступ.

Работа в другой команде обеспечивает те же преимущества, что и программа назначения специалистов из других команд. Но в этом случае создается более серьезный фундамент для эмпатии и понимания. Также формируются точки соприкосновения между разными членами группы. Если руководство не дает добро на проведение полномасштабной ротации, возможно, оно согласится на выполнение локальной ротации. Например, можно в течение нескольких часов создать возможности для парной работы над проектами, задействовав людей из разных команд. Например, на основе согласия, полученного от сотрудников, можно организовать парную работу инженеров над списком требований к ПО или над малобюджетными программами из категории внутренних продуктов или проектов с открытым кодом. Эти программы используются в компании либо поддерживаются этой компанией.

Ротации во вспомогательных командах

Как уже упоминалось ранее, описанные в книге принципы могут применяться не только по отношению к командам разработчиков и эксплуатации. Кроме того, расширение области применения этих принципов позволит сформировать более сильную компанию и промышленную культуру. Многие компании, специализирующиеся в технических областях, особенно стартапы, оценивают своих инженеров очень высоко, но в то же время с пренебрежением относятся к персоналу вспомогательных подразделений. В то время как инженеры щеголяют в фирменных толстовках с капюшонами и ездят на конференции за счет фирмы, другие сотрудники прозябают в забвении. Естественно, что эти сотрудники начинают ощущать дискриминацию, вызывающую у них негативные настроения.

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

Во многих компаниях в описанную выше категорию попадает клиентская поддержка. Хотя она не так престижна, как служба эксплуатации, ее сотрудники являются «лицом» компании. Точно так же, как системные администраторы выслушивают упреки в случае «падения» сети или неработающего принтера, эксплуатационные инженеры принимают на себя гнев пользователей, раздосадованных плохой работой программ. Если пользователь программы звонит в службу поддержки или пишет сообщение, скорее всего, он чем-то недоволен. В силу свойственной людям привычки обвинять посторонних людей в собственных несчастьях, крайними всегда окажутся специалисты из группы поддержки, даже если они ни в чем не виноваты. Поэтому в командах поддержки пользователей наблюдается повышенная текучесть кадров, а участники этих команд часто чувствуют себя недооцененными, несмотря на исполняемую жизненно важную роль.

Для уменьшения текучести кадров рекомендуется выполнять ротацию службы поддержки. В рамках ротации участники других команд по несколько часов в неделю отвечают на письма пользователей, адресованных службе поддержки, либо реагируют на жалобы заказчиков. Обычно в службу поддержки обращаются с однотипными вопросами, поэтому при наличии хорошей документации и заранее созданных шаблонов ответов работа в службе поддержки значительно упрощается. Конечно, это не означает, что не понадобятся навыки и терпение. Все это понадобится, если придется оказывать помощь в сложных ситуациях. Благодаря наличию документации и шаблонов работать в службе поддержки могут представители других групп, особенно при наличии инженерного образования. Участники других команд, работающие в службе поддержки пользователей, получат представление о типичных пользовательских проблемах. Как правило, эти проблемы отличаются от проблем, «живущих» в представлении разработчиков. Также они смогут осознать ценность службы поддержки для компании в целом и для выполняемой работы.

Помимо разрешения и поощрения переключения, а также ротации сотрудников между разными ролями внутри собственной компании, в некоторых организациях подобные принципы применяются в отношениях между разными компаниями. В процессе так называемого инженерного обмена два инженера, исполнявшие примерно одни и те же роли в разных компаниях, могут обмениваться знаниями, общим опытом и формировать эмпатию, но уже на более высоком уровне. Компании начинают отказываться от конкурентного менталитета «защитите секретный код любой ценой», господствующего в недавнем прошлом. Они разрешают своим сотрудникам выступать на конференциях и семинарах по использованию программ с открытым исходным кодом, поскольку прекрасно понимают, что подобная деятельность не приведет к ослаблению конкурентных позиций компании, а скорее будет способствовать усилению отрасли в целом.

Конечно, успех этих видов программ зависит от обмена знаниями и обучения. Если в одной компании инженеру по обмену разрешается принимать участие в качестве полноценного участника команды и выполнять реальную работу, в то время как его «коллега по обмену» будет ограничиваться лишь просмотром документации, подобная связь будет односторонней. Возвращаясь к имевшей место ранее дискуссии, посвященной «трагедии общин» и факторам, способствующим коллективному поведению, отметим, что санкции за поведение, несовместимое с групповой работой, могут вынудить компании отказаться от участия в программах обмена с организациями-нарушителями. В результате уменьшается объем информации, которую плохие исполнители будут получать в будущем.

Для организаций, ищущих способы улучшения эмпатии как в целом, так и между командами, важно исследовать не только способы взаимодействия разных команд и групп, но и ценности, как реальные, так и воспринимаемые разными группами. Традиционно такие отделы, как ИТ и поддержка, рассматриваются как центры затрат, которые не приносят прямую прибыль, а лишь увеличивают затраты на управление компанией. Хотя движение devops начало улучшать отношение к эксплуатационным командам в целом, для осуществления кардинальных перемен в этой области нужно пройти длинный путь. Сотрудники центра затрат часто занимают неблагодарные рабочие места и получают более низкую зарплату. Центры затрат характеризуются более высокими показателями товарооборота и повышенным риском сокращения во времена кризиса. И хотя центры затрат воспринимаются как нижние ступеньки на корпоративной лестнице, при наличии нужных людей, обучения и ресурсов они могут давать невероятную прибыль в таких областях, как потребительская лояльность или стабильность инфраструктуры.

Расширяя понятие devops в целях учета этих команд и их воздействия на бизнес в целом, необходимо отказаться от иерархической лестницы. Эта лестница является чрезмерно упрощенной моделью, которая не только приводит к неверным представлениям о служебном росте, но и затрудняет проявление эмпатии к другим людям, которые находятся «ниже» по лестнице. Как уже упоминалось в других главах, перемещение из инженерного отдела в отдел менеджмента является изменением в карьере, а не карьерным ростом. Такая модель игнорирует способы, с помощью которых группы связаны и взаимозависимы.

А теперь представим вместо лестницы веревочную пирамиду, которую иногда устанавливают на детских площадках. Эта пирамида представляет собой набор натянутых разноцветных канатов, по которым могут подниматься и играть дети (рис. 9.1). Несмотря на то что эта модель является иерархической, с ее помощью легче вообразить такие роли, как ИТ и поддержка, которые находятся в основании других частей пирамиды. При рассмотрении этой модели нетрудно понять, что без прочной основы стабильность и успешность структуры находятся под угрозой. Лестница может утратить нижнюю ступень и по-прежнему применяться по назначению. Поэтому нижние ступени лестницы рассматриваются как центры затрат, от которых нужно избавляться в первую очередь. Но прежде чем избавляться, нужно обращать внимание на связанные с ними ценности, которые далеко не всегда оцениваются в денежном выражении. Но если вы обрежете один из нижних канатов веревочной пирамиды, вся конструкция потеряет стабильность.


Рис. 9.1. Иерархия, представленная в виде лестницы и пирамиды

Улучшение общения между командами

Помимо проявления взаимной эмпатии для обеспечения хорошей совместной работы нужно наладить эффективное общение между командами. Продолжая дискуссию о стилях общения и типах переговоров, которая была начата в части II, рассмотрим в этом разделе применение этих же методик на межкомандном уровне. Именно хорошо налаженное общение позволяет получать преимущества от внедрения devops не только на уровне отдельных команд или инженерного отдела, но и на уровне всей организации или бизнеса.

На простейшем уровне общение в группе формируется на основе общения между отдельными людьми, входящими в группу. Среди различных стилей общения, используемых в группе, побеждают наиболее доминантные стили. Зачастую это завершается тем, что люди, которые говорят громче всех, дольше всех или прерывают других ораторов, становятся доминантными в групповых дискуссиях. Такие люди также могут убеждать других людей не своими ценными идеями, а лишь потому, что их собеседники менее убедительны и не склонны прерывать других. Всего лишь один доминантный член группы, склонный прерывать других, может изменить динамику общения всей группы. В подобной обстановке другие люди будут вынуждены чаще прерывать собеседников, чтобы «вставить свои пять копеек».

Группы также часто заимствуют стиль общения лидеров, будь то менеджер либо человек, имеющий авторитет и уважение в группе. Если лидеры не умеют хорошо общаться, мало общаются либо используют стили общения, которые неприемлемы в совместной рабочей среде, они послужат плохим примером для других сотрудников. Поэтому не забывайте о стандартах, устанавливаемых лидерами в организации.

Во многих организациях часто ведутся дискуссии по поводу того, как и сколько общаться. Как мы уже упоминали ранее, разные средства в той или иной степени лучше подходят для разных типов общения. При выборе средств учитываются такие факторы, как достижимость, срочность, контент и т. п. С учетом этих разных факторов и персональных предпочтений зачастую трудно выработать рекомендации, которые всем понравятся. Как бы там ни было, но лучше общаться слишком часто, чем очень редко.

Сказанное выше особенно верно для средств коммуникации, для которых относительно легко настроить отдельные фильтры, соответствующие предпочтениям людей. Клиенты электронной почты позволяют автоматически фильтровать сообщения электронной почты по разным папкам, а программы чата обеспечивают настройку слов-предупреждений. Естественно, что это не единственное решение – допускается изрядное количество отдельных настроек. Также не допускается создание впечатления сознательного сокрытия информации, поскольку это будет способствовать формированию бункеров и отношений «в группе/вне группы».

Также учитывайте распределение людей и команд в организации. Как только команды начинают перемещаться между местоположениями и часовыми поясами, становится все труднее включать всех в процесс общения между людьми. После приобретения привычки к общению на расстоянии, например, с помощью электронной почты и текстового чата, по умолчанию не только сохраняются записи о ваших переговорах, но и преодолевается изоляция как для отдельных людей, так и для целых команд.

Общение в кризисных ситуациях

В кризисных ситуациях общение может оказаться нестабильным, например при «падениях» сайта. Тогда как общение в подобных специфических ситуациях является относительно новым объектом исследований, эффективное общение в кризисных ситуациях, задействующее много людей и команд, в более общем смысле хорошо изучено. Медицинские аспекты, связанные с общением, давно описаны. Также известны несколько проверенных стратегий, применимых к разным ситуациям, в том числе и к вашей.

Кросс-функциональное общение

Люди зачастую привыкают к общению исключительно с членами собственной команды. Также общение часто осуществляется в целях поиска и устранения проблем либо координации действий при работе с несколькими командами. Практика кросс-функционального общения, не затрагивающего чреватые стрессом темы, способствует формированию хороших привычек. В медицинских бригадах подобное общение имеет место между врачами, медсестрами и фармацевтами. В описанной ранее программе назначения эксплуатационных инженеров преимущества от общения получит инженерная организация. Поскольку отдельным командам присущи различные стили общения, которые развиваются со временем, работа по выработке и поддержке общих стандартов общения (например, общие контрольные списки или шаблоны, используемые в разных ситуациях) может способствовать уменьшению трений в процессе кросс-функционального общения.

Ассертивное общение

Из-за кризиса практически не остается времени на решение проблем с общением или на догадки, поэтому жизненно важно, чтобы люди ощущали комфорт в процессе ассертивного общения. Но учтите, что быть прямым не означает быть грубым. Именно в этой области обеспечение доступа людей к обучению может помочь им наладить непосредственное и эффективное общение, которое может быть достаточно полезным. Культурные различия могут иногда создавать барьеры на пути к утвердительному или непосредственному общению. Эти же различия могут служить стимулом для разных групп людей (например, разделенных по полу или по расе) социализироваться, чтобы общаться по-иному. В упречных культурах часто предотвращается возможность непосредственного общения между людьми, поэтому важно, чтобы люди были хорошо осведомлены о безупречных и невербальных стилях общения.

Специфические критические языковые методики

За истекшие годы были разработаны и изучены несколько методик, позволяющих людям выражать беспокойство или критику в ситуациях, характеризующихся большим давлением. В соответствии с правилом двух возражений не рекомендуется возражать более двух раз. В кризисных ситуациях можно что-то упустить, особенно если полезная информация маскируется в потоке слов. Тем не менее не рекомендуется возражать более двух раз, поскольку это приведет к дискуссии или к продолжительным дебатам. В результате будет невозможно своевременно выполнить нужные действия.

Создавать комфортные условия для общения особенно важно во время кризиса, когда ставки намного выше, чем в обычной ситуации. В этом случае используется стратегия CUS[38], которая поощряет людей говорить, когда они:

• озабочены чем-то;

• не уверены в чем-то;

• не уверены в безопасности.

Альтернативная методика SBAR предлагает рекомендации, позволяющие убедиться в том, что проблемы или критические замечания выражаются продуктивным образом. Чтобы общаться, нужно убедиться в наличии следующих данных:

• ситуационная информация, описывающая происходящее;

• справочная информация или контент;

• оценка сути проблем;

• рекомендации по выполнению действий.

Описанные в разделе методики могут применяться регулярно, чтобы выработать у команд привычку использовать каждую из них, а также общаться непосредственно и эффективно, насколько это возможно, как во время кризиса, так и в обычной ситуации.

Теперь, когда мы исследовали способы улучшения близости, рассмотрим преимущества, которые она может дать организациям в реальном мире.

Оглавление книги


Генерация: 1.338. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз