Почему многие разработки БПЛА не доходят до серийного производства: проблема инженерного менеджмента

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

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

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

Но, на мой взгляд, существует еще одна причина, о которой говорят значительно реже.

Многим инженерным командам сегодня не хватает именно управленческих компетенций.

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

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

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

Поэтому эта статья — не руководство «как правильно», а попытка поделиться собственными наблюдениями и опытом. Возможно, кто-то узнает в этих примерах свою команду. Возможно — самого себя. Я тоже узнаю.

Ошибка №1. Влюбленность в технологию вместо решения задачи

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

Но заказчику редко нужен «самый технологичный дрон». Ему нужен инструмент, который эффективно решает конкретную задачу.

Очень часто разработка начинается с вопроса:

«Что еще можно добавить в конструкцию?»

Хотя должна начинаться совсем с другого вопроса:

«Какую проблему мы решаем?»

Именно здесь проходит граница между инженерным творчеством и разработкой продукта.

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

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

Инженерный менеджмент постоянно возвращает команду к главному вопросу:

«Какое изменение увеличит ценность изделия для конечного пользователя?»

Если ответа нет, возможно, это изменение вообще не стоит делать.

Ошибка №2. Отсутствие измеримых показателей эффективности

Еще одна очень распространенная проблема — разработка без объективных критериев успеха.

После испытаний часто можно услышать:

• «Летает лучше.»
• «Стало стабильнее.»
• «Почти готово.»
• «Вроде получилось.»

Подобные оценки не позволяют управлять разработкой.

Любой технический проект должен иметь измеримые показатели эффективности. Именно они позволяют понять, действительно ли изделие развивается или команда просто так ощущает.

Например, для БПЛА такими показателями могут быть:

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

Если после очередной доработки нельзя ответить цифрами, что именно улучшилось, значит управлять развитием изделия становится крайне сложно.

Интуиция и опыт инженеров чрезвычайно важны. Но по мере усложнения проекта они уже не могут заменить объективные данные.

Измерять — значит управлять. Всё остальное — это предположения.

Ошибка №3. Непонимание цепочки создания ценности

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

Ее суть намного глубже, чем просто последовательность этапов разработки.

Любая деятельность команды делится всего на два типа операций.

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

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

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

Главная задача руководителя — постоянно анализировать каждый процесс и задавать один простой вопрос:

«Эта операция создает ценность для изделия или только обслуживает процесс ее создания?»

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

На практике именно здесь скрываются самые большие потери.

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

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

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

Разработка БПЛА сегодня становится настолько сложной, что выигрывает уже не только тот, у кого лучше инженеры, но и тот, кто лучше организовал процессы создания ценности.

Ошибка №4. Непонимание жизненного цикла изделия

Еще одна распространенная ошибка — считать, что разработка заканчивается после первого успешного полета.

На самом деле в этот момент она только начинается.

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

Продукт начинается значительно позже.

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

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

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

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

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

Если ответов на эти вопросы нет, значит существует лишь удачный опытный образец, но еще не существует продукта.

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

Такой проект становится полностью зависимым от нескольких конкретных людей. Стоит одному из них уйти — и развитие фактически начинается заново.

Именно поэтому инженер должен мыслить не категорией:

«Я сделал дрон.»

А категорией:

«Я создал изделие, которое можно многократно производить, эксплуатировать, ремонтировать и постоянно совершенствовать.»

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

Опытный образец доказывает, что идея работает. Серийный продукт доказывает, что команда умеет управлять разработкой.

Ошибка №5. Отсутствие управления версиями изделия и разработки

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

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

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

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

Без версионирования невозможно установить причинно-следственную связь между изменениями и результатом.

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

Версионировать необходимо практически всё.

• конструкцию изделия;
• электрические схемы;
• 3D-модели;
• конструкторскую документацию;
• печатные платы;
• программное обеспечение;
• настройки автопилота;
• алгоритмы управления;
• методики испытаний;
• результаты каждого испытания.

Только тогда появляется возможность уверенно сказать:

«Версия 2.4 получила новый алгоритм наведения, измененный центр масс и другие пропеллеры. Это позволило увеличить вероятность успешного перехвата с 68 до 82 процентов.»

Именно так развивается инженерный продукт — через контролируемые изменения, а не через бесконечные эксперименты без истории.

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

Ошибка №6. Отсутствие проектного управления

Очень часто разработка ведется исключительно за счет энтузиазма команды.

Все понимают, что нужно делать, задачи обсуждаются устно, сроки существуют «примерно», а ответственность распределяется естественным образом.

Такой подход может работать, пока над проектом трудятся два-три человека.

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

Возникают типичные проблемы:

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

Проектное управление — это не красивые диаграммы Ганта.

Это понимание четырех простых вещей:

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

Когда проект становится прозрачным, руководитель перестает управлять людьми и начинает управлять системой.

А команда перестает постоянно работать в режиме аврала.

Ошибка №7. Постоянная смена приоритетов

Наверное, практически каждый разработчик узнает себя в этой ситуации.

Сегодня команда делает новую систему наведения.

Завтра появляется интересная идея изменить конструкцию.

Через неделю приходит предложение попробовать другие двигатели.

Еще через несколько дней возникает желание полностью переписать программное обеспечение.

Каждая идея по отдельности может быть действительно хорошей.

Проблема в другом.

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

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

Но если посмотреть на результат через несколько месяцев, оказывается, что готового изделия по-прежнему нет.

В управлении проектами существует простое правило:

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

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

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

Ошибка №8. Отсутствие технологической дисциплины

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

На первых этапах это действительно работает.

Но затем неожиданно выясняется, что два внешне одинаковых аппарата летают совершенно по-разному.

Причина чаще всего не в конструкции, а в технологии.

Один инженер затянул крепеж с другим усилием. Другой иначе уложил проводку. Третий использовал другой клей. Четвертый изменил последовательность сборки. Пятый установил регулятор немного иначе.

Каждое такое изменение кажется незначительным. Вместе они превращают одинаковые изделия в разные.

Технологическая дисциплина нужна не потому, что так требуют стандарты.

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

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

Именно поэтому появляются:

• технологические карты;
• инструкции по сборке;
• контрольные операции;
• регламенты испытаний;
• контроль качества.

Без этого невозможно организовать серийное производство, даже если речь идет всего о нескольких десятках изделий в месяц.

Ошибка №9. Отсутствие управления знаниями

Практически в каждой инженерной команде существует огромный объем знаний, который нигде не записан.

Почему отказались от определенной конструкции?

Почему выбрали именно этот двигатель?

Почему изменили алгоритм?

Почему испытания проводились именно по такой методике?

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

Пока вся команда работает вместе, проблема незаметна.

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

Команда начинает повторять собственные ошибки.

Управление знаниями — это не создание огромного архива документов.

Это фиксация наиболее важных решений:

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

Знания должны принадлежать проекту, а не отдельным людям.

Только тогда команда действительно развивается, а не начинает каждый новый этап практически с нуля.

Ошибка №10. Отсутствие анализа данных испытаний

Испытания — один из самых дорогих этапов разработки.

Но их ценность определяется не количеством полетов, а количеством выводов, которые команда смогла сделать.

К сожалению, после испытаний нередко звучат фразы:

• «Вроде стало лучше.»
• «Наверное, проблема была в прошивке.»
• «Кажется, двигатель перегрелся.»

Такие выводы не позволяют управлять развитием изделия.

Каждое испытание должно отвечать на заранее сформулированные вопросы.

Что именно мы хотим проверить?

Какие показатели измеряем?

Какие изменения были внесены относительно предыдущей версии?

Подтвердили ли результаты нашу гипотезу?

После каждого испытания должны появляться не только видеозаписи полетов, но и данные, которые можно сравнить с предыдущими испытаниями.

Только так возникает накопление опыта.

Со временем именно эти данные становятся главным активом проекта. Они позволяют принимать решения не на основе ощущений, а на основе статистики и фактов.

Можно сказать, что каждое испытание — это инвестиция. И чем лучше команда умеет извлекать знания из его результатов, тем быстрее развивается изделие.

---

Если внимательно посмотреть на все перечисленные ошибки, можно заметить одну закономерность.

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

Большинство этих проблем возникает из-за отсутствия системного управления разработкой.

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

Что такое инженерный менеджмент на самом деле

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

На самом деле всё наоборот.

Главная задача инженерного менеджмента — освободить инженеров от лишней работы и дать им возможность больше времени заниматься тем, что действительно создает ценность.

Хорошее управление не замедляет разработку. Оно делает ее быстрее.

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

Мне нравится рассматривать инженерную команду как сложную систему.

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

Именно поэтому две команды с одинаковыми ресурсами могут получить совершенно разные результаты.

Одна постоянно тушит пожары и живет в режиме бесконечных авралов.

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

С чего стоит начать

Не нужно пытаться внедрить десятки управленческих инструментов одновременно.

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

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

Ни один из этих инструментов сам по себе не сделает изделие лучше.

Но все вместе они позволяют команде развиваться значительно быстрее.

Вместо заключения

Я сознательно написал эту статью не как преподаватель менеджмента и не как консультант.

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

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

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

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

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

Каждый раз подобные решения казались оправданными.

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

Наверное, поэтому сегодня я все чаще прихожу к простому выводу.

Современные БПЛА — это уже не просто инженерные изделия.

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

Они требуют зрелого инженерного менеджмента.

Можно собрать великолепный опытный образец.

Можно провести впечатляющие испытания.

Можно придумать уникальное техническое решение.

Но настоящая ценность появляется только тогда, когда всё это превращается в изделие, которое можно воспроизводить, совершенствовать, ремонтировать и масштабировать.

Сегодня побеждает уже не тот, кто способен создать самый необычный прототип.

Побеждает команда, которая умеет системно превращать идеи в работающие изделия.

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

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