Как-то на ФБ среди френдов образовалась дискуссия о том, сколько уровней управления должно быть для обеспечения эффективной деятельности организации. Вспомнил доклад Арнольда (не терминатора, а математика), представленный почти 20 лет назад, на семинаре при Президентском совете РФ. В докладе был сделан достаточно неожиданный вывод.
«Многоступенчатое управление, описываемое нашей моделью при n > 3, неустойчиво. Двухступенчатое управление приводит к периодическим колебаниям, но не вызывает катастрофического нарастания колебаний, происходящего при трех- и более ступенчатом управлении. Настоящую устойчивость обеспечивает только одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства».
Как такое возможно, если в организации тысячи сотрудников?
А все дело в проектном управлении.
Сразу уточню, «если водитель трамвая начнет искать новые пути – жди беды». Если внешние условия хорошо известны и стабильны, если производственные операции хорошо изучены и неоднократно испытаны, а функции исполнителей определены и постоянны, в этих условиях основой эффективности служат узкая специализация и конвейер. При отсутствии возмущений организация может находиться сколь угодно долго в состоянии равновесия (хотя и неустойчивого) и выдержит любую иерархию управление. Вспоминаем многоуровневые бюрократии от Древнего Египта до советских времен.
Но, если внешние условия динамично изменяются, если организация хочет получить уникальный результат, разработать новый продукт, требования к которому постоянно меняются, впервые применяет производственные технологии, если требуются интеллектуальные усилия, творчество, поиск новых возможностей, то в этих условиях применяют проектную организацию управления. И именно о моделях управления в таких системах и говорил Арнольд.
— Но постой, — скажет читатель, — в проектной деятельности есть своя многоуровневая иерархия: цели, стратегии, программы, портфели, проекты, подпроекты, пакеты работ. И на каждом уровне сидит свой менеджер. Ну и где же здесь «…одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства»?
Основой основ проектного управления является иерархическая структура работ. Серьезной ошибкой является процессная декомпозиция: анализ, проектирование, кодирование, тестирование, документирование.
Правильная структура должна быть ориентирована на результат. Поэтому каждый пакет работ необходимо рассматривать, как мини-проект, направленный на достижение уникального результата и управляемый единолично. И чтобы это управляющее лицо было «более заинтересовано в интересах дела, чем в поощрении со стороны начальства», необходимо выполнение всего четырех условий.
1.Задан ожидаемый результат. «Что», а главное «зачем» (но ни в коем случае «как») должно быть сделано.
Как-то коллега Александр Орлов рассказал вот
такую историю
ИМХО, проблема, в том, что Максу была задана задача, а не цель — нет. Задача без цели, как правило, смысла не имеет. Цель без задачи имеет смысл. В данном случае цель, видимо, была повысить качество кода. Александр ее не озвучил — это его ошибка. Макс не спросил: «а нафига?».
Проявление непрофессионализма с его стороны.
Помню, еще в Intel говорю своему сотруднику: Макс, посмотри статические анализаторы. Макс говорит, мол, не вопрос, и уходит. Приходит через 3 дня. Я:
— Ну как?
— Посмотрел.
— И…?
— Вот таблица…
Я чуть его не убил. Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.
Макс понял задачу по-своему — что нужно провести сравнительный анализ доступных статических анализаторов. Человек скачал и установил все эти анализаторы, придумал метрики для сравнения, нашел тестовые примеры. Три дня он занимался довольно осмысленной деятельностью. А я, как его менеджер, в итоге остался недоволен.
ИМХО, проблема, в том, что Максу была задана задача, а не цель — нет. Задача без цели, как правило, смысла не имеет. Цель без задачи имеет смысл. В данном случае цель, видимо, была повысить качество кода. Александр ее не озвучил — это его ошибка. Макс не спросил: «а нафига?».
Проявление непрофессионализма с его стороны.
2. Определены правила «игры». Минимум ограничений, связанных с системной архитектурой, стандарт кодирования, предоставляемый API, что точно не надо делать. Помним чем больше правил и стандартов, тем ниже производительность труда.
3. Выделены ресурсы и их рабочее время, аппаратно-программные средства и т.д.
4.Установлены измеримые критерии оценки результата: что такое хорошо и что такое плохо.
И это все. Получаем устойчивое одноступенчатое управление, при котором руководитель работает в интересах дела, а не начальника.
Как-то, так.
Комментарии (15)
ServPonomarev
31.07.2015 22:25Поэтому каждый пакет работ необходимо рассматривать, как мини-проект, направленный на достижение уникального результата и управляемый единолично.
В результате, иерархию управления заменили на иерархию проектов. Ой молодцы. Вместо того, что-бы смотреть в стратегическую даль и вести компанию в будущее, руководитель оказывается непосредственным участником сотен мини-проектиков, на которые декопозировалась задача.
Вы вообще к управлению отношение когда-либо имели?
ncix
01.08.2015 00:17+14.Установлены измеримые критерии оценки результата: что такое хорошо и что такое плохо.
И эти критерии так или иначе привязаны к системе мотивации персонала, верно? И с ними есть одна проблема — измеряя эти критерии вы стимулируете персонал улучшать именно эти критерии, что однако не приводит к достижению общей цели.
Пример из жизни. Программистов решили мотивировать скоростью выполнения своих задач. Выполняешь быстрее оговоренного срока — получаешь + к премии, выполняешь дольше — не получаешь. И, следуя этим нехитрым правилам, программисты начали с одной стороны давить на руководителя, чтобы им растягивали сроки, а с другой — наотрез отказывались что-то доделывать по-мелочи без регистрации новой задачи. И в итоге появляются в трекере задачи «Добавить двоеточие к лэйблу» или «Увеличить форму по горизонтали на 1 пиксель». Со своей оценкой времени, и воркфлоу. Программисты довольны, делают 110-120% производительности, а проект буксует в бюрократических согласованиях сроков крошечных задач.
Chmyaf
01.08.2015 07:53Согласен. Аналогично с тех.поддержкой: пообещали клиентам ответ в течении часа. Ближе к концу часа клиенту отправлялся ответ в стиле «мы работаем над этим». В итоге работы по отпискам добавилось, сроки полных ответов остались такими же, а руководство компании какое-то время пребывало в уверенности, что компания стала работать лучше.
craft_brother Автор
03.08.2015 06:30Индивидуальные KPI — зло. Согласен, что измеряем, то и получаем. Показатели устанавливаются на пакет работ, которые выполняет, как правило небольшая команда под руководством тимлида. Пример пакет — разработать 100 форм регламентной отчетности. Команда: аналитик, тимлид, два программиста, два тестировщика. Как-то, так.
Mithgol
19.08.2015 14:37Материал http://t.co/TkbljqaBcJ позволяет предполагать: #вертикальВласти (как политическая идея) основана на математике из доклада Арнольда.
— Mithgol (@FidonetRunes) 19 августа 2015
Chmyaf
Жаль что с четвёртым пунктом почти везде беда. Захотели люди тишины ночью. Чтобы спать. И сделать так, чтобы те кто спать мешают несли за это ответственность (бабушки, конечно, хотели чтобы она была уголовной). Скрипя зубами и подтягивая пояса выделили денег на работу законодательного собрания. И получили точный список ночных дел за которые наказывают. И пункт, делающий этот список бесконечным: «иные действия». Т.е. по букве закона: тишину нарушать нельзя никак. Мужчинам всё-таки нельзя храпеть, женщинам — стонать, котам — топать, детям — кричать во сне при болезни. Конечно если эти граждане не занимаются деятельностью «при отправлении ими религиозных культов в рамках канонических требований соответствующих конфессий».
И если я правильно понимаю, то во славу давно забытых богов барана ночью можно зарезать (с песнями и танцами). А вот барану при этом мекать нельзя.
craft_brother Автор
Критерии оценки — результат переговоров руководителя и исполнителя. Ни один уважающий себя менеджер не подпишется под нереальными сроками/трудозатратами. Если Вы, конечно, об этом.
Chmyaf
Да, об этом.
А кем должна проводиться проверка контроля качества? Выноситься в отдельный проект или как?
craft_brother Автор
У меня видимо немного другая картина мира ;) Что такое «проверка контроля качества»?
Chmyaf
К примеру кто должен определять что выбранная для решения библиотека полностью подходит для использования?
Т.е. к примеру поставили задачу — взять что-нибудь для работы с soap и сделать плюшку. Разработчик взял библиотеку, сделал плюшку. После этого поставили задачу добавить ws-security, а этого выбранная библиотека не умеет.
По моему мнению, это всё должно продумываться архитектором, который ставит задачи руководителям направлений, которые в свою очередь раздают задачи по отделам. Но в данном случае выходит больше одного уровня в иерархии проекта, что в целом не есть хорошо?
Или я всё не так понимаю?
craft_brother Автор
Вы абсолютно правы. Это зона ответственности системного архитектора. См. пункт 2. Но, ИМХО, он не руководит разработкой ИС, а проектирует ее.
ncix
По моему скромному опыту заранее продумать всю архитектуру практически невозможно. Просто в силу того, что конечные задачи продукта могут меняться заранее непостижимым образом.
Задачей архитектора является придумать такую архитектуру, чтобы она с одной стороны удовлетворяла текущим требованиям, а с другой была бы достаточно декомпозирована, чтобы можно было выбрасывать и переделывать любые участки системы с минимальным ущербом для других участков.
Обычно говорят о «гибкости» и расширяемости. Но, по большому счету, нужна полная переделываемость. Не должно быть точек принятия решений, требующих сделать выбор раз и навсегда.
Chmyaf
Т.е. unix-way, если я правильно понимаю — набор небольших кубиков, каждый из которых делает свою работу хорошо и может быть при необходимости заменён аналогичным с недостающим функционалом, вместо одной большой собранной в монолит системы.
В целом то, что и предлагается в статье — куча проектов, каждый из которых, при грамотной проектировке, может быть убран/заменён или добавлен новый?
craft_brother Автор
Про современную архитектуру ПО от Мартина Фаулера и его коллеги Джеймса Льюиса. Рекомендую.