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

Хорошие требования к системе или продукту должны быть:

a) специфичными, т.е. отражать только один аспект конструкции или характеристик системы, и должны быть выражены в терминах необходимости (что и как хорошо), а не решений (как);

b) измеримы, т.е. характеристика выражается объективно и количественно (например, точное требование, указывающее температуру детали в градусах, может быть проверено при испытании);

c) достижимы, т.е. технически реализуемы при доступных затратах;

d) соответствовать указанному уровню подсистемы (например, требование наличия солнечных батарей спутника не входит в уровень требований ракеты-носителя, а только в требования для подсистемы полезного груза);

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

Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует «избегать» в тексте требований:

1) хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;

2) «лазеек», таких как «если это необходимо», поскольку они делают требование бесполезным;

3) помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;

4) рассуждений и нечетких слов («обычно», «в основном», «часто», «нормально», «типично»);

5) использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);

6) принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).

Приведем несколько примеров требований, с точки зрения того, хорошо ли они изложены.

•Самолет должен иметь три двигателя (исходное требование для DC-3). Позже выяснилось, что самолет должен отвечать требованиям эксплуатации при отказе одного двигателя.

• Разработчики смартфонов ставили своей целью улучшить технику для телефонных звонков. Однако пользователи стали выбирать смартфоны по опции связи и мультимедиа в мессенджерах и качеству снимков фотокамеры, т.е. по ранее вспомогательным критериям.

• После проектирования системы пожаротушения в Таганском туннеле 3-го транспортного кольца Москвы было проведено ее опробование. Оказалось, что после срабатывания системы огонь успешно ликвидируется, но восстановить движение по туннелю невозможно, так как пену нечем удалять (рис. 9). Видимо, предполагалось, что она будет сливаться в водостоки. Пришлось вносить в систему доработки.

На практике нередко встречаются отклонения от требований. Для дальнейшего продвижения в проекте необходимо указать причины отклонений. Как правило, это следствие отсутствия части информации. В документах встречаются места, оставленные для заполнения в дальнейшем. В документах на английском языке используют пометки типа TBA (to be agreed – необходимо согласовать), TBC (to be complete – необходимо завершить), TBD (to be decided – необходимо принять решение). Однако при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен. Важно знать при формулировке раздела требований в англоязычных контрактах, что слово «Compliance» является единственным вариантом подтверждения строгого соответствия исполнителя требованиям контракта.

Рис. 9. Срабатывание системы пожаротушения

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

Валидация требований часто входит в один из этапов ворот принятия решений. Проверка требования включает четыре типовых вопроса.

•Правильная ли сформулирована проблема?

• Смогли ли указанные требования отразить проблему?

• Верно ли сформулированы эти требования?

• Соответствуют ли требования установленным границам системы и ограничениям?

В процессе валидации требуется проверить, что системные требования полны, непротиворечивы и каждое требование достижимо и проверяемо. Валидацию требований проводят эксперты по конкретным вопросам, организация-разработчик и уполномоченные представители Заказчика.

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

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

Функциональный анализ включает итеративный процесс разбиения требований от уровня системы до подсистем и вниз по иерархической структуре, насколько это необходимо для определения входных критериев проектирования и ограничений для различных элементов системы. Требования верхнего уровня идентифицируют, разделяют на второй и далее уровни вниз до глубины, необходимой для целей определения элементов системы.

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

При оценке каждого функционального требования альтернативы могут включать выбор ПКИ, количество различных источников поставок, и элементы разработки, для которых требуется какая-то новая конструкция.

Функциональный анализ, в частности, формирует основу для разработки:

a) электрического и механического проектирования компонентов мониторинга состояния и средств диагностики;

b) моделей надежности;

c) анализа характера, последствий и критичности отказов;

d) анализа технического обслуживания, ориентированного на надежность;

e) анализа ремонтопригодности;

f) анализа человеческого фактора;

g) анализа безопасности и рисков системы;

h) логистического анализа (анализа цепочки поставок).

2.5. Принятие проектных решений

Следующим этапом процесса разработки является синтез системы, в ходе которого конструктор переводит функциональную архитектуру системы в физическую. Процесс сопровождается принятием множества проектных решений, где конструктор должен проявить как творческую сторону деятельности, так и профессиональный прагматизм. Термин сбалансированное решение означает, что проведено обсуждение общих рисков системы, стоимости, технической зрелости и надежности для каждой комбинации подсистем.

Основные принципы проектирования изделий можно свести к краткому перечню.

•Лучше продвигаться по проекту, имея несколько «сомнительных» решений, чем опоздать с решениями в поисках «совершенного» варианта. Лучшее – враг хорошего.

• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски и стоимость и обеспечить легкую реализацию и эксплуатацию.

• Излишние опции в проекте должны быть определены на ранней стадии (и удалены из целей системы), при этом влияние на характеристики продукта, вытекающие из осуществления этих опций, должно быть понятным.

• В проекте обязательны независимые обзоры промежуточных результатов для всестороннего обсуждения вопросов разработки.

Важно принимать во внимание информацию о том, что основные затраты на этапе разработки связаны с передачей в производство образцов и закупками ПКИ, тогда как уровень этих затрат определяется на раннем этапе, при разработке конструкторской документации. Т.е. принятые на ранней стадии решения являются ключевыми и определяют стоимость программы на последующих этапах ЖЦ.

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

1) использовать модели для проектирования систем;

2) использовать иерархический дизайн сверху вниз;

3) сначала выполняется работа с высокорисковыми компонентами;

4) конструировать минимум интерфейсов, разделяя их на механические, электрические, программные;

5) применять в альтернативах проекта удовлетворительные конструкции;

6) рекомендуется не проводить оптимизации на ранней стадии работ, пока нет уверенности, что база оптимизации выбрана достаточно обоснованно;

7) свои ошибки нужно находить самим, т.е. определить, что не так в очередном варианте;

8) полезно перечислить функциональные требования в случае использования системы;

9) выделить каждую функцию для только одного компонента;

10) категорически нельзя использовать недокументированные функции;

11) полезно применять быстрое прототипирование (варианты аддитивных технологий);

12) разрабатывать несколько итераций и сразу тестировать результат;

13) создавать библиотеки повторно используемых субъектов;

14) написать глоссарий соответствующих терминов;

15) удобно использовать создание конструктивных резервов (запасы);

16) следует проектировать компоненты с возможностью тестирования;

17) выполнять анализ чувствительности конструкции для альтернативных вариантов;

18) изменять поведение людей в команде для достижения результата.

Процесс определения проектного решения используется для перевода требований высокого уровня, полученных от ожиданий заинтересованных сторон, и результатов логического процесса декомпозиции в реализуемое решение. Производные технические требования используют для выбора альтернативных решений. Затем эти альтернативные решения анализируют для определения предпочтительной альтернативы. Выбранная альтернатива служит базой конечного проектного решения, которое удовлетворяет техническим требованиям.

Процесс принятия системного решения является совместным, итеративным и основанным на ценностях, который можно применять на любой стадии жизненного цикла системы для максимизации вероятности успеха.

Можно выделить несколько присущих характеристик процесса.

• Процесс решения охватывает динамический поток работ по проектированию системы и эволюцию ее состояния, начиная с текущего статуса (как есть) и заканчивая системой, которая приносит пользу заинтересованным сторонам (как должно быть).

• Этот совместный процесс фокусируется на ценности, потребностях и целях заинтересованных сторон и лиц, принимающих решения (ЛПР), обеспокоенных ценностью, предоставляемой системой. Заинтересованные стороны и ЛПР определяют важные функции, цели, требования (критерии отбора, которым должны соответствовать все потенциальные решения) и ограничения.

• Процесс принятия решения состоит из четырех последовательных этапов (определение проблемы, разработка, принятие и реализация решения), которые охватывают системное мышление и применяют проверенные подходы к системному проектированию, как правило, посредством итераций.

• Самая важная задача в любом процессе принятия системных решений: идентифицировать и понять проблему, которая определяется пониманием задач, целей и ограничений от ЛПР и заинтересованных сторон.

• Целевым для процесса является создание ценности (моделирование, генерация идей и усовершенствование вариантов) в дополнение к оценке и анализу чувствительности альтернатив. Ценности должны быть движущей силой принятия проектных решений для оценки фактических или потенциальных последствий действий и бездействия, предлагаемых альтернатив и решений.

Например, процесс принятия решения технической проблемы появления дефекта рекомендуется продвигать по следующим шагам:

1) наблюдаемые симптомы;

2) определение проблемы;

3) целевой результат;

4) анализ основной причины;

5) количество компонентов в эксплуатации;

6) частота отказов среди этих компонентов;

7) происходит ли сбой равномерно по всей совокупности или он связан с конкретной партией изделий;

8) связан ли отказ с конкретным пользователем или рабочим циклом;

9) предлагаемое решение;

10) план действий;

11) результаты плана действий;

12) подтверждение решения;

13) уроки на будущее.

Такой организованный подход к решению помогает участникам обсуждения, в том числе более опытным, внести свой вклад. В литературе существует большое количество рекомендаций по подобным алгоритмам принятия решений.

Вовлекаемый в процесс выработки решений опытный критический мыслитель должен обладать следующими качествами:

a) поднимает важные вопросы и проблемы, формулируя их четко и ясно;

b) собирает и оценивает соответствующую информацию, используя абстрактные идеи и объективные данные для ее эффективной интерпретации;

c) приходит к обоснованным выводам и решениям, проверяя их на соответствие заданным критериям и стандартам;

d) думает непредвзято в рамках альтернативных систем мышления, признавая и оценивая, при необходимости, их предположения и практические последствия;

e) эффективно общается с другими коллегами, находя решения сложных проблем;

f) осознает человеческие ошибки при принятии решений и компетентен в использовании статистических методов для получения обоснованных выводов.

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

Одной из основных задач при разработке системы является принятие решений по архитектуре системы. Лицо, принимающее решения (ЛПР), поставленное в ситуацию, когда решение необходимо принять, должно всегда выбирать, основываясь на явных или скрытых критериях оценки этого решения, то есть сознательный и обдуманный выбор критериев является жизненно важным в процессе принятия решения. Обязанностью ЛПР является получение согласованных решений проекта на этапе их принятия с учетом того, что все участники процесса имеют отличающиеся приоритетные цели в программе. При этом следует помнить, что в инженерных задачах возможно, как правило, наличие двух и более вариантов решения.

При принятии проектных решений следует начинать с выбора критериев оценки влияния решений на ход реализации проекта:

•когда решение связано с умеренным или высоким риском по результату;

• когда решение влияет на управление конфигурацией;

• когда результат решения может привести к значительным задержкам графика работ;

• когда результат решения может привести к значительным перерасходам;

• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости ПКИ.

Следует принимать во внимание, что каждое конкретное решение имеет свою «стоимость» в части объема затрат на реализацию. Схематично можно выделить четыре фазы зависимости «характеристика – ресурсы» (рис. 10). Здесь под стоимостью понимаются затраты любого ресурса (не только финансового).

Рис. 10. Кривая «стоимости» проектных решений

A. Рост характеристики от 0 до 1 дает ее заметное улучшение при минимуме затрат ресурса.

B. Рост характеристики 1—2 обеспечивает эквивалентный прирост характеристики на единицу затрат.

C. В приросте характеристики от 2 до 3 заметные затраты приводят к некоторому улучшению характеристики, но процесс сопровождается увеличением риска.

D. Рост характеристики выше 3 уровня показывает, что там невозможно получить улучшение характеристики при любом вложении ресурса.

Выбор набора базовых проектных решений, например, в компании Airbus выделен в отдельный этап и может длиться от 3 месяцев до 1,5 лет. В процессе участвуют эксплуатационники, конструкторы, технологи, производственники, закупщики, риск-разделенные партнеры. В ходе этапа проводится принятие базовых решений по выделенному перечню концептуальных мест проекта, составляют соглашения об используемых в программе инструментах, формате данных, требований, критериев, коммуникации и др. Этот руководящий документ служит защитой от принятия отдельными участниками ошибочных легковесных решений на этапах.

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

При переходе от уровня к уровню по зрелости частных решений также идет сужение масштабов решений от системы в целом к деталям и компонентам (рис. 11).

Рис. 11. Схема реализации проектных решений

Общий процесс системного решения необходимо адаптировать к системе, решению и этапу жизненного цикла системы. Для достижения нужного качества решения полезно следовать нескольким принципам.

• При формировании будущего решения нужно учитывать масштаб проблемы и все потребности заинтересованных сторон.

• Следует выбирать творческие и осуществимые решения, которые создают ценность для заинтересованных сторон и лиц, принимающих решения.

• Значимые данные, используемые для генерации и оценки возможных решений, должны быть обоснованными, понятными и заслуживающими доверия.

• Для генерации и оценки решений необходимо провести анализ компромиссов между системными требованиями, показателями ценности и ресурсами.

• Реализация решения является одним из самых сложных этапов процесса. Для этого необходимо выявить и устранить препятствия и риски. Избегать искушения слишком поспешного выбора решения. Критически важным для принятия системных решений является учет окружающей среды, ее факторов (технологических, безопасности, экологии и экономики) и взаимодействующих систем, в которой работает продукт или система.

При принятии решений проекта важно точно формулировать цели и объемы их исполнения. При работе с европейскими авиастроителями нашей команде был предложен проект переделки списанных пассажирских самолетов в грузовые. Исходный самолет был спроектирован в бумажных чертежах, а новые чертежи нужно было делать в электронном виде. Попытки оформить предложения по правилам выпуска новой документации в проекте (для минимизации переделки серийных деталей старой конструкции) не были услышаны. Заказчики потребовали при наличии сопряжений между старой и новой деталью оцифровывать их обе. При этом формально появлялась новая деталь для конструктора и для производства. В итоге контракт был подписан на доработку по трудоемкости 30% конструкции, а по факту получилась переделка планера на 70%. Пришлось оформлять соглашение о частичной компенсации затрат на дополнительные работы. В принятии неверного решения были виновны обе стороны. Заказчики ошибочно оценили допущения по технике предлагаемых работ и выделенный бюджет, у исполнителя не получилось внятно и вовремя донести опасения до партнеров.

Процесс принятия решений может включать следующие этапы.

1. Определение альтернативных решений для проектирования. Если они определены и полностью понятны, тогда выбор можно сделать с уверенностью. Процесс должен обеспечить наиболее функциональную, безопасную и экономичную конечную систему, в границах графика проекта. Следует оценить зрелость требуемой технологии и ожидания заинтересованных сторон для эффективной эксплуатации.

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

3. Анализ альтернативных проектных решений. Далее техническая группа анализирует, насколько хорошо каждая из альтернатив проекта соответствует целям системы (технологическая зрелость, эффективность, техническая достижимость, производительность, стоимость, и риск). Эта оценка осуществляется с помощью маркетинговых исследований. Следует оценить эти альтернативы с точки зрения стоимости ЖЦ системы. Для определения количественных параметров полезны математические модели. Выбранные альтернативы ранжируют в соответствии с установленными критериями отбора. Стоимость всегда является ограничивающим фактором. Однако также важны такие критерии, как время разработки, риск и надежность. Полезно оценить возможности выбора инструментов проекта и поставщиков.

4. Выбор лучшей проектной альтернативы. Эксперты выбирают лучшее решение из альтернативных концепций дизайна, принимая во внимание субъективные факторы, которые команда не могла определить количественно, например надежность. Важны также оценки того, насколько эти альтернативы соответствуют количественным требованиям: эффективности, стоимости, графику, рискам или другим ограничениям. Процесс анализа принятия решений, который описан в главе 3.9, должен использоваться для оценки альтернативных концепций дизайна и рекомендации наилучшего решения для проектирования.

5. Выбор и верификация решения для проектирования. После выбора предпочтительной альтернативы дизайна определяется окончательное решение, которое будет удовлетворять техническим требованиям и концепции эксплуатации системы. После того как решение было выбрано и задокументировано в пакете технических данных, оно должно быть верифицировано на соответствие системным требованиям и ограничениям. Нужно показать, что удовлетворены требования верхнего уровня и ожидания заинтересованных сторон.

6. Валидация проектного решения. Она отличается усеченной полнотой требований от валидации конечного продукта. Оперативная валидация может включать вопросы.

• Работает ли система так, как ожидалось?

• Как система реагирует на сбои, сбои и аномалии?

• Доступна ли система?

Если ответа на любой из этих вопросов нет, тогда потребуются изменения в проекте и процесс начнется снова.

7. Идентификация обеспечивающих продуктов. Обеспечивающими называют продукты и услуги поддержки жизненного цикла (например, производство, тестирование, развертывание, обучение, обслуживание и утилизация), которые облегчают продвижение и использование конечного продукта в течение его жизненного цикла. Поскольку конечный продукт и его поддерживающие продукты взаимозависимы, они рассматриваются как единая система. Поэтому важной задачей в процессе определения проектного решения является идентификация предоставляемых продуктов и персонала, которые понадобятся в течение жизненного цикла выбранного проектного решения.