---

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

Главная слабость подходов совершенствования процессов до Scrum заключалась в следующем: Они в основном сосредоточивались на организационных потребностях самого руководства.

Например, на контроле, соблюдении правил и предсказуемости. Хорошему обслуживанию клиентов и повышению морального настроя сотрудников внимания не уделялось вовсе.

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

Они наказывали людей за отклонения от плана и надеялись исправить возникающие проблемы до запланированного завершения проекта.

Кроме того, независимые обособленные подразделения выполняли полностью разделённые фазы разработки. Например, команда разработки была совершенно независима от команды тестирования (проверки). Большинство людей, которые должны были работать ради одной бизнес-миссии, даже не знали друг друга по именам.

Можете предположить причину такого изолированного мышления вместо внимания к бизнес-миссии и профессиональной (деловой) зрелости сотрудников?

Причина проста — матричное управление . Матричное управление — организационная структура управления и сотрудников, существующая в бизнесе с 1970-х годов. На первый взгляд отличительная идея матричной организации кажется разумной.

Руководство создаёт структуру, объединяя людей с похожими функциональными и техническими навыками в одни и те же или в лучшем случае соседние обособленные подразделения.

Каскадная модель выполнения проекта в матричной организации

Тогда в компаниях были популярны так называемые «центры компетенций», каждый из которых представлял независимое автономное подразделение.

Одно подразделение для C++-разработчиков, другое для администраторов баз данных, третье — совершенно отдельное обеспечение качества за границей, и так далее. Попробуйте разберитесь!

Главная трудность матрицы заключалась в том, что для выполнения программного проекта без Scrum и Scrum-мастеров руководители временно заимствовали сотрудников из подразделений.

Эти сотрудники даже физически не находились вместе с проектными командами, оставаясь в комнатах своих центров компетенций.

После завершения проектов временные команды распадались, а участники переходили к следующим заданиям в других проектах.

Поэтому целевая бизнес-ценность текущих проектов никогда не была главным приоритетом независимых подразделений.

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

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

Статья McKinsey & Company в McKinsey Quarterly также ясно показала эту иллюзию оптимизации затрат за пределами матричной организации .

По оценке Gartner, организации во всём мире ежегодно тратили 600 миллиардов долларов США на восстановление ИТ-систем из-за незапланированных работ сопровождения и дефектов.

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

Да, вы правы.

Руководство и сотрудники воспринимали изменения, препятствия и ошибки как нежелательные исключения, которых вообще не должно было быть.

Поэтому изменения стали синонимом задержек программного проекта. Они обычно запускали эффект домино из последующих задержек. Команды искали виноватых в дефектах и препятствиях.

Наконец, поскольку у обособленных подразделений не было механизма обработки, исправления и изучения ошибок, они продолжали их повторять.

Кроме того, они продолжали наращивать технический долг пассивно пытаясь справляться с проблемами.