Комментарии 4
А вы сталкивались с эффектом “мы и они”? Что сработало у вас?
Сталкивался на уровне ограничений в зоне ответственности. Уж очень наши люди любят принцип "моя хата с краю - ничего не знаю". Как только вопрос или проблема выходит за рамки их функциональной области - моментально выключаются, даже если этот вопрос/проблема НАПРЯМУЮ влияет на качество в их области. Потому что "это вне нашей зоны ответственности" сказать в сто раз легче, чем найти и вовлечь нужных людей, потратить свой ресурс, проработать вопрос кросс-функционально и увидеть картину целиком. И это очень сильно напрягает.
В моём случае помогало "привитие" принципа солидарной ответственности. Показывал на практике, что все вовлеченные участники - это часть одного механизма с одним общим результатом (в меру конечно, не по принципу все ответственны за всё, а именно в актуальных кросс-функциональных конкретных проблемах). Например, поменяли интеграционную шину. Данные льются из системы А в систему Б через эту новую интеграцию, система Б является "витриной" данных. Возникает инцидент с интеграцией, в системе Б данных нет. Все жалобы валятся на систему Б, а её владелец, видя, что корневая причина в интеграции, складывает ручки на груди и говорит "ну я ничё не могу сделать, проблема же в интеграции - я написал им пару писем, мне не ответили - я забил". А у заказчика уже глаз дёргается и небезосновательно сделан вывод - система Б - г*вно. Владелец интеграции же сидит и говорит "ну мы проверяем и чиним, когда починим - неизвестно, дел много, иди лесом короче, потому что я тебе не подчиняюсь напрямую и на систему Б мне как-то наплевать, она для меня - одна из тысячи".
Вот и рассказываешь всем этим "ответственным" людям про последствия, текущее влияние и потребность в совместной работе. При этом как таковые мосты из поста выше - проложены, только люди по ним ходить не хотят.
Я считаю, что основные проблемы подобного плана должны решаться на уровне корпоративной культуры компании и создания общей вовлеченности в работу. Чтобы у Васи и команды системы А и у Пети из команды системы Б изначально были установки на взаимоэффективность, понимание взаимосвязей, а ещё лучше - понимание зависимости общей прибыли из совокупной доступности функционала систем А и Б. Но это уже совсем другая история, как говорится:)
Спасибо за статью. Очень распространенная ситуация.
Похоже, что проблема также связана с недостатками в стандартах и процессах проектного управления внутри компании. Правильно ли я понял, что DevOps-специалисты не были выделены, не были закреплены за ИТ-проектом с функциональным подчинением руководителю проекта, а также не были назначены ответственными за этап развертывания в рамках проекта? Из описания можно сделать вывод, что коллектив DevOps действовал в рамках своей "текущей деятельности" и в лучшем случае руководствовался стандартами и внутренним SLA. Если реализация проекта зависела от этапа развертывания, то данный этап и необходимые ресурсы должны были быть включены в календарный и ресурсный план ИТ-проекта.
В соседней стать плюсуют совсем другому подходу -- умей говорить "Нет - это не моя работа". Истина, как всегда, где-то рядом.
Кросс-функциональное взаимодействие в ИТ: когда все правы, но ничего не работает