Модель «доверяй, но проверяй» обычно применяется для описания источников информации, которые в целом надежны, но все же требуется проведение дополнительных исследований, чтобы удостовериться в достаточной надежности. Эта модель может также применяться в случае совместного выполнения профессиональных обязанностей. Имеют место случаи, когда кто-то ждет, пока «заработает» доверие, а потом уже собирается работать. В этом случае появляется пресловутая проблема «курицы и яйца». Как можно заработать доверие, если ничего не делать для того, чтобы его заслужить? Поэтому следует возлагать на сотрудников какие-то обязанности. Но сначала нужно довериться им, а потом проверить, оправдали ли они это доверие. Сказанное также справедливо для разделения полномочий и способности к принятию решений (в дополнение к работе над проектом и исполнению текущих обязанностей).
Ощущение справедливости
Доверие важно не только для технической, но и для человеческой стороны растущей организации. Ощущение справедливости необходимо для достижения удовлетворенности сотрудников. На практике это означает, что сотрудники должны верить в справедливое к ним отношение. И помочь в формировании такой веры может разработка формализованной системы ролей, уровней рабочих мест, шкалы заработной платы, а также обеспечение разумного уровня прозрачности в этих областях. Это может помочь людям осознать требования к исполняемым ими ролям, глубже понять процессы, управляющие повышением заработной платы или продвижением по службе. Это, в свою очередь, может существенно уменьшить силу чувств, которые могут угрожать доверию, например чувство, вызываемое несправедливой задержкой в продвижении по службе.
Распределение рисков, выполняемое в дополнение к распределению обязанностей и ресурсов, также является ключевым фактором. Если две команды совместно выполняют работу или используют ресурсы, выделенные на проект, но только одна из них будет виновата в случае возникновения каких-либо неприятностей, команде с повышенным риском появления проблем будет оказано меньше доверия. Кроме того, это может привести к распределению полномочий в пользу команды с меньшим риском появления проблем.
Одно из последних соображений, которое следует учитывать при рассмотрении сотрудничества, – стоимость «человеческого капитала», задействованного в создании и поддержке ПО. Зачастую от этих людей требуется постоянная доступность в режиме 24/7/365. Одним из движущих факторов, приведших к появлению devops, были неблагоприятные последствия, к которым привела господствующая в то время практика разработки программного обеспечения. Суть этой практики заключалась в создании отдела техобслуживания и выделении серверов, на которых выполнялось программное обеспечение. После появления методик непрерывной интеграции и инфраструктуры, а также использования улучшенного кода положение дел в этой области улучшилось, хотя и остались определенные нюансы.
Доступность и техническая поддержка
Как правило, пользователи требуют, чтобы сайты были доступны постоянно. В связи с этим возникает вопрос о проведении техобслуживания, которое может привести к простою сайта или ограничить предоставляемые этим сайтом услуги. Если исходить из точки зрения пользователя, то техобслуживание следует выполнять тогда, когда сайт посещают меньшее количество пользователей. Поэтому компании, находящиеся в США, выполняют техобслуживание сайтов поздно ночью или рано утром, но если пользователи этих сайтов находятся в Азии, то для них это будет рабочий день.
Подобная практика не является идеальной с точки зрения технического обслуживания. И дело даже не в том, что обслуживающему персоналу приходится рано вставать и поздно ложиться, а в том, что уставшие люди не могут быть бдительными, отзывчивыми и эффективными. Техническому персоналу приходится выполнять важные операции по техобслуживанию, когда они только что проснулись и предрасположены к совершению ошибок. Если же буквальное выполнение требований пользователей повлечет за собой слишком много временн́ых и финансовых затрат, можно воспользоваться способами по уменьшению издержек на эксплуатацию.