Философия DevOps. Искусство управления IT Дэвис Дженнифер
Постмортем
В отличие от планового регулярного характера ретроспективы постмортем имеет место после какого-то незапланированного инцидента либо сбоя. Обычно это происходит тогда, когда последствия происшедшего события были неожиданными для участников проекта, а также обнаруживается как минимум один выход из строя системы или сбой в работе организации. В то время как ретроспективы имеют место по завершении проектов и планируются заранее, постмортем произносится неожиданно в силу непредсказуемости соответствующего события. Цель постмортема заключается в проведении обучения на уровне организации. При этом можно воспользоваться преимуществами, связанными с системным и последовательным подходом к постмортему. Не забудьте упомянуть следующие темы:
Что случилось?
Хронология инцидента от начала до конца, часто вместе с журналами общения или системных ошибок.
Опрос
Каждый человек, имеющий отношение к инциденту, высказывает свою точку зрения о происшедших событиях, в том числе о своих мыслях во время событий.
Что нужно исправить?
Что нужно исправить, чтобы улучшить безопасность системы и избежать повторения в будущем подобных инцидентов.
В сообществе devops большое внимание удаляется тому, чтобы во время проведения ретроспективы или произнесения постмортема не высказывались упреки. Конечно, в постмортеме могут содержаться упреки, адресованные виновникам инцидента, но эта политика противоречит акценту на обучение, занимающему центральное место в движении devops.
Безупречность
Концепция безупречности является противоположной культуре, основанной на обвинениях. Несмотря на то что эта концепция обсуждалась уже несколько лет, в основном Сидни Деккером и его сторонниками, настоящую известность она получила после появления поста Джона Оллспоу, посвященного постмортемам, не содержащим упреков (https://codeascraft.com/2012/05/22/blameless-postmortems/). Суть этого поста заключается в том, что ретроспектива инцидента будет более эффективной в случае акцента на обучении, а не на наказании.
Культура безупречности направлена не на то, чтобы дать людям возможность уйти от ответственности, а на то, чтобы люди чувствовали себя комфортно при обсуждении подробностей происшедшего инцидента, даже если они являются виновниками этого происшествия. Обучение будет успешным только после осознания всех деталей происшедшего события.
Организационное обучение
Самообучающейся называется организация, которая непрерывно обучается и трансформируется… Обучение – это непрерывный и направленный на достижение стратегических целей процесс, который интегрирован и выполняется одновременно с рабочим процессом.
– Karen E. Watkins and Victoria J. Marsick, Partners for Learning
Организационное обучение представляет собой процесс сбора, роста и совместного использования знаний организации. В самообучающейся организации процесс обучения является более продуманным, поскольку оно представляет собой конкретную цель. Также предпринимаются действенные меры, чтобы со временем увеличить интенсивность коллективного обучения.
Организационное обучение, выбранное в качестве цели, является частью того, что отделяет культуру, основанную на упреках, от безупречной культуры. Тогда как культуры, основанные на упреках, зачастую в большей степени ориентированы на наказание, а не на обучение, безупречные или самообучающиеся организации понимают ценность опыта, извлекают уроки из происшедших событий и накапливают опыт, даже если этот опыт является негативным. Обучение может происходить на разных уровнях – на индивидуальном, групповом и на уровне организации. Организационное обучение оказывает большее влияние на саму организацию. К тому же компании, практикующие организационное обучение, являются более успешными.
В этой главе были рассмотрены разные методики, связанные с разработкой, развертыванием и поддержкой программного обеспечения и лежащей в его основе инфраструктуры. Также были рассмотрены культурные концепции, связанные с реагированием на инциденты и сбои отдельных лиц и организаций, а также с процессом обучения.
Конечно, мы рассмотрели далеко не исчерпывающий список методик, к тому же в будущем неизбежно появятся новые методологии и технологии. Тем не менее фундаментальные темы, связанные с разработкой, развертыванием, обслуживанием и обучением, будут по-прежнему являться основными для разработчиков ПО еще долгие годы.
Глава 5. Заблуждения и антишаблоны, относящиеся к devops
Когда идет речь о devops, будет не лишним обсудить, что не относится к этой концепции. В результате этого обсуждения выявятся некоторые очевидные заблуждения или идеи, не имеющие отношения к devops. В этой главе рассматривается дополнительный контент, касающийся devops, а также некоторые общие анти-шаблоны.
В индустрии разработки ПО часто встречаются неверные представления о devops. Поэтому группы сотрудников, сформированные в вашей организации, могут и должны бороться за выработку ясных и точных убеждений и ценностей, имеющих отношение к devops. В этом разделе мы рассмотрим некоторые проблемы, с которыми обычно сталкиваются при попытке внедрения devops в организации.
Devops – это лишь разработчики и системные администраторы
Несмотря на то что название «devops» произошло от слов development (разработка) и operations (эксплуатация), оно скорее является напоминанием об источниках происхождения движения devops, чем строгим определением. И хотя на конференциях devopsdays звучит слоган «Конференция, которая объединяет разработку и эксплуатацию», на самом деле концепции и идеи devops охватывают все роли в организации. Не существует единого исчерпывающего списка, регламентирующего, как и какие люди и команды должны быть вовлечены в движение devops. Также отсутствует единый универсальный подход к внедрению devops.
Идеи, которые помогают группам разработчиков и специалистам эксплуатации лучше общаться и более эффективно работать вместе, могут применяться на уровне компании в целом. Можно повысить эффективность любой группы в составе организации, будь то служба безопасности, отдел контроля качества, отдел эксплуатации или юридический отдел. Например, эффективные devops-процессы, внедренные на уровне юридического и коммерческого отделов, позволят реализовать автоматическое формирование контрактов на основе постоянного обновляемого каталога товаров.
Обратите внимание, что благодаря использованию принципов devops выигрывают любые две или большее число команд, поэтому не ограничивайте потенциальную аудиторию пользователей devops и не изолируйте группы сотрудников. В части III будут изложены соображения по эффективному привлечению групп сотрудников к использованию devops.
Devops – это команда
В общем случае создание специальной «devops-команды» вряд ли можно считать удачным решением. Обратите внимание, что ни создание команды под названием «devops», ни присвоение имени «devops» существующей команде не является ни необходимым, ни достаточным условием для формирования devops-культуры. Если ваша организация пребывает в таком состоянии, что члены команд разработчиков и эксплуатации не могут общаться друг с другом, создание дополнительной команды, ответственной за налаживание общения, приведет лишь к появлению дополнительных проблем. Чтобы внедрить значительные и долговременные изменения, сначала нужно решить фундаментальные проблемы.
Формирование отдельной команды в среде, в которой запускаются новые процессы и коммуникационные стратегии, может быть эффективным в тех случаях, когда проект стартует «с нуля». В больших компаниях формирование отдельной devops-команды обычно осуществляется на короткий срок. Основная задача подобной команды заключается во внедрении значительных изменений. Со временем, выполнив задачи по инициированию изменений, члены вновь созданной команды возвращаются обратно в свои группы.
Наличие в стартап-среде единственной команды, выполняющей обе упомянутые выше функции, является целесообразным в том случае, если она берет на себя ответственность за разработку ПО и выполняет миссию по его эксплуатации. При этом в команде должно быть налажено сотрудничество между участниками, позволяющее быстро решать возникающие проблемы, не прибегая к экстренному вызову отдельных профессионалов. В этом случае все равно потребуется менеджмент, позволяющий облегчить четкое распределение ролей и обязанностей. Это позволит выполнять масштабирование группы по мере роста компании в целом.
В этой книге рассматриваются различные возможности, используемые при организации команд, и стратегии, обеспечивающие коммуникации и координирование деятельности отдельных групп. В конечном счете следует помнить, что не существует единственного верного или неправильного способа внедрения devops. И если в вашей организации уже сформирована команда, в названии которой присутствует слово «devops», и эта команда действительно работает, нет смысла менять ее на другую команду. Имейте в виду, что слово «devops» подразумевает культуру, процесс, название и структуру команд, сформированных в вашей организации.
Devops как профессия
Толкование профессии «devops-инженер» является неоднозначным. Некоторые из толкований приведены в следующем списке:
• системный администратор, который знает, как писать программный код;
• разработчик ПО, владеющий навыками системного администрирования;
• мифический десятикратный инженер (производительность этого сотрудника в 10 раз выше производительности других сотрудников, хотя это скорее образное выражение), который может за одну зарплату выполнять обязанности системного администратора и разработчика ПО с наивысшим качеством работы.
Описанная концепция devops-инженера не только нереалистична, она еще и плохо масштабируется. В новых организациях разработчики нередко развертывают код и поддерживают сопутствующую инфраструктуру, но если компания является зрелой и имеет большие размеры, целесообразно привлекать специалистов к выполнению отдельных работ.
Вряд ли имеет смысл назначать devops-директора либо любого другого человека, ответственного за внедрение devops-практик в организации. По своей сути devops является культурным движением, поэтому идеи и принципы этого движения должны внедряться на всех уровнях организации. Лишь в этом случае devops будет эффективным.
Несмотря на все, что сказано выше, должность «devops-инженер» действительно существует. В соответствии с данными, опубликованными в отчете 2015 DevOps Salary Report от Puppet (https://puppet.com/resources/white-paper/2015-devops-salary-report), у инженеров, в названии должности которых присутствует слово «devops», зарплата выше, чем у обычных системных администраторов. Конечно, эти оценки весьма приблизительны, поскольку в разных организациях devops-инженеры исполняют самые разные роли. Скажите на милость, кто бы отказался от звания devops-инженера за прибавку в 10 тыс. долларов к зарплате?
В отчете 2015 DevOps Salary Report отмечается, что «большинство devops-инженеров работают более 50 часов в неделю, системные инженеры работают от 41 до 50 часов в неделю, а системные администраторы работают менее 40 часов в неделю». Как видите, никто даром деньги не платит. Если вы получаете высокую зарплату, будьте готовы пожертвовать своим личным временем и здоровьем.
Методология devops связана только с веб-стартапами
Основной продукт интернет-компаний – веб-приложения, с которыми имеют дело пользователи при просмотре веб-сайта компании. Эти сайты часто могут быть реализованы без использования информации, которая хранится где-либо между сеансами взаимодействия пользователей с сайтом (то есть сеансы без отслеживания состояния). Обновление сайта можно выполнить либо поэтапно, либо путем переноса «живого» трафика на новую версию сайта. При этом облегчается процесс непрерывного развертывания.
Несложно понять, почему devops-методики имеют такое значение для интернет-компаний. Это движение помогает разрушить барьеры, которые стоят на пути разработки и развертывания программного обеспечения. Если процессы, реализованные в интернет-компании, настолько медленны, что требуется несколько недель на устранение мелкой ошибки, скорее всего, эта компания не сможет конкурировать с организациями, в которых используются новые гибкие подходы к разработке и развертыванию приложений.
Преимущества, обеспечиваемые улучшенным сотрудничеством, близостью и инструментами, проявляются не только в веб-стартапах. Просто повторяющиеся действия (или итерации) с групповыми структурами и процессами проще выполнять в рамках небольших стартапов. Крупные компании сопротивляются быстрым изменениям, а правительственные учреждения активно препятствуют изменениям и ограничивают их с помощью специальных законов. Тем не менее изменения возможны даже в таких учреждениях и организациях. В следующих главах книги будут рассмотрены примеры использования методик devops в крупных корпорациях и правительственных учреждениях.
Devops нужно сертифицировать
Поскольку devops-методики в большой степени связаны с культурой, сертификация в этом случае вряд ли применима. Невозможно провести 60-минутный экзамен и по его результатам сертифицировать эффективность общения с другими людьми, оценить степень налаженности командной работы в вашей организации и сделать выводы о порядке обучения в организации. Сертификацию имеет смысл применять по отношению к высоким технологиям, использование которых потребует серьезного уровня знаний о таких вещах, как специфическое программное обеспечение или оборудование. Благодаря подобной сертификации компании могут получить представление о знаниях отдельных сотрудников в данной области.
При использовании devops-методов не требуется технологическая база либо универсальные решения. На сертификационных экзаменах обычно проверяют уровень знаний, задавая вопросы, на которые существуют четко определенные ответы. Как правило, в devops таких ответов не существует. То, что хорошо работает в одной компании, вовсе не обязательно окажется оптимальным для другой компании. Не существует простого способа разработать набор вопросов, имеющих отношение к devops, которые имели бы однозначные ответы. Сертификация в devops может либо использоваться в качестве средства заработка, либо быть связанной определенным решением поставщика, но называть ее devops-сертификацией некорректно.
Благодаря devops можно сократить персонал
Некоторые полагают, что благодаря devops можно получить разработчика ПО и инженера из службы эксплуатации в одном лице, но не платить ему двойной оклад. Мало того что это мнение ошибочно, оно еще и очень вредно. Многие стартапы предлагают сотрудникам бонусы, такие как трехразовое питание и прачечная на рабочем месте, в надежде стимулировать сотрудников подольше задерживаться на работе, но это приводит к негативным эффектам. Многие инженеры проводят на работе по 60–80 часов в неделю, люди перестают соблюдать баланс между работой и отдыхом, что ведет к переработке и переутомлению.
На самых ранних стадиях проекта стартап может только выиграть, если разработчики настолько хорошо разбираются в эксплуатации, что могут выполнять развертывание ПО, особенно при обращении к провайдерам облачных услуг и другим компаниям, могущим взять на себя выполнение большого объема оперативной работы. Но как только компания переходит в стадию зрелости и сотрудники начинают выполнять двойную работу, это может вылиться в выгорание.
Методология devops не поможет вам сэкономить деньги за счет сокращения вдвое количества инженеров, работающих в компании. Скорее она позволяет организациям улучшить качество и эффективность работы, сократить количество и длительность простоев, уменьшить время разработки и улучшить эффективность отдельных сотрудников и команд в целом.
Не существует единственно верного пути внедрения devops
Практики и специалисты по внедрению devops, работавшие во времена появления этой методологии, особенно хорошо известные в этой области, например Netflix и Etsy, часто назывались «единорогами»[14]. Они монополизировали рынок «правильных» способов внедрения devops. Другие компании, стремящиеся ощутить преимущества devops-культуры, иногда стремятся подражать этой практике.
Тот факт, что компания представляет собственную успешную devops-стратегию, вовсе не означает, что те же самые процессы позволят корректно внедрить практики devops в другой среде. Принудительный «вброс»[15] процессов и инструментов в среду может привести к дополнительной изоляции и к появлению сопротивления изменениям.
В devops поощряется критическое мышление по отношению к процессам, инструментам и практикам. В самообучающейся организации требуется проведение опросов и итеративный перебор процессов. При этом не принимаются на веру такие утверждения, как «единственно верный путь» либо «все уже было сделано до нас».
Не следует прислушиваться к людям, навязывающим свой способ внедрения devops. Нелишним будет повторить, что существует множество вариантов внедрения devops. Методология devops – это не набор жестко заданных правил, подобно Scrum либо ITIL. Компании, которые наиболее успешно внедрили devops, добились этого путем создания комфортных условий для обучения и итеративного поиска наиболее эффективных инструментов и процессов.
Для внедрения devops нужно X недель/месяцев
Если для внедрения devops нужно согласие руководства, то обычно задается вопрос о том, сколько времени займет подобное преобразование. Дело в том, что многие считают, что состояние внедрения devops можно как-то оценить либо измерить. И как только это состояние будет достигнуто, работу по переходу на devops можно завершить.
В действительности же devops представляет собой непрерывный процесс, это путешествие, а не конечная точка. Некоторые компоненты devops будут иметь фиксированные конечные точки (например, настройка системы управления конфигурированием и управление всеми серверами компании с помощью этой системы), но текущее обслуживание, разработка ПО и использование системы управления конфигурированием – непрерывный процесс.
Поскольку движение devops является в большей степени культурным феноменом, затруднительно предсказать, сколько будут длиться некоторые из этих изменений, сколько потребуется времени людям, чтобы отказаться от привычки работать в одиночестве и получить навыки сотрудничества. Все это довольно сложно предугадать, но пусть это не остановит вас от реализации важнейших культурных преобразований.
Методология devops – это лишь инструменты
Методология devops не требует обязательного применения каких-либо конкретных инструментов. Неверное представление об обязательности использования инструментов способствует формированию убежденности, что devops предназначен исключительно для стартапов, поскольку крупные компании зачастую не склонны внедрять новые технологии.
По своей природе devops является культурным движением. Инструменты, используемые в определенной среде, также являются частью культуры. Прежде чем принять решение в пользу изменений, требуемых для внедрения devops-принципов, нужно идентифицировать инструменты, являющиеся частью существующей культуры, получить сведения об опыте использования этих инструментов отдельными сотрудниками, а также идентифицировать сходство и различие между этими инструментами. После получения этой информации вы сможете определиться с необходимыми изменениями.
Применяемые технологии влияют на скорость изменений и организационные структуры организации. Серьезные изменения, внесенные в набор используемых инструментов, могут привести к замедлению скорости развития организации в целом, особенно если эти инструменты представляют ценность для отдельных сотрудников или команды.
Принципы, рассматриваемые в книге, не требуют специального набора инструментов и могут применяться к произвольному набору технологий. Существует довольно много общего между компаниями, которые практикуют devops, и компаниями, использующими контейнеры или провайдеров облачных услуг, но это вовсе не означает, что для внедрения devops нужны эти конкретные технологии. Известны примеры компаний, которые успешно внедрили devops, не используя какие-либо инструменты. В части IV будут рассмотрены эффективные способы оценивания, выбора и внедрения инструментов.
Методология devops эквивалентна автоматизации
Благодаря совершенствованию инструментов, применяемых devops-командами, облегчается систематизация накопленной информации. Внедрение автоматизации позволяет улучшить взаимодействие между командами. Практические специалисты делают упор на инструментах, устраняющих необходимость выполнения скучных повторяющихся задач. Примеры подобных инструментов – автоматизация инфраструктуры и непрерывная интеграция. В этих случаях автоматизация является результатом применения улучшенной технологии.
Если для освобождения персонала от выполнения рутинной работы используется автоматизация, это приведет к росту эффективности труда. В некоторых случаях преимущества автоматизации очевидны. Например, создание автоматизированного сервера позволит системному администратору сэкономить драгоценное время, которое можно потратить на более интересную или интеллектуальную работу. Но если на внедрение автоматизации будет потрачено больше времени, чем сэкономлено в результате этой же автоматизации, то вряд ли игра стоит свеч (рис. 5.1).
В свое время имели место многочисленные дискуссии о роли автоматизации в разных средах и о роли человеческого фактора в выборе типа автоматизации и способах ее внедрения. Эти дискуссии можно рассматривать в качестве примера межотраслевой близости. Если даже автоматизация применяется в других областях промышленности, вы сможете перенять чужой опыт и творчески его переосмыслить.
Рис. 5.1. Карикатура на потраченное и сэкономленное время согласно представлению карикатуриста из XKCD (https://xkcd.com/ 1205); изначально была опубликована со следующим текстом: «Не забывайте о том, что на поиск диаграммы, которая позволит узнать, сколько вы сэкономите, тратится время. Также вы тратите время на чтение напоминания о потраченном времени. И тратите время на выяснение разных фактов. Помните о том, что вы тратите секунды вашей жизни на выполнение разных действий, и делаете это сейчас»
РАННИЕ ПРИМЕРЫ АВТОМАТИЗАЦИИ В АВИАЦИИ
В 1977 году при рассмотрении состояния дел в американской авиапромышленности Комитет палаты представителей по науке и технике пришел к выводам о том, что автоматизация кабины пилотов негативно влияет на авиационную безопасность. В результате проведенных исследований выяснилось, что автоматизация кабины привела практически к полной атрофии критического мышления пилотов. Они утратили способность к ориентированию в пространстве без использования карты, отображаемой на дисплее, не могут выбрать следующее действие либо распознать сбой прибора. Как видите, применение автоматизации способно изменить поведение и способ мышления.
В июле 2013 года рейс 214 компании Asiana Airlines врезался в дамбу в международном аэропорту Сан-Франциско. В результате этого авиационного происшествия получили смертельные травмы 3 человека. В ходе расследования этого инцидента, проводимого Национальным советом по безопасности на транспорте (National Transportation Safety Board, NTSB), был выявлен ряд причин, способствующих катастрофе. Среди этих причин – недостаточный контроль скорости воздушного судна из-за чрезмерной зависимости от автоматизированных систем, показания которых не всегда корректно интерпретировались пилотами.
В своих попытках устранить ненадежный человеческий фактор разработчики автоматизированных систем управления невольно создали возможности для появления новых типов ошибок, которые могут быть более серьезными, чем те, которых они стремятся избежать.
Джеймс Рисон, Managing the Risks of Organizational Accidents
По мере усложнения систем и распространения общих услуг автоматизация приобретает критическое значение. Но если при внедрении автоматизации не используется общий контент и не учитываются интересы персонала, появляется дополнительный риск. Несомненно, благодаря автоматизации ускоряется выполнение работы, но чтобы это выполнение стало более эффективным, нужно увеличить степень прозрачности, сотрудничества и понимания.
Методология devops вышла из моды
Подобно тому как методология devops не привязана жестко к используемой технологии, инструменту или процессу, нельзя сказать, что она устарела или нуждается в замене. Движение, направленное на повышение эффективности деятельности организации и создание хорошего настроения для каждого сотрудника, может стать привычным и незаметным, но вряд ли когда-либо устареет.
Одно из основных различий между devops и такими методологиями, как ITIL и гибкая разработка (Agile), заключается в том, что последние имеют строгие определения, им присущ постепенно добавляемый контент. С другой стороны, devops – это движение, основанное на историях и идеях, которыми делятся отдельные люди, команды и организации. Это движение выливается в повторяющиеся беседы, эволюцию процессов и идей, которые приводят к росту и изменениям организаций.
В сообществе пользователей devops имела место дискуссия о том, потеряла методология devops вектор развития или нет. Критики этого движения утверждают, что оно слишком сильно зависит от отрицательных факторов, что оно уже не то, чем было ранее. Они также утверждают, что devops не является уникальным, что это всего лишь ребрендинг идей, которые существовали ранее, и от devops откажутся, как только появятся новое имя или тренд.
Многие из идей, лежащих в основе движения devops, действительно витали в воздухе в течение некоторого времени и под разными названиями, но дух devops является чем-то большим, чем простая сумма составляющих частей. Конечно же, люди выступали против функциональной изоляции еще до появления devops, высказываясь в пользу самообучающихся организаций, в защиту человеческих ценностей и автоматизации.
Движение devops объединило эти идеи и смогло достичь значимого успеха (http://bit.ly/2015-state-of-devops). Обобщение и использование эффективных методик devops приведет к росту и эволюции инструментов, технологий и процессов в вашей организации.
В этом разделе будут определены некоторые дополнительные термины, которые помогут лучше осознать суть devops. Но в отличие от терминов, определенных в предыдущей главе, эти понятия, как правило, трактуются как антишаблоны, продвигающие идеи, которые идут вразрез с концепциями devops.
Культура, основанная на обвинениях
Культура, основанная на обвинениях (упречная культура), проявляет склонность к обвинениям и наказаниям людей, совершивших ошибку (как на индивидуальном, так и на организационном уровне). В рамках этой культуры анализ первопричин не включается в постмортем или ретроспективу, используемые для идентификации причины сбоя или инцидента. Если анализу подвергаются действия человека, служащего «первопричиной» инцидента, он будет обвинен, ему будет объявлен выговор или его даже уволят из-за неприглядной роли в происшедшем инциденте. Этот вид культуры часто имеет место там, где нужно давать ответы внешним аудиторам либо нужно повысить производительность в соответствии с запланированными показателями.
В сильно изолированных или сегментированных средах, в которых уделяют недостаточно внимания прозрачности, пышным цветом расцветает культура, основанная на обвинениях. Если менеджмент стремится обвинить сотрудника или группу людей в каждом происшедшем инциденте и избавиться от «гнилого яблока», отдельные сотрудники будут пытаться переложить вину на других сотрудников или посторонних лиц. Хотя стремление к самосохранению вполне объяснимо в подобной среде, оно несовместимо с культурой открытости и сотрудничества. Более чем вероятно, что в подобной ситуации люди начнут скрывать информацию о происшедших событиях, особенно возникших вследствие их собственных действий, чтобы попытаться избежать обвинений.
Если не рассматривать реагирование на инциденты, культура, основанная на обвинениях, в попытках повышения производительности сотрудников будет способствовать формированию атмосферы враждебности между коллегами, в которой каждый сотрудник будет пытаться избежать ответственности. Если люди только и думают о том, чтобы не подвергнуться наказанию, они в меньшей степени нацелены на обучение и сотрудничество.
Барьеры
С помощью модели барьера на уровне отдела или организации описывается менталитет команд, которые не делятся своими знаниями с другими командами внутри одной и той же организации. Вместо того чтобы иметь общие цели и обязанности, группы, находящиеся за барьерами, исполняют разные и сегрегированные роли. В сочетании с культурой, основанной на обвинениях, это может привести к накоплению секретной информации о порядке выполнения той или иной работы («Если я единственный, кто знает, как выполнить X, они не смогут меня уволить»). Подобная атмосфера может привести к затруднениям в работе или к затягиванию работы, выполняемой несколькими командами, а также к ухудшению морального климата, когда команды или люди, находящиеся за барьерами, начинают видеть друг в друге противников.
Зачастую в барьерной среде можно найти разные команды, применяющие совершенно разные инструменты или процессы для выполнения идентичных задач. В этой среде сотрудники используют несколько уровней управленческой цепочки команд для получения ресурсов или информации от членов другой группы и достаточно часто перекладывают ответственность на другую команду.
Для устранения проблем и решения вопросов, связанных с организационными барьерами, потребуются время, усилия и культурные изменения. Наличие отдельных барьеров для разработчиков программ, системных администраторов и инженеров из группы эксплуатации, а также предпринимаемые попытки исправления ошибок, допущенных при разработке программного обеспечения, привели к возникновению движения devops. Основная причина появления барьеров заключается не в тотальном разделении обязанностей, а в отсутствии общения и сотрудничества между командами. Именно эти проблемы способно устранить движение devops.
Анализ первопричин
Анализ первопричин (Root Cause Analysis; RCA) – это метод идентификации причин возникших событий либо опасных ситуаций и выработки комплекса мер, направленных на предотвращение рецидивов. Это повторяющийся процесс, который продолжается до тех пор, пока не будут идентифицированы все организационные факторы либо пока не будут исчерпаны все данные. Организационный фактор – это фактор, который осуществляет контроль над системой на любом этапе жизненного цикла: проектирование, разработка, тестирование, техническое обслуживание, эксплуатация и списание.
Один из методов идентификации первопричин известен под названием «5 почему». При использовании этого способа вопросы «почему» задаются до тех пор, пока не будут идентифицированы основные причины. При этом требуется, чтобы лица, отвечающие на вопрос «почему», располагали объемом информации, достаточным для ответа на вопрос должным образом. Второй, более систематический подход заключается в создании диаграммы Ишикавы. Разработанная в 1968 году Каору Ишикавой, эта причинно-следственная диаграмма помогает командам визуализировать и группировать первопричины в основные категории, чтобы идентифицировать причины изменчивости, выявлять взаимосвязи между источниками и обеспечивать понимание процесса.
Зачастую метод RCA применяется для идентификации единственной первопричины. Инструменты, которые поддерживают управление событиями, часто допускают единственное назначение ответственности. Это ограничивает степень полезности метода RCA, поскольку внимание акцентируется на непосредственных причинах, а дополнительные элементы упускаются из виду. В методе анализа первопричин имеет место неявное предположение, что сбой или успех системы происходит в соответствии с линейным законом, что некорректно в случае достаточно сложных систем.
Человеческие ошибки
При использовании метода анализа первопричин в качестве основной причины сбоя указывается человеческая ошибка. Зачастую за этим утверждением следует вывод, что другой человек не совершил бы подобной ошибки. Это типично для культур, основанных на обвинениях, когда кому-то нужно объявить выговор за роль в происшедшем инциденте. Опять же, это слишком упрощенное представление, используемое в качестве точки остановки при проведении расследования. Предполагается, что человеческие ошибки совершаются из-за простой небрежности, усталости или некомпетентности. При этом из виду упускаются мириады факторов, которые способствовали принятию решения либо выполнению действия.
В культуре, основанной на обвинениях, обсуждение завершается после того, как будет найден человек, совершивший ошибку. При этом упор делается на самой ошибке и ее последствиях. В безупречной культуре или в самообучающейся организации человеческая ошибка рассматривается в качестве отправной точки, а не завершающего этапа. Появление ошибки приводит к дискуссии о контексте, связанном с принятием ошибочного решения, и о его смысле в данной ситуации.
Знакомство с терминами, рассмотренными в главе, обеспечит вам углубленное понимание остального материала книги. Вооруженные основной терминологией и концепциями, рассмотренными в предыдущей главе, а также сведениями из главы 3, вы получите более четкое представление о современном состоянии devops. На основе этого представления можно определить и более подробно рассмотреть четыре столпа эффективных devops-методов, что и будет сделано в следующей главе.
Глава 6. Четыре столпа devops
По мнению Патрика Дебуа, devops является чисто человеческой проблемой (http://bit.ly/debois-devops-culture). Это означает, что в каждой организации формируется собственная devops-культура, которая является уникальной для людей, принимающих в ней участие. Хотя и не существует универсального «единственно верного» способа внедрения devops во всех организациях, мы идентифицировали четыре общих компонента, с которыми придется иметь дело команде или организации, выделяющей время и ресурсы на внедрение devops.
Внедрение эффективных devops-методик зиждется на следующих четырех столпах:
• сотрудничество;
• близость;
• инструменты;
• масштабирование.
Благодаря комбинации этих четырех факторов учитываются как культурные, так и технические аспекты вашей организации. Можно, конечно, начать изменения в организации, опираясь на один или два столпа, но лишь использование комбинации всех четырех столпов позволит внедрить эффективные изменения в организации на длительной основе.
Не следует игнорировать первые два столпа, которые охватывают нормы и ценности культур и межличностных взаимодействий, опираясь лишь на использование инструментов. Конечно, для проведения успешной devops-трансформации необходимы эффективные инструменты, но только их недостаточно. Если бы можно было ограничиться одними инструментами, мы могли бы просто составить список успешных devops-практик и на этом успокоиться. Но на самом деле без разрешения межличностных и межгрупповых конфликтов, возникающих в организации, невозможно наладить устойчивые отношения, которые и приводят к формированию devops-среды.
Сотрудничество – это процесс достижения поставленной цели с помощью взаимодействия между несколькими людьми. Руководящим принципом движения devops стала кооперация между командами по разработке и эксплуатации программного обеспечения. Прежде чем организовать успешное взаимодействие между командами, имеющими разные цели, нужно наладить групповую работу в одной команде. Если в командах не налажена работа на индивидуальном и групповом уровне, вряд ли будет успешным взаимодействие между командами.
Помимо развития и поддержки отношений сотрудничества между отдельными людьми, группами и отделами внутри организации, важны прочные взаимоотношения в отрасли. Близость – это процесс формирования взаимоотношений между командами, способствующий свободе выбора разных целей или показателей при сохранении общих целей организации. При этом облегчается развитие эмпатии и обучение в разных группах. Близость может проявляться на уровне взаимоотношений между организациями, позволяя им делиться историями и учиться друг у друга. В результате создается коллективная база культурных и технических знаний.
Инструменты – это стимулятор изменений, реализуемых на основе текущей культуры и целей. Отнеситесь серьезно к выбору инструментов. Важно понимать, как правильно выбрать инструменты, как они воздействуют на существующие структуры, чтобы предотвратить появление скрытых проблем в командах и организациях. Невозможность выявления проблем, связанных с ценностями, нормами и организационной структурой, в случае отсутствия развития культуры ведет к формированию условий для появления скрытых сбоев. Если выбранные инструменты (или их отсутствие) мешают работать отдельным сотрудникам, ваша инициатива по внедрению devops будет обречена на провал. И если цена налаживания сотрудничества и так высока, то отсутствие инвестиций в инструменты (либо, что еще хуже, инвестиции в плохие инструменты) приведет к дальнейшему росту этой цены.
Масштабирование концентрируется на процессах и движущих силах, которые должны использовать организации на протяжении всего жизненного цикла. Помимо заметной роли масштабирования в процессе внедрения devops в больших корпорациях, оно также позволяет управлять другими столпами эффективных devops-методик на уровне организаций. Это управление осуществляется по мере роста, достижения зрелости и даже сокращения организаций. Имеют место разные соображения, как технические, так и культурные, связанные с организациями разного масштаба. В части V мы рассмотрим, каким образом применяются эти соображения в организациях, которые не попадают в категорию «типичных» devops-культур.
Благодаря использованию четырех столпов эффективных devops-методик вы можете устранить культурные и технические проблемы, влияющие на разработку программного обеспечения. Эти столпы будут подробнее рассмотрены в каждой из следующих четырех частей книги. Примеры использования этих методик, позаимствованные из практики реального бизнеса, относятся к самым разным компаниям – от веб-стартапов до крупных корпораций. Хотя и необязательно читать главы книги по порядку, но мы все же рекомендуем вам прочесть все главы книги. Это позволит вам осознать, каким образом гармоническое сочетание четырех столпов devops позволит devops-методологии стать по-настоящему эффективной.
Часть II. Сотрудничество
Глава 7. Совместная работа
Формирование устойчивых и долговременных взаимоотношений является критически важным для людей, проводящих долгие часы в совместной работе. Сотрудничество – это процесс получения определенных результатов с помощью взаимодействий, вклада и поддержки множества людей. Один из примеров сотрудничества, и далеко не единственный, – парное программирование. Суть этой методики, появившейся в рамках концепции гибкой разработки программного обеспечения, заключается в одновременной работе двух человек над одним фрагментом кода.
«Я действительно думаю, что у нас есть отличная возможность создать наш новый сервис по работе с отзывами на базе MongoDB. Я прочел отличное руководство по этой системе, где рассказывается, как можно быстро и легко разработать нужный нам компонент, не неся бремя административных расходов, как в случае с другими решениями», – сказал Джорди, разработчик внешних клиентских интерфейсов в компании Sparkle Corp.
Заразившись энтузиазмом Джорди, Дженераль прикинула потенциальные выгоды от включения MongoDB в стек инструментов Sparkle Corp. «У кого-нибудь есть какие-либо соображения или опасения по поводу MongoDB?» – обратилась она к группе разработчиков.
«В нашем стеке мы уже поддерживаем MySQL и связанные с ним компоненты. Мы уже вложили достаточно много усилий в интеграцию MySQL. Использование MongoDB приведет к дополнительным затратам на поддержку и техническое обслуживание. Может ли MongoDB дать нам что-то полезное, компенсирующее дополнительные затраты?» – спросила Элис, старший разработчик из компании Sparkle Corp.
Разногласия подобного рода часто проявляются в команде. Каким образом сотрудники могут ухудшить или улучшить отношения в команде? Давайте углубимся в devops-пакт и изучим способы налаживания сотрудничества между коллегами.
Являясь одним из базовых столпов devops, сотрудничество относится к интенциональным процессам и к общим целям отдельных сотрудников. Практические примеры сотрудничества приведены в следующем списке:
• асинхронный анализ кода;
• документирование;
• выпуски обновлений и отчеты об ошибках;
• демонстрация еженедельного прогресса;
• регулярное обновление статуса;
• парная работа.
Важно распознавать ценность и назначение разных форм сотрудничества. Один вид коллективной работы выполняется совместно с другими сотрудниками. При этом каждый сотрудник несет ответственность за свою часть работы, которую он выполняет на пути к достижению общей цели. Другой тип коллективной работы выполняется непрерывно, двумя или большим количеством сотрудников, которые работают вместе для достижения общей цели. Выбор формы сотрудничества зависит от характера работы и окружающего контента.
И помните о том, что зацикливание на единственном типе совместной работы подобно утверждению о том, что бег – это единственная форма физических упражнений.
В январе 2015 года Анита Вулли и ее коллеги представили результаты проведенного анализа деятельности команд в статье «Why Some Teams Are Smarter Than Others» (http://www.nytimes.com/2015/01/18/opinion/sunday/why-some-teams-are-smarter-than-others.html?_r=0), опубликованной в New York Times. В терминологии, предлагаемой Вулли, умные команды отличаются от прочих команд следующими характеристиками:
• связь;
• равное участие;
• модель психического состояния человека.
Другими словами, эффективное сотрудничество включает такие компоненты, как связь, равное участие и модель психического состояния человека (Theory of Mind; ToM). Компонент ToM – это способность идентифицировать свою перспективу и признать факт, что другие сотрудники имеют иные перспективы в силу индивидуальных отличий. Осознание различий между людьми и влияние этих различий на потенциальную перспективу поможет расширить свою собственную модель ToM, сформировать взаимное понимание и помочь разрешить конфликты, что критически важно для devops-пакта. Все это поможет усилить коллективный разум команды.
Каждому из нас присущи собственные навыки и уникальный опыт, которые обусловливают выбор и порядок выполнения работы. Благодаря уважительному отношению к индивидуальным различиям облегчается формирование взаимопонимания и разрешение конфликтов способом, который критически важен для devops-пакта. Благодаря использованию разных команд вы выиграете в креативности, скорости устранения проблем и производительности, но проиграете из-за повышенной вероятности возникновения краткосрочных межличностных конфликтов, возникающих как на персональном, так и на профессиональном уровне.
Профессиональные навыки
Профессиональные навыки либо опыт, полученный на предыдущей работе и применяемый на новом рабочем месте, могут быть самыми разными. И хотя нам кажется, что мы судим о человеке лишь по результатам текущей работы, на самом деле это не так. На наше мышление, наши взаимоотношения и наши усилия по налаживанию сотрудничества между коллегами большое влияние оказывает предыдущий опыт работы.
Зависимость профессиональных навыков от размера компании
Причина различий между профессиональными навыками может заключаться в размере компаний, в которых работали раньше носители этих навыков. В мире стартапов предпочитают нанимать и работать с людьми, имеющими опыт работы в стартапах. Подобная практика имеет смысл на ранних стадиях стартапов. В этом случае проще достичь успеха, поскольку на ключевых должностях находятся люди, имеющие успешный опыт запуска стартапов. Но не следует относиться предвзято к людям с опытом работы в больших компаниях. Если человек имеет опыт работы в крупной корпорации, это вовсе не означает, что он будет плохо справляться со своими обязанностями в малой компании. Поэтому не относитесь к таким сотрудникам предвзято – далеко не каждый сотрудник крупной компании относится к категории «динозавров», не способных приспособиться к изменившимся условиям. Избегайте предвзятого отношения к людям и эйджизма.
При подборе сотрудника обращайте внимание не на корпоративный опыт работы, а на способность перейти от балансирования между разными задачами, возникающими в крупных компаниях, к контекстному переключению, характерному для небольших фирм, выполняющих большой объем работ.
Влияние технического и гуманитарного образования
У людей, имеющих техническое и гуманитарное образование, могут возникать трения. Это может проявиться на уровне компании, когда инженерно-технический персонал расценивается как более ценный для компании. А с персоналом из отделов поддержки, продаж и маркетинга будут обращаться как с людьми второго сорта. Если подобные настроения овладеют умами всех менеджеров, например инженерами-соучредителями стартапа на ранних стадиях, это может привести к воцарению уныния среди обслуживающего персонала. Персонал должен ощущать адекватную оценку его труда.
Иерархии ролей
Имейте в виду, что дискриминации могут подвергаться не только сотрудники, не владеющие техническими специальностями. Во многих традиционных софтверных компаниях к ИТ-специалистам и людям, исполняющим вспомогательные роли (системные и сетевые администраторы, эксплуатационные инженеры, инженеры из отдела обеспечения качества и администраторы баз данных), часто относятся похожим образом. Например, денежное содержание эксплуатационного отдела часто проводится по затратным статьям. В этом случае затраты, связанные с эксплуатацией, рассматриваются как неизбежные обязательства без учета той пользы, которую может принести этот отдел для организации.
Конечно, польза от проведения эксплуатации на уровне организации не заметна. Она проявится лишь в том случае, когда что-то пойдет не так, произойдет какой-либо технический сбой или служба перестанет работать. Зачастую сотрудники других команд относятся к эксплуатационным отделам как к ненужной обузе или к прислуге. Именно проблемы такого рода в первую очередь вызвали появление движения devops.
Способы получения инженерной специальности
Даже среди инженерного персонала могут быть люди с разным образованием и опытом работы. Раньше считалось, что практически все инженеры-разработчики программного обеспечения имеют техническую подготовку, один или несколько дипломов в таких областях, как информатика и компьютерная инженерия, либо имеют многолетний опыт работы с компьютерами. Если человек с раннего детства был с компьютером «на ты», то ему проще научиться программировать в процессе получения инженерного образования.
За последние годы, по мере развития механизмов получения профессиональных навыков, уменьшились барьеры на пути к рынку разработки ПО. Появились краткосрочные школы программирования (от трех до шести месяцев) и образовательные программы, которые позволили радикально сократить время подготовки специалистов. Новые способы получения образования предназначены для людей, которые хотят выбрать карьеру программиста, но не имеют ни времени, ни денег на получение традиционного высшего образования.
В современных школах программирования имеются классы, предназначенные для обучения социальных групп, которые недостаточно представлены в ИТ-отрасли, например женщин или национальных меньшинств. Эти группы могут стать источником кадров для компаний, которые хотят внести разнообразие в инженерный персонал. Несмотря на эти новые тенденции, остаются компании, которые ищут людей с «традиционным» инженерным образованием. Это ведет к недостатку специалистов гуманитарного профиля, обладающих навыками, требуемыми для налаживания командной работы.
Опыт работы
Источником трений между членами команды также может стать опыт работы или профессиональный уровень. При рассмотрении кандидатов на рабочее место члены команды могут оказать предпочтение более опытным профессионалам или «старшим» инженерам, поскольку полагают, что более опытный сотрудник сможет быстрее войти в курс дела и начнет сотрудничать с другими членами команды.
К сожалению, на рынке труда гораздо меньше старших инженеров, чем выделенных для них вакансий. Помимо простого накопления технического опыта молодые сотрудники нуждаются в руководстве и обучении, чтобы дорасти до уровня опытных сотрудников. Помимо наличия технических навыков важно учитывать возможность использования сотрудников команды в качестве учеников или наставников. Если такие люди имеются, ваша команда сможет эффективно развиваться.
Личные качества
Увеличение разнообразия в команде ведет к расширению набора личных качеств, представленных в команде. Благодаря разнообразию опыта и точек зрения сотрудников, относящихся к разным расам и общественным группам, имеющих разные способности и уровень образования, растет потенциал организации, ориентированной как на конечный продукт, так и на поддержку пользователей.
Разнообразие персонала приносит пользу отдельным группам, организациям и отрасли в целом. Но оно также может привести к появлению определенных трений. Если в команде имеется одна преобладающая группа, например белые гетеросексуальные мужчины, и на работу принимается гомосексуальная женщина или человек другой расы, понадобится внести определенные изменения в политику организации во избежание появления проблем.
Подобные изменения могут быть достаточно простыми, например выбор другого стиля обращения членов команды друг к другу. Скажем, вместо приветствий в стиле «Привет, парни», «Как дела, чувак?» или «Господа» используйте более нейтральное приветствие, например «Привет, народ». Не позволяйте себе двусмысленных шуток, которые, вместо того чтобы снять напряжение, приведут к его нагнетанию. Также не забывайте о распределении рабочих часов и о соблюдении баланса между работой и личной жизнью. Представьте себе команду, состоящую из молодых одиноких людей, которые привыкли засиживаться на работе допоздна, а потом еще и пропускать рюмочку-другую. И вот в эту команду попадает одинокий отец, которому нужно забирать ребенка из детского садика в 6 часов вечера. Естественно, он не сможет принимать участие в бурной жизни своих коллег и будет исключен из социальных отношений.
Если сотрудники службы персонала понимают, насколько важны проблемы, вызванные различиями между сотрудниками, они помогут сгладить возникающие трения. Следует поощрять отдельных сотрудников и менеджеров научиться преодолевать невольные предубеждения, влияющие на рабочие взаимоотношения.
Благодаря изменениям в политике службы персонала формируется рабочая среда, основанная на безопасности, уважении и индивидуальном отношении. Без обеспечения личной безопасности вряд ли возможно формирование доверительных отношений между сотрудниками. Личные качества сотрудников влияют на формирование отношений между членами команды, и не всегда это влияние позитивное.
Важно также учитывать, что с ростом глобализации и популярности удаленной работы растет вероятность включения в состав команд представителей разных групп и национальностей. При работе с людьми разных наций следует учитывать даже такие нюансы, как особенности рукопожатий. Культурные и региональные отличия могут проявляться многими другими способами.
Цели
В то время как члены команды работают в одном направлении и разделяют ответственность за успех, отдельные люди могут иметь собственные личные и профессиональные цели, которые способны привести к конфликту. Если же быть в курсе личных мотиваций членов команды, можно добиться лучшего взаимопонимания и эмпатии между ними.
• Некоторые люди расценивают свое текущее положение в качестве некоего «трамплина» для дальнейшего продвижения по службе, в то время как другие относятся к нему как к «обычной работе». Сотрудники, принадлежащие ко второй категории, могут что-то делать в том случае, если ожидают прогресса в карьере. В противном случае они могут работать на стороне либо просто уделять повышенное внимание своим семьям в ущерб основной работе. Благодаря распределению работы с учетом приоритетов отдельных сотрудников можно избежать таких неприятных ситуаций, как срыв сроков сдачи критических проектов, ответственность за которые возложена на не слишком дисциплинированных сотрудников.
• Многие люди хотят учиться и совершенствовать свои навыки, но этот процесс специфичен для каждого человека. Поэтому следует скоординировать рабочие обязанности с учебными целями сотрудника и уточнить их влияние и ценность для общих командных целей.
• Некоторые люди склонны к индивидуальной работе, в то время как другие предпочитают развивать социальные взаимосвязи либо принимать участие в групповой деятельности, такой как наставничество или выступление на отраслевых конференциях. Вторая группа сотрудников воспринимает инженеров, постоянно озабоченных работой, как ограниченных людей, не участвующих в жизни коллектива. Ну а индивидуалисты, которые целиком погружены в работу, считают общественную деятельность бесполезной для «реальной» работы. Знакомство с особенностями разных членов команды и ожиданиями организации от каждой команды позволит свести к минимуму разногласия между отдельными сотрудниками.
Когнитивные стили
Причины возникновения разногласий между членами группы могут заключаться в различных способах обработки информации, так называемых когнитивных стилях. Ответьте на следующие вопросы, касающиеся особенностей мышления сотрудников:
• как они думают о разных вещах;
• как они учатся и усваивают новую информацию;
• как они мысленно связаны со своей работой, своей средой и окружающими людьми.
Различные когнитивные стили могут быть описаны как группы, состоящие из разных осей, или спектры. И хотя следующий список далеко не исчерпывающий, все же он включает некоторые ключевые стили, которые могут встретиться в рабочей среде.
Интроверт, амбиверт и экстраверт
Эти термины отражают особенности получения людьми энергии, направляемой на «перезарядку внутренних батареек». Интроверты восстанавливают энергию, пребывая в одиночестве или в хорошо знакомых им группах. В то же время экстравертам для восстановления энергии нужно взаимодействие с большим количеством людей. Амбиверты же находятся посредине, поскольку, в зависимости от обстоятельств, могут восстанавливать энергию как в одиночестве, так и в группе. Экстраверты получают удовольствие от групповых проектов либо организационных ролей, предусматривающих взаимодействие с большим количеством людей, и от открытого рабочего пространства. Интроверты предпочитают выполнять рабочие задачи в одиночестве и на закрытых рабочих площадках.
Спрашивающий или догадливый
Культура вопросов и догадок ведет свое начало от поста на интернет-форуме, написанного в далеком 2007 году. В этой публикации шла речь о различных способах, используемых людьми для получения информации от других людей. Те, кто спрашивают, предпочитают задавать вопросы в большинстве ситуаций, даже если понимают, что могут получить ответ «нет». Ну а любители догадок предпочитают получать информацию самостоятельно, избегая задавать вопросы, если не уверены, что получат ответ «да».
Разъяснение и документирование стиля общения, ожидаемого от членов команды, может помочь им прийти к взаимопониманию и избежать проявлений недовольства.
Стартер или финишер
Стартеры – это люди, которые любят придумывать новые идеи и начинать их реализовывать. Они энергезируют процесс начала нового проекта. Финишеры же настроены на успешное завершение дел, поэтому обычно устраняют проблемы, мешающие завершению проекта. Стартеры, скорее всего, начнут скучать, если их попросят выполнить работу финишера, ну а финишеры будут ошеломлены и не будут знать, что делать, если их попросят выполнить работу стартеров.
Аналитики, критики и универсалы
Аналитическое мышление сосредоточивается на фактах и доказательствах, разбирает сложные проблемы на более простые части, а также устраняет лишнюю информацию или некорректные альтернативы. Универсальное мышление получает информацию более опосредованно, находит недостающие элементы, рассматривает вопросы с разных точек зрения и устранят стереотипные паттерны мышления. Критическое мышление выполняет оценку и анализ информации до тех пор, пока не будет сформировано суждение. В сферу критического мышления включается оценка рассуждений, требуемая для получения логического обоснования или поиска источников предубеждений. Также сюда входит взвешивание разных мнений или частей доказательства для принятия решения, проверка логичности вывода на основе выполняемых рассуждений или же нахождение логических пробелов в рассуждениях.
Пуристы или прагматики
Пуристы стремятся использовать самые лучшие в мире технологии для решения возникших проблем, а если подобной идеальной технологии в природе не существует, они стремятся создать ее сами. Пуристы чувствуют себя некомфортно, если им приходится выполнять проекты с использованием обходных путей либо идти на компромиссы с инженерными принципами. Прагматики же более практичны, оценивают стоимость создания идеального решения и работы в реалиях текущих условий и ограничений. Прагматики будут думать о том, как запустить что-то в работу в реальной производственной среде вместо сосредоточения на технологии самой по себе, как это делается при использовании пуристского подхода.
Важно создавать и поддерживать рабочую среду, которая будет комфортной для людей с произвольными когнитивными стилями. Следите за офисной политикой, не допуская предоставления необоснованных преимуществ людям с определенными когнитивными стилями. Бывает так, что от сотрудников требуют, чтобы они появлялись на работе в 8 часов утра, не разрешают удаленное присутствие на собраниях либо планируют шумный открытый офис, не предусматривающий отдельных тихих помещений, в которых можно собраться с мыслями. Понятно, что подобная политика подойдет далеко не всем.
Если вас посетили мысли о найме новых сотрудников, учитывайте изложенные в этом разделе соображения. Обратите внимание на то, в какой части спектра находятся члены вашей команды, а также отслеживайте дисбалансы в вашей команде. Хотя это не столь уж и важно, но если в вашей команде больше сов, чем жаворонков, если отсутствует баланс между стартерами и финишерами, пуристами и прагматиками, это может привести к ухудшению качества работы и к падению общей производительности команды. Если вы полагаете, что для устранения этого дисбаланса нужно нанять сотрудников, обладающих определенными качествами, сделайте это при найме новых сотрудников.
Компании тратят деньги и ресурсы, чтобы форсировать процессы обеспечения качества и донести до сознания отдельных сотрудников ценности, которые являются критически важными для организации.
Наставничество
Важно уделять внимание вопросам обучения и наставничества, поскольку по-настоящему зрелые (старшие) инженеры всегда готовы поделиться своим опытом и знаниями с другими сотрудниками. Организации, которые вкладывают средства в рост и развитие младших инженеров, получат конкурентное преимущество. И это преимущество связано не только с ростом кадрового резерва организации, но и с тем, что компетентные инженеры имеют гораздо больше шансов остаться там, где они чувствуют поддержку независимо от имеющегося опыта. Обратите внимание, что разработка формальной программы наставничества может потребовать много времени.
Спонсорство
Помимо наставников пользу персоналу организации также приносят спонсоры, которые оказывают поддержку и защищают своего протеже. Спонсоры также инвестируют развитие отношений, приводящих к формированию взаимовыгодного альянса. Спонсоры способствуют продвижению своего протеже по службе, делают его своим фаворитом, способствуют росту самосознания своего протеже, а также обеспечивают связи с высшим руководством. На основе исследования карьеры 12 тысяч мужчин и женщин в Великобритании и США экономист Сильвия Энн Хьюлетт пришла к выводу, что для достижения ощутимых успехов в карьере спонсорство важнее наставничества (http://www.nytimes.com/2013/04/14/jobs/sponsors-seen-as-crucial-for-womens-career-advancement.html?_r=0). В каждой организации следует разработать комплексную программу по обучению сотрудников навыкам, необходимым для осуществления спонсорства, способам оценки потенциального протеже и методикам поиска и оценки спонсоров.
Образование
Руководство некоторых организаций опасается, что интенсивное обучение персонала будет стимулировать людей использовать новые навыки как повод для поиска лучшего места работы. И действительно, обучение и профессиональный рост реально мотивированных сотрудников могут привести к тому, что они найдут новое рабочее место, где ощутят поддержку и встретят понимание. Ну а в вашей организации останутся менее обученные или менее мотивированные сотрудники. В результате ваша организация может получить репутацию места, не самого идеального для работы, к тому же вы лишитесь талантливых сотрудников.
Обучайте людей достаточно хорошо, чтобы они захотели уйти от вас, относитесь к ним настолько хорошо, чтобы они захотели остаться.
– Ричард Бренсон
Успешная официальная программа наставничества призвана выработать у наставников и их подопечных соответствующие цели, роли и обязательства. Здоровое наставничество «течет» в обоих направлениях, что позволяет расти и учиться всем участникам отношений. Понимание этих отношений может помочь вам стать наставником, даже если у вас нет соответствующего опыта.
Наставничество молодежи старшими
Наиболее традиционным является наставничество младших со стороны старших. В этом случае старший инженер является наставником младшего инженера (обычно одного) в рамках некоторой официальной программы наставничества. Этот подход хорош для привлечения опыта многих старших членов команды для развития навыков младших членов команды. Эта методика работает лучше всего, если старшие сотрудники имеют достаточные навыки общения, способности к преподаванию и терпение, необходимое для действительного обучения других людей (нетерпеливому человеку проще взять клавиатуру в руки и сделать все самому). В идеале вопросы, заданные младшими сотрудниками, помогут старшим сотрудникам подумать о таких вещах, которые они ранее считали само собой разумеющимися, прежде чем предложить решение, которое было бы лучшим, чем решение в стиле «мы так всегда делали».
Наставничество старших со стороны старших
Наставничество старших со стороны старших имеет место нечасто. В этом случае старшие сотрудники наставляют друг друга. В процессе такого наставничества может иметь место глубокий обмен знаниями, но если оба сотрудника некоторое время занимали должность старшего сотрудника в одной и той же компании, они могут утерять способность задавать вопросы и видеть новые перспективы, присущие новым сотрудникам, имеющим свежий взгляд на мир.
Наставничество старших со стороны младших
Наставничество старших со стороны младших имеет место в том случае, когда младший сотрудник обучает одного старшего сотрудника. Если этот процесс реализован хорошо, укрепляется этический принцип «учиться у каждого, невзирая на личность». Всем нам присущи разные уровни конкретных навыков. Как правило, мы выбираем ту область обучения, в которой являемся наиболее сильными. Это означает, что довольно часто более младший по возрасту человек является более квалифицированным, чем старший по возрасту.
Наставничество младшего со стороны младшего
И наконец, наставничество младшего со стороны младшего имеет место в том случае, когда два сотрудника младшего звена пытаются научить друг друга. Оно характерно для быстро растущих команд, в которых отсутствует старший инженер, а другие сотрудники старшего звена слишком заняты своими делами. Совместное обучение позволяет двум людям получить нужные знания быстрее, чем в случае самостоятельного обучения, но отсутствие опытных наставников, обучающих хорошим практикам либо помогающим в случае возникновения каких-либо проблем, приводит к далеко не лучшим результатам.
Образ мышления – это наши представления о себе и о том, как мы используем наши возможности. После нескольких лет исследований в области мотивации доктор философии Кэрол С. Двек описала фиксированный образ мышления и образ мышления роста[16]. Под фиксированным образом мышления понимают врожденные способности и таланты, фиксированные черты характера, которые могут быть как хорошими, так и плохими, но неизменными. При образе мышления роста таланты и способности изучаются и улучшаются с помощью определенных усилий и практики. Образ мышления может серьезно воздействовать на то, как люди работают, как решают проблемы и как справляются с неудачами.
Культивирование правильного образа мышления
Читать бесплатно другие книги:
