[БЕЗ_ЗВУКА] Теперь мы должны разобраться с методами, методологиями. Иногда говорят даже другие слова: процесс разработки, но это означает одно и то же. Итак, метод, методология — это синонимы. Стандарт ISO 24744 особо это подчеркивает. Метод, методология — это синонимы. И означает обычно набор практик жизненного цикла, который достаточен для выполнения какой-то деятельности, широко понимаемой. Например, инженерный метод, метод системной инженерии или методология системной инженерии. Это просто набор каких-то конкретных практик, которых обычно несколько в этом случае, который позволяет достичь этой цели. Например, метод инженерии требований. Это означает, что множество разных практик, которые позволяют полностью сделать все работы, нужные для инженерии требований. И мы, говоря слово «метод» и «методология», сразу понимаем, что там есть какие-то части, есть какие-то отдельные практики. Это какой-то сложный объект. То есть нам его надо как-то описывать более подробно. И в какой форме существует описание методов, описание методологии? Они существуют в виде разных стандартов и корпусов знаний — body of knowledge, которые описывают ту или иную деятельность, как наборы отдельных совершенно практик. Мы знаем, что сегодня многие выпускают вот такие body of knowledge: Systems Engineering Body of Knowledge выпускается, Software Engineering Body of Knowledge, Business Analysis Body of Knowledge, Project Management Body of Knowledge. Все эти PMBoK, SEBoK — это они и есть. Там описывается, что мы должны делать, какие основные понятия предметной области. Но не описывается обычно технология. Это очень важно понять, что мы описываем только с чем мы работаем. Мы описываем, что у нас в голове. Описывается, что нужно делать, но не описываются конкретные материальные объекты, с которыми мы работаем, потому что они же будут каждый раз все продукты рабочие, которые мы используем, уникальны для той или иной организации, для той или иной закупки, которая была сделана в этой организации. Каждый поставщик этой технологии хочет каким-то образом дифференцироваться от других, придумывает даже свои названия. Тем не менее, в этих body of knowledge у нас излагается дисциплина. Конечно, не всегда это body of knowledge, это может быть и просто учебник. Это может быть просто стандарт. Но, мы понимаем, что каждый раз, если у нас есть метод и методология, надо читать, какой тренд. Я сильно буду забегать вперед, но какой основной тренд с методами и методологиями? Если раньше считалось, что вас могут научить какому-то методу, какой-то методологии, для того чтобы вы познакомились подробно с каждой из практик и у вас отлично получилась ваша работа, то есть вы знаете всю работу, которую надо сделать, все методы используете, то сейчас от этого отказываются. И мы работаем на уровне отдельных практик. По большому счету происходит сейчас такой особый период, когда у нас есть «смерть» методологий, «смерть» методов, и мы переходим к обсуждению отдельных практик. А методы и методологии мы используем не в жизни, а методы и методологии мы используем для того, чтобы просто классифицировать как-то практики и рассуждать о них. Например, в жизни вы не будете использовать какую-то конкретную методологию работы с инженерией требований, вы будете брать отдельные, возможно, из разных учебников, практики работы с этими требованиями, но, вас это не должно смущать, потому что мир всё больше и больше становится похожим на Лего. Разные стандарты описывают разные компоненты этого Лего. И дальше в деятельности мы как-то вот эти практики совмещаем. Смотрите, это всё что я говорю, все эти стандарты — это работа с жизненными циклами, которые понимаются во втором поколении, то есть как вид жизненного цикла — это логическая функциональная архитектура деятельности. Это архитектура обеспечивающих систем, подсистем. Это принципиальные схемы деятельности. То есть это неконструктивные объекты, я не говорю тут об управлении работами конкретными, я не говорю о проектном управлении. Я, например, когда говорил, что это Project Management Body of Knowledge, то есть корпус знаний по проектному управлению, я говорю, что это набор практик, то есть то, как мы обычно работаем, а не говорю, что это конкретная работа и нам надо проуправлять сейчас работой. Нет. Это как бы роли, практики — это роли, которые надо выполнить, роли работ, конкретные работы каких-то конкретных людей с конкретными рабочими продуктами потом эти роли должны будут исполнить. То же самое не только к проектному управлению относится, но и к любым другим практикам, например, Software Engineering Body of Knowledge — это то же самое. Это какие вообще работы надо выполнять, для того чтобы работать в программной инженерии. Не сами эти работы, потому что сами работы — это работы, они как бы в реальном мире. Это единство технологии, практики и воплощенная в конкретном экземпляре 4D мира. Это просто работы. И надо помнить, что методы и практики тем самым оказываются иерархичны, то есть у нас есть моделеориентированная системная инженерия и инженерный менеджмент. Мы можем заниматься еще и технологическим предпринимательством. Это вот верхний уровень. Но если мы посмотрим на метод моделеориентированной системной инженерии, или иногда говорят инженерный процесс разработки какой-то (тоже слова такие используются), или на практики моделеориентированной системной инженерии. Сейчас чаще и чаще говорят «практики» вместо слова «метод», чтобы подчеркнуть, что никакого особого единства там нет, что мы можем брать отдельные практики, как-то их сочетать из разных методов, то мы увидим, что там есть внутри моделеориентированная инженерия требований, там есть инженерия системной архитектуры, там есть проверка и приемка, там есть управление конфигурацией. Но, если мы посмотрим, например, моделеориентированную инженерию требований, то там тоже у нас есть множество разных вариантов практик. Например, практика User story, практика User case, то есть пользовательские истории или варианты использования, или Use case 2.0. Use case 2.0 — это то же самое, что Use case, только там отдельный вариант использования — еще и на ломтики, на слайсы делится. И там есть разные, опять же, разные в разнообразии методы целеориентированной инженерии требований и так далее. То есть каждый раз, когда мы смотрим какую-то практику, мы получаем всё больше и больше знаний о мире и можем дробить это знание на мелкие части и углублять его, после чего в жизни использовать весь набор знаний, тем более что часть из них альтернативна. Например, вы можете использовать или для маленьких проектов User story или для более больших проектов Use case, или для agile проектов Use case 2.0, но вы можете использовать их не все вместе, а по одиночке, как-то составляя из них тот набор практик, который лучше всего подойдет для вашей конкретной ситуации. То есть не бывает таких вот методов работы, которые позволят вам работать всегда и везде, в любых условиях для любых проектов. Более того, если вы второй раз будете делать похожую деятельность, то у вас будет уже больше информации, какие риски вам встретятся на вашем нелегком пути разработчика, например, или изготовителя. И вы возьмете другие практики, которые лучше удовлетворяют конкретным условиям, о которых вы сейчас больше знаете. Кроме этого, есть еще практики самого жизненного цикла. То есть есть практики жизненного цикла, которые в нем используются, а есть практики жизненного цикла, которые работают с самим жизненным циклом. Прежде всего, вам надо моделировать жизненный цикл. То есть вы должны выбрать его вид. То есть вы должны иметь практики, которыми вы работаете с тем, как вы работаете с другими практиками, то есть практики, объектами которых являются другие практики, и практики, выстроенные в полный жизненный цикл. Например, архитектура предприятия заставляет вас выбирать разные практики и показывать их в составе предприятия, рисовать принципиальную схему предприятия, а потом рисовать, конечно, не принципиальную схему, а рисовать какую-то модульную диаграмму, например, органиграмму. Выбор методологии разработки, когда вы говорите: вот я, наверное, буду заниматься agile-разработкой (мы буквально через некоторое время познакомимся чуть подробнее с этим понятием). Но когда вы говорите, что мы будем заниматься водопадной разработкой или agile-разработкой, сам этот выбор, вам потребуется практика. И мы буквально через Буквально в следующем уроке мы займемся разбирательством, какие же это бывают практики. А есть еще практики управления жизненным циклом. Это управление конфигурацией и поиск коллизий, то есть мы понимать должны, что каждый раз у нас система целостна, что разные ее части не входят в противоречия друг к другу и нет каких-то коллизий из-за этого. Мы должны управлять изменениями. И вот эти практики, обычно говорится, что это практики жизненного цикла, потому что они обеспечивают связность деятельностей по всему жизненному циклу. Есть и другие практики, например, интеграция данных жизненного цикла. Это означает, что у нас в самых разных точках жизненного цикла, а что такое точки жизненного цикла? Это моменты выполнения разных практик, разных деятельностей, которые мы разрабатываем в нашей системе. У нас в эти моменты появляются данные, и мы должны как-то обеспечить, чтобы эти данные были доступны в ходе выполнения разных работ. Это означает, что, если у нас есть практика 3D-проектирования и мы получаем 3D-модель нашей системы, то мы должны каким-то образом передать в практику проектного управления эту 3D-модель, чтобы каждому объекту в 3D-модели была сопоставлена какая-то работа. Речь идет об интеграции данных жизненного цикла, то есть мы работаем с какими-то практиками, которые работают с жизненным циклом, обеспечивая его целостность, то есть с выбором практик, с обеспечением целостности прохождения работ этих всех практик к тому, чтобы рабочие продукты передавались из одной практики в другую как функциональные объекты, чтобы у нас работа над системой была целостная. Состав этих практик вы можете увидеть в стандарте 15288, если мы говорим о самом верхнем уровне рассмотрения этой иерархии практик. Это стандарт системной инженерии. Он так и называется — практики жизненного цикла системной инженерии. Обратите внимание, что в последнее время слово «процесс» потеряло свою пошаговость исполнения, развертку во времени. В стандарте 15288 вы не найдете последовательности выполнения этих практик, не найдете последовательности шагов внутри практик. Это чисто функциональные процессы, как бы процессы, которые только по названию остались процессами чисто исторически. Раньше говорили про процессы, что это пошаговые алгоритмы выполнения деятельности. Выяснилось, что это полная утопия, и мы должны говорить о деятельностях, функциональных деятельностях, о каких-то ролевых деятельностях, которые мы не знаем, в жизни они, в исполнении, в какой последовательности они будут. Поэтому мы говорим сейчас слово «практики», а не слово «процессы» в переводе. Но в жизни очень часто можно встретить и слово «процессы» примерно так, как используют слово «практики». Но вы видите набор этих практик. Их довольно много. Есть даже такое утверждение, что, если вы выполняете практики, это и есть системная инженерия. Я бы так не сказал. Это избыточный набор практик, если вы выполняете какие-то госконтракты, военные контракты, вам надо выбрать как можно больше дел, под которые можно было бы запросить финансирование. Он очень хороший стандарт, он позволяет сказать, чем бы еще вы могли бы заняться в проекте, что еще бы вы могли сделать, легко обосновать, что вроде бы все это надо. Это полностью противоречит Lean, или экономичным, экономным способам ведения деятельности. И тем не менее этот стандарт я рекомендую, потому что он служит чеклистом. Подумали ли вы все об этих практиках или не подумали в вашей работе? Может быть, есть какие-то практики, которые вам действительно надо бы делать, но вы их не делаете? Они не избыточны, а сущностны будут. Они не для того, чтобы вы могли под них списать какие-то деньги, а для того, чтобы работу реально выполнить. Эти наборы практик очень хороши для такой деятельности. И можете сделать еще упражнение, что вы осознанно делаете в своих предприятиях из там написанного, что вы делаете в ваших учебных проектах из там описанного. Это очень хорошее упражнение. Посмотрите на эту схему. Может быть, вам придут в голову какие-то нетривиальные мысли для вашей работы. Но это инженерные практики. А вот менеджерские методы и практики, они вырастают обычно из смеси инженерных и менеджерских. Agile, например. Сначала это была практика, которая работала и с инженерией, — в программировании, например, там были буквально рекомендации, как работать с кодом, как писать код, — и менеджерские практики, которые иногда на грани менеджерских и инженерных, например, парное программирование — вы должны за одной клавиатурой вдвоем писать текст программы, то есть такие на границе между инженерией и менеджментом работы. А далее, Agile начал все больше и больше заниматься менеджерской стороной вопроса. И практики в больших количествах стали менеджерские, потому что люди которые занимаются Agile, они попросту говорят, что эффективность их работы с менеджерами была выше, чем с инженерами. Они прямо говорят, что инженеры, в общем-то, и сами справлялись. Они сами понимали, как им работать. А менеджеры плохо понимали работу инженеров, и Agile сегодня — это объяснение менеджерам очень часто, это практики как бы менеджерские для того, чтобы облегчить жизнь инженерам. Six Sigma — примерно то же самое, склоняется больше к менеджерским практикам. А начиналась эта практика как производственная. DevOp тоже рассматривается как менеджерская практика вначале, что это разделение труда, каким образом у нас происходит между программистами и администраторами системными. Но DevOp тем не менее склоняется сейчас в инженерную практику, потому что выяснилось, что все это разделение труда, его можно автоматизировать. И по мере автоматизации там больше и больше инженерная составляющая. Есть инженерный менеджер. И такие практики, как немножко уже устаревшая теория ограничений Голдратта, Lean и Lean 2.0. Есть практика проектного управления. То есть мы видим, что огромное количество у нас менеджерских методов и практик, и им тоже надо учиться. Сейчас на эту тему есть множество книг, учебников, стандартов, множество программных продуктов, потому что в крупных предприятиях не люди держат огромные, многотысячные коллективы, а держат, как ни странно, работу, слаженное выполнение работ программные системы, управления конфигурацией и обеспечивающей системы, и целевой системы выполняют у нас, главным образом, технологии. Не голым мозгом люди работают с многотысячными коллективами. И этому тоже надо учиться. Это тоже практики, там тоже есть дисциплины, там тоже есть технологии. И развитие у нас — это постановка новых практик. Она как раз идет от менеджерских практик. Для того чтобы поставить новую практику, вам надо взять откуда-то людей. Для того чтобы поставить практику, вам надо взять какую-то технологию. Это капитальные затраты. И поэтому мы понимаем, что без менеджерских методов, методов практик, дело с места не сдвинется, и это должны делать менеджеры не по наитию, обращу особое внимание.
