Практики
Модульное/продуктное/конструктивное представление работ жизненного цикла «как в управлении проектами» очень нравилось менеджерам, а вот для инженеров оказывалось недостаточным, как это обычно и бывает в системном подходе: область интересов инженеров отличалась от области интересов менеджеров, занимавшихся операционным управлением. Для проектирования, «изготовления», «наладки» самой последовательности работ (то есть проектирования, изготовления, наладки создателей/оргзвеньев, выполняющих эти проектирования, изготовления, наладки работ) нужно было выходить на функциональное/ролевое представление, обсуждать виды работ с точки зрения их ролевого назначения/функций, а оргзвенья создателей рассматривать в их оргролях. Работы как поведение/«экземпляры сервисов ресурсов»/«конструктивных объектов»/оргзвеньев должны выполнять функции/практики функциональных/ролевых объектов/оргролей в создателях, удобных для обсуждения «как работают системы создания, чтобы целевая система меняла своё состояние в ходе жизненного цикла и становилась успешной». Что именно делает Вася Пупкин, не понимая его текущей роли --- всегда непонятно (он своей «работой» играет роль Отелло? Принца Гамлета? Офелии? Видно, что Вася Пупкин занят, работает. Но что и зачем он делает?!). Что делает та или иная работа для менеджера-проектировщика (который вроде как должен её запроектировать) непонятно, нужно смотреть на задаваемое прикладным инженером «содержание работы»/«способ работы»/метод/практику/«функциональную ипостась работы».
Рассмотрение поведения систем создания как функций оргролей/проектных ролей/деятельностных ролей в жизненном цикле произошло не сразу: ресурсы в системах создания ведь были конструктивными объектами, и как системы с их ведущим пониманием как именно функциональных объектов не воспринимались! Систем создания не было как систем, не было системного рассмотрения! «Оргроли» при этом это всё те же функциональные/ролевые объекты, которые играются оргзвеньями. «Орг» просто подчёркивает, что речь идёт об организации, то есть существует договорённость о том, кто может просить исполнителя роли выполнить работы этой роли. Проектная роль --- тут подчёркивается, что речь идёт о проекте. Деятельностная роль --- что речь идёт о множестве проектов и множестве организаций. Но в принципе это всё про одно и то же: это функциональные/ролевые объекты, которые выполняют содержательные действия в организационной системе как системе создания целевой системы (включая все цепочки создания, если это оказывается нужным). Об этой же оргсистеме говорилось и как о «системе ведения жизненного цикла целевой системы», а сейчас говорят как о «системе создания и развития целевой системы», то есть системе-создателе или даже просто создателе. Оргроли, проектные роли, деятельностные роли --- это всё роли в создателе.
Переход к диаграммам типа принципиальных/функциональных схем для систем создания произошёл постепенно (и помним, что во всех этих диаграммах было отражено не создание и последующее развитие/эволюция системы, а однократное прохождение «не жизненного не цикла» --- это «отрезки», а не «кольца/циклы»). После классических «колбасок» для стадий жизненного цикла поначалу появилось множество гибридных диаграмм, пытавшихся отразить сразу и конструктивную/логистическую и функциональную/назначения ипостаси жизненного цикла как поведения систем создания. И это не случайно: ключевые/концептуальные решения по устройству жизненного цикла --- это решения о том, какие оргроли будут выполняться какими оргзвеньями, а в другой формулировке ---какими работами будут выполнены те или иные практики/виды работы/деятельности. Это принятие решений по концепции жизненного цикла (по аналогии с концепцией системы) и организация выполнения этих решений стали называться управлением жизненным циклом (life cycle management, ср. work management/управление работами. В управлении работами нет концептуальных решений по жизненному циклу: не идёт речь о содержании и технологии работ, то есть о практиках, но только о длительности работ и потребных ресурсах безотносительно к «способу выполнения работ»/«way of working»/методу).
Одной из самых известных гибридных для управления жизненным циклом и управления работами диаграмм жизненного цикла является горбатая диаграмма (hump diagram) из методологии rational unified process (RUP)[1]:
В этой диаграмме 1996 года уже видно, что кроме безымянных «итераций» как групп работ, по-старинке разбитых на «стадии» во времени, появился новый тип объекта, практика (practice, деятельность, род/вид работы, труд, инженерия как изменение чего-то в мире каким-то явным способом), именованная по её теоретической инженерной или менеджерской дисциплине (discipline, теория).
«Практика» и есть культурно-обусловленное функциональное/ролевое поведение создателей. Работы оргзвеньев выполняют роль тех или иных практик культурно-обусловленных оргролей, а жизненный цикл состоит как раз из работ по этим методам/практикам, называемых по их дисциплинам (а иногда слово «дисциплина» включает и собственно «теорию», и использование материалов и инструментов --- то есть отсылает к самому методу/деятельности/инженерии, а не только к теоретической их части).
Роли и практики, объекты и их поведение неразлучны, всегда вместе. Системный архитектор (роль) выполняет практику системной архитектуры (поведение роли). Авиапредприятие (роль) выполняет практику строительства самолётов (поведение роли). И не надо сочинять каждый раз роли и практики «с нуля», надо брать их из культуры, они культурно-обусловлены, они определяются успешно реплицирующимися (и при этом эволюционирующими) мемомами этих практик. Если раньше практика свидания включала шаблон «под часами» (хороший ориентир плюс возможность сверить время), то сейчас мобильная связь привела к тому, что шаблон не выжил --- свидание назначается в приблизительно условленном месте в более-менее приблизительное время, а «точная встреча» уже корректируется с учётом доступной технологии, практика свидания изменилась, эволюционировала. Поэтому культурная обусловленность:
- Включает общеизвестность мемома практики: если кто-то что-то как-то делает, то он вряд ли придумал свой метод сам. «Взял из воздуха» --- это задействовал те мемы, которые у него уже были. Может быть, где-то уже есть мемы и получше, более современные. Но «изобрёл практику» --- это крайне редкая ситуация.
- Привязана ко времени. Так, дисциплина Requirements в диаграмме 1996 года была очень и очень современной, культурно-обусловленной. А сейчас это воспринимается как анахронизм, привет из прошлого.
Как проверить культурную обусловленность? Обычно по культурно-обусловленным практикам есть учебники. А если это кулибинство/«я сам придумал!»[2], то учебника обычно нет --- и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как выполнять практику мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем). Методология не учит, что делать в этом случае, но заставляет удерживать во внимании практики работы и интересоваться их культурной обусловленностью.
Работы разных практик как-то распределены по времени жизненного цикла в его начальном (1.0) представлении как «последовательности работ». В RUP это работы по практикам организационного моделирования/business modeling (помним про перевод business как «организационный»), инженерии требований (уже устарела со времён популярности RUP), анализа и проектирования (анализ как отдельная подпрактика не рассматривается, он включается в проектирование), разработки (границы этой практики определяются сейчас по-другому), испытаний (сегодня это «инженерные обоснования»/quality assurance), разворачивания (но вот delivering нет как «введение в эксплуатацию»), управления конфигурацией и изменениями, управления проектом, работы с окружением. И это никак не закольцовано, хотя и выделены «порции работ по всем практикам вместе» как «итерации» --- но это просто «постепенное достижение конечного результата», а не создание и потом развитие, развитие, развитие, то есть не длительная эволюция без явного достижения заранее определённой цели. Нет, подразумевается, что «определили требования, повозились, удовлетворили требования --- всё, проекты жизненного цикла закончены, даже если этих проектов было несколько, всё развитие как продолжение работы над системами подобного класса --- за рамками жизненного цикла».
Эти работы делятся на стадии, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) из проектного управления, в то же время практики (названные на «горбатой диаграмме» по их дисциплинам) отражают разделение труда (division of labor).
Разделение труда (практик, деятельности, инженерии) на качественно различные виды не нужно путать с разделением работ, которое количественно. Разделение работ обсуждает, как много работы разбить по ресурсам (например, если нужно выполнить однородную работу вдвое быстрее, то нужно поставить вдвое больше людей, или использовать станок с большей производительностью), а вот разделение труда обсуждает, как практику для одного исполнителя с одной ролью разбить на подпрактики, у которых в качестве их исполнителей возможны разные агенты, которые будут играть по этим подпрактикам разные роли как подроли общей роли для начальной общей практики. Дальше исполнитель подпрактики может углубить своё мастерство, ибо он не должен тратить время на выполнение всей общей практики и может достичь уровней мастерства выше, чем по начальной практике без разделения труда.
Врач раньше занимался всеми дисциплинами, а потом прошло глубокое разделение врачебного труда, и врач-гинеколог начинает существенно отличаться по своей квалификации от врача-дантиста. Веб-мастер занимался всеми работами по небольшому вебсайту, а потом прошло глубокое разделение труда, и этими же работами занимаются программист бэк-энда, программист фронт-энда, дизайнер, контент-менеджер, редактор и ещё много других деятельностных ролей. Инженер раньше был «просто инженер», а сегодня без уточнения того, какой именно это инженер, сказать ничего нельзя. И так со всеми практиками. Там, где был один учебник одной дисциплины, появляется десять учебников по десяти дисциплинам.
Работы --- это про количество работы и её скорость, а труд/деятельность/практика --- это про назначение иразнообразие видов/родов/сортов/способов работы и их уместность/полезность/назначение/роль в проекте.
На горбатой диаграмме в строчке каждой практики показано, что интенсивность этих работ разная в разные моменты жизненного цикла (и это будет отражаться также и в ходе закольцовывания такой диаграммы или разбития её на поддиаграммы для множества команд, занимающихся развитием тех или иных фич системы в ходе её развития/эволюции, а не только однократного проектирования-изготовления-использования, как это подразумевается оригинальной линейной диаграммой): специализирующиеся на разных практиках роли то больше, то меньше задействованы для выполнения работ жизненного цикла в разные его моменты. Тем самым на графике зависимости интенсивности работ от времени появляются «горбы», отсюда и название «горбатая диаграмма». Напомним, что работы --- это взаимодействующие продукты/люди/оборудование/ресурсы, участвующие в выполнении сервиса/поведения оргзвена из жизненного цикла. Но работы выполняют какие-то практики (поведение взаимодействующих функциональных/ролевых единиц), они определяются этими практиками.
В 21 веке описания жизненного цикла перестали обсуждаться как описания только поделенных на стадии работ. Эти описания включили в себя и практики: основные (не все! Описания жизненного цикла обычно делаются на уровне концепции, а не детального проектирования) практики оргролей, которые выполняются как производимые оргзвеньями работы. Концепция создателя как концепция системы --- это не только функциональная/деятельностная/ролевая декомпозиция ролей как подсистем создателя, но и декомпозиция их поведений, то есть практик, а также не только конструктивный/продуктный/модульный синтез организации/оргзвеньев, но и синтез работ. Для полноценного системного рассмотрения создателей нужны и оргроли, и оргзвенья, и их поведения (практики/функции и работы/сервисы) и дальше размещения и стоимость. Упоминание жизненного цикла (линейного однократного «не цикла», или включающего развитие, «цикла, хотя и без размножения») --- это указание не столько на целевую систему, сколько на поведение систем создания, рассматриваемых и как организационные роли и практики этих ролей, и какназначенные на оргроли оргзвенья и выполняемые имиработы, реализующие практики этих ролей.
Жизненный цикл скворечника на вчера рассматривался как главным образом плотницкая практика, реализованная плотницкими работами, выполняемыми Фадеем (оргзвено) в оргроли плотника, а всего несколько лет назад он бы рассматривался как работы Фадея, и неважно по какой практике (плотницкая практика подразумевалась, но явно не обсуждалась). Сегодня понятие «жизненного цикла скворечника» было бы размыто, и больше бы говорили про программу создания и развития скворечника --- ибо ожидались бы какие-то непрерывные улучшения в конструкции и материалах скворечника, способах его изготовления, и ещё бы неявно в рассмотрение попал Фадей и его мастерство плотника.
Жизненный цикл атомной станции на сегодня рассматривается как набор практик замысливания, проектирования, сооружения, эксплуатации, модернизации (увы, мы тут не можем говорить о развитии --- отрасль серьёзно зарегулирована), ликвидации, реализуемый работами, выполняемыми проектными, строительными, монтажными, эксплуатирующими организациями в самых разных организационных ролях: основателя компании, линейного/операционного менеджера, инженера в целевой предметной области. А всего несколько лет назад обсуждались бы прежде всего работы как «стадии», а не практики этих работ.
Жёсткие условия госрегулирования делают очень трудным разговор о развитии/эволюции атомной станции, поэтому вопрос развития даже не ставится: «модернизация» по факту идёт только как «продление срока службы энергоблоков» (по факту это ремонт, а не улучшение со smart mutations в проекте/design атомной станции) --- именно так понимается «управление жизненным циклом» на объектах атомной энергетики. В любом случае, обсуждаются (инженерами АЭС) по линии управления жизненным циклом прежде всего наборы практик, а не наборы работ --- работы обсуждаются по линии операционного менеджмента, управления работами.
Обсуждение практик при этом первично: если не знаешь, как ты будешь работать, то ничего про саму работу сказать нельзя. Скрепить две детали --- какая практика? Если не знаешь, сварка это, проклейка, болтовое соединение --- ничего сказать про работу нельзя. Поэтому практика (функциональное рассмотрение поведения) обсуждается всегда логически сначала, работа (конструктивное рассмотрение) --- всегда логически потом, и они итеративно утрясаются так, чтобы удовлетворять условиям доступности в проекте, экономической эффективности и прочим архитектурным характеристикам, которые должны быть удовлетворены системой создания. Ибо жизненный цикл даже энергоблока АЭС --- это разговор не столько про саму АЭС и её архитектуру, сколько про создателя АЭС (проектные и строительные организации, поставщики оборудования) и его орг-архитектуру (создатель АЭС --- это организация, поэтому говорим не просто про архитектуру, а организационную архитектуру).
Системы создания имеют первичные названия по основной функции/практике, по их организационной роли. Эти названия строятся как и названия любых других систем, вопрос подробно разбирался в курсе системного мышления. Парикмахерская выполняет работы своего сервиса как оргзвено (например, как частный парикмахер Ольга, как предприятие ООО «Причешем», или подразделение холдинга Всёрежьчешиукладка), а практику выполнения причёсок выполняет как ...парикмахерская! Оргроль парикмахерской --- «парикмахерская», «делатель причёсок»! Увы, оргроли в бытовом языке не имеют своих специальных слов для названия. А проектные роли? Это они и есть.
В проектной роли может быть не только человек (на сегодня это самое маленькое оргзвено, агенты сегодня главным образом люди), но и любое другое оргзвено из группы людей и их оборудования. Главное тут не впадать в сверхобобщение, оргроль «клиника» или ещё более обобщённое «лечебное заведение» обычно не даёт возможности что-то содержательно обсуждать: лечебное заведение выполняет слишком много практик/деятельностей для целевых систем с самых разных системных уровней, и лучше бы такие «сверхроли» сразу дробить до ролей с более-менее понятными компетенциями, которые мог бы выполнять отдельный человек как оргзвено. Проектные роли не «клиника», а «врач» и «техник медицинской аппаратуры», а ещё лучше не «врач», а «гинеколог» и «дантист». Принцип почтальона хорошо бы соблюдать и с оргролями (они тоже функциональные части, только систем создания!), а не только с функциональными частями целевых систем: адрес предмета обсуждения лучше бы давать точно, без «на деревню дедушке Константину Макарычу».
А оргзвено? Для каждой более мелкой роли будет более мелкое оргзвено. Для клиники --- предприятие; для врача --- не слишком понятно, что (и это должно напрягать: модульный синтез будет трудным); для гинеколога --- человек, обладающий мастерством в/знающий дисциплину и владеющий инструментами/практикующий гинекологию и занимающий позицию в штатном расписании и распоряжающийся в силу этого необходимыми для его работы инструментами/оборудованием: оргзвено размером с одного человека. Является ли сообщество, или общество, или даже человечество оргзвеном? Вряд ли: «орг» тут означает организованность, то есть известность всем тех агентов, которые распоряжаются ресурсами оргзвена. С натяжкой можно говорить, что в социалистических диктатурах всеми ресурсами понятно кто распоряжается (диктатор, и дальше идёт какое-то делегирование полномочий диктатора «на места»), но это на больших масштабах оказывается крайне неэффективным в части распределения труда: потребности людей в масштабах общества учесть невозможно, организовать (наладить систему поручений что-то делать) труд так, чтобы число производимых шнурков как-то билось с числом производимых ботинок оказывается в масштабах общества нерешаемой задачей (до сих пор калькуляционный аргумент Мизеса, который это формулирует, не опровергнут[3]). Так что в нашем курсе мы ограничиваемся оргзвеньями минимально как отдельными личностями (существа как оргзвенья не подойдут, кошечек и слонов не организуешь, у компьютеров достаточного уровня интеллекта ждём), а максимально как компаниями/организациями со всеми их компьютерами, куда включены на нижних уровнях конструкции и компьютеры, и люди, и другое оборудование.
В системном менеджменте не ограничиваются обсуждением практик и работ. Сегодня там большое внимание уделяют понятию оргвозможности/capability для указания ресурсной доступности какой-то практики (то, что на выполнение практики-поведения назначено какое-то компетентное оргзвено, и ему выданы все полномочия по распоряжению ресурсами, нужными для выполнения этой практики. Компетентное --- это которое знает, как выполнять практику, включая компетенции отдельных людей и компетенции по объединению труда/деятельности этих людей, а ресурсы включают необходимое оборудование и материалы). По большому счёту, вас интересует не «теоретическая возможность выполнения работы» (все люди обучены, оборудование и материалы есть --- практика поставлена), а реальная организационная возможность (практика поставлена, ресурсы есть, плюс выдано полномочие работать по этой практике, тратить на это ресурсы). Переход от состояния организации «практика поставлена, по идее можно работать» до «а вот теперь и правда можно работать» может занимать много лет. Вы можете уметь пользоваться новейшим гвоздезабивальным автоматом, и этот автомат может быть уже закуплен и развёрнут, и закуплен запас специальных гвоздей для этого автомата, но команды им пользоваться не будет, не будет проявлена уже поминавшаяся в нашем курсе «политическая воля» --- и вы будете забивать обычные гвозди камнем или микроскопом. Молотка у вас тоже не будет, ибо «мы же только что купили гвоздезабивальный автомат! Он полностью заменяет молоток, и даже лучше!». Вот это типичная для организационного менеджмента ситуация, в которой мы должны отличать практику («как это обычно делается», описана в учебнике) от оргвозможности (как мы это будем делать у нас в проекте). Но повторим: когда мы говорим об оргзвене, чаще всего мы говорим об оргвозможности --- то есть это не «оргзвено, которое просто есть», а «оргзвено, которое вполне способно выполнять работы/сервис по известной ему практике, и имеет для этого все полномочия и ресурсы». Как сделать так, чтобы появилась оргвозможность --- это рассказывается в курсе «Системный менеджмент».