В процессе управления проблемами есть такая роль: координатор проблем. Как правило, эта роль предполагает ответственность за диагностику и решение проблем в какой-то предметной области, в том числе, с привлечением специалистов из смежных областей. И иногда я слышу от заказчиков вопрос: «А кто, собственно, должен быть координатором той или иной проблемы»?
Например, время от времени начинает тормозить приложение. Вполне логично координатором данной проблемы становится один из ведущих специалистов app-саппорта. Далее, предположим, в результате диагностики он выясняет, что тормоза возникают на СХД. Почему? Причин может быть множество, способов решения еще больше. А наш координатор проблемы в СХД не специалист. Как быть? Кто теперь станет координатором проблемы? Передать ее координатору по СХД? Оставить на app-саппорте?
Возможно, в сильной матрице, когда процессы доминируют над функциональными границами*, я бы принял вариант «Оставить на app-саппорте». И чтобы не поощрять перебрасывание проблем. И чтобы сохранить в качестве двигателя для решения проблемы мотивацию «страдающей стороны». И чтобы обеспечить более компетентную проверку результативности примененного решения. Но в слабой матрице этот вариант, к сожалению, работает плохо. У app-саппорта зачастую просто не хватает сил, чтобы влиять на смежников. Требуется множество эскалаций, возникают сложности в системе мотивации координаторов проблем. И передать проблему в группу СХД тоже не очень хороший вариант (мы теряем плюсы, перечисленные мной выше).
Так вот, в слабой матрице (а таких сценариев в моей практике большинство) приходится искать альтернативы. И я предлагаю действовать так: создать новую проблему по торможениям на СХД и передать ее соответствующему координатору, сохранив при этом проблему с торможениями приложения на исходном координаторе. Вместо одной сложной в решении проблемы (сложной из-за слабости горизонтальных связей) получаем две «простых», связанных друг с другом. Как дополнительный бонус, при таком раскладе получаем возможность «параллельного» решения обеих проблем. Ведь торможение приложения из-за СХД можно решать не только ускорением СХД, но и оптимизацией самого приложения, и перераспределением данных приложения по дискам – все же есть возможности и на уровне прикладного админа. Так пусть каждый и занимается своей проблемой, нечего ждать «пока поработают другие». К тому же, возможно, торможение СХД проявляется и другими способами, а значит с проблемой торможения СХД может быть связано несколько вызванных ей проблем. И эти взаимосвязи позволят лучше описать обстоятельства проявления проблем и оценить их уровень влияния.
Да, возможно, классический процессный подход тут подвергнут … вмешательству. Да, теоретически, это не самый эффективный способ управления ресурсами. Но, может быть, результат стоит того? Или вам известны достойные альтернативы?
(*) Про сильные и слабые матрицы можно почитать, например, здесь: http://www.inform-it.org/wp-content/uploads/2015/01/PMM-The-Process-Management-Matrix-article-Global-Best-Practice-Vol-I-2008.pdf
На мой взгляд в слабой матрице оптимальным вариантом решения данного вопроса является экскалация инцидента на уровень вверх, пока не дойдет до рук-ля, т.к. в приведенном примере нужно задействовать специалистов одновременно двух подраздлений и необходима координация их действий, в противном случае возникнет "футбол".