Пример: практики жизненного цикла системной инженерии
Стандарт практик жизненного цикла системной инженерии ISO/IEC/IEEE 15288:2015[1] Systems and software engineering --- System life cycle processes является примером документирования практики не в формате свода знаний. Он устанавливает наиболее общие описания практик жизненного цикла систем, созданных людьми в ходе системноинженерных проектов («жизненный цикл систем» как раз отражает, что он стандарт уже прошлого поколения инженерии).
Он определяет необходимый для системной инженерии набор практик создания и развития (в стандарте --- «жизненного цикла») какой-то системы, связанную с ними дисциплину/теорию (в том числе предлагается терминология для её выражения). Эти практики могут быть применены на любом уровне разбиения системы --- предполагается рекурсивное использование стандарта. Эти практики определены для всего времени создания (развитие может быть, но явно не предусмотрено) и существования созданной системы. В выполнение этих практик вовлекаются все проектные роли (stakeholders, и внутренние и внешние), с главной целью --- удовлетворить клиента.
Стандарт делит все практики на 4 группы, часть из них «технические» и относятся к преобразованиям целевой системы, часть «управленческие» и относятся к оргзвеньям/создателям, занимающимся проектами, в которых проводятся работы по практикам из этого стандарта, часть к создателям создателей (практики порождения организации проекта создания системы какой-то инициирующей этот проект организацией), часть относится к заключению и выполнению соглашений по закупкам и поставкам. Вот они:
Стандарт задуман так, чтобы проверять: если вы выполняете все эти практики, то вы занимаетесь системной инженерией. Если не выполняете --- то это просто инженерия, не системная. Но тут нужно предостеречь, что этот стандарт, как и все остальные всевозможные BoK, описывает отнюдь не минимум или оптимум использования разных практик для достижения результата какой-то конкретной деятельности в конкретном проекте, а, скорее, возможный максимум в абстрактном проекте. Эти стандарты особо любимы представителями государственных (и в них особенно военных) кругов, потому как подход «что ещё можно было бы сделать» отлично подходит к ситуациям, когда стороны заинтересованы поднять цену проекта по созданию успешной системы, а влияние проектных ролей, заинтересованных в снижении цены, минимально. Каждая очередная выполненная рекомендация по применению тех или иных практик будет затратна, а вот даст ли это существенный эффект в расчёте на каждый затраченный рубль или доллар --- это не гарантировано.
Поэтому пользоваться такими стандартами и публичными документами нужно только как справочным материалом, но не как руководством к действию: брать из этих документов только тот минимум, который подойдёт для масштабов вашего проекта. А учитывая, что это стандарт предыдущего поколения системной инженерии (до перехода к «непрерывному всему»), то и вообще на него ориентироваться нельзя. Хотя в государственных и тем более военных организациях этот стандарт как раз и описывает метод создания (и даже очень ограниченно развития) системы, каким бы он ни был нерезультативным и неэффективным.
Сегодня существует тренд антиперфекционизма (движения agile, lean, lightweight methodologies, идеи типа minimal viable product --- погуглите все эти понятия, если они плохо вам знакомы, они входят в современный кругозор менеджеров, основателей компаний, инвесторов): нужно выполнять минимум работы, не добиваться «совершенства», не тратить ненужных ресурсов. Это контркультурный тренд, он борется с культурой перфекционизма, в которой вы должны выполнять даже никому не нужную работу и доделывать её до конца, потому как «так надо», и «так принято». Но вчерашняя контркультура антиперфекционизма становится сегодняшней культурой, она оставляет перфекционизм только в реализации уникального торгового предложения и увеличении скорости разработки. Это всё приложение принципа минимального действия в физике к инженерии в целом и к менеджменту (инженерии организации) в частности.
Если речь идёт о стандартах, описывающих какие-то интерфейсы, реализуйте их полностью, но проверьте, какое поколение стандарта вы реализуете (возможно, реализовать нужно сразу несколько поколений стандарта, сразу несколько вариантов интерфейса). Если речь идёт о сводах знаний, стандартах выполнения практик, то берите из нихдля реализации только минимум! Для этого хорошо разбирайтесь в предметной области, чтобы взять реально важный минимум, оставив всё неважное вне воплощения.
Как и для любой другой классификации, для технических практик системной инженерии из стандарта можно предложить и альтернативные варианты. Например, наш курс «Системная инженерия» в Школе системного менеджмента использует более короткий список практик (и соответствующих им ролей), которые имеют отличающиеся названия (это практики визионерства, разработки, архитектурной деятельности, инженерии производственной платформы), эти же практики в менеджменте и исполняющие эти практики роли называются по-другому (практики бизнеса, организовывания, орг-архитектуры, администрирования). Так что стандарт практик системной инженерии вроде как есть, но он устарел (и немудрено: разработки международных стандартов и голосования стран в ISO тянутся годами, и практики успевают измениться раньше, чем успевают менять стандарты и BoK, по которым должны получать знания о практиках. Поэтому самые свежие практики надо искать в статьях, и даже не в журналах --- там опоздание будет на год, а в препринтах, а самое современное будет опубликовано в постах в блогах).
Но знать о стандартах и публичных документах (типа BoK) с описаниями практик/процессов/методов надо. Ими руководствуется довольно много людей, с которыми вам придётся разговаривать --- и незнание их может быть сочтено профессиональной неграмотностью. Поэтому можно показывать их знание, но совсем необязательно им следовать, вам необязательно воплощать в жизнь старые методы работы из этих стандартов, когда можно сразу воплощать в жизнь современные (state-of-the-art, SoTA) методы. Другое дело, что всегда есть риск взять за основу своей работы какой-нибудь неработающий метод --- но брать стандарт или публичный документ с заведомо неработающим методом будет ещё хуже. Подробней эти «муки выбора в условиях неопределённости» будут разбираться в курсе системного менеджмента, в практике стратегирования.