Основания системной инженерии
09. Сравнение принципов системной инженерии.
У меня есть вот такая табличка.
Здесь есть принципы Хитчинса, принципы Боэма и Lean Principles. В известной мере это очень полезное и интересное сравнение. Люди, занятые в области решения сложных практических задач, связанных с использованием технологий для достижения целей, как бы они ни мыслили, какими бы подходами не пользовались, они в итоге выходят на некоторый набор базовых норм и правил, которые в значительной мере коррелируют друг с другом. Пренебрегая этими правилами [общего в этих принципах], вы возьмете на себя неприемлемый риск.
Если не будет холистического рассмотрения, риски, которые вы на себя возьмете, существенно возрастут. Скажите, пожалуйста: люди, которые не знают, что такое системная инженерия, не идут сверху вниз, не знают о холизме, — есть примеры того, что этими людьми создается, например система вооружения, и она работает? Есть, безусловно. Но при этом риски, которые брались на себя коллективом, были заметно выше, чем в другом случае. При этом я могу через эти риски успешно пройти: риск же не обязан реализоваться. Просто вероятность повышается. Могу сказать иначе: не пользуясь, например, принципом холизма, я приду к ситуации, когда риск недостижения цели будет существенно выше. К примеру, если речь идет о проекте полного жизненного цикла. Если я оцениваю в начале проекта риск, оцениваю в 10 процентов, то в конце он у меня будет 30 процентов. Могу ли я сделать при 30-процентном риске успешный проект? Могу. Могу и при 70-процентном. Но вероятность маленькая.
Системный инженер не гарантирует, что система обязательно будет успешной. Появление системного инженера не гарантирует успеха миссии на Марс. Но появление хорошего системного инженера, заметно снижает риск неудачи этого проекта.
Ведь штука какая: системный инженер не гарантирует, что система будет обязательно успешной. Он не гарантирует, что мы в каком-то смысле лучшим образом организуем работу. Он гарантирует, что при прочих равных условиях риск будет снижен. Появление системного инженера не гарантирует успеха миссии на Марс. Но появление хорошего системного инженера, который занимается проектом «Миссия на Марс» снижает риски неудачи этого проекта, и снижает заметным образом.
Дальше мы можем вернуться к дискуссии. У меня есть личный опыт. Весь мой практический опыт (20-25 лет) это главным образом опыт работы в проектах по заказам оборонки. Так получилось, что некоторые из проектов имели отношение к системам управления ракетами. И вот в связи с одним из таких проектов мы несколько лет тому назад приехали на завод в Подмосковье. Пришли, переговорили с коллегами, пошли смотреть на монтажно-испытательный комплекс, потому что там наши изделия должны были использоваться. Видим: двое седых, один лысый тянут, как бурлаки, тележку с зенитной ракетой для испытаний. Ракета лежит на тележке, и вот они ее тянут в цех. В этом цеху испытательное оборудование. В основном оно не работает, но видно, что одним рабочим местом пользуются. Они туда эту ракету подтягивают и что-то там начинают привязывать. И вот на этом фоне потом мы столкнулись со следующей ситуацией. Нам нужна модель полета ракеты — иначе нашу работу невозможно проводить. А тот человек, который знает модель полета ракеты, он доктором наук стал еще в 70-х годах, не вчера, и даже не позавчера, так вот он говорит:
— Скажите, а вот там какие-то чудаки пришли. Чего они собираются делать?
— Они вот хотят нам испытательный стенд сделать.
— Интересно. И что же это: вы хотите от меня модель полета, да?
— Хотелось бы с Вами поговорить...
— А как они собираются делать? Вы знаете, если писать программу не на Фортране, то ничего сделать нельзя. Они не на Фортране пишут? Тогда я с ними не буду разговаривать.
Всё.
— Скажите, а вот там какие-то чудаки пришли. Чего они собираются делать?
— Они вот хотят нам испытательный стенд сделать.
— Интересно. И что же это: вы хотите от меня модель полета, да?
— Хотелось бы с Вами поговорить...
— А как они собираются делать? Вы знаете, если писать программу не на Фортране, то ничего сделать нельзя. Они не на Фортране пишут? Тогда я с ними не буду разговаривать.
Всё.
Вы знаете, если писать программу не на Фортране, то ничего сделать нельзя. Они не на Фортране пишут? Тогда я не буду с ними разговаривать.
Список литературы
- Poppendieck M., Poppendieck T. Lean software development, an agile toolkit. – Addison Wesley, 2003.