Архитектурная практика (выполняет архитектор, ответственный за архитектурные характеристики): установить приоритетные архитектурные характеристики, принять решения по способам их достижения путём предписания деления системы на части и указания способа взаимодействия этих частей, а также отслеживать, что создание системы в целом улучшает эти характеристики (то есть, что не накапливается «технический долг» как долг по проведению работ, предотвращающих ухудшение архитектурных характеристик в долгосрочной перспективе)
Инженерия «производственного конвейера» (выполняет DevOps/инженер «производственного конвейера»/internal development platform, ответственный за средства/технологию воплощения проектных и архитектурных решений, а также технологию эксплуатации результата): создание условного завода-автомата/pipeline/internal development platform («конвейер»: оборудование и софт в компьютерах, но иногда это всё не работает без людей-операторов и это не совсем «автомат», а «обычный завод»), который используется разработчиками и архитекторами, чтобы воплотить проектные и архитектурные решения, провести инженерное обоснование (испытания, проверка соответствия архитектурным решениям и т.д.), а затем выдать пользователям/клиентам для эксплуатации. Современный взгляд на это «изготавливают» фичи системы разработчики, а DevOps только предоставляют им полностью работающее и обслуживаемое «заводское оборудование»/конвейер/pipeline/IDP (internal development platform). DevOps становится инженером конвейера, он осуществляет platform engineering, разрабатывает тот самый «завод-автомат», «конвейер», internal development platform. Редко бывает, что это именно завод/фабрика с настоящим конвейером или трубопроводом, ибо системы бывают крайне разные. Конвейер/platform начинается с правильной системы автоматизации проектирования, заканчивается системой поддержки цифрового двойника и не требует от разработчика никаких специальных знаний по его запуску и наладке, разработчики его просто используют. Вы как разработчик сами пользуетесь лопатой, чтобы копать, и точно так же сами пользуетесь internal development platform, чтобы создавать системы. Эту платформу вы сами их не создаёте, её создают инженеры производственного конвейера/DevOps/инженеры платформы разработки, но пользуетесь платформой вы сами, это называется «самообслуживание»/self-service35. Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it ты это строишь, ты и эксплуатируешь36). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве случаев это совсем не похоже на «конструкторское бюро» и «завод», например, трудно говорить о «конструкторском бюро для оргсистем» и «заводе оргсистем», «конструкторском бюро мастерства» и «заводе мастерства» и даже для компьютерных программ это не так очевидно. Но структура производства и эксплуатации везде будет одинаковой.
Вот это всё мы должны найти сейчас в менеджменте, понимая, что создаётся организация::система. Сложности ещё и в том, что одни и те же люди::агенты создают организацию в роли создателей и работают в этой созданной организации как её части-сотрудники. Поэтому лишний раз подчеркнём, что говорим о ролях, исполняемых агентами (со всеми обычными оговорками, что это может быть одна роль, исполняемая несколькими людьми, один человек, исполняющий несколько ролей, некоторые роли можно отдавать компьютерам, но потом считать, что их выполняет владелец компьютера, владелец компьютера может оказаться оргзвеном из полусотни человек с самыми разными ролями и т.д.).
Напомним системную схему проекта:
В этой схеме мы видим в голубых областях интереса сразу три организации, которые требуют менеджмента: организацию инвестпроекта, организацию проекта развития, организацию проекта. И это минимальная схема, в реальности она более запутанна:
В организации редко бывает один проект. Этих проектов множество. Они как иерархичны (проекты и подпроекты), так и множественны (заказная разработка: разные заказчики получают разные системы), и всё это сложным образом перепутано.
Редко так мало звеньев в цепочке создания. На диаграмме три звена, а в жизни в типовых ситуациях 46 звеньев в не самых даже больших проектах. И там не цепочки, а «деревья», и они сложно перепутаны, если учитывать ещё и множественность самих проектов из предыдущего пункта.
Схема используется для MVP системы, а затем для каждого инкремента/фичи в порядке «непрерывного всего»/continuous everything (разработки, введения в эксплуатацию). То есть нужно учитывать, что для каждого инкремента нужно порождать адаптированный экземпляр диаграммы (и напомним, что лучше бы это делать в табличных представлениях, а не графическом представлении диаграммы).
Помним, что эту схему нужно уточнять и конкретизировать в каждом проекте, ибо она дана в терминах самых общих, мета-мета-модели из учебников «Методология» и «Системная инженерия». Вот пример такой конкретизации до уровня мета-модели из учебника «Системная инженерия», схема проекта создания курса (и помним, что целевой системой в таком проекте будет не курс, а мастерство):
Эту схему мы прокомментируем чуть дальше, а пока заметим, что конкретизация из схемы «для всех случаев» в схему «для нашего проекта» ведётся на двух уровнях метамоделирования:
Мета-модель domain «как в учебниках предметной области» (где самая общая терминология, иногда на иностранном языке, а ещё перечисляются альтернативные варианты представления предметной области, разные школы мысли с предложением разных практик и способов их описания). Для краткости можем называть её метаУ-модель (как в Учебниках)
Мета-модель domain ситуационная, как это принято в вашей организации, где термины могут быть совсем не «из учебника», а исторически сложившимся сленгом, изо всего разнообразия практик выбраны какие-то конкретные практики (необязательно SoTA, а уж какие исторически сложились, при этом адаптированные под конкретный подвид систем или особенности систем создания скажем, не просто жарка картошки, а жарка картошки особых сортов, как в McDonalds). Для краткости можем называть её метаС-модель (Ситуационная).
Предметная область/domain в каждом звене цепочки создания, представленном отдельной зоной интересов своя! Где-то это domain целевой системы, где-то это domain менеджмента, где-то будет domain маркетинга как работы с сообществами, и т. д. Когда у вас не мета-мета-модель, а просто мета-модель с одним «мета» это уже не «безмасштабно» и «беспредметно» типа «каких угодно систем», а для какого-то масштаба, какой-то предметной области работы с какими-то конкретными типами систем.
Примеры ошибок, которые делают практически все наши студенты, проверьте, что вы их не делаете (тут приведены, конечно, не все ошибки, люди очень изобретательны в ошибках, но вот эти делают практически все новички в системном менеджменте):
Число звеньев цепочки создания (включая то, что разветвления цепочек создания даже не рассматривается, там ведь дерево, а в общем случае направленный граф из таких цепочек) ровно такое, как на наших картинках. Нет, выше было написано, что там граф, и даже в линейном случае очень часто 56 звеньев в такой цепочке. Поэтому нельзя копировать схему из учебника, в ней просто другое число элементов! А почему случай не будет линейным? Например, вы тут не видите организации, которая создаёт клиентуру (команда, выполняющая практику продвижения), а она обычно есть.
Поскольку наш этот единственный пример с курсом (мета-модель, как раз пример конкретизации) явно не подходит для проекта студента, студент вздыхает и берёт диаграмму общего вида (мета-мета-модель), прямо из курса «Методология», где она приводится впервые. И рассуждения ведутся для мета-модели предметной области устно, а на диаграмме так и остаются нетронутыми типы мета-мета-модели в надежде, что «когда-нибудь потом, не сейчас» будет проведена адаптация для предметной области и «когда-нибудь потом всё перерисуем, и даже переложим в таблички». Это откладывание «на потом» ошибка: в этом и смысл всей работы с мета-мета-моделью, что надо проводить адаптацию, это же поиск важных объектов внимания в вашем проекте, которые вы будете отслеживать! Найдите их, выясните их имена! Честно стройте вашу собственную схему, адаптированную для вашей системы, и в которой другое число элементов, чем на диаграмме из наших учебников (может быть и то же самое, но такое бывает редко, не промахнитесь если визуально ваш труд «по картинке» и по именам основных альф похож на то, что в наших учебниках, то вы уже ошиблись, хватает пары секунд взгляда на результаты вашего моделирования, чтобы это понять).
Эти диаграммы распухают, графически их поддерживать становится невозможно. Графическая форма не позволяет легко вносить изменения, диаграммы плохо эволюционируют, они хороши для случая «один раз красиво нарисовал, потом показал начальству, потому что это красиво», а вот редактировать их замучаетесь, их долго править. Вы уже знаете, что для альф придётся добавлять подальфы, для альф и подальф задать ожидаемые состояния, для них сформулировать контрольные вопросы и превратить всё это в кейс в управлении работами но вместо того, чтобы делать это в табличках какого-нибудь универсального low code моделера, делаете очень долго в графическом виде. А поскольку изменения вносить в диаграмму трудно, то не вносите изменения, и диаграмма теряет актуальность и потом не превращается в исполняемую модель управления кейсами. Поэтому не увлекайтесь рисованием, вовремя переходите к табличному моделированию.
Обращается внимание не на понятие, а на термин, «совпадение слов», а не совпадение значений это грубая ошибка. Так, на первом уровне создания «организация», «организация проекта», «предприятие», «инженерная команда», «поток студентов на курсе» это всё про одно и то же: организованную группу людей.
Теперь надо показать, как оргпроект (создание организации какого-то звена в цепочке создания, плавно переходящее в бесконечное развитие этой организации мы будем называть это «проектом оргразвития», с акцентом не столько на момент создания, сколько на момент continuous delivery новых оргвозможностей/capabilities и фич в этих оргвозможностях) раскладывается на вышеописанные роли из «Системной инженерии». Различаем при этом время развития организации/«организационных изменений»/«change management» (не путаем «organizational change management»/«управление организационными изменениями»/организовывание с «configuration and change management» из инженерии целевой системы) и время работы/функционирования/operations организации/оргзвена/предприятия/проекта (тут мы показываем эти термины как синонимы: организации/оргзвена/предприятия/проекта, но в реальности за ними могут скрываться разные сущности, будьте внимательны).
Итак, менеджмент как инженерия предприятия включает в себя следующие практики и роли:
Организатор (аналог developer в системной инженерии) выполняет организовывание. Он предлагает концепцию использования организации (зачем её делать, каких изменений в мире ожидать, какие оргизменения нужно сделать, какие практики нужно освоить организации как development и затем превратить их в оргвозможности/capability как delivery, чему научиться новому). Предлагает, ибо это «гипотеза», организационная гипотеза/guess. Он затем разрабатывает концепцию организации (как и из чего сделать организацию с ограничениями от архитектора), затем проектирует (моделеры! Корпоративный софт!) с точностью, достаточной для «изготовления» (конечно, это не заводское изготовление! Потребуются закупки оборудования, найм сотрудников, лидерство и т.д.), будет работать администрация (аналог DevOps/internal development platform engineering), затем введение в эксплуатацию и всё это непрерывно, цикл непрерывного оргразвития.
Практику прибыльности осуществляет бизнесмен, ответственный за отношения с инвесторами (IR, investor relations) и надзор за прибыльностью. Так же как визионер/стратег (например, как одна из ролей должности product manager) отслеживает, что клиентура «покупает» целевую систему дороже, чем затрачивается на её изготовление, бизнесмен отслеживает, что инвестура (все владельцы, их часто называют одним словом «инвесторы») «покупает» организацию не дешевле, чем нужно для начала зарабатывания, выхода на break even. Если денег от инвесторов не удалось собрать, то организация никому не нужна, её не будет. При этом инвесторы сами контролируют то, что на эти деньги будет прибыль в рамках corporate governance (это как бы «потребительский надзор», «клиентский контроль за качеством целевой системы» только этой системой тут будет организация, а «клиентом» будет «инвестор»)! Бизнесмен компании отслеживает обратную ситуацию: чтобы инвестиций хватило для организации нового дела, он должен проверить идею/орггипотезу организатора, которая достаточно убедительна для инвесторов. Отдельно можно обсуждать, как все упомянутые роли разложены по должностям в некоммерческих организациях, в небольших стартапах, в крупных холдингах, государственных/правительственных организациях, и даже командах агентов внутри личности (internal team в практике ролевого мастерства личности, команды из частей личности с интеллектом меньше, чем у полной личности). При этом как визионер сам не осуществляет продвижения (маркетинг, реклама, продажа), а лишь выполняет оценку выгодности производства продукта, сервиса, фичи, так и бизнесмен не сам выполняет практику привлечения инвестиций, но он занимается стратегированием: согласует все идеи о том, как компания может зарабатывать деньги для инвесторов. И если эти идеи будут убедительными, то как «в основе хорошей рекламы лежит хороший товар», то и тут «в основе хорошего привлечения инвестиций лежит прибыльная фирма». Вот бизнесмен и озабочен этой прибыльностью.
Практика архитектуры выполняется архитектором организации (часто архитектора выделяют на уровне предприятия, самой верхушке организации, поэтому называют архитектор предприятия. Но легко вообразить роль архитектора какой-нибудь службы предприятия, а не всего предприятия): установить приоритетные архитектурные характеристики, принять решения (с учётом обратного манёвра Конвея) по способам их достижения через предписание деления организации на отдельные максимально автономные/независимые оргзвенья и указания способа взаимодействия оргзвеньев, а также отслеживания/надзора/governance, что оргизменения как результат работы разных организаторов улучшают эти характеристики организации в целом (то есть, что не накапливается «технический долг» из системной инженерии, когда система организация): «организационный долг» это работы, которые надо выполнить для предотвращения ухудшения архитектурных характеристик организации в долгосрочной перспективе.