Как я придумал свой процессор 2: Из виртуальности в реальность

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

Решив, что останавливаться на достигнутом ещё рано, я стал думать, что делать дальше. Перебрав несколько вариантов я решил, что надо от симулированных схем переходить к настоящим. В качестве "мягкого" варианта работы с железом я выбрал экспериментирование ПЛИСом. В поисках подходящий платы я перебрал много вариантов и в итоге я выбрал для себя Terasic DE0 с чипом Cyclone III. Этот набор имеет достаточно мощный чип и хороший набор интегрированных портов и вспомогательных устройств (ОЗУ, Flash, SD-слот, кнопки, светодиоды)

ПЛИС: Начало

Цель - сделать свой процессор на ПЛИС - более амбициозная и более сложная, чем нарисовать его в программе-симуляторе. Помимо того, что надо осваивать новый язык (VHDL) и инструментарий (Altera Quartus II), здесь надо было думать о некоторых вещах, которые в симуляторе уже были сделаны за меня. Например, самому реализовать консольный ввод/вывод при помощи VGA-монитора и PS/2-клавиатуры.

Чтобы ускорить процесс, я искал и применял готовые наработки:

1. Прототип текстового VGA-контроллера (нашёл на сайте проекта "Марсоход").
2. Контроллер PS/2 клавиатуры вместе с ASCII-декодером: тут.
3. Простейший SDRAM-контроллер.

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

Через тернии

Поскольку новый материал и инструментарий представляли для меня определённую сложность, я решил сократить риски и не делать на ПЛИС что-то концептуально новое. Вместо этого я решил максимально подробно воспроизвести предыдущий процессор, поскольку он уже доказал свою логическую корректность на симуляторе. Это оказалось абсолютно правильным решением, поскольку человеку, привыкшему писать обычные программы, надо немножко мозг сломать, чтобы научиться думать в непривычных для себя реалиях. Некоторой диверсией является то, что язык VHDL очень похож на "обычный" язык программирования, что у бывшего программиста порождает неоправданные ожидания о его семантике.

Другой проблемой, над которой изрядно пришлось поломать голову, стала проблема взаимодействия двух схем, синхронизированных разными тактовыми частотами. Проявлялась она в том, что периодически зависал мой видеоконтроллер, который работал на частоте 25 МГц, но взаимодействовал с шиной низкой частоты (сотни герц). Разрешение этой проблемы потребовало чтение многих статей, изучения новых для меня понятий и концепций (например, "метастабильное состояние", "домен синхронизации"). Итог - вставленный за десять минут между шиной и контроллером асинхронный FIFO-буфер из библиотеки Altera Quartus II решил проблему. Но шёл я к этому тривиальному ответу долго...

Результат

Сказать по правде, пару раз руки опускались. Возникала мысль, мол, а не взялся ли я за проблему не по моим способностям? Но благодаря проявленной моральной и интеллектуальной стойкости мне удалось продраться через возникавшие по пути проблемы. Результатом стала точная логическая копия второго процессора на ПЛИС, бинарно совместимая с оригиналом. Даже микрокод из оригинала был повторно использован без изменений. В подтверждение скриншот виртуального терминала и фото реального монитора с выводом программы самотестирования:

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

1. Ширина машинного слова: 16 бит.
2. Ширина адреса: 16 бит, максимально адресуемая память - 128К (65536 двухбайтовых слов). Отдельные байты не адресуются.
3. Ввод-вывод с отображением на адресное пространство.
4. ОЗУ на чипе ПЛИС - 16К (8192 двухбайтовых слова).
5. Ввод: PS/2 клавиатура.
6. Вывод: текстовый VGA-терминал, матрица 80х30 символов. Знакогенератор использует прошивку от CGA-адаптера с шрифтом 8х8 точек (эх, ностальгия!).
7. Потребленные ресурсы ПЛИС: 2147 логических модуля (примерно 15% от ресурсов чипа).

Итог

Успешный прогон программы самотестирования - значительная веха моего домашнего "процессорного" проекта. Однако почти всё ещё впереди: видеотерминал надо превратить в полноценный адаптер с графическим режимом, для ОЗУ использовать SDRAM-чип, установленный на плате, освоить работу с Flash-чипом и SD-слотом, установленными на плате. После этого можно писать свой монитор и совершенствовать процессор, который ещё бесконечно далёк от совершенства.

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

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

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

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

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

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

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

Для экспериментов я использую программу 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), которые я выбрал для себя как некий идеал конечного результата. К этой цели и буду двигаться по мере наличия вдохновения и свободного времени, так что ждите новых публикаций по этой теме :)

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

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

"Прогресс

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

 СПИН продажи, стр.22.

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

В чем тут польза для меня? Дело в том, что по роду своей работы я постоянно так или иначе веду переговоры с коллегами. Собственно, вся работа менеджера - это коллективное решение проблем с привлечением своих коллег в качестве партнёров (а иногда и оппонентов). Можно сказать, что я постоянно занят тем, что "продаю" свои идеи коллегам, а они продают свои идеи мне. 

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

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

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

Будьте здоровы :)

Софт для мозга, ч. 2

Введение

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

Предыстория

В то время я был участником крупного проекта, разрабатывавшего продукт в области ИБ. Проектная команда была большой (десятки человек) и сложно организованной. Она состояла из 10+ подкодмад из которых почти десять писали код. Как несложно догадаться, если такое количество людей коммитит в транк продукта, транк становится очень нестабильным, что мы и имели в полный рост. Наша индустрия уже имеет рецепт борьбы с такой проблемой в виде бранч-плана, подразумевающего разработку и стабилизацию новых фич в отдельных ветках с последущей интеграцией в транк.

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

Как это было

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

Замысел состоял в том, чтобы путем личного общения "завербовать" критическую массу руководителей команд. Таким образом, действуя горизонтально, я распространял свою идею. С каждым человеком я сначала находил общий язык о проблеме, потом обсуждал с ним свою идею, его замечания и предложения. Этот процесс был взаимным - я "заражал" их своей идеей, а они способствовали её дальнейшему развитию своей обратной связью. После фазы вербовки я предложил без особой помпы провернуть пару пилотных интеграций новых фич в продукт по моей схеме. Естественно, что первый блин вышел отчасти комом, но это позволило нам отладить процесс. 

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

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

Разбор полётов

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

1. Активно вовлекал будущих "пользователей" процесса в его разработку, чем добился понимания ими целей внедрения и учёл их реальные интересы.
2. Применил пилотное внедрение на котором выявил слабые места процесса.
3. После внедрения процесса активно сопровождал его, оперативно решая возникающие проблемы и корректируя.
4. Начал с простого решения, которое по ходу эксплуатации развилось благодаря отзывам и инициативам коллег.

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

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

Заключение

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

Софт для мозга

"You can't do much carpentry with your bare hands and you can't do much thinking with your bare brain."

- Bo Dahlbom

Введение

Недавно я посмотрел выступление американского философа-когнитивиста Даниеля Деннета под названием "Tools To Transform Our Thinking". В нем он, рассуждая с позиций меметики, представляет наши полезные знания и умения как набор инструментов (или приложений), которыми мы можем пополнять свой арсенал, "скачивая" их у других людей или информационных источников. Это и другие его выступления я рекомендую посмотреть всем, кто заинтересован в науке о сознании.

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

В поисках этого источника я и обратил внимание на тот подход, который описывает Деннет в своих работах. Бизнес-процессы - это, в первую очередь, знания, навыки и привычки, аккуратно рассаженные по головам участников процесса, и позволяющие им вместо сумятицы и беспорядка производить согласованные действия. А если всё это суть программное обеспечение для нас, людей, то почему бы не посмотреть на разработку процессов, как на разработку ПО? Я вышел из разработчиков и знаю много о разработке, о подводных камнях и удачных практиках. Может быть эти полезные практики и модели можно перенести на бизнес-процессы?

Пример от противного

Представьте себе, что разработчик, которому поручили разработку line-of-business системы, проигнорировал реальные проблемы пользователей, не общался с будущими пользователями, не проводил промежуточных демо или пилотов. Все это время он провёл, разрабатывая "по водопаду" очень сложную систему, которая (по его мнению) должна идеально покрыть все пользовательские сценарии. После окончания разработки он установил программу только части пользователей, забыв настроить её под них нужды и обучить использованию системы. Более того, система заточена по Windows, в то время как у пользователей разносортица платформ: Windows, Linux, MacOS, Android. Проведя такое "внедрение" разработчик потерял интерес к проекту и занялся другими вещам. Не в силах разобраться с новой системой, и не видя в ней надобности, пользователи быстро забыли про неё и стали работать по-старому.

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

"Тринадцать шагов к успеху"

Некоторое время назад я был участником крупного проекта разработки информационной системы в области ИБ. Команда проекта включала в себя много сотрудников (десятки) и была разбита на несколько подкоманд с определенной специализацией. Проект испытывал затруднения: разработка шла медленно, качество результата не удовлетворяло заинтересованных лиц. Команды работали рассогласованно, статус работ был непрозрачен для руководителя проекта, постоянно случались накладки организационного и технического характера.

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

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

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

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

Анализ примера

Если проводить аналогию с внедрением софта, то был применен метод: "записать на диск и выкинуть в толпу пользователей, авось как-то само внедрится". Почему-то не внедрилось. Что было упущено, и что можно было сделать, если взглянуть на этот пример через призму опыта разработки и внедрения ПО?

1. Сотрудники не понимали целей внедрения и не видели в новом процессе решения насущных для них проблем. Та же проблема есть и при софтверных внедрениях. Как мы знаем, пользователей и прочих заинтересованных лиц надо активно вовлекать в разработку. Это не только проинформирует о  нововведении, но и поможет учесть интересы всех участников.
2. Был предложен сложный процесс, который было трудно запустить. За один прием разработать и запустить сложную систему тоже непросто, поэтому были придуманы такие методы, как пилотное внедрение, итеративная разработка и внедрение.
3. Информирование и обучение было сделано откровенно на "отвяжись". Мало того, что информирование было очень скудным и разовым, оно даже не покрыло всю проектную команду. Обучение сотрудников - это установка в их мозг новой программы. Внедрение сложной системы - это целый отдельный проект, который нужно планировать и исполнять.
4. Отсутствовала системная работа по сопровождению нового процесса. Новые сложные системы требуют периода опытно-промышленной эксплуатации, чтобы устранить выявленные проблемы и гарантировать работоспособность в реальных условиях.

Заключение

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

How to turn Ideas into Reality, by GEN David Perkins

Посмотрел пару дней назад выступление генерала Дэвида Перкинса с необычным для военного темой: "Как сделать идеи реальностью". Перкинс руководит TRADOC - организацией, которая разрабатывает доктрины и программы подготовки для армии США. В каком-то смысле, быть реформатором - его профессия, потому что его работа - предлагать и внедрять новшества.

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

1. Основная причина неудач внедрения - отсутствие системного подхода. Люди пишут документы, кладут на полку и думают, что само получится. (Очень напоминает некоторые процессные внедрения, которые я видел)

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

По измерению ресурсов: 

1. Что мы можем сделать прямо сейчас с тем, что у нас есть?
2. Что мы можем сделать, не изменяя существенно утвержденные планы или орг. структуру?
3. Что мы можем сделать, если добьёмся выделения крупных ресурсов и/или изменения в организации

По эшелонам (как он приводил пример):

1. У себя локально (т.е. в армии)
2. С привлечением комитета конгресса.
3. С привлечением конгресса и изменением законодательства.

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

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

Собственно, видео: