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

Так исторически сложилось

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

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

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

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

Плюсы и минусы

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

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

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

Взболтать, а не смешивать

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

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

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

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

#engineering #development #management