Анатолий Левенчук - Системное мышление

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

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

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

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK) 162 162 http://www.iiba.org/babok-guide.aspx , оглавление на русском https://iiba.ru/babok/chapters-of-babok-version-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) 163 163 https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge . Там практики называют «процесс», например, группа процессов планирования определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов, и т. д. (всего 47 процессов в актуальной 6 версии PMI PMBoK).

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

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

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

Не уделяют они внимания и вопросам выбора варианта функционально одинаковых практик, оставляя этот выбор за человеком-актёром, готовящимся к выполнению какой-то стейкхолдерской роли. Например, есть набор практик проектного управления PMI PMBoK, но есть и альтернативый вариант, APM BoK 165 165 https://www.apm.org.uk/body-of-knowledge/about-bok/ – и нужно выбирать, каким набором практик пользоваться для изучения дисциплины. Абсолютно не исключено, что разные группы компетентных в той или иной практике людей будут рекомендовать использование своего варианта, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.

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

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

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

Стандарт практик жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2015 167 167 https://www.iso.org/standard/63711.html 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).