Сколько должно быть уровней управления

Сколько должно быть уровней управления - 1

Как-то на ФБ среди френдов образовалась дискуссия о том, сколько уровней управления должно быть для обеспечения эффективной деятельности организации. Вспомнил доклад Арнольда (не терминатора, а математика), представленный почти 20 лет назад, на семинаре при Президентском совете РФ. В докладе был сделан достаточно неожиданный вывод.

«Многоступенчатое управление, описываемое нашей моделью при n > 3, неустойчиво. Двухступенчатое управление приводит к периодическим колебаниям, но не вызывает катастрофического нарастания колебаний, происходящего при трех- и более ступенчатом управлении. Настоящую устойчивость обеспечивает только одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства».

Как такое возможно, если в организации тысячи сотрудников?

А все дело в проектном управлении.

Сразу уточню, «если водитель трамвая начнет искать новые пути – жди беды». Если внешние условия хорошо известны и стабильны, если производственные операции хорошо изучены и неоднократно испытаны, а функции исполнителей определены и постоянны, в этих условиях основой эффективности служат узкая специализация и конвейер. При отсутствии возмущений организация может находиться сколь угодно долго в состоянии равновесия (хотя и неустойчивого) и выдержит любую иерархию управление. Вспоминаем многоуровневые бюрократии от Древнего Египта до советских времен.

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

— Но постой, — скажет читатель, — в проектной деятельности есть своя многоуровневая иерархия: цели, стратегии, программы, портфели, проекты, подпроекты, пакеты работ. И на каждом уровне сидит свой менеджер. Ну и где же здесь «…одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства»?

Основой основ проектного управления является иерархическая структура работ. Серьезной ошибкой является процессная декомпозиция: анализ, проектирование, кодирование, тестирование, документирование.

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

1.Задан ожидаемый результат. «Что», а главное «зачем» (но ни в коем случае «как») должно быть сделано.
Как-то коллега Александр Орлов рассказал вот

такую историю

Помню, еще в Intel говорю своему сотруднику: Макс, посмотри статические анализаторы. Макс говорит, мол, не вопрос, и уходит. Приходит через 3 дня. Я:
— Ну как?
— Посмотрел.
— И…?
— Вот таблица…
Я чуть его не убил. Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.
Макс понял задачу по-своему — что нужно провести сравнительный анализ доступных статических анализаторов. Человек скачал и установил все эти анализаторы, придумал метрики для сравнения, нашел тестовые примеры. Три дня он занимался довольно осмысленной деятельностью. А я, как его менеджер, в итоге остался недоволен.

ИМХО, проблема, в том, что Максу была задана задача, а не цель — нет. Задача без цели, как правило, смысла не имеет. Цель без задачи имеет смысл. В данном случае цель, видимо, была повысить качество кода. Александр ее не озвучил — это его ошибка. Макс не спросил: «а нафига?».
Проявление непрофессионализма с его стороны.

2. Определены правила «игры». Минимум ограничений, связанных с системной архитектурой, стандарт кодирования, предоставляемый API, что точно не надо делать. Помним чем больше правил и стандартов, тем ниже производительность труда.

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

4.Установлены измеримые критерии оценки результата: что такое хорошо и что такое плохо.

И это все. Получаем устойчивое одноступенчатое управление, при котором руководитель работает в интересах дела, а не начальника.

Как-то, так.

Автор: craft_brother

Источник

Оставить комментарий