Где искать описания современных инженерных практик ​

Документированные методы создания и развития систем можно встретить в различных инженерных стандартах (стандарт --- это когда известен способ проверки соответствия описанию) и публичных документах (всё то же, что у стандарта, но не предполагается проверки соответствия). Помним, что терминология тут будет самая разная. Например, часто это будет «процесс разработки», не менее часто «практики жизненного цикла», иногда «процессы жизненного цикла». Разбирайтесь по содержанию, а не по названиям: слова важны (у нас кроме слов обычно ничего нет), и не важны (слова терминов имеют много словарных значений, размытые значения, неправильно употребляются, искажаются при переводе, в них может быть метонимия, и т.д.).

Наиболее типичны для документирования прикладных методов/практик классической инженерии и менеджмента своды знаний (body of knowledge^[1], корпус знаний), описывающие различные подпрактики какой-то более-менее крупной практики/деятельности и возможные варианты выбора этих подпрактик в какой-то связный метод. Но могут быть и справочники, и учебники.

Все эти стандарты и публичные документы используют разные методы описания (viewpoints), дающие разные описания (view) даже одних и тех же практик, которыми ведутся работы проекта. Даже название практики будет существенно различаться, могут быть неожиданности. Например, в медицине лечат сегодня по протоколам диагностики и лечения^[2] --- эти протоколы и есть методы лечения, лечение/работа идёт по описаниям способов лечения/работы в этих протоколах. В сводах знаний могут практику обозвать мастерством, могут обозвать способностью/ability. Чаще всего встречаться будут процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000, в которых путаются модульный/конструктивный «процесс как последовательность шагов/операций/работ во времени» и функциональный/ролевой «процесс как описание принципов, каким способом нужно достичь результатов, способа работы»). Не реже будут методы (наборы практик, достаточных для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), а иногда и «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity).

У СМД-методологов используется термин «деятельность» и даже «труд» (когда говорится о разделении труда, division of labour/labor). А с учётом того, что практики что-то меняют в окружающем мире, это ещё и инженерии (и не только классические, но и социальная инженерия тоже, и многие другие прикладные практики). В образовании речь может идти о методиках, при этом путают и метод, и описание метода, и документ описания метода --- всё называют одним словом «методика», хотя иногда тут идёт и уточнение: метод обучения --- это методика, описание метода --- методические рекомендации. Всегда ориентируйтесь по ситуации, что имеется в виду! Слова могут запутать, работайте с понятиями! В нашем курсе мы постоянно даём синонимы для практик, это затрудняет чтение, но облегчает потом перенос знаний курса в рабочие проекты.

Часто «практику» или какой-то её синоним считают типом, и вообще не упоминают: просто указывают на то, как и что нужно делать, приводя название объекта типа практика, но не используя сам термин. Например, говорят «проектное управление», но не «практика проектного управления». Так же часто говорят «самолёт», но не «система самолёт» --- слово «практика» как указатель типа встречается отнюдь не всегда.

Вы должны уметь распознать тип, указать тип «метод/практика/деятельность» прямо по ходу разговора! «Выращивание цветов» --- это деятельность, следовательно где-то существует описание способа этого выращивания, хотя бы в голове выращивающего (и методолог сможет вытащить описание этого метода выращивания цветов из головы садовника, мировой литературы и наблюдения за поведением садовника). Главное, чтобы вы очень чётко понимали, когда вы встречаетесь с практиками, с описаниями практик, с практикованием по неописанным и необсуждённым методам. Тогда вы должны сыграть роль методолога и разобраться с тем, что там с методом (отмоделировать метод, описать его основные черты) --- это должно быть умением любого человека с сильным интеллектом. Методология --- это одна из трансдисциплин интеллект-стека, при помощи методологии обсуждаются все остальные фундаментальные и прикладные дисциплины, а также практики на основе этих дисциплин (практика = дисциплина + технология).

Вот примеры документирования некоторых методов/практик в сводах знаний:

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK)^[3]. Тут в главе 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)^[4]. То, что называется «практики» в нашем курсе, в PMBoK называют «процесс». Например, группа процессов планирования определяет и уточняет цели, а также планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов и т.д. (всего 47 процессов в 6 версии PMI PMBoK 2017 года). В 2021 году вышла 7 версия PMI PMBoK, которая была существенно переработана.
• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)^[5]. Сами практики тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».
• ... множество других BoK, это сегодня стандартная форма выражения знаний по практикам какой-то инженерной или менеджерской дисциплины.

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

Поэтому дисциплину нужно учить, а вот к новым технологиям эти своды знаний правильно адаптировать: в части новых технологий эти своды знаний могут быть устаревшими. И даже современное состояние дисциплины эти своды знаний могут не отражать, они готовят к «выигрышу в прошедшей войне», а не к новой современной ситуации! Технологии часто показывают это: свежие их версии поддерживают новации в дисциплине, которые ещё не успели отразиться в сводах знаний, хотя своды знаний регулярно актуализируются (но на то они и своды, чтобы «сведение» происходило после появления тех работ, по которым делается это «сведение знаний в одном тексте»). Так что за современностью в практиках и технологиях нужно внимательно следить. Например, понятие критической цепи/critical chain некоторое время назад было контркультурным, свежим словом в дисциплине проектного управления, сам термин мало кто знал. Сегодня это общее место, все уже понимают разницу критического пути/critical path и критической ресурсной цепи на уровне дисциплины, и обращают внимание на возможности софта поддержки проектного управления по поддержке соответствующих расчётов.

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

Абсолютно не исключено, что разные группы компетентных в той или иной практике людей будут рекомендовать использование своего любимого варианта практики, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.

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

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

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

Трансдисциплина методологии, которую вы сейчас изучаете, работает с практиками, как с объектами, поэтому вам легко будет объяснить, почему ТРИЗ --- это не вариант системной инженерии. В ТРИЗ, например, нет подпрактики технологии производства из практик разработки, нет практик архитектурной деятельности, которая даже не подпрактика разработки. Зато в ТРИЗ есть довольно изощрённые методы создания концепции системы, «изобретения». Если методологией не владеть, то можно вечно спорить, что могут, а что не могут делать инженеры-тризовцы/«мастера ТРИЗ». Они мастера отнюдь не во всех практиках/деятельностях/видах труда системной инженерии! Вам всё равно нужны будут кроме тризовцев в командах разработчиков и мастера других инженерных практик, дисциплины которых отсутствуют в ТРИЗ. Сами ТРИЗовцы при этом не будут удерживать чеклиста с инженерными практиками, которыми надо заниматься в проекте --- или будут рассказывать об этих практиках «по наитию», вне своей ТРИЗ-экспертизы, а «из опыта». Когда они сделают ошибку в рассуждениях о современном инженерном методе, они её не заметят, ибо в их мышлении нет необходимых понятий для рассуждения о методах работы и нет знания SoTA системной инженерии. Знание методологии тут существенно поможет: вы можете понимать границы применимости того или иного мастерства, в том числе мастерства ТРИЗ.

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