Анатолий Левенчук – Системный менеджмент – 2023 (страница 11)

• Администрирование (аналог DevOps/internal development platform engineering) как практика, выстраивающая и эксплуатирующая «организационный конвейер», позволяющий организаторам проводить изменения. Администраторы довольно разнообразны, ибо тут идёт довольно дробное разделение на подроли: финансисты, снабженцы (административно-хозяйственная часть, закупки), HR, офис-менеджеры, хелп-деск и ресешпн, и т. д. Администратор (который как врач, давно специализирован в своих подролях, и эти подроли выполняются разными даже не людьми, а часто целыми службами) предоставляет разработчикам «конвейер», по которому организаторы проводят изготовление оргвозможностей: получают необходимые «сырые ресурсы» и проводят их превращение в оргвозможности согласно разработанным ими оргпроектам/orgdesign при надзоре со стороны архитектора, следящего за общими архитектурными характеристиками организации. Тут та же сложность, что в определении «производственного конвейера» в более общем случае системной инженерии – этот конвейер сначала надо построить, а затем только эксплуатировать. То есть обсуждаем и время создания целевой организации, и работающий в это время «конвейер» администратора создателя организации, но перед временем создания организации нужно предусмотреть ещё время создания этого «конвейера» его разработчиком/«создателем создателя организации»/«создателем администрации». Сложность в том, что в жизни всё это происходит одновременно в физическом времени, а «логические» времена создания выделяются исключительно вниманием: и производится целевая система, и производятся организационные изменения в организации-создателе, и производятся организационные изменения в администрировании. Эта цепочка создания каждый раз продумывается – и таки дотягивается до целевой системы в конечном итоге, или до клиентуры, или до инвестуры (фирма создаёт минимально три системы). Пока мы будем называть администраторами и создателей (включая разработчиков/организаторов) конвейера (platform engineers) и его работников (не всё там удаётся автоматизировать, хотя даже HR практики сегодня пытаются автоматизировать), но если в вашем внимании создание самого этого конвейера, вам придётся их различить. К цепочкам создания надо быть внимательным, они в жизни не такие простые, как на примерах диаграмм из нашего учебника! Сам термин взят из критики Henry Mintzber программ MBA (master of business administration): они вроде нацелены на подготовку организаторов и стратегов в целом, но по факту готовят глав финансовых служб, глав служб HR и прочих администраторов, которые явно не справляются с должностями, требующими компетенций в других ролях. Они «работники производственного конвейера для поддержки жизни организации, поддержки развития», а после приобретения какого-то опыта могут пытаться ещё и строить такой конвейер. Но вот использование этого конвейера для развития организации в целом требует других специализаций: организатора, бизнесмена, архитектора организации. И мы понимаем, что слово «администратор» очень широкое, но всё-таки означает чаще «исполнительные» роли поддержки какого-то конвейера, а не роли, занятые использованием этого конвейера для какого-то дела (при всём понимании, что «всё со всем связано, конвейер должен быть согласован с типом тех систем, которые по нему проходят»).

Примеры соответствия системноинженерных и прикладных ролей

Давайте попробуем изложить всё то же самое в виде таблички, в которой пропишем роли (но за каждой ролью обязательно скрывается практика этой роли, её просто не будем писать для экономии места):

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

Это редко называют «организация менеджеров», но вот «менеджерская команда» вполне можно услышать, равно как и просто множественное число «менеджеры», равно как и «служба развития», хотя бы часть этой команды, например, люди в подролях оргроли менеджера развития. У оргроли «менеджер» (помним, что в жизни эта роль обычно исполняется целой организацией, а не одним человеком) множество подролей, это будут подальфы – бизнесмен, орг-архитектор, организатор (с его подролями, которые в проекте могут быть отслеживаемы как подальфы, проходящие каждая свои состояния), администратор.

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

И мы действительно видим в проекте создания курса места для этих ролей, но эти роли задействованы в разных командами, находящимися в разных местах цепочки создания, в разных областях интересов. Главное, чтобы мы не пропустили за многочисленными командами наличие этих ролей. Например, «курс системной инженерии» легко представляется, как нечто, соответствующее его описанию, «проекту курса», который создали авторы курса. Но реальным объектом «курса» будет его прохождение, а оно организовано в форме занятий студенческой группы с преподавателями – потока. То есть команды создания курсов в рамках какой-то учебной программы (над которой работает архитектор как автор куррикулума, он отслеживает относительную автономность потоков и команд создания курсов) по сути дела создают проект курса (то есть в этих командах предусмотрены роли культуртрегера, автора курса), а затем преподаватели как части этих команд (они «инженеры-технологи», работают во время изготовления мастерства) создают мастерство в рамках работы команд потоков, тьюторы отслеживают при этом общее прохождение работ по изготовлению мастерства разными командами, пытаясь ускорить прохождение обучения студентами (например, давая указания, какая стадия обучения должна быть оптимизирована методистами, ибо студенты застревают именно на ней).

Можно, конечно, обсуждать – в каких именно командах и как должны работать все указанные роли, но уже понятно, что такие быстрые прикидки («кто такой преподаватель? Он инженер-технолог, стадия изготовления. Это не автор курса? Сколько нам надо иметь преподавателей? Сколько авторов курса? Понимаем ли мы, что преподаватели по конкретному предмету/курсу – по роли это не столько члены «потоков», сколько члены команды создания курсов, подроль «разработчика»? Получается, что команда потока состоит из людей, которые частично пришли в неё из другой команды!

То есть «поток» представляет собой не столько «команду разработки мастерства», сколько банальный станок изготовления мастерства (предоставляется деканом как «инженером платформы», ответственным за «станочный парк»), а инженер-технолог/преподаватель просто использует студенческую группу как конвейер со станками, изготавливающий мастерство в мозгах студентов в ходе занятий. Но точно так же можно использовать и компьютерную систему, и даже вообще обойтись без преподавателя, если у нас «завод-автомат» (скажем, так устроены онлайн-курсы).

То, что вы должны делать, когда адаптируете системную схему проекта – это проводить вот такие рассуждения. И, конечно, поскольку каждый раз речь идёт о каких-то командах и налаживании их работы, нужно задавать вопрос – а кто и как эти команды организует? Это уже будет обсуждением менеджерских ролей. Команду создания курса надо организовать, команду потока надо организовать – первую как команду разработчиков/авторов курса и преподавателей этого курса, вторую как учебную группу (куда будут входить в том числе и люди первой команды – преподаватели). Число рассматриваемых ролей быстро начинает расти, и даже для небольшого проекта вы будете находить не только от 15 внешних ролей проекта, но и чуть ли ни несколько десятков внутренних ролей, нужных для создания самых разных встречающихся в проекте систем, и эти роли будут раскиданы по самым разным командам (да ещё и люди в этих командах будут пересекаться, но орг-архитекторы будут приглядывать, чтобы команды всё-таки были по возможности автономны).