Совмещение разработки и администрирования автоматизированных систем

На практике часто встречается построение процессов разработки и эксплуатации прикладных систем, при котором функции, связанные с поддержкой их функционирования и обслуживания пользователей, совмещаются одним или группой сотрудников с функциями развития этих систем^[1]. То есть одни и те же сотрудники заняты выпуском обновлений к программам (их доработкой) и администрированием промышленно эксплуатируемых комплексов — установкой обновлений, настройкой прав доступа, устранением инцидентов и т. д.

Данный подход не является допустимым как с точки зрения современных стандартов управления информационными технологиями, так и с точки зрения здравого смысла.

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

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

Как минимум, данная модель создает чрезмерную нагрузку на сотрудника, которая не компенсируется никаким профессионализмом и умением управлять рабочим временем. Проведенные на практике замеры занятости разнородными задачами программистов-администраторов крупных систем показывают распределение загрузки разработка/администрирование в среднем как 40/60%. При этом приведенные 60% распределены по времени в течение дня. Таким образом, программисты заняты в течение дня разработкой программ короткими порциями, многократно переключаясь между задачами и тратя суммарно значительное время на восстановление внутреннего видения структуры и текущего состояния поставленной задачи разработки после очередных прерываний. Производительность разработчика при такой работе снижается не до 40% от рабочего времени, а едва ли не до 0. Представьте реальную ситуацию, при которой неизбежный рост функциональности крупной системы приводит к постоянному росту количества пользователей, сбоев и задач по администрированию. Функция доработки такой системы неизбежно коллапсирует со временем.

Крайняя нежелательность данного режима для разработки программ подробно обсуждается, например, в работе Коберна^[2]. К слову, данный автор является одним из основателей agile и создателем Манифеста agile.

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

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

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

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

Основным показателем эффективности работы программиста-разработчика является скорость, с которой он выполняет заказы на развитие системы, и количество выполненных заказов на доработку.

Любое изменение промышленной системы несет риск сбоя, связанный с недостатками тестирования, который тем выше, чем менее эффективно оно выполняется.

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

И наконец, люди различаются своими психологическими характеристиками. В литературе встречается деление психотипов на спринтеров, стайеров и марафонцев. Первый тип людей склонен за счет кратковременного усилия добиваться значительных результатов и перемежать работу обоснованными периодами отдыха. Второй тип склонен к долговременной рутинной деятельности. Совмещая администрирование и разработку, мы заставляем один тип (чаще это оказывается спринтер) совмещать рутину и творчество. Заставляя спринтера заниматься рутиной, мы лишаем его заслуженного отдыха, что неизбежно приведет к потере ценного сотрудника. Не говоря уже о том, что творческий администратор критичной системы — это ночной кошмар любого руководителя; от него постоянно ожидают неприятного сюрприза, организованного из лучших побуждений. Он забывает народную мудрость, выраженную в поговорке «работающую систему не трогай».

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

• [1] Здесь мы не обсуждаем случай совмещения данных функций в рамках одного подразделения, когда их совмещение у одних сотрудников отсутствует.
• [2] Коберн А. Быстрая разработка программного обеспечения.