Билдскриптам тоже нужны тесты (и типы, спеки, и документация). Ну а теперь о погоде...

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

а не могли бы пример sla для данного случая привести?

Доступность сервиса NNN 0.9998 в год (2 часа простоя) - стоимость на обеспечение - 500 р в месяц.

это в упрощенном варианте, без извращений.

если бизнес скажет что дорого, то тогда ок, снижаем стоимость, но так же увеличиваем время простоя

обеспечение - это как раз рестарты и связанные вещи?

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

SLA не админом определяется, а бизнес-потребитель. В % или временах простоя в определенный период.
А админ должен уже внести предложения по градациЯм инцедентов и скорости реагирования на них.

Ярослав, мне не принципиально, пусть это будет не админ :) , а кто-то другой инициирует  процедуру определения  SLA нового сервиса.

Вы, как менеджер проекта, будете неизбежно сталкиваться с конфликтами в вашей команде. В этом видео я рассмотрел два варианта конфликтов:

1) Межличностный
2) Между группировками

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

https://youtu.be/byBd0GGpmXo

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

Ярослав, в договоре или в ТЗ всего не предусмотришь, это дорого и долго, да и не снимает все риски, например, чтобы предусмотреть  проблемы как в описываемом примере, необходимо было уже иметь опыт "встречи" с данной ошибкой.

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

Это чего вообще такое и как соотносится с Agile'ом ?

Всех и не надо. Но тот конфликтоген, что в описанном примере был бы снят, или , как минимум, смягчен.

Это про конфликты