Где искать описания современных методов менеджмента и инженерии
Документированные методы создания и развития систем можно встретить в различных инженерных стандартах (стандарт — это когда известен способ проверки соответствия жизни описанию) и публичных документах (всё то же, что у стандарта, но не предполагается проверки соответствия). Помним, что терминология в них всех для методов будет самая разная. Например, для совокупного «метода создания и развития системы» в его самом верхнеуровневом разложении часто будет термин «процесс разработки», не менее часто «инженерный процесс», не менее часто «процессы жизненного цикла» (привет от «смертных» систем), иногда «методы разработки». Разбирайтесь по содержанию**/понятиям****, а не по** форме/словам/терминам**😗*
- слова важны (у нас кроме слов обычно ничего нет), и
- не важны (слова терминов имеют много словарных значений, размытые значения, неправильно употребляются, искажаются при переводе и с греческого, и с латыни, и с английского или наоборот, на английский**, в них может быть метонимия, и т.д.).**
Наиболее типичны для документирования прикладных методов классического инженерного процесса и основных методов менеджмента такие публичные документы и стандарты, как своды знаний (body of knowledge[1], корпус знаний), описывающие различные подпрактики какой-то более-менее крупной практики/деятельности и возможные варианты выбора этих подпрактик в какой-то связный метод. Но описания методов могут быть найдены и в справочниках, и в учебниках, в монографиях, небольшие методы могут быть описаны в статьях и блог-постах, набирает форму и видео рассказ-показ в соцсетях. Скажем, культура социальных танцев редко документируется текстами, чаще это видеоролики — по понятным причинам, но если речь идёт о предъявлении культуры/стиля на соревновании/конкурсе для оценки соответствия предъявляемого стиля танцевания судьями, то ассоциации танцоров какого-то стиля готовят стандарты, которым надо соответствовать, чтобы считаться победителями. Если есть несогласие с тем, что сделала одна какая-то ассоциация в плане документирования метода, в спор включается другая ассоциация с другим стандартом.
Все эти стандарты и публичные документы используют разные методы описания (viewpoints), дающие разные описания (view) даже одних и тех же методов, которыми ведутся работы проекта по созданию и развитию того или иного вида систем. Даже название метода и название знаний метода будет существенно различаться, могут быть неожиданности.
Например, в медицине лечат сегодня по протоколам диагностики и лечения[2] — эти протоколы и есть методы лечения, лечение/работа идёт по описаниям способов лечения/работы в этих протоколах. В сводах знаний могут запросто метод обозвать мастерством, могут обозвать способностью/ability.
В организационном менеджменте чаще всего встречаться будут процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000). Не реже будут и методы (помним, что в инженерии термин «метод» часто используется как набор составляющих его более мелких практик, достаточный для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), а иногда и «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity).
У СМД-методологов используется термин «деятельность» и даже «труд» (когда говорится о разделении труда, division of labour/labor). А с учётом того, что методы что-то меняют в окружающем мире для того, чтобы изменить этот мир к лучшему путём создания успешных систем, их называют ещё и инженери****ей(и не только классической «железной» или программной инженерией, но и генной инженерией, социальной инженерией и т.д.). Деятельность, труд, инженерия всё-таки сами по себе общи, часто ими называют и все возможные методы, которыми работают интеллектуальные агенты, например, «человеческая деятельность» — это отсылка ко всем методам, которыми работает человек, всё, что делают люди. Так что тут могут сужать значение, говоря о виде деятельности, виде труда, виде инженерии — это будет достаточно широко понимаемый метод работы, с вариантами разложения для очень широко понимаемой сигнатуры. Скажем, инженерия путей сообщения как вид инженерии — все методы работы путевых инженеров. Формально пути сообщения — это и автомобильные дороги, и водные пути, и железные дороги. Часто инженерия путей сообщения понимается вообще узко, только как инженерия железных дорог[3]. Программная инженерия (software engineering) тоже весьма и весьма широко понимаемый набор методов создания программных систем. Посмотрите на то, как «программная инженерия» таки сводится к «методу разработки» в статье Википедии[4], вы там увидите в определении множество знакомых слов из синонимов метода работы, все эти слова как-то ссылаются на одно и то же: Software engineering is an engineering approach to software development. A practitioner, called a software engineer, applies the engineering design process to develop software. Неявно из синонимов метода тут помянута даже «практика», через роль practitioner, но ещё и процесс, и разработка, и инженерия. И тут прямо в определении сужение понимания границ инженерного процесса, ограничиваемое только проектированием и кодированием как аналогом проектирования/design в машиностроении. Помним, что сначала процесс разработки касался только разработки как проектирования, затем разработки до момента получения работоспособного образца целевой системы, затем в инженерный процесс (который продолжали называть «разработкой») начал включать в себя и производство, затем включили эксплуатацию и вывод из эксплуатации, затем только перешли к тому, что всё это, только повторяемое для множества и множества версий системы — поэтому вывод из эксплуатации перестал быть особо актуальным, но ведение всего остального подразумевалось непрерывным. Конечно, в «народной памяти» (памяти инженеров самых разных поколений) живут одновременно все эти воспоминания, которые прорываются в тексты — и мы видим ровно вот такие попытки объять необъятное и плохо совместимое, как в обсуждаемой статье Википедии. Поэтому обращайте внимание на смысл, а не на употребляемые слова — и не ждите, что про методы вам будут писать тексты со строгим контролем типов. Даже если формализацией методов занимаются математики или онтологи, будьте внимательны: оторванная от жизни, незаземлённая логика может не сработать. Что верно в математике и физике, может быть неверно в системном мышлении: в математике у стада может быть хвост, а системное мышление говорит, что так думать нельзя. Этот пример был в «Системном мышлении».
Повторим, что внимательным тут надо быть не только к чужим словам, но и своим словам: когда вы художественно описываете то, что предстаёт перед вашим внутренним взором — бойтесь допустить ошибки в типах, уменьшайте уровень художественности, контролируйте ошибки типов, а речь по возможности заземляйте.
При обсуждении обучения (инженерия личности) речь может идти не о методах, а о методиках, при этом очень часто путают и метод, и описание метода, и документ описания метода — всё называют одним словом «методика», хотя иногда тут идёт и терминологическое уточнение: метод обучения — это методика, описание метода — методические рекомендации.
Всегда ориентируйтесь по ситуации, что имеется в виду! Слова могут запутать, работайте с понятиями! В нашем руководстве мы постоянно даём синонимы для методов, это затрудняет чтение, но облегчает потом распознавание методов в жизни, а также облегчает переход к разговору о методах в рамках того языка, который принят в той прикладной инженерной культуре, в какую вы будете попадать в самых разных проектах.
Часто «метод» или какой-то его синоним считают типом, и вообще не упоминают: просто указывают на то, как и что нужно делать, приводя название объекта типа «метод», но не используя сам термин. Например, говорят «проектное управление», но не «метод проектного управления» или «процесс проектного управления». Это обычное дело для типов высокого онтологического уровня (метод тут тип мета-мета-модели). Мы уже говорили об этом, когда в «Системном мышлении» разбирали, что говорят «самолёт летит», но не «система самолёт выполняет метод полёта» (но также замечали, что если очень хочется подчеркнуть тип, например, чтобы избежать возможных ошибок — то тип добавлять можно, речь же приобретёт черты канцелярита). Опускание типа мета-мета-модели мы также рекомендовали в общении с коллегами, не знакомыми с системным мышлением: если будете добавлять, будете считаться говорящими на птичьем языке.
Вы должны уметь распознать тип «метод/практика**/культура****» прямо по ходу разговора****—** и удерживать на нём внимание. «Выращивание цветов»****— это культура/«вид деятельности», следовательно где-то существует описание способа этого выращивания, хотя бы в голове выращивающего. Вы как методолог сможете вытащить описание этого метода выращивания цветов (дисциплину/теорию/знания/объяснения/правила/алгоритм) из головы садовника, мировой литературы и наблюдения за поведением садовника. Главное, чтобы вы очень чётко понимал****и: когда вы встречаетесь с самими методами работы (поведение! Изменение состояния каких-то предметов!)****, в каких случаях это не методы, а описанияметодов работы (в распределённых или локальных/символьных представлениях), в каких случаях речь идёт не о методе, а о выполнени****и работ по неописанным и необсуждённым методам (поведение! Изменение с****остояний каких-то предметов!), а в каких случаях вы обсуждаете не метод, а роль с какой-то сигнатурой метода и фантазией о том, каким методом реализуется сигнатура, какое там даже верхнеуровневое разложение метода на его составляющие, когда речь идёт не о методе, а о работе. В****ы должны уметь играть роль методолога, чтобы разобраться с тем, что там с методом и работами (отмоделировать метод, описать его основные черты**, отделить паттерн метода от работ этим методом****)—** **это должно быть умением любого человека с сильным интеллектом.**
Методология — это один из фундаментальных методов мышления интеллект-стека, при помощи методологии обсуждаются все остальные фундаментальные и прикладные методы как чистого мышления (работа с описаниями, вычисления), так и создания и развития систем (изменение физического мира).
Вот примеры документирования некоторых методов работы (видов инженерии, методов разработки) в сводах знаний:
- свод знаний по организационному анализу (business analysis body of knowledge, BABoK)[5]. Тут в главе 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)[6]. То, что называется «метод работы» в нашем руководстве, в PMBoK называют «процесс». Например, группа процессов планирования определяет и уточняет цели, а также планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов и т.д. (всего 47 процессов в 6 версии PMI PMBoK 2017 года). В 2021 году вышла 7 версия PMI PMBoK, которая была существенно переработана.
- свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)[7]. Сами методы тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».
- … множество других BoK, это сегодня стандартная форма выражения знаний по разложению какого-то инженерного или менеджерского метода на составляющие.
Можно спорить, описывают ли подобные документы методы, включая возможный инструментарий («гвозди должны быть забиты быстро и ровно, для этого используйте молотки, а не любые попавшиеся под руку камни»), или только «чистые объяснения», «чистую теорию», оставляя какое-то описание возможных инструментов за своими пределами («гвозди должны быть забиты быстро и ровно»). Авторы подобных документов обычно уделяют не столь большое внимание таким вопросам, не различают «научную дисциплину» и «инженерную дисциплину, включающую указания на методы работы с инструментарием». Но нужно помнить, что знания о методе меняются медленно, а инструменты — крайне быстро. Пример нового инструмента — ChatGPT в 2023 году получил 100 миллионов пользователей за первые два месяца. Это пример скорости распространения нового инструментария. Новые инструменты часто приводят к тому, что появляются и новые методы работы, опирающиеся на новые объяснения, новые знания: так, появилось несколько инструментов поиска для интернета, а метод «погуглить» появился только с появлением достаточно продвинутого инструмента интернет-поиска от Google, теперь поиску в интернете учат в некоторых вузах как отдельному методу в составе исследовательского процесса (исследовательский процесс — метод получения знаний, о котором думать надо ровно так же, как об инженерном процессе — методе получения успешных систем).
Алгоритмы поисковой системы Google меняются часто, но дисциплина «гугления» меняется много медленней. Хотя и тут уже происходят драматические изменения, ибо вопросы можно теперь задавать не только Гуглу, но ещё и AI-агентам на базе больших языковых моделей, так что знание/теория правильного вопрошания кардинально изменились и получили название prompt****engineering[8]. Но и с prompt engineering как новым методом работы с системами AI на основе новой дисциплины уже происходят драматические изменения: оказалось, что AI-системы отлично пишут промпты сами себе, и специальных знаний для задания вопросов большим языковым моделям иметь не нужно, надо просто быть достаточно умным, чтобы сформулировать вопрос и уточнить его — примерно так же, как это было бы в любой беседе с людьми. И этот вопрос может быть и поисковым запросом на получение знаний, с каким раньше обращались к Гуглу.
Так что дисциплину/знания/правила/алгоритм метода вполне можно смотреть по сводам знаний, понимая, что эти знания эволюционируют, но и могут устаревать. Скажем, SEBoK на сегодня отражает версию методов системной инженерии, бывших SoTA много лет назад. Сегодня лучшие методы в жизни уже поменялись, а в SEBoK они ещё не отражены. А ещё эти своды знаний правильно адаптировать к новым инструментам, ибо в части новых инструментов эти своды знаний обычно заведомо устаревшие, даже если основная теория метода в них рассказывается более-менее SoTA.
Вообще, проверку на современность у описаний методов надо делать регулярно. Многие своды знаний даже в их старших версиях сегодня готовят к «выигрышу в прошедшей войне», а не к новой современной ситуации! Инструментарий часто это показывает наглядно: свежие версии инструментов поддерживают новации в дисциплине, которые ещё не успели отразиться в сводах знаний, хотя своды знаний регулярно актуализируются (но на то они и своды, чтобы «сведение» происходило после появления тех работ, по которым делается это «сведение знаний в одном тексте»).
За современностью в методах и поддерживающих их инструментах, современностью материалов в предметах метода нужно внимательно следить. Например, понятие критической цепи/critical chain некоторое время назад было контркультурным, свежим словом в дисциплине проектного управления, сам термин мало кто знал. Сегодня это общее место, все уже понимают разницу критического пути/critical path и критической ресурсной цепи в объяснениях/теории метода проектного управления, и обращают внимание на возможности софта поддержки проектного управления по поддержке соответствующих расчётов — чтобы не промахнуться с инструментарием (мы приводили уже этот пример).
Не уделяют авторы сводов знаний внимания и вопросам выбора варианта метода по его сигнатуре, оставляя этот выбор за агентом, готовящимся к выполнению метода в какой-то проектной роли. Например, есть вариант метода проектного управления, описанный в PMI PMBoK, но есть и альтернативный вариант метода проектного управления, описанный в APM BoK[9] — и нужно выбирать, каким из этих двух вариантов метода надо будет работать, поэтому каким из этих сводов знаний воспользоваться для изучения метода проектного управления. Содержание этих сводов знаний абсолютно разное. Это химия или физика в двух учебниках окажется одной и той же, хотя и это не всегда факт для более современных учебников, а проектное управление обычно будет очень разным!
Абсолютно не исключено, что разные группы компетентных в том или ином методе работы экспертов будут рекомендовать использование своего любимого варианта метода, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.
Методы работы могут быть разложены на составляющие довольно глубоко. Мы помним, что это разложение в одном из самых простых и грубых вариантов можно представить как иерархию составляющих. Например, можно говорить о системной инженерии как методе/культуре работы. Но в системной инженерии можно выделить её основные методы визионерства, разработки, архитектурной деятельности, инженерии производственной платформы. Но и дальше может быть деление: например, в разработке можно выделить практики прикладной методологии (выбор SoTA методов работы), проектирования (создание информационной модели с проектом/design), производства (использование производственной платформы для изготовления системы по проекту/design), эксплуатации/операторства (настройка изготовленной и развёрнутой системы на условия эксплуатации и удержание параметров работы в заданных пределах). В порядке глубокого разделения труда роль разработчика тем самым будет разбита на подроли методолога, проектировщика, технолога производства, оператора — и эти подроли сегодня для разработки крохотных систем может играть буквально одно оргзвено из буквально одного человека, для небольших систем играть команда из нескольких человек в одном оргзвене, а для больших систем эти роли играют целые предприятия со множеством людей и оборудования.
И даже на этом уровне разбиения могут быть самые разные варианты. Например, если брать такой метод проектирования как ТРИЗ, то за последние двадцать лет ТРИЗ-методы создания концепции системы были дополнены ТРИЗ-методами создания концепции использования. Так что для создания концепции использования можно или использовать методы ТРИЗ[10] (включая инструменты их поддержки: моделеры специфических для этого диаграмм ТРИЗ), или альтернативные методы, например сценарии использования (use cases, включая инструменты: моделеры, поддерживающие специфические языки для моделирования use cases).
Методология — это фундаментальный метод мышления, входит в интеллект-стек. Она работает с прикладными методами как предметами метода «методология». Вы уже освоили мышление по методам первой половины руководства по методологии, поэтому вам легко будет понять, почему ТРИЗ — это не вариант системной инженерии. В составе ТРИЗ::«инженерный метод», например, нет процесса/метода изготовления из практик разработки, нет архитектурной деятельности, которая даже не входит в разложение процесса/метода разработки. Зато в ТРИЗ есть довольно изощрённые методы создания концепции системы, проектирования, «изобретения». Если методологией не владеть, то можно вечно спорить: что могут, а что не могут делать инженеры-тризовцы/«мастера ТРИЗ». Они мастера отнюдь не во всех «инженерных методах»/«видах труда» из состава методов системной инженерии! Вам всё равно нужны будут кроме тризовцев в командах разработчиков и мастера других инженерных практик, дисциплины которых отсутствуют в ТРИЗ. Например, мастера организационного развития (которых готовит наша полная учебная программа, «Методология» как раз входит в эту программу). Сами ТРИЗовцы при этом не будут удерживать чеклист со всеми инженерными методами работы, которыми надо будет заниматься в проекте — или они будут рассказывать об этих методах «по наитию», вне своей ТРИЗ-экспертизы, исходить «из опыта», а не «из теории». Когда ТРИЗовцы сделают ошибку в рассуждениях о современном инженерном процессе, они её не заметят, ибо в их профессиональном мышлении нет необходимых понятий из методологии для рассуждения о методах работы, а также нет знания SoTA системной инженерии хотя бы на кругозорном уровне. Так что знание фундаментальной методологии тут существенно поможет: методология позволяет вам обсуждать границы применимости того или иного метода (и тем самым мастерства по этому методу), в том числе границы применимости ТРИЗ (и тем самым границы полезности в проекте мастерства ТРИЗ, которое может найтись у каких-то агентов).
Отдельно нужно сказать о моделях зрелости**/maturity, в которых обсуждается прохождение каких-то ступенек в достижении оргзвеньями какого-то мастерства в работе по методам, или достижение какой-то характеристики. На сегодня использование разных моделей зрелости и «ступенек» признано неверным: все они подразумевают конечное достижение какой-то цели, после чего развитие вроде как останавливается (дальше подразумевается вечное совершенствование). Поэтому от использования моделей зрелости в самых разных их вариантах повсеместно отказались.** Всего десяток лет назад модели зрелости были очень популярны: вы определяли конечную цель и шли к ней по чётко определённым ступенькам. За десять последних лет пришлось признать, что ступенек бесконечное количество, они никогда не кончаются, да и лестниц тоже бесконечно много — и считать ступеньки перестали. Переход к бесконечной эволюции, «непрерывному всему» положил конец и этой культуре/практике.