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

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

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

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

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

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

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

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

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

Определенные истории (например, Netfix и Etsy) часто пересказывают в качестве успешных примеров внедрения devops. Но они не описывают все способы применения четырех принципов devops с целью повышения производительности. Такие организации, как Etsy, которые славятся своими культурными и техническими традициями, определенно могут поделиться историями роста производительности и эффективности работы. Но в этой книге собраны не только те истории, которые традиционно излагаются в devops-окружении. Разнообразие изложенных историй никоим образом не отрицает роль devops, а, наоборот, дает ключ к пониманию его важности в функционировании отдельной компании и отрасли в целом.

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