Як фронтовий сигнал стає інженерним завданням. Колонка директорки Defence Builder Accelerator Яни Шкваровської

Що розробники deftech-рішень мають розуміти про специфіку військових випробувань і як їм правильно реагувати на запити з фронту та фідбек від військових?

Нещодавно директорка акселератора Defence Builder Яна Шкваровська повернулася з робочої поїздки на Донеччину, де разом із співзасновником DeepStateUA Романом Погорілим працювала з командирами бригад і батальйонів, операторами та керівниками майстерень. Частину висновків, здобутих під час цієї поїздки, вона зафіксувала в колонці для Defender Media.

За 2025 рік у межах профільних тестів Збройні Сили отримали від виробників понад 500 заявок. За даними Центрального управління інноваційної діяльності ЗСУ, успішними можна вважати лише половину польових випробувань. 

Випробування й мають знаходити проблеми та перевіряти заявлені характеристики, поки виріб не пішов у серію і не почав застосовуватися системно. Цікавіше, на якому етапі ці проблеми виникають.

У кількох кейсах, якими ділилися військові, до перевірки головної функції виробу навіть не доходило. Розробка не проходила штатний запуск, вимикалася невдовзі після старту або втрачала зв’язок ще до завершення тестового маршруту. 

Те, як виріб переносить дорогу, розгортання чи втрату каналу, можна перевірити раніше і дешевше. Якщо команда дізнається про це вже в полі, однією з причин може бути те, що у вимогах були дальність і корисне навантаження, але не було повного сценарію застосування. Іншими причинами можуть бути якість збірки, інтеграція компонентів, умови середовища або підготовка користувача.

Нещодавно ми зі співзасновником DeepStateUA Романом Погорілим, членом Advisory Board Defence Builder, працювали на Донеччині з командирами бригад і батальйонів, операторами та керівниками майстерень. Деталі розмов залишаться поза текстом з міркувань безпеки, але не сам метод роботи.

Чому я не питаю, яке рішення потрібне

Під час цієї поїздки розмови були відкритими: я насамперед слухала те, чим військові були готові поділитися. У подальшій роботі із запитом я не починаю з питання “яке рішення вам потрібне”, бо воно одразу переводить її на конкретний виріб, а спершу треба зрозуміти проблему. Важливо з’ясувати, яке завдання виконує підрозділ, який результат потрібно покращити, що заважає це зробити, що вже пробували і чому рішення не стало стійкою практикою.

З відповідей поступово стає видно, хто безпосередньо стикається з проблемою, в якому сценарії вона виникає і які питання ще потрібно перевірити. На виході першої розмови не завжди має бути готове технічне завдання. Часто чесніший результат – це структурований опис проблеми, потрібного ефекту, контексту й обмежень. Технічні вимоги з’являються пізніше.

Щоб скласти повнішу картину, я намагаюся зіставити щонайменше три перспективи, коли це можливо. Командира бригади чи батальйону цікавить спроможність — який результат потрібен, що має вищий пріоритет і де технологія може зменшити ризик для людей. Оператору видно, чого система вартує в щоденному застосуванні та як вона поводиться поза демонстраційними умовами. Керівник майстерні бачить життєвий цикл: що ламається після постачання, наскільки відрізняється якість партій, скільки триває ремонт і чи є запасні частини. Ці погляди можуть не збігатися,але це не означає, що хтось помиляється, адже вони описують різні частини однієї системи і саме на їхньому перетині з’являється реалістичніше інженерне завдання.

Частину цих даних держава вже збирає. Рейтингова система DOT-Chain Defence є одним із каналів структурованого військового відгуку: авторизовані користувачі можуть оцінювати дрони та описувати досвід застосування, зручність експлуатації, якість збірки й стійкість до перешкод. Аналітичні дашборди Brave1 Market дають виробникам, які працюють за програмою “Армія дронів.Бонус”, статистику уражень, єБалів і місце виробу серед аналогів. Але ці дані не замінюють інформацію про ремонтопридатність, варіативність партій, запасні частини та навантаження на майстерні. У доступних нам каналах цей пласт поки представлений значно слабше, хоча саме він допомагає зрозуміти повну операційну придатність виробу.

Коли запит стає напрямом роботи

Фіксованого порога, після якого запит стає напрямом когорти акселератора, немає. У нашій робочій рамці, поки запит походить від одного підрозділу чи середовища, ми вважаємо його польовим сигналом і перевіряємо, чи повторюється він деінде і чи описують різні люди той самий потрібний ефект, навіть якщо використовують різні слова. Продукт, вирощений під один підрозділ, ризикує мати вузьку застосовність, якщо така спеціалізація не була свідомим задумом від початку. 

Повторюваний запит ще перевіряємо на реалістичність – чи досяжне рішення технологічно і чи можна довести його до перевірки в межах програми. Заодно з’ясовуємо, чи не дублює воно рішення, яке вже доступне.

Для частини команд між входом у програму і перевіркою в релевантному середовищі минають місяці. Тому, формуючи напрями когорти, ми не намагаємося точно передбачити майбутнє, а створюємо портфель робочих гіпотез на горизонті шести-дванадцяти місяців. За цей час змінюються і тактика, і контрзаходи противника, і доступність компонентів, і технологічні можливості самих команд. Але ці потреби ми ведемо як гіпотези й регулярно переглядаємо.

Лише в третій набір акселератора команди подали понад 110 заявок, з яких ми відібрали десять. Наведу один кейс: команда прийшла з іншим продуктом, але, оцінивши її інженерну експертизу, компетенції та наявні напрацювання,ми побачили, що вони можуть бути  кориснішими для конкретного запиту військових – підвищити захищеність наявної платформи від певного класу загроз. Ми рекомендували змінити фокус і підтримували команду ресурсами, експертним контекстом, партнерськими зв’язками та іншими ресурсами, необхідними саме для цієї розробки. Станом на підготовку колонки команда має робочий прототип і переходить до тестування разом із військовими.

Готового ТЗ на старті не було, тож завдання уточнювалося ітераційно. Робочий бриф після уточнення потрібних деталей має описувати всі важливі для застосування деталі: потрібний ефект, контекст інтеграції, обмеження, навантаження на користувача, очікувану поведінку у разі відмови та сценарій перевірки. Без останніх двох пунктів складно визначити прийнятний результат і дії у разі нештатної поведінки системи. 

Перед першим польовим випробуванням  

Коли бриф складено і прототип зібрано, перед полігоном потрібна окрема перевірка готовності. Її завдання – зняти всі питання, для яких не потрібне релевантне польове середовище. Для мобільної безпілотної або роботизованої платформи базовий перелік може виглядати так:

• Чи витримує виріб транспортування до позиції у штатному пакуванні;
• Чи проходить релевантний функціональний цикл — від розгортання до повернення, або безпечного припинення роботи;
• Чи тримає зв’язок і як поводиться після втрати каналу;
• Скільки часу і людей потребує розгортання;
• Чи сумісний він з обладнанням, яке підрозділ уже використовує.

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

Якщо проблема все ж виявилася на полігоні, це не катастрофа — полігон якраз і має перевіряти припущення в релевантних умовах. Відмова стає корисними даними, коли команда фіксує, на якому етапі вона сталася, за яких умов, чи повторюється на інших зразках, а потім локалізує джерело:  конструкцію, компонент, програмне забезпечення, налаштування, інтеграцію, середовище чи, скажімо, підготовку користувача. 

Такий розбір може оновити і виріб, і вимоги до нього. До вимог додаються, наприклад, передбачена поведінка після зміни умов, безпечне завершення роботи або можливість швидко встановити причину відмови. Конкретні параметри мають залишатися у закритій програмі випробувань.  

Найгірше, що можна зробити після невдалого тесту, — повторити його без нової гіпотези, змін у виробі або уточнених критеріїв. Результат перевірки може вести до доопрацювання, зміни вимоги, перегляду самої концепції або рішення зупинити напрям. Негативний тест – не вирок команді, але й не автоматична підстава продовжувати без змін. 

Марнотратство – це коли полігон знову виявляє те, що можна було з’ясувати раніше і дешевше. Розмова з підрозділом і бриф із повним сценарієм – це теж інженерна робота. Вона не гарантує успіху, але зменшує кількість зайвих ітерацій і підвищує шанси довести корисне рішення до належної перевірки.

Яна Шкваровська

Директорка акселератора Defence Builder

• LinkedIn