Технология в составе практики

 

Технология хорошо видима, но «ружьё в руках дикаря – кусок железа». Технология без понимания поддерживаемой ей дисциплины мертва, тот самый «кусок железа» из пословицы. Традиционный капитал (средства производства) мёртв, если он не поддержан человеческим капиталом – образованными в части дисциплине и натренированными на владение конкретным вариантом инструментария данного предприятия сотрудниками.

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

Так, программы проектного управления могут поддерживать самые разные дисциплины проектного управления, самые разные наборы альф. Например, управление проектами может быть классическим с альфой «критический путь» (critical path) и по теории ограничений с альфой «критическая цепь» (critical chain)[159] и управлением по заполнению буферов проекта[160]. Если вы не понимаете связи между инструментами и дисциплинами, и купите просто «программу управления проектами», то вас может ожидать сюрприз.

В программе управления проектами на рисунке (Рис. 5) нет никаких буферов проекта, поэтому она не поддерживает мышления согласно дисциплине управления проектами теории ограничений.

А вот эта программа (Рис. 6) поддерживает, «светофоры» буферов хорошо видны на её скриншотах.

Если не владеть дисциплиной проектного управления, то можно вообще не понять, почему так различается инструментарий для вроде бы одной и той же практики, а «светофоры буферов» будут казаться особенностями интерфейса программы, а не дисциплины проектного управления в какой-то её версии. Инструментарий различается не столько удобством в использовании, сколько поддерживаемыми дисциплинами этой практики: тем, какие понятия в мышлении они способны отразить.

Тем самым совершенствование (improvement) предпринятия, совершенствование обеспечивающей системы, совершенствование жизненного цикла сводится к смене технологий на более современные, наладке бездефектной работы технологий, обеспечение хорошей логистики рабочих продуктов между технологическими операциями. Практика меняется только в части технологий, но не дисциплины. При совершенствовании люди переучиваются (training) на работу с новой технологией.

Развитие (development) предпринятия происходит тогда, когда меняется практика в части дисциплины и неминуемо происходит смена технологии для поддержки этой дисциплины.

 

 

 

При развитии люди образовываются (education, «как в ВУЗе») для освоения новой дисциплины мышления и обучаются/тренируются (training, часто на рабочем месте) в работе с новой технологией, новым инструментарием.

Текущий тренд в том, что периоды совершенствования становятся всё короче и короче, и всё чаще и чаще приходится осуществлять шаги развития: предпринятие начинает использовать незнакомые практики работы, ибо ожесточается конкуренция не только технологий, но и дисциплин – в конкурентной борьбе оказывается недостаточно использовать «лучшие инструменты», необходимо использовать и «лучшее мышление» прежде всего, и уж это «лучшее мышление» поддерживать «лучшими инструментами».

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

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

 

Практики жизненного цикла

 

Множество примеров практик, встречающихся на протяжении жизненного цикла системы (их часто так и называют – практики жизненного цикла, life cycle practices), можно встретить в различных инженерных стандартах и публичных документах, и наиболее типичны тут своды знаний (body of knowledge[161], корпус знаний), описывающие различные варианты практик какой-то более-менее крупной дисциплины.

Все эти стандарты и публичные документы используют для практик разные названия – практика (practice), способности (abilities), процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000, в которых путались модульный/конструктивный «процесс как последовательность шагов/операций/работ во времени» и компонентный/функциональный «процесс как описание принципов, каким способом нужно достичь результатов»), методы  (наборы практик, достаточных для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), иногда «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity). Иногда и вообще не используют каких-то терминов – просто говорят, «что нужно делать», приводя название практик, но не используя сам термин.

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK)[162]. Тут в главе 10 кратко охарактеризован набор из 50 практик, называемых «метод», начиная с 10.1 Acceptance and Evaluation Criteria (Определение критериев приемки и оценки), 10.2 Backlog Management (Управление бэклогом), 10.3 Balanced Scorecard (Сбалансированная система показателей, ССП), 10.4 Benchmarking and Market Analysis (Бенчмаркинг и Анализ рынка), 10.5 Brainstorming (Метод мозгового штурма), 10.6 Business Capability Analysis (Анализ бизнес-возможностей), 10.7 Business Cases (Бизнес-кейсы), …, 10.47 Use Cases and Scenarios (Сценарий использования и Сценарии), 10.48 User Stories (Пользовательские истории), 10.49 Vendor Assessment (Оценка поставщика), 10.50 Workshops (Воркшопы или Семинары)

• свод знаний по проектному управлению института проектного управления (Project Management Institute, project management body of knowledge, PMI PMBoK)[163]. Там практики называют «процесс», например, группа процессов планирования определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов, и т. д. (всего 47 процессов в актуальной 6 версии PMI PMBoK).

• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)[164]. Сами практики тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».

• … множество других BoK, это сегодня стандартная форма выражения знаний по практикам какой-то инженерной или менеджерской дисциплины.

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

Не уделяют они внимания и вопросам выбора варианта функционально одинаковых практик, оставляя этот выбор за человеком-актёром, готовящимся к выполнению какой-то стейкхолдерской роли. Например, есть набор практик проектного управления PMI PMBoK, но есть и альтернативый вариант, APM BoK[165] – и нужно выбирать, каким набором практик пользоваться для изучения дисциплины. Абсолютно не исключено, что разные группы компетентных в той или иной практике людей будут рекомендовать использование своего варианта, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.

Методы работы/практики/деятельности глубоко иерархичны. Не только метод состоит из практик (и гарантируется, что набор этих практик достаточен для достижения цели метода), но и сами практики состоят из подпрактик на много уровней. Например, можно говорить о системной инженерии как методе или практике работы. Но в системной инженерии можно выделить её основные практики инженерии требований, инженерии системной архитектуры, управления конфигурацией и изменениями, проведения испытаний/проверки и приёмки.

Но и дальше может быть деление: например, в инженерии требований можно выделить практики выявления потребностей и требований, анализа требований, специфицирования (документирования) требований, управления требованиями.

И даже на этом уровне могут быть самые разные варианты. Например, при развитии ТРИЗ за последние двадцать лет тамошние практики инженерии системной архитектуры были дополнены практиками инженерии требований. Так что для выявления требований можно или использовать методы/практики ТРИЗ[166] (включая технологию: моделеры специфических для этого диаграмм ТРИЗ), или альтернативных других практик, например вариантов/сценариев использования (use cases, включая технологию: моделеры специфических диаграмм use cases).

 

Пример: практики жизненного цикла системной инженерии

 

Стандарт практик жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2015[167] Systems and software engineering – System life cycle processes устанавливает общий подход к описанию практик для описания жизненного цикла систем, созданных людьми. Он определяет набор практик и связанную с ними терминологию в инженерном методе описания. Эти практики могут быть применены на любом уровне иерархии в структуре системы. Выбранный набор этих практик могут быть применены в ходе всего жизненного цикла для управления и выполнения всех стадий жизненного цикла системы. Это достигается через вовлечение всех стейкхолдеров, с главной целью достижения удовлетворения клиента (establishes a common framework of process descriptions for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology from an engineering viewpoint. These processes can be applied at any level in the hierarchy of a system’s structure. Selected sets of these processes can be applied throughout the life cycle for managing and performing the stages of a system’s life cycle. This is accomplished through the involvement of all stakeholders, with the ultimate goal of achieving customer satisfaction).

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

 

 

Стандарт задуман так, чтобы проверять: если вы выполняете все эти практики, то вы занимаетесь системной инженерией. Если не выполняете – то это просто инженерия.

Но тут нужно предостеречь, что этот стандарт, как и все остальные всевозможные BoK, описывает отнюдь не минимум или оптимум использования разных практик для достижения результата какой-то конкретной деятельности в конкретном проекте, а, скорее возможный максимум в абстрактном проекте.

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

Каждая очередная выполненная рекомендация по применению тех или иных практик будет затратна, а вот даст ли это существенный эффект в расчёте на каждый затраченный рубль или доллар – это не гарантировано.

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

 

Методологии

 

Популярные методологии разработки (development process), т.е. разные варианты agile[168], «гибкая методология разработки»), обеспечения качества (six sigma[169]), преодоления барьера между разработкой и эксплуатацией (DevOps[170] и DataOps[171]), и даже социализации в танце (социальные танцы[172] – танго, кизомба, сальса, самба) оказываются все наборами практик жизненного цикла, разве что не всех стадий.

Методологии часто содержат в себе три части:

• Общее описание дисциплины для многих составляющих методологию практик. Эта дисциплина вводит альфы, а отдельные практики потом могут работать с подальфами этих альф. Например, agile-практики вводят альфу backlog[173] как «список хотелок». Практики ТРИЗ-методологии используют понятие «идеального конечного результата»[174], социальные танцы работают с понятием «коннекшн»[175]

• практики как инструкции что и как нужно делать. Их обычно много разных, они могут вводить свои подальфы.

• указания на то, как сочетать практики с работами в ходе жизненного цикла, то есть выход на практики управления работами, прямые указания на управление жизненным циклом, вид жизненного цикла. Иногда даже слова «методология разработки» используют именно как указание на этот аспект (подменяя этим слова «вид/модель жизненного цикла»).

Сегодняшний тренд – это разборка крупных методологий на отдельные практики. Если ещё лет десять назад считалось, что нужно обязательно использовать в работе все описанные какой-то методологией практики, и без любой из описанных результат будет плохим, то сегодня такого уже нет. Для методологий разработки Ивар Якобсон (один из соавторов стандарта OMG Essence) призывает «освободить практики от методологий», ибо они являются отличными единицами накопления опыта – его доклад на SECR’17 так и называется: «Kill All Methods – Free the Practices»[176].

Интересно, что это относится даже к танцевальным методологиям, повсеместно происходит переход к fusion dance[177] (смеси разных практик танцевальных стилей, определяемых разными методологиями – и помним, что практика в танце поддерживается не только дисциплиной/теорией, но и инструментарием в виде тела и звучащей музыки, поэтому объединение практик танца из разных его стилей требует дополнительного развития тела).

Сами методологии тоже не ограничиваются практиками, взятыми из какой-то одной сферы человеческой деятельности. Так, agile-методологии появились как некоторый сплав (fusion) инженерных и менеджерских практик, хотя за последний десяток лет там практически не осталось инженерных практик, но только менеджерские[178], а методологии проектного управления всё больше и больше обращают внимание на инженерные аспекты разработки (в последние годы в них даже появляются отдельные практики инженерии требований, хотя и совершенно недостаточные для полноценной инженерной работы).

Системное мышление позволяет похожим образом думать о практиках таких разных сфер человеческой деятельности с их такими разыми дисциплинами и технологиями, как менеджмент, инженерия, культура. А учитывая то, что развитие это замена одних практик на другие (обычно с заменой дисциплины, а не только технологии – речь не идёт о совершенствовании), то системное мышление позволяет обсуждать организационное развитие в рамках управления жизненным циклом: обсуждать использование различных практик и способ их связи с выполняемыми работами.

 

 

Вид жизненного цикла

 

V-diagram

 

Самым упрощённым, популярным и распространённым представлением жизненного цикла в его современном виде является V-диаграмма (V-diagram, Vee diagram), популяризованная в 1991 году Kevin Forsberg[179]:

 

 

Название этой диаграммы происходит от формы латинской буквы V, а форма выражает линию времени, перегнутую пополам в точке, где укрупнённая стадия определения системы переходит в укрупнённую стадию воплощения системы.

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

Первая из них – стадия определения системы (system definition), когда физической системы не существует, а ведущими являются практики инженерии требований, инженерии системной архитектуры и (рабочего) проектирования. Это «работа с битами», информационная. Словосочетание «определение системы» тем самым используется в двух разных значениях (и никогда в значении «словарное определение!):

• Информация о системе, выраженная в требованиях, архитектуре и неархитектурной части проекта/design

• Обобщённая/укрупнённая стадия жизненного цикла, то есть работы различных практик по созданию определения системы в первом смысле этого слова

Дальше линия времени делает перегиб, и логически начинается вторая стадия воплощения системы (system realization). Словосочетание «воплощение системы» тем самым тоже используется в двух значениях:

• Сама система как 4D индивид (как пространственно-временной экстент в физическом мире)

• Обобщённая/укрупнённая стадия жизненного цикла, то есть работы различных практик по созданию воплощения системы в первом смысле этого слова

Сам излом V нужен для того, чтобы показать суть верификации и валидации: изготовление деталей (неделимых далее в проекте модулей) системы делается и проверяется (verification) в соответствии с проектом/design, стрелки верификации показывают именно этот факт. Ради показа этих стрелок проверки соответствия определения и воплощения и сделана сама V-диаграмма: она показывает способ работы, в котором воплощение/создание системы (system realization) происходит не путём проб и ошибок, сразу работы с материалом, а сначала путём размышлений и моделирования – определения системы (system definition). И созданная (изготовленная в виде деталей, а затем собранная из этих деталей) система проверяется на соответствие её предварительно разработанному определению – эти проверки изображаются стрелочками на диаграмме.

Последнее, что происходит в ходе воплощения – это приёмка в эксплуатацию, которая проходит в форме проведения испытаний на соответствие определённым в самом начале стейкхолдерским потребностям (то есть проверяется, что происходит не с целевой системой, а с использующей).

На этом первые V-диаграммы обычно и заканчивались, но потом иногда начали изображать и стадию эксплуатации (работу/функционирования системы, system operation) как длинный горизонтальный отрезок. На нашем рисунке это «иногда» показано квадратными скобочками вокруг system operation. Внешний вид диаграммы больше стал напоминать квадратный корень, но название «V-диаграмма» осталось.

Стадию вывода из эксплуатации на V-диаграммах изображать так и не начали. Это отражает постепенное восприятие системного мышления инженерами: сначала идея жизненного цикла проекта разработки системы (то, чем занимаются системные инженеры в своём проекте), потом охват мышлением стадии эксплуатации, и только в самое последнее время (уже в 21 веке, начиная со стандарта ISO 15288, первая версия которого вышла в 2002 году) умолчанием является обязательное рассмотрение полного жизненного цикла – в том числе и (инвестиционный) замысел, и вывод из эксплуатации/уничтожение после использования.

Горизонтальная пунктирная линия, отделяющая верх и низ V-диаграммы часто используется для того, чтобы отделить практики и работы (в V-диаграмме практики и работы они перемешаны и чётко не разделяются) системной инженерии (то есть практики и работы с требованиями, архитектурой, верификацией и валидацией) от практик и работ предметной инженерии/инженерии по различным специальностям – по рабочему (а не архитектурному) проектированию механических, электрических элементов, кодированию софта, а затем изготовлению механических и электрических частей системы, разворачиванию программных частей системы на целевых компьютерах. Так что из диаграммы видно, что практики системной инженерии встречаются главным образом на начальных стадиях проекта/project и конечных стадиях, а в середине проекта превалирует работа самых других инженерных специальностей, направляемая архитектурными решениями.

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