30 июля 2015 в 15:17

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


Как-то на ФБ среди френдов образовалась дискуссия о том, сколько уровней управления должно быть для обеспечения эффективной деятельности организации. Вспомнил доклад Арнольда (не терминатора, а математика), представленный почти 20 лет назад, на семинаре при Президентском совете РФ. В докладе был сделан достаточно неожиданный вывод.
«Многоступенчатое управление, описываемое нашей моделью при n > 3, неустойчиво. Двухступенчатое управление приводит к периодическим колебаниям, но не вызывает катастрофического нарастания колебаний, происходящего при трех- и более ступенчатом управлении. Настоящую устойчивость обеспечивает только одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства».

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

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

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

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

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

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

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

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

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


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

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

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

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

Как-то, так.
Сергей Архипенков @craft_brother
карма
65,0
рейтинг 0,0
Эксперт в управлении разработкой ПО
Похожие публикации
Самое читаемое Управление

Комментарии (15)

  • –1
    Жаль что с четвёртым пунктом почти везде беда. Захотели люди тишины ночью. Чтобы спать. И сделать так, чтобы те кто спать мешают несли за это ответственность (бабушки, конечно, хотели чтобы она была уголовной). Скрипя зубами и подтягивая пояса выделили денег на работу законодательного собрания. И получили точный список ночных дел за которые наказывают. И пункт, делающий этот список бесконечным: «иные действия». Т.е. по букве закона: тишину нарушать нельзя никак. Мужчинам всё-таки нельзя храпеть, женщинам — стонать, котам — топать, детям — кричать во сне при болезни. Конечно если эти граждане не занимаются деятельностью «при отправлении ими религиозных культов в рамках канонических требований соответствующих конфессий».
    И если я правильно понимаю, то во славу давно забытых богов барана ночью можно зарезать (с песнями и танцами). А вот барану при этом мекать нельзя.
    • 0
      Критерии оценки — результат переговоров руководителя и исполнителя. Ни один уважающий себя менеджер не подпишется под нереальными сроками/трудозатратами. Если Вы, конечно, об этом.
      • +1
        Да, об этом.
        А кем должна проводиться проверка контроля качества? Выноситься в отдельный проект или как?
        • 0
          У меня видимо немного другая картина мира ;) Что такое «проверка контроля качества»?
          • 0
            К примеру кто должен определять что выбранная для решения библиотека полностью подходит для использования?
            Т.е. к примеру поставили задачу — взять что-нибудь для работы с soap и сделать плюшку. Разработчик взял библиотеку, сделал плюшку. После этого поставили задачу добавить ws-security, а этого выбранная библиотека не умеет.
            По моему мнению, это всё должно продумываться архитектором, который ставит задачи руководителям направлений, которые в свою очередь раздают задачи по отделам. Но в данном случае выходит больше одного уровня в иерархии проекта, что в целом не есть хорошо?
            Или я всё не так понимаю?
            • 0
              Вы абсолютно правы. Это зона ответственности системного архитектора. См. пункт 2. Но, ИМХО, он не руководит разработкой ИС, а проектирует ее.
            • +1
              По моему скромному опыту заранее продумать всю архитектуру практически невозможно. Просто в силу того, что конечные задачи продукта могут меняться заранее непостижимым образом.

              Задачей архитектора является придумать такую архитектуру, чтобы она с одной стороны удовлетворяла текущим требованиям, а с другой была бы достаточно декомпозирована, чтобы можно было выбрасывать и переделывать любые участки системы с минимальным ущербом для других участков.
              Обычно говорят о «гибкости» и расширяемости. Но, по большому счету, нужна полная переделываемость. Не должно быть точек принятия решений, требующих сделать выбор раз и навсегда.
              • 0
                Т.е. unix-way, если я правильно понимаю — набор небольших кубиков, каждый из которых делает свою работу хорошо и может быть при необходимости заменён аналогичным с недостающим функционалом, вместо одной большой собранной в монолит системы.
                В целом то, что и предлагается в статье — куча проектов, каждый из которых, при грамотной проектировке, может быть убран/заменён или добавлен новый?
  • 0
    Поэтому каждый пакет работ необходимо рассматривать, как мини-проект, направленный на достижение уникального результата и управляемый единолично.


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

    Вы вообще к управлению отношение когда-либо имели?
    • 0
      Иерархия работ != иерархия управления.
  • +1
    4.Установлены измеримые критерии оценки результата: что такое хорошо и что такое плохо.
    И эти критерии так или иначе привязаны к системе мотивации персонала, верно? И с ними есть одна проблема — измеряя эти критерии вы стимулируете персонал улучшать именно эти критерии, что однако не приводит к достижению общей цели.

    Пример из жизни. Программистов решили мотивировать скоростью выполнения своих задач. Выполняешь быстрее оговоренного срока — получаешь + к премии, выполняешь дольше — не получаешь. И, следуя этим нехитрым правилам, программисты начали с одной стороны давить на руководителя, чтобы им растягивали сроки, а с другой — наотрез отказывались что-то доделывать по-мелочи без регистрации новой задачи. И в итоге появляются в трекере задачи «Добавить двоеточие к лэйблу» или «Увеличить форму по горизонтали на 1 пиксель». Со своей оценкой времени, и воркфлоу. Программисты довольны, делают 110-120% производительности, а проект буксует в бюрократических согласованиях сроков крошечных задач.
    • 0
      Согласен. Аналогично с тех.поддержкой: пообещали клиентам ответ в течении часа. Ближе к концу часа клиенту отправлялся ответ в стиле «мы работаем над этим». В итоге работы по отпискам добавилось, сроки полных ответов остались такими же, а руководство компании какое-то время пребывало в уверенности, что компания стала работать лучше.
    • 0
      Индивидуальные KPI — зло. Согласен, что измеряем, то и получаем. Показатели устанавливаются на пакет работ, которые выполняет, как правило небольшая команда под руководством тимлида. Пример пакет — разработать 100 форм регламентной отчетности. Команда: аналитик, тимлид, два программиста, два тестировщика. Как-то, так.
  • 0

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.