Методология 2023 Левенчук Анатолий
• Привязана ко времени. Так, дисциплина Requirements в диаграмме 1996 года была очень и очень современной, культурно-обусловленной. А сейчас это воспринимается как анахронизм, привет из прошлого.
Как проверить культурную обусловленность? Обычно по культурно-обусловленным практикам есть учебники. А если это кулибинство/«я сам придумал!»33, то учебника обычно нет – и дальше вам принимать решение: учебника нет, потому как речь идёт о фронтире, и учебник не успели написать, или учебника нет, потому как этот кривой свежесочинённый метод работы отражать в учебнике ни в коем случае нельзя, или просто не знаем об учебнике (но он в реальности был, а как выполнять практику мы подглядели у человека, который по этому учебнику учился. Но о том, что он учился по учебнику, мы даже не знаем). Методология не учит, что делать в этом случае, но заставляет удерживать во внимании практики работы и интересоваться их культурной обусловленностью.
Работы разных практик как-то распределены по времени жизненного цикла в его начальном (1.0) представлении как «последовательности работ». В RUP это работы по практикам организационного моделирования/business modeling (помним про перевод business как «организационный»), инженерии требований (уже устарела со времён популярности RUP), анализа и проектирования (анализ как отдельная подпрактика не рассматривается, он включается в проектирование), разработки (границы этой практики определяются сейчас по-другому), испытаний (сегодня это «инженерные обоснования»/quality assurance), разворачивания (но вот delivering нет как «введение в эксплуатацию»), управления конфигурацией и изменениями, управления проектом, работы с окружением. И это никак не закольцовано, хотя и выделены «порции работ по всем практикам вместе» как «итерации» – но это просто «постепенное достижение конечного результата», а не создание и потом развитие, развитие, развитие, то есть не длительная эволюция без явного достижения заранее определённой цели. Нет, подразумевается, что «определили требования, повозились, удовлетворили требования – всё, проекты жизненного цикла закончены, даже если этих проектов было несколько, всё развитие как продолжение работы над системами подобного класса – за рамками жизненного цикла».
Эти работы делятся на стадии, а потом на более и более мелкие работы в классическом разбиении работ (work breakdown structure, WBS) из проектного управления, в то же время практики (названные на «горбатой диаграмме» по их дисциплинам) отражают разделение труда (division of labor).
Разделение труда (практик, деятельности, инженерии) на качественно различные виды не нужно путать с разделением работ, которое количественно. Разделение работ обсуждает, как много работы разбить по ресурсам (например, если нужно выполнить однородную работу вдвое быстрее, то нужно поставить вдвое больше людей, или использовать станок с большей производительностью), а вот разделение труда обсуждает, как практику для одного исполнителя с одной ролью разбить на подпрактики, у которых в качестве их исполнителей возможны разные агенты, которые будут играть по этим подпрактикам разные роли как подроли общей роли для начальной общей практики. Дальше исполнитель подпрактики может углубить своё мастерство, ибо он не должен тратить время на выполнение всей общей практики и может достичь уровней мастерства выше, чем по начальной практике без разделения труда.
Врач раньше занимался всеми дисциплинами, а потом прошло глубокое разделение врачебного труда, и врач-гинеколог начинает существенно отличаться по своей квалификации от врача-дантиста. Веб-мастер занимался всеми работами по небольшому вебсайту, а потом прошло глубокое разделение труда, и этими же работами занимаются программист бэк-энда, программист фронт-энда, дизайнер, контент-менеджер, редактор и ещё много других деятельностных ролей. Инженер раньше был «просто инженер», а сегодня без уточнения того, какой именно это инженер, сказать ничего нельзя. И так практически со всеми практиками. Там, где был один учебник одной дисциплины, появляется десять учебников по десяти дисциплинам.
Работы – это про количество работы и её скорость, а труд/деятельность/практика – это про назначение и разнообразие видов/родов/сортов/способов работы и их уместность/полезность/назначение/роль в проекте.
На горбатой диаграмме в строчке каждой практики показано, что интенсивность этих работ разная в разные моменты жизненного цикла (и это будет отражаться также и в ходе закольцовывания такой диаграммы или разбития её на поддиаграммы для множества команд, занимающихся развитием тех или иных фич системы в ходе её развития/эволюции, а не только однократного проектирования-изготовления-использования, как это подразумевается оригинальной линейной диаграммой): специализирующиеся на разных практиках роли то больше, то меньше задействованы для выполнения работ жизненного цикла в разные его моменты. Тем самым на графике зависимости интенсивности работ от времени появляются «горбы», отсюда и название «горбатая диаграмма». Напомним, что работы – это взаимодействующие продукты/люди/оборудование/ресурсы, участвующие в выполнении сервиса/поведения оргзвена из жизненного цикла. Но работы выполняют какие-то практики (поведение взаимодействующих функциональных/ролевых единиц), они определяются этими практиками.
В 21 веке описания жизненного цикла перестали обсуждаться как описания только поделенных на стадии работ. Эти описания включили в себя и практики: основные (не все! Описания жизненного цикла обычно делаются на уровне концепции, а не детального проектирования) практики оргролей, которые выполняются как производимые оргзвеньями работы. Концепция создателя как концепция системы – это не только функциональная/деятельностная/ролевая декомпозиция ролей как подсистем создателя, но и декомпозиция их поведений, то есть практик, а также не только конструктивный/продуктный/модульный синтез организации/оргзвеньев, но и синтез работ. Для полноценного системного рассмотрения создателей нужны и оргроли, и оргзвенья, и их поведения (практики/функции и работы/сервисы) и дальше размещения и стоимость. Упоминание жизненного цикла (линейного однократного «не цикла», или включающего развитие, «цикла, хотя и без размножения») – это указание не столько на целевую систему, сколько на поведение систем создания, рассматриваемых и как организационные роли и практики этих ролей, и как назначенные на оргроли оргзвенья и выполняемые ими работы, реализующие практики этих ролей.
Жизненный цикл скворечника на вчера рассматривался как главным образом плотницкая практика, реализованная плотницкими работами, выполняемыми Фадеем (оргзвено) в оргроли плотника, а всего несколько лет назад он бы рассматривался как работы Фадея, и неважно по какой практике (плтницкая практика подразумевалась, но явно не обсуждалась). Сегодня понятие «жизненного цикла скворечника» было бы размыто, и больше бы говорили про программу создания и развития скворечника – ибо ожидались бы какие-то непрерывные улучшения в конструкции и материалах скворечника, способах его изготовления, и ещё бы неявно в рассмотрение попал Фадей и его мастерство плотника.
Жизненный цикл атомной станции на сегодня рассматривается как набор практик замысливания, проектирования, сооружения, эксплуатации, модернизации (увы, мы тут не можем говорить о развитии – отрасль серьёзно зарегулирована), ликвидации, реализуемый работами, выполняемыми проектными, строительными, монтажными, эксплуатирующими организациями в самых разных организационных ролях: основателя компании, линейного/операционного менеджера, инженера в целевой предметной области. А всего несколько лет назад обсуждались бы прежде всего работы как «стадии», а не практики этих работ.
Жёсткие условия госрегулирования делают очень трудным разговор о развитии/эволюции атомной станции, поэтому вопрос развития даже не ставится: «модернизация» по факту идёт только как «продление срока службы энергоблоков» (по факту это ремонт, а не улучшение со smart mutations в проекте/design атомной станции) – именно так понимается «управление жизненным циклом» на объектах атомной энергетики. В любом случае, обсуждаются (инженерами АЭС) по линии управления жизненным циклом прежде всего наборы практик, а не наборы работ – работы обсуждаются по линии операционного менеджмента, управления работами.
Обсуждение практик при этом первично: если не знаешь, как ты будешь работать, то ничего про саму работу сказать нельзя. Скрепить две детали – какая практика? Если не знаешь, сварка это, проклейка, болтовое соединение – ничего сказать про работу нельзя. Поэтому практика (функциональное рассмотрение поведения) обсуждается всегда логически сначала, работа (конструктивное рассмотрение) – всегда логически потом, и они итеративно утрясаются так, чтобы удовлетворять условиям доступности в проекте, экономической эффективности и прочим архитектурным характеристикам, которые должны быть удовлетворены системой создания. Ибо жизненный цикл даже энергоблока АЭС – это разговор не столько про саму АЭС и её архитектуру, сколько про создателя АЭС (проектные и строительные организации, поставщики оборудования) и его орг-архитектуру (создатель АЭС – это организация, поэтому говорим не просто про архитектуру, а организационную архитектуру).
Системы создания имеют первичные названия по основной функции/практике, по их организационной роли. Эти названия строятся как и названия любых других систем, вопрос подробно разбирался в курсе «Практическое системное мышление». Парикмахерская выполняет работы своего сервиса как оргзвено (например, как частный парикмахер Ольга, как предприятие ООО «Причешем», или подразделение холдинга Всёрежьчешиукладка), а практику выполнения причёсок выполняет как …парикмахерская! Оргроль парикмахерской – «парикмахерская», «делатель причёсок»! Увы, оргроли в бытовом языке не имеют своих специальных слов для названия. А проектные роли? Это они и есть.
В проектной роли может быть не только человек (на сегодня это самое маленькое оргзвено, агенты сегодня главным образом люди), но и любое другое оргзвено из группы людей и их оборудования. Главное тут не впадать в сверхобобщение, оргроль «клиника» или ещё более обобщённое «лечебное заведение» обычно не даёт возможности что-то содержательно обсуждать: лечебное заведение выполняет слишком много практик/деятельностей для целевых систем с самых разных системных уровней, и лучше бы такие «сверхроли» сразу дробить до ролей с более-менее понятными компетенциями, которые мог бы выполнять отдельный человек как оргзвено. Проектные роли не «клиника», а «врач» и «техник медицинской аппаратуры», а ещё лучше не «врач», а «гинеколог» и «дантист». Принцип почтальона хорошо бы соблюдать и с оргролями (они тоже функциональные части, только систем создания!), а не только с функциональными частями целевых систем: адрес предмета обсуждения лучше бы давать точно, без «на деревню дедушке Константину Макарычу».
А оргзвено? Для каждой более мелкой роли будет более мелкое оргзвено. Для клиники – предприятие; для врача – не слишком понятно, что (и это должно напрягать: модульный синтез будет трудным); для гинеколога – человек, обладающий мастерством в/знающий дисциплину и владеющий инструментами/практикующий гинекологию и занимающий позицию в штатном расписании и распоряжающийся в силу этого необходимыми для его работы инструментами/оборудованием: оргзвено размером с одного человека. Является ли сообщество, или общество, или даже человечество оргзвеном? Вряд ли: «орг» тут означает организованность, то есть известность всем тех агентов, которые распоряжаются ресурсами оргзвена. С натяжкой можно говорить, что в социалистических диктатурах всеми ресурсами понятно кто распоряжается (диктатор, и дальше идёт какое-то делегирование полномочий диктатора «на места»), но это на больших масштабах оказывается крайне неэффективным в части распределения труда: потребности людей в масштабах общества учесть невозможно, организовать (наладить систему поручений что-то делать) труд так, чтобы число производимых шнурков как-то билось с числом производимых ботинок оказывается в масштабах общества нерешаемой задачей (до сих пор калькуляционный аргумент Мизеса, который это формулирует, не опровергнут34). Так что в нашем курсе мы ограничиваемся оргзвеньями минимально как отдельными личностями (существа как оргзвенья не подойдут, кошечек и слонов не организуешь, у компьютеров достаточного уровня интеллекта ждём), а максимально как компаниями/организациями со всеми их компьютерами, куда включены на нижних уровнях конструкции и компьютеры, и люди, и другое оборудование.
В системном менеджменте не ограничиваются обсуждением практик и работ. Сегодня там большое внимание уделяют понятию оргвозможности/capability для указания ресурсной доступности какой-то практики (то, что на выполнение практики-поведения назначено какое-то компетентное оргзвено, и ему выданы все полномочия по распоряжению ресурсами, нужными для выполнения этой практики. Компетентное – это которое знает, как выполнять практику, включая компетенции отдельных людей и компетенции по объединению труда/деятельности этих людей, а ресурсы включают необходимое оборудование и материалы). По большому счёту, вас интересует не «теоретическая возможность выполнения работы» (все люди обучены, оборудование и материалы есть – практика поставлена), а реальная организационная возможность (практика поставлена, ресурсы есть, плюс выдано полномочие работать по этой практике, тратить на это ресурсы). Переход от состояния организации «практика поставлена, по идее можно работать» до «а вот теперь и правда можно работать» может занимать много лет. Вы можете уметь пользоваться новейшим гвоздезабивальным автоматом, и этот автомат может быть уже закуплен и развёрнут, и закуплен запас специальных гвоздей для этого автомата, но команды им пользоваться не будет, не будет проявлена уже поминавшаяся в нашем курсе «политическая воля» – и вы будете забивать обычные гвозди камнем или микроскопом. Молотка у вас тоже не будет, ибо «мы же только что купили гвоздезабивальный автомат! Он полностью заменяет молоток, и даже лучше!». Вот это типичная для организационного менеджмента ситуация, в которой мы должны отличать практику («как это обычно делается», описана в учебнике) от оргвозможности (как мы это будем делать у нас в проекте). Но повторим: когда мы говорим об оргзвене, чаще всего мы говорим об оргвозможности – то есть это не «оргзвено, которое просто есть», а «оргзвено, которое вполне способно выполнять работы/сервис по известной ему практике, и имеет для этого все полномочия и ресурсы». Как сделать так, чтобы появилась оргвозможность – это рассказывается в курсе «Системный менеджмент».
Жизненный цикл 2.0: практики, по которым выполняются работы
Недостаточность и ограниченность описания жизненного цикла как поведения создателей (view) через метод описания (viewpoint) последовательностей крупных работ как стадий жизненного цикла с каждым годом становилась очевидней. Назревала необходимость смены метода описания поведения создателей.
Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что нельзя сделать никакого предварительного планирования отдельных работ. Разработка везде велась, как судебные дела, «непрерывно открывающимися обстоятельствами», и только производство/изготовление можно хоть как-то было планировать, ибо к этому моменту уже было хотя бы известно, что производить, и какие нормы производительности хотя бы примерно существуют. А нормы мыслительной деятельности и количество порождённых и раскритикованных гипотез в ходе разработки – этого оценить нельзя. Инженеры на невозможности up-front/предварительного планирования и строго последовательного выполнения заведомо успешных мыслительных/знаниевых работ (knowledge works) настаивали, менеджерам это не нравилось, они требовали чётких планов, затем оценки инженеров по поводу планирования (гипотезы!) менеджеры объявляли обещаниями и считали их требованиями. То есть жизнь в проектах шла одним образом, но в учебниках продолжали писать, «как надо»: планировать постадийную работу!
Наборы различных концепций планирования выполнения практик в виде последовательностей работ получили название модели жизненного цикла (life cycle model35, вид/форма жизненного цикла). Концепция тут понимается примерно так же, как концепция системы: как увязаны функциональное и конструктивное понимание (а также размещение и оценки стоимости), но не частей системы, а поведения системы, причём не целевой, а системы-создателя.
Концепции/модели жизненного цикла грубо можно разместить между двух крайностей:
1. практики и работы-стадии совпадают и для их выражения хватает «колбаски» с интерфейсами между работами (обсуждается «видимость работ», как обычно в модульных диаграммах – нельзя из работ одной стадии затребовать ресурсы соседней стадии),
2. практики и работы не совпадают и для их выражения нужны какие-то сложные структуры с акцентом на связь практик, т.е. даже внешне похожие на принципиальные схемы с их «логическим, а не физическим временем» и «потоками альф, меняющими по ходу этих потоков состояния», а не модульные диаграммы с их «видимостью интерфейсов».
Первый вид жизненного цикла (квинтэссенция подхода 1.0, «проектное управление с непересекающимися стадиями») получил название «водопад» (cascade, каскад). Работы практик жизненного цикла выполняются однократно, созданные рабочие продукты/артефакты как output передаются как input-ресурсы для следующих работ, и больше к этим практикам никакого возврата нет, выполняются работы последующих практик. Водопад/каскад течёт всегда сверху вниз, назад возвратов нет! Для более убедительной иллюстрации этого «невозвратного» хода работ традиционную «колбаску» начали рисовать как ступени настоящего водопада36:
Между стадиями осуществлялись действия по инженерным обоснованиям (проверки, приёмки, испытания, экспертные оценки) результатов предыдущих стадий, при этом принималось решение о продолжении работ, возврате на доработку или прекращении работ по всей системе. Эти инженерные обоснования с принятием решений между стадиями жизненного цикла для всей системы по итогам оценки рисков успешности проекта на разных стадиях его реализации получили название гейтов (gates, ворота – не путать с milestones/вехами, которые не связаны с решениями о прекращении всего проекта в целом и служат лишь для контроля скорости его прохождения. Ворота могут быть закрыты, а вот вехи просто отмечаем глазами на обочине). Вообще-то решений в гейтах обычно не два типа (go – no go), а три (доработать результат стадии и повторить гейт; переходить к следующей стадии; остановить проект):
Но данная концепция/модель жизненного цикла оказалась для проектов с существенной долей работ с новыми для разработчиков типами систем полной утопией, она более-менее выполнялась лишь в проектах, где можно было накопить огромный опыт сборки/изготовления многочисленных очень похожих систем «из вещества» (там небольшая вариативность), например, гражданское (жилищное) блочное строительство.
Во всех остальных случаях (и особенно ярко это проявлялось в айтишных проектах) после выполнения работ по любой из практик «водопадного жизненного цикла» (в те времена типично было, например, указание на инженерию требований в ходе стадии работ «формирование требований» – понятно, что разработанные требования говорили «какая должна быть система, чтобы быть успешной», и дальше ожидалось, что можно просто спроектировать и изготовить такую систему для гарантированной успешности) после всех гейтов с их проверкой независимыми экспертами, после всех ожиданий, когда все рабочие продукты соберут по их состоянию готовности на конец стадии (скажем, если речь идёт о требованиях – то это будут абсолютно все требования, и если не готово даже какое-то второстепенное требование, то его будут ждать), всё равно при попытке работы с этими результатами предыдущих стадий находятся ошибки и недоработки и приходится выполнять новые работы, выполняющие практики работ предыдущих стадий жизненного цикла. Требования постоянно оказывались не «долженствованием», а «мы чуток ошиблись, гипотеза не подтвердилась», «мы тут не уточнили, давайте сформулируем по-другому». Пробы и ошибки всё равно были, новые и новые переделки/reworks не позволяли хоть как-то соотносить запланированные стадии жизненного цикла и реально ведущиеся работы. «Водопад» был только на бумаге в учебниках инженеров и в мечтах менеджеров.
«Водопад» оказался утопией, типа менеджерского философского камня или эликсира бессмертия: очень привлекательно, но абсолютно нереалистично, нереализуемо. Проблема в том, что следование этой утопии в планировании и отслеживании планов во многих организациях происходит до сих пор! В договорах, планах и отчётах до сих пор можно найти именно «водопад», а то, что в жизни всё совсем не так, никак не влияет на эти документы, поэтому они не отражают реальную жизнь. Эта ситуация известна как проблема «а чо такова?», то есть проблема непринятия всерьёз логичных рассуждений, игнорирование важности соответствия жизни и описаний жизни. Это всё равно как знать, что суеверия – плод фантазии, но всё-таки следовать им. «Водопад» оказывается утопичен, фантазиен, но всё-таки люди считают, что он хорошо описывает проект и дальше пытаются ему следовать.
Использующим «водопадную» концепцию жизненного цикла в своих проектах инженерам приходилось признавать, что с практиками приходится работать в ходе всего полного жизненного цикла (те же самые «утверждённые требования», которые и до сих пор используются, менять по многу раз в ходе проекта, иногда чуть ли не в момент окончания работ, чтобы получить приемлемые инженерные обоснования). Работы назначать (и выделять ресурсы для проведения этих работ) на практики приходилось независимо от «водопадной» модели жизненного цикла, каждая практика (особенно легко это объяснять на примерах управления работами/операционного менеджмента, управления конфигурацией и прочих «управлениях») встречается на всех стадиях «водопада», их принципиально непонятно как выносить на какую-то обособленную во времени стадию. Но это же верно и для всех остальных практик, есть только ложное убеждение, что «мы утвердим очередной рабочий продукт, например, архитектурное решение, и больше никогда к нему не вернёмся». Нет, так не получится. Непрерывное всё, придётся постоянно работать над изменениями. Так что деление на стадии при принятой концепции «водопада» в жизненном цикле отражается не столько на реальных работах (они идут как надо, а не как задокументировано в планах!), сколько на договорной документации и официальных документах, которые должны идти в архив. «Водопад» путает классических инженеров в части описания того, какими методами они работают, а менеджерам/«инженерам предприятия» даёт нереалистичные оценки как в части рациональной организации работ (архитектуры предприятия, облегчающей инженерию целевой системы), так и в части операционного менеджмента (работы оказываются совсем не такими, какие можно ожидать, и происходят они в неожиданные моменты – предсказания модели «водопада» очень плохие).
Каждый раз, когда люди говорят «у нас принята водопадная модель» – это означает, что они думают «колбаской», а в жизни у них не-пойми-что, но только не эта «колбаска» с последовательным продвижением по стадиям. Тем самым описание проекта сильно отличается от жизни, а это недопустимо, это само по себе вносит риск в проект! Если у вас на чертежах собачья будка, а в жизни это получается скворечник – то к такому проекту будут вопросы. Но если на «чертежах» самого проекта (то есть в договорной документации, в отчётных документах – это и есть «проект/design проекта/project»/«чертежи проекта», по этому проекту/design планируется разворачивать работы проекта/project) «водопад», а в жизни получается какая-нибудь спираль или что-то другое, лучше отражающее непрерывные изменения, «цикличность/продолженность/непрерывность развития», то принято делать понимающее выражение на лице. Но ведь это то же самое: системное мышление по отношению к целевой системе и системам создания устроено одинаково, и описание должно соответствовать воплощению!
Менеджерам и особенно госчиновникам в военных проектах гейтовая схема была очень удобна, ибо она позволяла легко организовывать финансирование проектов, деля деньги по их стадиям. Проектные управляющие до сих пор пользуются гейтовой схемой из «водопадной» модели как основным описанием для организации своей проектной работы. Страдают при этом не менеджеры, страдают инженеры-технари: функциональные диаграммы, говорят, например, что нужно доработать концепцию использования (при этом для концепции системы ещё и требуют «для архива» разработать требования, которые потом будет очень трудно менять!). А у менеджеров финансирование работ на разработку требований уже закончено, а концепция использования вообще не учтена, ибо «как же вы будете работать без требований?». И инженерам-технарям (или не технарям, а из других сфер деятельности, где они даже «инженерами» не называются) средства на доработку концепции использования поэтому не дают, «поезд ушёл». Конечно, дорабатывать самые разные описания системы в жизни таки приходится, но это будут «неучтённые работы», и поэтому в проектах с официально принятым «водопадом» в качестве концепции жизненного цикла всегда наблюдается управленческий хаос, непримиримые конфликты менеджеров (инженеров организаций) и инженеров-технарей (прикладных инженеров целевой системы).
Читать бесплатно другие книги:
