воскресенье, 31 января 2016 г.

Холакратия на авианосце?

Продолжая свое исследование опыта построения организационных структур у военных, я наткнулся на очень любопытную публикацию из журнала "Naval War College Review" от 1987-го года. Сама статья называется "The Self-Designing High-Reliability Organization: Aircraft Carrier Flight Operations at Sea"

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



"The job of this ship is to shoot the airplanes off the pointy end and catch them back on
the blunt end. The rest is detail."
-- Carrier commanding officer


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

Итак, какие основные особенности авторы выделили в ходе своего исследования?

Живая культура.
Несмотря на то, что армия считается исключительно зарегулированным институтом, в котором на каждый чих есть свой SOP (Standard operating procedure), в реальности записанного в инструкциях категорически недостаточно для того, чтобы успешно осуществлять деятельность. Конкретика уточняется на месте самими командами кораблей, подгоняется под конкретные условия и постоянно эволюционирует. В результате даже у кораблей одного класса сложившиеся порядки и протоколы взаимодействия могут серьезно различаться. Так же это означает, что новый корабль, укомплектованный свежими кадрами не готов к развертыванию до тех пор, пока его команда не научится его применять. Большинство выработанных "на месте" правил существует в виде живой неписанной культуры, которая поддерживается за счет постоянного применения на практике. Это приводит к тому, что без поддержки непрерывности действий эта культура быстрое теряется и нуждается в восстановлении. Если корабль на долгое время выбывает из строя (например, из-за кап.ремонта), то после введения в строй ему нужно существенное время для восстановления культуры, необходимой для обретения боеспособности.

Текучка кадров.
В американском флоте огромная текучка кадров, причем люди меняют не только места службы, но и специализацию. К тому же флот имеет склонность к воспитанию офицеров широкого профиля и поощряет смену вида деятельности в ходе карьеры. Это приводит к тому, что человек, оказавшись на новом месте, с большой вероятностью окажется и в новой для себя роли. Это представляет угрозу для уровня боеготовности корабля, так как привнесение не обученных кадров снижает способность экипажа эффективно выполнять свои функции. Между тем авторы статьи отмечают, что флот сумел обернуть эту текучку себе на пользу. По сути каждый корабль - это плавающая школа, в которой не только происходит обучение новичков, но и постоянный критический пересмотр уже сложившихся правил и адаптация их к изменениям. Ротация кадров не дает сложившимся правилам закоснеть и приобрести статус священного писания ("делаем так, потому что так всегда делали"). Приток новичков означает так же и приток новых идей. В итоге в каждый момент времени существующая культура определяется динамическим равновесием между новаторским настроем новичков и консерватизмом стабильного костяка офицеров.

"Плоская" структура.
Хотя флот, как и любая военная структура, имеет ярко выраженную иерархическую организационную структуру, решения об установлении или изменении тех или иных правил принимаются на основе горизонтальных связей: офицеры и подразделения сами договариваются со смежниками о разделении зон ответственности, протоколах взаимодействия, действиях в экстренных ситуациях и т.п. Эти решения не "спускаются сверху", а вырабатываются децентрализовано "по месту". 

Избыточность и дублирование.
Зоны ответственности смежных подразделений сильно перекрываются, а сами подразделения часто обладают избыточностью и дублируют некоторые функции друг друга. Хотя в гражданской культуре менеджмента такие явления клеймятся как "неэффективные", а излишние ресурсы и дублирующиеся функции "оптимизируются" с целью экономии, на флоте это явление рассматривается как ресурс для использования в критической ситуации. В случае ошибки, выбывания из строя или перегрузки одного подразделения, смежники могут без промедления принять на него свои функции, распределив их между собой таким образом, чтобы ничего не "повисло в воздухе". Практика внутренней ротации кадров между подразделениями способствует тому, что люди хорошо понимают, чем занимаются их "соседи", и разрушает организационные барьеры (т.н. "организационные бункеры"). В итоге на уровне отдельных людей и целых подразделений экипаж корабля демонстрирует высокий уровень гибкости и способности адаптироваться к неожиданным изменениям обстановки.


Почему это может быть интересно нам?

Выявленные исследователями особенности организационной культуры очень близко перекликаются с теми идеями, которые продвигают апологеты Agile, а также с новой и модной идеей под названием "Холакратия". Ключевой особенностью, которая кажется мне интересной в разрезе наших реалий, является децентрализация процесса принятия не только оперативных решений, но и решений об установлении правил и протоколов взаимодействия. В нашей организационной культуре такие внедрения идут обычно централизованно "сверху вниз", что порождает ряд негативных эффектов: сопротивление "снизу", неприспособленность выработанных "наверху" решений реалиям и конкретике "на местах", формальное и поверхностное выполнение новых требований при сохранении старой сути вещей. В итоге это идёт долго, больно, неэффективно, и успевает потерять актуальность к моменту, когда хоть что-то начнет работать как задумано.

В статье описан другой подход к решению задачи о выработке и оптимизации: "снизу вверх", в котором исполнители на местах самостоятельно договариваются друг с другом для того, чтобы устанавливать и изменять правила игры по мере необходимости. За счет проявления инициативы и наличия полномочий цикл между выявлением проблемы и внедрением улучшения, призванного её устранить, сокращается, т.к. не надо проходить цикл согласования "через начальство", и болезненную процедуру внедрения "в сжатые сраки" (с) начальствующих фантазий. Неосознанно я однажды применил схожий подход, о чем написал в более ранней статье.

"Главный секрет атомной бомбы был в том, что она возможна"

Безусловно, эта короткая публикация не содержит в себе готовых рецептов, о том, как это делать, но она сообщает нам важную информацию: есть люди (очень серьезные люди!), которые так попробовали, и у них оно заработало. Причем, это не просто какой-то мелкий стартап, а крупная военная организация с очень высокими требованиями к эффективности и надёжности. Своим примером они показывают, что децентрализация принятия решений не только не противоречит этим жёстким требованиями, но является средством обеспечения их выполнения. Мы можем изучать их опыт для того, чтобы попытаться повторить их успех на своей почве.

суббота, 9 января 2016 г.

Как я придумал свой процессор.

Я давно работаю в индустрии разработки программного обеспечения. Десять лет я увлекался программированием как хобби, ещё десять лет был программистом по профессии. Хотя мне доводилось программировать на достаточно низком уровне, одно оставалось для меня загадкой: каким образом из простых логических элементов получается машина, способная последовательно менять своё состояние и что-то делать, руководствуясь заданной программой. Не смотря на то, что я читал материалы о том, как устроены процессоры, полного понимания я так и не получил, всё равно оставалась в этом какая-то тайна и магия. Воспользовавшись праздниками я решил восполнить этот пробел, руководствуясь принципом: "чтобы что-то понять, надо научиться это сделать самому".

Для экспериментов я использую программу Logisim - очень удобное и наглядное средство для моделирования дискретных схем. 

Калькулятор

Для разминки и освоения инструмента я решил сделать что-то простое: шестнадцатеричный калькулятор. Калькулятор уже обладает некоторым состоянием, так что это упражнение помогло мне освоить азы работы с регистрами, логическими элементами и арифметическими устройствами.



Процессор 1.0

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

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

Процессор 2.0

Попытки написать программы для Процессора 1.0 выявили примитивность и непрактичность его набора команд, поэтому целью разработки второго процессора стала поддержка полноценного набора команд, который позволит писать осмысленные программы. В частности, необходимым я счёл:
  1. Условные переходы
  2. Косвенная адресация (доступ к ячейке, адрес которой хранится в регистре)
  3. Работа со стеком (команды push/pop).
  4. Поддержка подпрограмм (команды call/ret)
Составив список нужных команд я засел за разработку и через несколько дней получил первые работающие варианты. Сегодня компьютер выполнил "Hello, World". Сейчас процессор выглядит так:
Некоторые характеристики:
  • Разрядность регистров, шины данных и адреса: 16 бит.
  • Память адресуется только 16-битными словами
  • Микрокодовая архитектура процессора реализующая 60 команд (RISC). 
  • Микрокод составляет 255 24-битных слова.
  • Восемь регистров общего назначения (R0-R7)
  • Прямая и косвенная адресация через регистры
  • Косвенная адресация со смещением через два спец. регистра: SP (stack pointer) и OP (object pointer). 
  • Объединенная шина памяти и ввода-вывода.
  • Одношинная микроархитектура
  • Средняя длительность выполнения команды - 4 такта.
Процессор сделан по максимально простой одношинной архитектуре, которая даёт процессору хорошую гибкость, но делает его чрезвычайно медленным в исполнении команд. Пока я с этим смирился, так как простой процессор позволяет легко добавлять новые команды, просто расширяя микрокод.

При разработке процессора очень удобным инструментом оказался Excel. В нем я вел документацию, составлял микрокод и даже реализовал на VBA простой ассемблер. Вот так выглядит программа "Hello, World" и с генерированный ассемблером код:


Программа Logisim оказалась удивительно хорошо совместима с Excel: сгенерированный двоичный код прекрасно переносится в Logisim через copу/paste. 

Заключение

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

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

Конечная цель моих игр с Logisim - создание простого виртуального компьютера и базового ПО к нему. Меня сильно вдохновляют советские домашние компьютеры 80-ых (например, ЮТ-088), которые я выбрал для себя как некий идеал конечного результата. К этой цели и буду двигаться по мере наличия вдохновения и свободного времени, так что ждите новых публикаций по этой теме :)