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

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

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

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

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

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