Вот я как-то рассказывал в качестве курьеза историю про программиста под Android, который, когда у него по какой-то причине перестала загружаться Android Studio, сообщил об этом боссу, отказался самостоятельно разбираться, что там глючит и попросил, чтобы сисадмин «все починил». Так как умения сисадмина в офисе ограничиваются своевременной заменой картриджей в принтере, все растянулось на два дня с переустановкой ОС, хотя скорее всего, могло бы быть решено гораздо проще. Ну и разумеется, приводил я ее в качестве примера «тщательно выстроенных границ», причем выстроенных в ущерб логике и здравому смыслу.
Вообще, конечно, в этой вашей айтишечке это считается крайне «неправильным» поведением, принято наоборот, всячески стараться разобраться в чем-то непонятном самостоятельно. Вот глючит у тебя твоя Android Studio? Сам разберись, сам поправь, «ты ж программист» — и любое поведение в духе «этим должен заниматься другой специалист» считается контрпродуктивным. Занятно, кстати, что во многих интерпретациях скрама даже требуют, чтобы каждый «разработчик» был кросс-функциональным (то есть мог выполнять работу кого угодно в команде) — хотя это не так, в Scrum Guide речь шла только о кросс-функциональных командах (т. е. состоящих из всех необходимых разнопрофильных специалистов).
А давайте попробуем переложить этот подход, скажем, на производство? Вот, скажем, токарь обнаруживает, что у него станок после поворота рубильника не включается. Вопрос: должен ли токарь самостоятельно залезть в электрошкаф, кинуть там какую-нибудь нештатную перемычку, и в зависимости от своего везения, получить один из нескольких результатов (а может и несколько сразу):
— неисправность устранена, все хорошо;
— неисправность не устранена, токаря ухуярило током, но не насмерть;
— токаря ухуярило током насмерть;
— электрошкаф задымился и сгорел нахуй;
— из-за нештатной перемычки вместо предохранителя загорелась проводка, пол-завода сгорело к ебеной матери?
Зато, разумеется, гайз, мы получили ценный опыт!