«Fail fast in metal» працює. Але є одна сліпа зона, з якою оборонні команди справляються вручну

Спостереження після місяця розмов з фаундерами оборонного hardware та думка з нагоди публікації dev.ua про культуру розробки в українському miltech

dev.ua нещодавно опублікувала розгорнутий матеріал про культуру розробки в українському miltech, з прямими цитатами SKIFTECH, Himera, BlueBird, DevDroid, The Fourth Law та інших команд. Прочитав і впізнав майже все, з чим зустрічався особисто, спілкуючись з фаундерами defense hardware за останній місяць. Хочу додати одну річ, яка в тій статті прозвучала між рядків, але варта окремої уваги.

Спочатку зафіксую те, з чим повністю погоджуюсь.

«Test now, fix now», як це сформулювали в Himera, на ранніх ітераціях оптимальне. Цикл «отримали фідбек — внесли зміни — перевірили» в години, а не тижні — це не просто перевага, це необхідність, коли ціна затримки вимірюється життями. Українська defense екосистема за два роки побудувала ринок, де класичний Scrum просто не виживає. Це сильна позиція. Вона працює.

Хочу зупинитися на одній деталі з тієї ж публікації. Олег Федоришин з DevDroid говорить про моменти, коли система поводиться непередбачувано, і проблему треба шукати «на полігоні під дощем, в умовах стресу та обмеженого часу». В такі моменти, за його словами, вирішальними стають не інструменти, а інженерна інтуїція та досвід команди.

Підписуйтеся на наші соцмережі

Це чесний опис того, як працюють hardware/software системи у складних умовах. І саме звідси починається питання, яке мені здається корисним підняти: яка частина цієї полігонної інтуїції могла б бути систематизована в передпрототипний аналіз? Не замість польових тестів, а до них.

Бо є категорія ризиків, які не виявляються на швидкій ітерації. Вони проявляються або через час (накопичувальна втома матеріалів), або через комбінацію (стики між підсистемами від різних підрядників), або через сценарій, якого не було у специфікації (деградація замість бінарного стану). У SKIFTECH про це сказали прямо: будь-яка зміна в софті може вплинути на сенсори, електроніку, енергоспоживання чи зв'язок. У The Fourth Law назвали створення повноцінних апаратно-програмних систем найскладнішою інженерною задачею галузі.

Кілька прикладів патернів, які я зустрічав у розмовах останнього місяця.

Перший. Герметичні роз'єми, які проходять статичний IP-тест. Команда збирає блок, перевіряє герметичність на стенді, все ок. У полі перший і другий місяць працює. На третьому починаються незрозумілі відмови, які важко повторити. Розбираються: 40+ циклів «холодний пуск при мінус 15 → робота → вимкнення» дали мікротріщини в ущільнювачі. Стенд не зловив, бо стендовий тест статичний, а реальне поле — це накопичувальна термоциклічна втома. На етапі, коли вже сотні виробів у полі, виправлення коштує переробки всього парку.

Другий. Дрейф юстировки між підсистемами. Силовий і обчислювальний модулі збираються у різних підрядників, кожен проходить factory acceptance test самостійно. На стенді інтегруються, працюють. У полі після кількох циклів транспортування і вібрації з'являється мікроперекіс. Окремо кожен модуль у нормі. Разом накопичується похибка позиціонування, яка у критичний момент дає збій. Жоден підрядник не «винен», вузол між блоками структурно нічий.

Третій. Software fallback у деградуючому каналі зв'язку. Система спроєктована для двох сценаріїв: повний зв'язок і повна втрата зв'язку. Обидва тестуються, обидва працюють. Але реальне поле дає третій сценарій, якого не було у специфікації — деградуючий зв'язок, 5-15% втрати пакетів. У цьому режимі обидві моделі дають хибну поведінку. Між ними мертва зона, де система працює непередбачувано.

Жоден з цих ризиків не виявляється на ітерації «зробив-протестував-виправив». Вони ловляться або через досвід («ми це вже бачили, давайте перевіримо»), або реактивно — коли воно вже вилізло у залізі.

Питання, яке мене цікавить: чи можна частину цієї роботи перенести на етап до прототипу. Як додатковий шар, який бере на себе категорію ризиків, що «test now, fix now» структурно не бачить. Внутрішні red teams це частково роблять. Зовнішні валідатори на конкретні архітектурні рішення — частково. Accelerated lifecycle testing до серії — частково.

Друге питання, на яке у мене поки немає однозначної відповіді: чи готова українська defense екосистема системно вкладатися в передпрототипну валідацію зараз, коли темп випуску в поле задає все, або це історія наступної фази, коли почнеться серійне виробництво і експорт.

Цікаво почути думку команд.