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