Читать книгу Навигатор лидера - Виктор Николенко - Страница 7
Глава 4.
Специальные знания главного конструктора
4.2. Охватывать картину в целом
ОглавлениеК задаче стратегического осмысления главным конструктором будущих периодов деятельности примыкает еще один аспект. Если вы или ваш ребенок когда-нибудь складывали из фрагментов картинку, вам знакомо чувство перехода разбросанных кусков мозаики в стройное изображение. Глядя на гору картонных кусочков, вы пока не понимаете, как будет выглядеть окончательная картина. Однако на крышке коробки напечатано изображение в собранном виде. Так и у вас перед глазами должна быть интегрированная система в целом, хотя вы видите хаотичный набор компонентов. Лидеры должны быть в центре внимания своей программы или проекта. В программе есть много людей, ответственных за детали. Из них есть несколько, помимо руководителей, ответственных за обеспечение того, чтобы все части собрались вместе для создания желаемой системы. Они гарантируют, что и система спроектирована правильно, и что команда разрабатывает правильную систему. Руководитель технической команды, главный конструктор, должен иметь возможность постоянно концентрироваться на общей картине.
Когда мы разрабатываем системы, они включают множество отдельных частей. Но вместе эти части рассказывают совсем новую историю. В любом проекте элементы могут жить своей собственной жизнью. Вместе все они функционируют коллективно, выполняя целевую роль, сильно отличающуюся от отдельных частей. Также эта система должна работать в определенной окружающей среде и, возможно, интегрироваться с другими системами, которые являются частью большой программы. Как-то мы приехали к заказчику небольшой работы, согласованной устно, и привезли ему первый экземпляр требуемого насоса. Он радостно сказал: «Отлично. Пойдемте попробуем его в вакуумной камере». Мы застыли в немой сцене, потому что про вакуумную камеру услышали впервые. Поэтому общая картина должна жить в вашей голове на протяжении всей жизни вашего проекта.
Откуда главные конструкторы могут взять общую картину? Есть несколько источников. Многие проекты начинают разработку с потребностей, целей и задач. Эти наборы кратких заявлений обеспечивают стратегическое описание высокого уровня. Указано, почему необходима разрабатываемая система, каковы основные цели системы. Дан краткий список отдельных задач, которые часто ориентированы на характеристики будущей системы. Технические условия излагают общую картину разрабатываемой системы на нескольких страницах. В системной инженерии их часто излагают в форме концепции операций, из которой выводятся системные требования, включая наиболее важные. Эта концепция также является хорошим источником для определения общего вида системы.
Необходимо детально ознакомиться с ожиданиями клиентов и заинтересованных сторон. Некоторые из них послужат отличным начальным шагом, гарантирующим, что и заказчик, и поставщик одинаково понимают задачу с точки зрения ожиданий. На следующем уровне определения ожиданий клиентов и заинтересованных сторон могут быть отражены в качественных мерах эффективности (МЭ) [6], которые используются для проверки системы на каждом этапе процесса проектирования. МЭ дают представление о некоторых из субъективных качеств, желаемых заказчиком, которые не всегда видны в длинном наборе жестких требований. Наконец, конкретные количественные показатели эффективности (ПЭ) послужат хорошим источником для правильного вида на общую картину. ПЭ обычно являются выборкой наиболее важных требований к производительности изделия и используются в качестве метрик для отслеживания характеристик системы в процессе проектирования.
Команда программы хочет знать, что их лидеры поддерживают общую картину. Это важная ответственность, к исполнению которой коллективный опыт большинства главных конструкторов должен их подготовить. На очередных испытаниях экспериментального компрессора мне пришлось в нештатной ситуации взять на себя руководство испытаниями и аккуратно вести испытания до момента, когда перегрев подшипников ротора достиг критической величины. Важные данные были вовремя представлены иностранному заказчику, стенд остался неповрежденным, хотя материальная часть потребовала длительного ремонта. Позже, работая над программой с ГК «Росатом», часто в ходе аудитов на объектах я ставил в тупик дежурных вопросом, где аварийные инструкции, излагающие взгляд на проблему в целом при ее возникновении? Обычно отвечали, что есть номер телефона, куда звонить в экстренных ситуациях. В авиационной промышленности всегда было законом, что такие инструкции нужно написать и выучить заранее участникам работ по принадлежности. Ведь не каждый сможет внятно объяснить при аварии, что происходит, когда время крайне дорого. Да и тому, кому будут звонить, сложно сориентироваться в ситуации, когда часто счет идет на секунды. На испытательных стендах по двигателям такие инструкции всегда были у оператора. Поэтому, например, в моей практике были несколько раз снижены аварийные последствия: при возникновении пожара в ходе испытаний изделия и во время испытаний камеры сгорания. Во втором случае позже оказалось, что виноват производственный брак, изготовитель произвел несанкционированную замену материала.
Главному конструктору проекта, находящегося в стадии разработки, предстоит управлять, определяя приоритеты многих значительных технических проблем, которые постоянно возникают. У большинства разрабатываемых проектов есть основные и второстепенные цели. Задокументированы ключевые требования к параметрам для достижения максимальной эффективности. Вам, как руководителю инженерной команды, нужно будет поддерживать эти цели и требования на протяжении всей деятельности. Эту важную часть вашей работы не получится делегировать, но есть варианты облечения части вопросов. Большую помощь в контроле управленческого процесса вам окажет еженедельно обновляемый менеджером перечень текущих задач проекта для исполнения open items list, который обычно ведут в формате электронных таблиц. Например, по результатам очередного оперативного совещания американский менеджер при мне за полчаса оформил протокол с перечнем четырех десятков очередных задач с датами исполнения и указанием ответственных по пунктам. Включены все открытые для решения текущие вопросы. Такие перечни легко поручить контролировать помощникам. Позже в европейской компании мне показали аналогичный протокол и гордо отметили, что сюда вошли все главные задачи ближайшего месяца. На мой вопрос, как они собираются контролировать исполнение второстепенных задач, которых наверняка гораздо больше, последовало красноречивое молчание. Ведь их тоже нужно выполнять и отслеживать.
В предисловии к книге К. Вуд «Проектирование самолетов» (русский перевод 1940 г.) автор описал неразбериху при создании самолета, если бы проектированием командовали специалисты разных направлений. Этот юмористический взгляд на дисциплину командной работы предостерегает, что может случиться, если никто не смотрит на систему в целом.
Работа главного конструктора заключается в том, чтобы всегда иметь общую картину с собой, куда бы вы ни пошли, и ежедневно обращаться к ней. Часто просят оценить улучшения по проекту и принять технические решения с несколькими вариантами. Каждый вариант может содержать ряд плюсов и минусов. Каждый выбор, вероятно, будет включать и преимущества, и недостатки. Какой путь выбрать? Конечно, каждое решение уникально и должно пониматься в контексте задаваемого вопроса. Однако каждая сделка и каждый выбор приводят к необходимости решений, принимаемых на пути к верхнему системному уровню, характеризуемому удерживаемым вами видом системы в целом. Если вы не будете осторожны, можно легко потерять эту общую картину. В [6] показана практика отслеживания количественных технических показателей эффективности (ПЭ), которая помогает контролировать достижение желаемых характеристик подсистем или компонентов. Например, в типовом техническом задании на разработку нового самолета может быть записано несколько тысяч единичных требований. Сокращенные выборки ПЭ проще контролировать для установления и отслеживания целей. Этого достаточно для информации, достигает ли система основных целей или отклоняется от них. Масса летательного аппарата является важным базовым ПЭ для авиационной и космической техники. Аналогично можно контролировать различные показатели, например дальность полета, грузоподъемность, скорость крейсерского полета, уровень производимого шума на местности и любые другие технические параметры. Контролируя ПЭ, главный конструктор и технические лидеры на протяжении всего процесса проектирования могут следить за характеристикой компонента (аналитической или измеренной), оценивая его способность выполнять поставленные задачи.
В сложных системах процесс можно начать с этапа концепции эксплуатации объекта, продолжить практику на этапах эскизного и технического проекта, далее до изготовления, испытаний и сертификации. Если характеристики не соответствуют поставленным нами целям или соответствуют им с недостаточным запасом (на влияние точности производства, быстрого ухудшения параметров в эксплуатации и др.), можно оперативно предпринять действия для исправления ситуации. Например, изменить проект, запланировать различные доработки или даже снизить желаемую характеристику, если последствия пренебрежимо малы, а, например, стоимость производства заметно снизится. Контроль ПЭ дает возможность поддержки достижения целей программы, чтобы гарантировать получение заданных требований от системы, которую мы проектируем и строим.
В некоторых случаях ПЭ могут жить собственной жизнью и мы можем потерять общую цель ради отдельных деревьев. В стандартной схеме «светофорного» табло, которое сейчас часто используют менеджеры, ПЭ должны быть показаны разным цветом (зеленым, желтым или красным) для упрощенного контроля того рубежа, когда ПЭ станет серьезной проблемой. Цвет зависит от заданных пороговых значений величин. Вы должны убедиться, что система в целом может выполнять свою миссию, и это иногда может противоречить исправлению любого отдельного ПЭ. Бывает, что при решении одной проблемы вы фактически создаете другую проблему на уровне интегрированной системы. Например, в программе по созданию авиадвигателя во времена СССР было порядка 15 ПЭ по таким вопросам, как расход воздуха на входе, эффективность узлов, уровень температуры газа перед турбиной, время раскрутки роторов двигателя с «малого газа» до «максимального режима» и другие параметры. ПЭ отслеживались на предмет соответствия заданию каждый раз, когда конфигурация изделия обновлялась в процессе разработки. Обсуждались вопросы, которые в современной терминологии звучали бы так: «В какой момент этот ПЭ переключается с зеленого на желтый? При каком уровне запаса ПЭ будет считаться невыполненным и нужно пересмотреть требования?» По ходу программы часть ПЭ были зелеными, несколько – желтыми. Один ПЭ по ходу программы оказался красным. Жизненно важный уровень тяги двигателя на максимальном режиме оказался ниже заданного для применения на самолете значения. Этот красный сигнал для тяги стал источником существенных доработок двигателя в сторону ее увеличения. При этом параметры ряда других ПЭ пришлось снижать для оптимизации системы. Все взаимосвязано, и даже в общей картине есть свои приоритеты. Лидер программы сохранил свою точку зрения на системном уровне. Он использовал процесс, в котором любое предлагаемое решение для устранения проблемы «красных» ПЭ запускалось через верх руководства. Успех этого проекта был связан с производительностью на уровне системы. Да, вам нужно исправить некоторые ПЭ, чтобы летать безопасно и успешно, однако производство двигателя, который соответствовал бы почти всем ПЭ, но не выполнял свою основную функцию (создание нужной тяги для самолета), было бы поражением. В итоге двигатель получился и много лет успешно эксплуатируется у нас в стране и за рубежом.
Говоря об ограничениях, обратите внимание, что все вопросы, что мы обсуждали до сих пор, относились к тому, что система должна делать в эксплуатации. Однако также важно понимать, чего система и проектная организация делать не будут. То есть главному конструктору необходимо знать об ограничениях и лимитах проекта. В этом отношении я не имею в виду стандартные эксплуатационные ограничения (такие как красные линии, ограничения сертификации и др.). На верхнем уровне я имею в виду такие соображения, как лимиты бюджета проекта, ограничения от регуляторных комитетов отрасли, отраслевые стандарты, предписания для персонала и другие барьеры, которые могут ограничивать область, в которой вам придется работать и решать задачи. Во избежание будущих неприятностей на проекте рекомендуется также обращать внимание на следующие моменты. Старайтесь выявлять требования к системе на ранней стадии и отказываться от включения дополнительных требований позже в процессе. Соблюдение требований с самого начала проекта снижает затраты и дает более реалистичную оценку времени, необходимого для завершения проекта. Минимизация последующего управления изменениями с соблюдением строгой дисциплины управления программой очень важно. Изучите наличие реалистичных и выполнимых оценок стоимости проекта в начале программы. Это поможет предотвратить перерасход затрат в течение жизненного цикла программы. Важно помнить об основных ограничениях, поскольку они могут определять объем, трудоемкость и сложность вашего проекта.
Однажды мы от имени собственной частной команды выиграли тендер зарубежной компании на проект турбины воздушного цикла. Ее устанавливают на нефтяной платформе как вспомогательную для утилизации тепла выхлопных газов основной энергетической газовой турбины. Коллектив активно взялся за интересный проект. В ходе разработки коллеги представили мне альтернативу. Кроме заданного заказчиком набора параметров было предложено слегка перераспределить в конструкции распределение нагрузки по модулям турбины. Такой вариант давал заметный выигрыш по коэффициенту полезного действия установки. Отправили работодателям оба варианта вовремя. Увы, в полученном ответе было написано, что нас благодарят за предложение, но использовать его не получится. Заказчики пояснили, что между модулями будет установлен промежуточный воздухоохладитель. Он является покупным агрегатом, и поэтому выбранное ими разделение нагрузки между контурами определяется его пропускной способностью. В нашем варианте нужен воздухоохладитель с другими характеристиками, которых на рынке нет. Так, из-за отсутствия информации по ограничениям покупного агрегата нам не удалось реализовать эффектное, с нашей точки зрения, предложение.
Итак, концепция операций, материалы эскизного проекта, ПЭ, требования по надежности и ремонтопригодности, ограничения и лимиты – все это может быть полезно для главного конструктора при создании общего видения системы. Перечисленные продукты, материалы, документы и тому подобное не закрывают вопрос целиком. Общее видение можно уточнить путем обсуждений с менеджером проекта, сертификационными органами, встречами с заинтересованными сторонами. Хотя каждая деталь этих разговоров не всегда может быть задокументирована, главный конструктор может использовать полученную информацию, чтобы сформировать в своем сознании качественную картину общего видения задачи. В том числе на практике часто возникают задачи сравнения вашей будущей системы и конкурентной. Перечень основных ПЭ может, например, включать 50 позиций. При сравнении часто получается, что примерно по 25 ПЭ у каждой из двух систем лучше. Тогда приходится углубиться в детальный анализ с приоритизацией параметров, чтобы понять основные цели создания вашего конкурентоспособного продукта. Пример из этой же серии. Часто встречается, что ваш сотрудник радостно доложил об успешном решении какой-то конкретной задачи. В таких случаях я обычно брал в руки лист бумаги и спрашивал: «Представим, что лист изображает вашу часть работы в целом. Выполненная веха завершила всю работу над задачей на 100%? Или она составляет 50%? Или 1% от вашей общей задачи?» Подобным образом вы ориентируете команду на то, чтобы они тоже держали перед глазами общую цель программы и свои локальные части. При этом следует предпочитать постановку сложных, но выполнимых целей для себя, отдельных членов команды, тематических групп и команд в целом.
Постоянное удержание общего видения картины обеспечивает системный уровень усилий по разработке и информирует как об объективных конкретных требованиях, так и о деталях, все на уровне общей картины. Также нужно помнить о времени, отпущенном на программу, и не забывать, как время влияет на общую картину. Иногда мы будем развивать имеющиеся возможности системы путем модернизаций, продления ресурса, модификаций для разных приложений. Общая картина для таких проектов будет меняться. Главный конструктор в любое время должен знать, о каком объекте идет речь и чем каждый вариант отличается от других. Это не так сложно, потому что вся система, даже развивающаяся, остается знакомой тем, кто работает над ней изо дня в день. Итак, общая картина системы имеет решающее значение для вашей деятельности. Как руководитель, вы будете нести ответственность за то, чтобы помнить об этом на протяжении всего жизненного цикла проекта.