Навигатор лидера

скачать книгу бесплатно


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

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

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

1) Как можно исправить то, что происходит; и

2) Если мы не сможем исправить дроссель, что мне нужно сделать, чтобы не упустить сроки проекта?

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

По смешению вопросов тактики и стратегии программы еще один пример. Во время эксплуатации на серийном изделии произошла авария с разрушением вращающейся части конструкции газотурбинного двигателя. Назначили аварийную комиссию. На заводе был собран совет экспертов отрасли для установления причин разрушения конструкции и выработки мер по искоренению дефекта на изделии. В ходе обсуждения один из приглашенных экспертов высказал мнение, что имеющиеся данные по измерениям напряжений и термометрированию изделия неполны и нужно повторить эксперимент. Некоторые внешние эксперты дружно поддержали его, подразумевая, что наше предприятие возьмет исполнение работ и затраты на себя. Обычно термометрирование (измерение максимальных температур деталей по внутреннему тракту двигателя) совместно с тензометрированием (измерение максимальных рабочих напряжений в ответственных деталях) газотурбинного двигателя на рабочих режимах проводится на наземном испытательном стенде один раз в истории изделия. Так проверяют соответствие использованных при проектировании максимальных расчетных температур и напряжений их действительным значениям. Для эксперимента выделяется отдельный двигатель, который потом приходится списать как непригодный к дальнейшему использованию. Все ответственные детали неподвижной и вращающейся частей изделия препарируют термопарами и тензодатчиками. Сверлят множество отверстий в деталях для прокладки проводов от датчиков. Используют специальное устройство для вывода сигналов от датчиков с вращающихся деталей на пульт управления. На местах, где препарирование не удается организовать, наносят специальные термокраски, меняющие цвет в зависимости от температуры детали. Подготовительные работы занимают около одного года. Затраты включают, кроме стоимости натурного изделия, датчиков и времени работы стенда по программе испытаний, также оплату усилий по препарированию объекта и последующей расшифровке экспериментальных данных. К сожалению, в ходе испытаний часть датчиков обычно выходит из строя, и некоторые результаты измерений приходится восстанавливать расчетным путем с использованием данных по соседним деталям. Все это мгновенно промелькнуло у меня в голове. Попробовал использовать мысленный эксперимент (авторство приписывают известному физику А. Эйнштейну). Я обратился к автору предложения со словами: «Давайте представим, что прошел год с лишним, все работы завершены, уточненные данные получены. На этом столе лежит отчет по результатам работ. Какие выводы по причинам обсуждаемой аварии мы сможем тогда сделать?» Эксперт после небольшой паузы чистосердечно ответил: «Будем думать!» Участники совещания заулыбались, затратный вопрос о программе дополнительного термометрирования был снят с повестки. Для меня вопрос был и тактическим (требовалось оперативно установить причины аварии и принять меры), и стратегическим (неприятно более года находиться в подвешенном состоянии, понимая, что идет серийный выпуск изделий и где-то опять может произойти повторный отказ. Не исключено, что с более тяжелыми последствиями). В итоге конструкторам удалось за месяц с помощью расчетных моделей выявить причину аварии и доработать конструкцию для исключения повторных случаев.

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

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

Каждый холдинг или госкорпорация имеет стратегические планы, сверстанные на основе отраслевых перспективных задач. Проводится ряд обзоров по выработке стратегии. На них собирают руководителей проектов и программ для обсуждения предложений по исследованиям и разработкам в предстоящем цикле бюджетного планирования. Обсуждаются вопросы, какие конкретные программы принесут пользу холдингу или отрасли или повысят конкурентоспособность РФ на мировом рынке. Это могут быть и другие чисто стратегические перспективы. Такие дискуссии сосредоточены на подготовке предложений в инвестиционный комитет корпорации для проверки, рентабельно ли вкладывать средства в разработку этих продуктов и систем.

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

Стратегическое мышление дается нелегко, и его способности необходимо развивать в человеке. Способность мыслить масштабно над решениями, с долгосрочным видением относится в какой-то мере к талантам, доступным для немногих из нас. Однако до вполне приемлемого уровня вы обязаны развить это в себе и при отсутствии врожденного таланта. Это необходимое главным конструкторам качество для достижения успеха. Если вы чувствуете, что вашу способность стратегически мыслить нужно немного улучшить, ищите возможности повлиять на ее развитие. Обучайтесь, читайте, посещайте встречи, подобные предложенным, и найдите способы сделать это самостоятельно. Обучите свой мозг мыслить стратегически, и со временем он начнет это делать. В том числе пересмотрите сцену из замечательного кинофильма «Чапаев», где Василий Иванович проводит летучую презентацию, используя чугунок и картошку, о том, где должен быть командир дивизии в разных ситуациях на поле боя.

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

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

4.2. Охватывать картину в целом

К задаче стратегического осмысления главным конструктором будущих периодов деятельности примыкает еще один аспект. Если вы или ваш ребенок когда-нибудь складывали из фрагментов картинку, вам знакомо чувство перехода разбросанных кусков мозаики в стройное изображение. Глядя на гору картонных кусочков, вы пока не понимаете, как будет выглядеть окончательная картина. Однако на крышке коробки напечатано изображение в собранном виде. Так и у вас перед глазами должна быть интегрированная система в целом, хотя вы видите хаотичный набор компонентов. Лидеры должны быть в центре внимания своей программы или проекта. В программе есть много людей, ответственных за детали. Из них есть несколько, помимо руководителей, ответственных за обеспечение того, чтобы все части собрались вместе для создания желаемой системы. Они гарантируют, что и система спроектирована правильно, и что команда разрабатывает правильную систему. Руководитель технической команды, главный конструктор, должен иметь возможность постоянно концентрироваться на общей картине.

Когда мы разрабатываем системы, они включают множество отдельных частей. Но вместе эти части рассказывают совсем новую историю. В любом проекте элементы могут жить своей собственной жизнью. Вместе все они функционируют коллективно, выполняя целевую роль, сильно отличающуюся от отдельных частей. Также эта система должна работать в определенной окружающей среде и, возможно, интегрироваться с другими системами, которые являются частью большой программы. Как-то мы приехали к заказчику небольшой работы, согласованной устно, и привезли ему первый экземпляр требуемого насоса. Он радостно сказал: «Отлично. Пойдемте попробуем его в вакуумной камере». Мы застыли в немой сцене, потому что про вакуумную камеру услышали впервые. Поэтому общая картина должна жить в вашей голове на протяжении всей жизни вашего проекта.

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

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

Команда программы хочет знать, что их лидеры поддерживают общую картину. Это важная ответственность, к исполнению которой коллективный опыт большинства главных конструкторов должен их подготовить. На очередных испытаниях экспериментального компрессора мне пришлось в нештатной ситуации взять на себя руководство испытаниями и аккуратно вести испытания до момента, когда перегрев подшипников ротора достиг критической величины. Важные данные были вовремя представлены иностранному заказчику, стенд остался неповрежденным, хотя материальная часть потребовала длительного ремонта. Позже, работая над программой с ГК «Росатом», часто в ходе аудитов на объектах я ставил в тупик дежурных вопросом, где аварийные инструкции, излагающие взгляд на проблему в целом при ее возникновении? Обычно отвечали, что есть номер телефона, куда звонить в экстренных ситуациях. В авиационной промышленности всегда было законом, что такие инструкции нужно написать и выучить заранее участникам работ по принадлежности. Ведь не каждый сможет внятно объяснить при аварии, что происходит, когда время крайне дорого. Да и тому, кому будут звонить, сложно сориентироваться в ситуации, когда часто счет идет на секунды. На испытательных стендах по двигателям такие инструкции всегда были у оператора. Поэтому, например, в моей практике были несколько раз снижены аварийные последствия: при возникновении пожара в ходе испытаний изделия и во время испытаний камеры сгорания. Во втором случае позже оказалось, что виноват производственный брак, изготовитель произвел несанкционированную замену материала.

Главному конструктору проекта, находящегося в стадии разработки, предстоит управлять, определяя приоритеты многих значительных технических проблем, которые постоянно возникают. У большинства разрабатываемых проектов есть основные и второстепенные цели. Задокументированы ключевые требования к параметрам для достижения максимальной эффективности. Вам, как руководителю инженерной команды, нужно будет поддерживать эти цели и требования на протяжении всей деятельности. Эту важную часть вашей работы не получится делегировать, но есть варианты облечения части вопросов. Большую помощь в контроле управленческого процесса вам окажет еженедельно обновляемый менеджером перечень текущих задач проекта для исполнения open items list, который обычно ведут в формате электронных таблиц. Например, по результатам очередного оперативного совещания американский менеджер при мне за полчаса оформил протокол с перечнем четырех десятков очередных задач с датами исполнения и указанием ответственных по пунктам. Включены все открытые для решения текущие вопросы. Такие перечни легко поручить контролировать помощникам. Позже в европейской компании мне показали аналогичный протокол и гордо отметили, что сюда вошли все главные задачи ближайшего месяца. На мой вопрос, как они собираются контролировать исполнение второстепенных задач, которых наверняка гораздо больше, последовало красноречивое молчание. Ведь их тоже нужно выполнять и отслеживать.

В предисловии к книге К. Вуд «Проектирование самолетов» (русский перевод 1940 г.) автор описал неразбериху при создании самолета, если бы проектированием командовали специалисты разных направлений. Этот юмористический взгляд на дисциплину командной работы предостерегает, что может случиться, если никто не смотрит на систему в целом.

Работа главного конструктора заключается в том, чтобы всегда иметь общую картину с собой, куда бы вы ни пошли, и ежедневно обращаться к ней. Часто просят оценить улучшения по проекту и принять технические решения с несколькими вариантами. Каждый вариант может содержать ряд плюсов и минусов. Каждый выбор, вероятно, будет включать и преимущества, и недостатки. Какой путь выбрать? Конечно, каждое решение уникально и должно пониматься в контексте задаваемого вопроса. Однако каждая сделка и каждый выбор приводят к необходимости решений, принимаемых на пути к верхнему системному уровню, характеризуемому удерживаемым вами видом системы в целом. Если вы не будете осторожны, можно легко потерять эту общую картину. В [6] показана практика отслеживания количественных технических показателей эффективности (ПЭ), которая помогает контролировать достижение желаемых характеристик подсистем или компонентов. Например, в типовом техническом задании на разработку нового самолета может быть записано несколько тысяч единичных требований. Сокращенные выборки ПЭ проще контролировать для установления и отслеживания целей. Этого достаточно для информации, достигает ли система основных целей или отклоняется от них. Масса летательного аппарата является важным базовым ПЭ для авиационной и космической техники. Аналогично можно контролировать различные показатели, например дальность полета, грузоподъемность, скорость крейсерского полета, уровень производимого шума на местности и любые другие технические параметры. Контролируя ПЭ, главный конструктор и технические лидеры на протяжении всего процесса проектирования могут следить за характеристикой компонента (аналитической или измеренной), оценивая его способность выполнять поставленные задачи.

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

В некоторых случаях ПЭ могут жить собственной жизнью и мы можем потерять общую цель ради отдельных деревьев. В стандартной схеме «светофорного» табло, которое сейчас часто используют менеджеры, ПЭ должны быть показаны разным цветом (зеленым, желтым или красным) для упрощенного контроля того рубежа, когда ПЭ станет серьезной проблемой. Цвет зависит от заданных пороговых значений величин. Вы должны убедиться, что система в целом может выполнять свою миссию, и это иногда может противоречить исправлению любого отдельного ПЭ. Бывает, что при решении одной проблемы вы фактически создаете другую проблему на уровне интегрированной системы. Например, в программе по созданию авиадвигателя во времена СССР было порядка 15 ПЭ по таким вопросам, как расход воздуха на входе, эффективность узлов, уровень температуры газа перед турбиной, время раскрутки роторов двигателя с «малого газа» до «максимального режима» и другие параметры. ПЭ отслеживались на предмет соответствия заданию каждый раз, когда конфигурация изделия обновлялась в процессе разработки. Обсуждались вопросы, которые в современной терминологии звучали бы так: «В какой момент этот ПЭ переключается с зеленого на желтый? При каком уровне запаса ПЭ будет считаться невыполненным и нужно пересмотреть требования?» По ходу программы часть ПЭ были зелеными, несколько – желтыми. Один ПЭ по ходу программы оказался красным. Жизненно важный уровень тяги двигателя на максимальном режиме оказался ниже заданного для применения на самолете значения. Этот красный сигнал для тяги стал источником существенных доработок двигателя в сторону ее увеличения. При этом параметры ряда других ПЭ пришлось снижать для оптимизации системы. Все взаимосвязано, и даже в общей картине есть свои приоритеты. Лидер программы сохранил свою точку зрения на системном уровне. Он использовал процесс, в котором любое предлагаемое решение для устранения проблемы «красных» ПЭ запускалось через верх руководства. Успех этого проекта был связан с производительностью на уровне системы. Да, вам нужно исправить некоторые ПЭ, чтобы летать безопасно и успешно, однако производство двигателя, который соответствовал бы почти всем ПЭ, но не выполнял свою основную функцию (создание нужной тяги для самолета), было бы поражением. В итоге двигатель получился и много лет успешно эксплуатируется у нас в стране и за рубежом.

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

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

Итак, концепция операций, материалы эскизного проекта, ПЭ, требования по надежности и ремонтопригодности, ограничения и лимиты – все это может быть полезно для главного конструктора при создании общего видения системы. Перечисленные продукты, материалы, документы и тому подобное не закрывают вопрос целиком. Общее видение можно уточнить путем обсуждений с менеджером проекта, сертификационными органами, встречами с заинтересованными сторонами. Хотя каждая деталь этих разговоров не всегда может быть задокументирована, главный конструктор может использовать полученную информацию, чтобы сформировать в своем сознании качественную картину общего видения задачи. В том числе на практике часто возникают задачи сравнения вашей будущей системы и конкурентной. Перечень основных ПЭ может, например, включать 50 позиций. При сравнении часто получается, что примерно по 25 ПЭ у каждой из двух систем лучше. Тогда приходится углубиться в детальный анализ с приоритизацией параметров, чтобы понять основные цели создания вашего конкурентоспособного продукта. Пример из этой же серии. Часто встречается, что ваш сотрудник радостно доложил об успешном решении какой-то конкретной задачи. В таких случаях я обычно брал в руки лист бумаги и спрашивал: «Представим, что лист изображает вашу часть работы в целом. Выполненная веха завершила всю работу над задачей на 100%? Или она составляет 50%? Или 1% от вашей общей задачи?» Подобным образом вы ориентируете команду на то, чтобы они тоже держали перед глазами общую цель программы и свои локальные части. При этом следует предпочитать постановку сложных, но выполнимых целей для себя, отдельных членов команды, тематических групп и команд в целом.

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

4.3. Быть главным техническим интегратором

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

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

Этот процесс обычно обеспечивают с помощью ряда ключевых факторов.

1. Четкое представление системы в целом

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

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

2. Знание интерфейсов системы

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

3. Возможность идти на уступки в решении

пограничных вопросов

Ответственность за конструкцию обычно распределяется по дисциплинам, и можно ожидать, что каждый владелец расставит приоритеты в своей области. Главному конструктору приходится регулярно делать выбор между мнениями и позициями. Этот выбор не всегда прост, поскольку обе стороны спора могут иметь веские обоснования для своего решения. Иногда просто нет хорошего решения, но решение все равно необходимо. Эти вопросы будут возникать у главного конструктора еженедельно, и ожидается, что он будет принимать решения. Его основная цель – интегрировать успешную в целом систему. Некоторые из решений могут потребовать уступок в определенных областях. На некоторые из этих уступок можно легко согласиться, другие могут потребовать снижения каких-то параметров системы, полностью или частично. Для выполнения функций интегратора необходима ответственность, чтобы пойти на эти уступки, сохраняя системное видение. Однажды в процессе испытаний авиадвигателя была отмечена плохая работа камеры сгорания. Руководитель подразделения разнес в массы мысль, что это происходит из-за непредусмотренного скоса потока воздуха, поступающего в камеру сгорания из компрессора, расположенного выше по потоку. Как водится, отдел компрессора возглавлял другой руководитель. Двигатель разобрали для осмотра деталей. Стало видно, что на масляной пленке по корпусам в месте стыковки компрессора и камеры сгорания остались следы идеально осевого потока. Сказка закончилась, пришлось перейти к обсуждению более правдоподобных гипотез.

4. Общение на всех уровнях

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

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

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

На рисунке 3 фотография автора на испытаниях инновационной авариестойкой топливной системы вертолета. Подробности можно найти в [7].

Рис. 3. На испытаниях топливной системы

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

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

Регулярные обсуждения вопросов интеграции с командой могут быть бесценными с точки зрения понимания комплексных характеристик системы и выявления препятствий, которые могут помешать штатному функционированию. В ходе обсуждения технических команд часто бывает, что владелец компонента или подсистемы, которая не обсуждается, заявляет: «Стоп, это не пойдет. Моя часть системы не может работать таким образом!» Эти открытия не всегда идентифицируются с помощью требований или технической документации; иногда их удается выявить на основе опыта и знаний экспертов по дисциплинам, и эффективное общение наилучшим образом поможет вам. После того как вы получили подтверждение проблемы, вам нужно будет решить, как это исправить.

На начальном этапе инженерной деятельности мне довелось принимать участие в разработке двигателя Р79—300 для первого в мире сверхзвукового самолета вертикального взлета и посадки Як-141. Сложнейшей задачей программы было обеспечение режима «висения» самолета при вертикальном взлете. На этом режиме скоростной напор воздуха отсутствует, крылья не поддерживают аппарат и балансировка самолета в воздухе достигалась струйными рулями. Они работали за счет автоматически регулируемого отбора воздуха из компрессора и перенаправления его по четырем магистралям на концы крыльев, в нос и к хвосту фюзеляжа. Количество отбираемого воздуха за доли секунды менялось от 0 до 100%, при этом двигатель не должен был попадать в помпажный режим. Для отработки динамических процессов на предприятии был построен натурный стенд с двигателем, воздуховодами и быстродействующими клапанами. Я участвовал в цикле проводимых лабораторных испытаний. На основе информации по испытаниям мы смогли оптимизировать алгоритмы функционирования системы. Интеграция была выполнена в лучшем виде. Опытный самолет успешно прошел летные испытания.

Неприятная задержка произошла при разработке самого большого пассажирского самолета Airbus А-380. В ходе работ ИТ-подразделение фирмы организовало переход инженерного программного обеспечения от версии Catia V4 к новой Catia V5. Завод, где велось проектирование и производство электрокабелей, работал на версии V4, поэтому чертежи прокладки кабелей нельзя было проверить на соответствие интеграционным блок-схемам всего самолета, которые были сделаны на версии V5. Когда электрокабели, общая длина которых на самолете составила более 500 километров, доставили для установки на линию конечной сборки, они оказались слишком короткими. В технические условия было внесено изменение, которое не нашло отражения в общих блок-схемах. Эта ошибка в интеграции обошлась компании в миллиарды долларов, включая затраты на повторное производство и задержку сроков поставки готовой продукции. Как следствие этой истории, многие компании ввели у себя правило, что программное обеспечение во время работы над большими проектами обновлять не разрешается.

Еще несколько моментов, требующих регулярного обсуждения на проекте. Главному конструктору следует уделять время вопросам организации взаимодействия между производителями оборудования и поставщиками. Были различные случаи, когда поставщики не понимали требований по оборудованию для своевременной разработки и поставки наилучшего продукта. Также дополнительные проблемы вызывает большая продолжительность жизненного цикла современных программ. За годы работы происходят изменения технологии, устаревание и частое изменение требований. Часто видно, что не на всех этапах программы соблюдается надлежащая дисциплина. Например, из-за отсутствия определения начальных требований к возможностям специальных процессов и процедур производства образцов. На эффективности общения сказывается наличие слишком многих линий связи и уровней отчетности. В число контролеров входят руководители программ, руководители высшего звена, структуры госкорпорации. На госконтрактах добавляются руководители отделов закупок, технологий и материально-технического обеспечения представителей заказчика.

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

4.4. Презентовать проект заинтересованным лицам

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

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

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

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

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

Чтобы адекватно представить точки зрения и проблемы членов команды, нужно было проводить часть времени один на один с людьми, которых я представлял. Такой подход приносил обоюдную выгоду. Я понимал суть проблемы и ее последствия в достаточной степени, чтобы представлять организацию, а также вселял в коллег уверенность в том, что я поступлю так же. В качестве побочного преимущества между нами возникало доверие. Моя защита на верхних уровнях позволяла им расти, не опасаясь ошибок. В своих инженерных центрах неоднократно приходилось объяснять руководителям среднего звена необходимость регулярных (квартальных, полугодовых) бесед с подчиненными. Те искренне не понимали, зачем это нужно, если они общаются со своими сотрудниками ежедневно. Терпеливо пояснял, что сотрудник в спокойной беседе должен иметь возможность задать свои вопросы. Выяснить, какие стороны своей деятельности ему следует развивать, обсудить, как ему можно расширить круг своих рабочих интересов, или поговорить о перспективных темах для кандидатской диссертации и др. Там же всплывают не озвученные формально технические проблемы проекта, сомнения по поводу принимаемых решений и много другой полезной руководителю информации. Это разительно отличается от текущего ежедневного общения в горячке продвижения запаздывающих задач и очередных требований вышестоящих начальников.

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

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

Когда этот документ находился на подписании у первых лиц, некоторые наши пункты были истолкованы как моя личная ограниченная точка зрения. Хотя на самом деле они были получены в результате группового обсуждения. Такого поворота я не ожидал. Это была очередная крупица опыта обучения. Сегодня, столкнувшись с тем же набором обстоятельств, я спрашиваю себя, поступил бы я по-другому. Ответ в том, что у меня повторно было бы желание действовать в качестве защитника от имени команды и представлять команду в продвижении конструктивной критики организации. Работа по защите тех, кто не может говорить на этом уровне, жизненно важна. Я горд тем, что я продвинул эти предложения от имени команды и смог быть их голосом.

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

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

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

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

Важно, что когда вы являетесь голосом многих, вам необходимо понимать, что вы говорите. Не обязательно быть экспертом в этом вопросе, но вы должны обладать достаточным пониманием, чтобы быть эффективным защитником. Это может показаться очевидным, но не всегда об этом помнят. В свое время мы исполняли контракты по газовым турбинам для компании General Electric. В кризис 1998 г. удалось набрать средств только на один авиабилет до США. Пришлось мне одному лететь в Гринвилл, штат Южная Каролина, для доклада по комплексной работе, где участвовало пять специалистов разных профилей (прочнисты, газодинамики, тепловики). Я отвечал на вопросы по работе примерно четыре часа. Через два часа после начала в комнате, кроме полутора десятков инженеров, появился еще один человек. Далее беседа пошла интересно. Очередной американец задавал вопрос, я поворачивался к собеседнику для ответа, а тот меня обращал отвечать ко вновь пришедшему. В конце сам пришелец задал несколько вопросов, затем сказал, что у него вопросов больше нет, и исчез. На визитке было написано «Том Фаррел, General Electric» и телефон. Ни позиции, ни названия подразделения. Я спросил: «Наша работа принята?» Мне ответили, что услышанная фраза от г-на Фаррела есть наивысшая возможная похвала выполненной нами работе и они готовы оформить акты о сдаче-приемке работ. Конечно, перед визитом я потратил полных два дня на беседы с исполнителями работ, чтобы не опростоволоситься перед таким заказчиком.

Свою профессиональную деятельность я начинал в авиадвигателестроении. Поэтому мои знания и знакомство с проектами первые три десятка лет были по своей сути высококвалифицированными и регулярно обновляемыми на современном уровне. Придя на работу в инженерный центр ECAR, мне пришлось добирать обучение для овладения отдельными вопросами проектирования самолетов. Нельзя было ударить лицом в грязь перед коллективом и руководством. Позже я оказался в силу житейских обстоятельств в программе, совместной с ГК «Росатом». Некоторые вопросы сначала были для меня проблемными. Опять пришлось уделить много времени обучению. Вернувшись в авиацию, получил назначение на роль директора Центра проектирования (главного конструктора) АО «Технодинамика», где велась разработка 18 самолетных систем. Одновременно действовали более 100 контрактов ОКР, каждый со своими уникальными техническими, календарными или бюджетными проблемами, и все они требовали ежемесячной отчетности. В этом лабиринте систем я почти ни в чем не был экспертом. Однако, благодаря предыдущему разнообразному опыту, достаточно быстро дозрел до уровня квалифицированного руководства работой коллектива из почти 600 человек. Параллельно пришлось налаживать организационные вопросы функционирования инфраструктуры распределенного конструкторского бюро, расположившегося в 5 городах на 8 площадках. Обходя по утрам рабочие залы, участвуя в технических совещаниях, держал руку на пульсе текущих событий и мог доложить вышестоящему руководству детали работ, проблемы и предлагаемые пути решения. Вспоминается один забавный эпизод. С учетом скудости штата опытных сотрудников я предложил коллегам объединить два отдела, один по гидравлическим системам, другой по топливным. Было бы удобнее использовать опытных экспертов по обоим направлениям. Начальник второго отдела азартно стал доказывать мне, что это совершенно разные области деятельности и объединение не пойдет на пользу. Мне же казалось на основе прошлого опыта работы с этими системами на газотурбинных двигателях, что в методологии и подходах есть много общего. Там и там течение несжимаемых жидкостей. Основное отличие в том, что системы используют разные уровни рабочего давления. В гидравлике насосы качают жидкость с давлением 210 атмосфер, тогда как в топливных системах используют давление не выше 40 атмосфер. Но это всего лишь вопрос задания исходных данных при проектировании, не более того. Дискуссию пришлось отложить, и мне случайно пришла в голову мысль освежить анкету главного спорщика. В анкете я прочитал, что ярко споривший начальник отдела топливных систем ранее имел приличный опыт работы именно в отделе гидравлических устройств. Как я и предполагал, различия между системами оказались некритичными. После ее изучения я вновь собрал двух руководителей и объявил решение об объединении состоявшимся.

Потребовалось установить для себя высокую планку на выступлениях. Многие ораторы моего уровня просто читали слова на слайдах презентации почти дословно, что аудитория могла бы сделать самостоятельно. Я считал нужным объяснить предысторию и контекст слайдов, чтобы в зале были понятны проблемы и позиция главного конструктора. За несколько дней до совещания нужно было вычитать слайды, выделить детали, которые имели отношение к нашим техническим проблемам и на которых мне нужно было сосредоточиться во время презентации. Записывал вопросы по тем пунктам, которые мне нужно было прояснить, и лакомые технические детали, которые, по моему мнению, уместны для понимания аудитории. В ходе презентации мне обычно удавалось иметь достаточно высокий уровень понимания обсуждаемых вопросов, чтобы излагать их в разговорной форме. На этом этапе карьеры я не был экспертом ни в одной из отдельных задач. У меня не было личного опыта в решении проблем, но я мог объяснить их так, что аудитория обретала такое же базовое понимание, как и я. Это работало очень хорошо. Конечно, помогал доставшийся от родителей в наследство талант скорочтения. Например, однажды в АО «Технодинамика» мне принесли итоговый отчет по контракту объемом около 700 страниц. Пролистав его, я обнаружил ужасную смесь из прошлых отчетов, подобранную в случайном порядке и производившую впечатление набора макулатуры. Пришлось посмотреть в текст контракта, освежить в памяти техническое задание на работу. После чего примерно за два часа лично реструктурировал принесенный отчет и вернул его руководителю работ, попросив перепечатать страничку оглавления по факту. Изучив документ, он спросил: «Скажите, пожалуйста, а где вы это взяли?» Из кучи бумажного мусора был сформирован внятный документ, соответствовавший требованиям заказчика. Конечно, можно было озадачить исполнителя, но срок сдачи затянули, время поджимало, пришлось ограничиться мастер-классом.

Помните, что главные конструкторы представляют команды. Быть голосом многих ответственно и почетно, это приносит огромное удовлетворение.