Работа оргдизайнеров

Как создавать модели оргразвития и целеполагания было рассмотрено в разделе по практике стратегирования, а здесь (в разделе по организационному дизайну) рассмотрим создание концепции организации и оргпроекта (проекта организации с точностью и детальностью, достаточной для воплощения в жизнь — управления изменениями/лидерства). В текущей литературе эти вопросы относятся к вопросам архитектуры предприятия, но мы учитываем свежие тренды:

• Архитектор предприятия находится по отношению к оргдизайнерам и лидерам в отношениях надзора и «продуктивного конфликта». Лидеры тут тоже важны, ибо организация может быть спроектирована с учётом орг-архитектурных решений, а вот лидеры потом могут эти архитектурные решения при воплощении проекта проигнорировать (например, «для скорости сейчас» в ущерб «скорости потом», о которой заботятся архитекторы).
• В рамках тренда на автоматизацию/цифровую трансформацию всё больше и больше функций операционного менеджера возлагается на софт, поэтому разработчики корпоративной информационной системы в существенной мере привлекаются к оргдизайну/оргпроектированию. По факту сегодня многие решения оргдизайнеров сразу отражаются в «настройках» корпоративного софта, которые не столько «настройки», сколько структура таблиц базы данных, какие-то маршрутизации в скриптах автоматизации и прочая специфика современного верхнеуровневого программирования софта, что трудно передаётся словом «настройка». Поэтому часто оргдизайнеры становятся неотличимыми от каких-нибудь «аналитиков при CIO», а дальше вместо лидеров выступают они же, чтобы обучить сотрудников пользоваться этими «настройками софта», а «лидеры для корпоративного софта» (лидеры — это роли, которые уговаривают людей заняться не тем, чем они хотят сами по себе, а чем надо для успеха организации, а тут надо уговорить этим заняться компьютеры со сложным софтом) — это программисты, которые делают эту самую «настройку».

Концепция организации создаётся ровно по тому же образцу, что и концепция любой системы: надо с учётом архитектурных ограничений разбить организацию на какие-то модули-оргзвенья (люди и их компьютеры, от одиночных людей и даже частей личности в случае part time работы до частей крупных холдингов с десятками тысяч сотрудников и огромными датацентрами), на которые назначить функции, требуемые для успешности во внешней среде. Вот как это схематически изображается для общего случая, описанного в «Системной инженерии»:

Далее внесём специфику менеджмента как инженерии организации:

Разработчик тут стал оргдизайнером (мы расщепили роль разработчика-организатора на подроли менеджера оргразвития и операционного менеджера, а менеджера развития на подроли занимающегося проектированием оргдизайнера/оргпроектировщика и лидера, оставили на диаграмме только оргдизайнера, а уж он согласует оргпроект со всеми остальными ролями, это его работа). Визионер (который смотрит, можно ли продать целевую систему клиентам) стал в организации как системе создания целевой системы бизнесменом (который смотрит, можно ли продать организацию инвесторам и использует для этого бизнес-модель). Уточнены и названия моделей. Use case при этом стали просто «сценариями» (ибо странно говорить про «сценарий использования дирекции инжиниринга», но можно говорить, например, о «сценариях взаимодействия с дирекцией инжиниринга», что то же самое с точки зрения окружения, просто перевели не двумя словами, а одним, но людям в дирекции инжиниринга это на слух много приятнее, нет оттенка «нас используют»). Юнит-тесты стали уже хорошо знакомыми нам чеклистами — организацию не принято «испытывать», хотя вполне можно «проверять», а уж чеклисты вообще не вызывают особых вопросов. Так что отношения между ролями и характер разрабатываемых моделей не изменились, но все они были уточнены для организации: это мы отразили переход от самой абстрактной мета-мета-модели системной инженерии к более конкретной метаУ-модели менеджмента как инженерии не вообще любой системы, а именно инженерии организации.

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

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

• Архитектор целевой системы предписывает ещё разбиение на какие-то модули с тщательно спроектированными интерфейсами и прописанными взаимодействиями через эти интерфейсы, это разбиение следует какому-то архитектурному стилю. Это делает архитектор, которого заботит «что будет потом» в терминах архитектурных характеристик целевой системы. Команды разработчиков по возможности независимо далее развивают каждая команда свой модуль для «что важно для клиента прямо сейчас», добавляя в него нужные для успешности надсистемы функции. При этом они могут мешать друг другу, часто ненамеренно. Грубо говоря, «мы хотим вот тут взять немножко энергии для печки, нам удобно взять 12 вольт, а рядом идёт провод 12 вольт из какого-то другого модуля, мы к нему подцепимся, то есть сделаем «неучтённый интерфейс» мимо публично объявленного той командой», и после этого в машине почему-то не срабатывает тормозная система после того, как включается печка: эти 12 вольт взяты из питания для тормозной системы, которое не было рассчитано на печку. Архитекторы целевой системы следят, чтобы такого не было, чтобы сиюминутные технические решения одной команды не влияли на характеристики системы на следующих шагах развития. Их отношение к разработчикам: сначала принятие обязательных для соблюдения разработчиками решений, затем менторство по разъяснению этих решений (не только «что надо делать», но и «почему надо делать», ибо разработчики будут придумывать хитрые способы обходить решения архитекторов — «по форме всё в порядке, а по сути — сущее безобразие»), а затем ещё и осуществлять надзор за выполнением этих решений. Разработчики и архитекторы в конфликте из-за разных межвременных предпочтений: архитекторы больше думают обычно про «потом», а разработчики про то, что клиенту нужно вот прямо сейчас: «давай реализуем грязный и быстрый способ решения текущей проблемы, а нормальную реализацию отложим на когда-нибудь». Разработчики постоянно накапливают долг по работам, нужным для выполнения архитектурных решений (на этот «технический/архитектурный долг» в среднем планируют до 20% ресурса разработчиков, задача только в том, чтобы у них обязательно было время выполнять эти планы).
• Оргдизайнер как разработчик организации должен спроектировать организацию: ровно вот те команды, которые будут выполнять работы по созданию системы, но и предусмотреть архитекторов, и визионеров, а ещё разработчиков и эксплуататоров внутреннего «конвейера» (platform engineers/DevOps). То есть он должен предложить организационную структуру (модель иерархической организационной структуры с делением организации на оргзвенья называется органиграмма), в которой будут для оргзвеньев отражены играемые ими организационные роли, о которых мы говорим — то есть транзитом он должен учесть предложения разработчиков (ибо там определяется предметное содержание модулей, важное для определения требуемых ролей — «для электронных модулей нужна роль электронщика») и архитектора целевой системы (сама нарезка на модули и принципы этой нарезки, помним о законе Конвея и обратном манёвре Конвея), чтобы отразить команды разработчиков на органиграмме, назначив им соответствующие функции в разработке. Всё ещё запутанней, ибо оргдизайнер в органиграмме должен отразить и менеджерские службы, в том числе отразить себя, а ещё тех, кто организует самого оргдизайнера, выполняющего практику оргдизайна. Оргпроектировщик/оргдизайнер тоже не «самозарождается» в организации, а его кто-то проектирует, а затем он сам будет объектом лидерства со стороны разных подролей организатора организаторов инженерных команд целевого проекта, цепочки создания обычно длинны. Ещё раз вернитесь к системной схеме инженерного проекта, представьте себе, что в организации множество проектов, которые делят между собой ресурсы — и вот эту задачу создания организационной структуры и решают архитектор организации и оргдизайнеры (которые занимаются вообще-то проектированием более-менее автономных модулей общей организационной структуры, определённых орг-архитектором). Довольно верный признак того, что вопрос должен решаться оргдизайнером — это звучащая в разговоре лексика каких-то отдельных специфических предметных практик, которыми занимается организация. Организация учится чему-то новому, для этого нужно запроектировать оргструктуру, которая будет поддерживать эту новую практику, поэтому «новая практика» тут будет ключевым. Архитектор же будет говорить самые общие слова, которые обычно говорят архитекторы: скорость, надёжность, безопасность, гибкость, масштабируемость, взаимонезависимость и т.д., только по отношению к организации, а не к целевой системе.