Чому оборонний продукт треба перевіряти в полі, навіть якщо закупівельник задоволений

12 хвилин читання

Стаття написана Катериною Безсудною – директоркою TEKEVER Ukraine

TEKEVER Ukraine — провідний європейський виробник оборонних безпілотників з командою 1200+ людей та офісами в Україні, Великій Британії, Португалії та Франції. З 2022 року платформи TEKEVER налітали 50 000+ годин разом із ЗСУ.

10+ років досвіду в продажах, виробництві, IT та автомобільній галузі. З початку повномасштабного вторгнення очолювала українське представництво Nova Ukraine — координація гуманітарної допомоги на мільйони доларів.

Досвід роботи з Brave1 та Міністерством оборони України.

Читайте також: Кабмін схвалив зміни до державного бюджету на 2026 рік, які передбачають рекордне збільшення фінансування сектору безпеки та оборони. Йдеться про $99 млрд завдяки коштам ЄС, повідомили у Мінфін.

Спікерка на курсі Miltech Product Management від Choice31&IAMPM

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

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

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

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

Закупівельник і військовий відповідають на різні запитання

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

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

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

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

Польове дослідження починається до розмови

Запитання «Що користувачі думають про наш продукт?» майже гарантовано дасть набір загальних вражень. Частині людей продукт подобатиметься, частині — ні, у висновку перетворити такі відповіді на продуктове рішення буде складно.

Корисне дослідницьке питання має бути конкретним, наприклад: чому екіпажі в певному сценарії втрачають час на конкретному етапі? Це пов’язано з конструкцією продукту, навчанням, сервісом чи умовами застосування?

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

До початку дослідження команда має зафіксувати чотири речі:

  • 1
    що саме потрібно зрозуміти;
  • 2
    яке продуктове рішення залежить від відповіді;
  • 3
    які факти підтвердять або спростують гіпотезу;
  • 4
    кого потрібно почути, щоб не зробити висновок на основі досвіду лише одного типу користувачів.

Якщо відповідь не здатна змінити жодного рішення, дослідницьке питання сформульоване надто широко.

У польових умовах немає часу на годинні інтерв’ю, тому розмова має вкладатися у 10–15 хвилин. Варто також мати резервну версію з трьох ключових запитань на випадок коротшої бесіди.

Найбільше інформації дає розбір останнього конкретного епізоду:

  • 1
    Яке завдання виконував користувач і в яких загальних умовах?
  • 2
    Що він робив крок за кроком?
  • 3
    На якому етапі втратив час або результат чи був змушений змінити процес?
  • 4
    Як самостійно обійшов проблему?
  • 5
    Як збій вплинув на виконання завдання, екіпаж або техніку?
  • 6
    Як часто таке трапляється і що буде, якщо нічого не змінити?

Запитання «Чи подобається вам наш продукт?» перевіряє ставлення, а не поведінку. Натомість запитання «Що ви робили б, якби цього продукту не було?» допомагає зрозуміти його реальну цінність і побачити наявні альтернативи.

У польовій нотатці має бути факт, а не враження

Вас мають цікавити конкретні факти і цифри: фраза «користувачу не сподобалася батарея» нічого не пояснює, а от «батарея пропрацювала 40 хвилин замість заявлених 90 за високої температури» дає факт, який можна перевірити.

Якісна польова нотатка містить:

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

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

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

Контекст визначає рішення

Припустімо, кілька підрозділів повідомляють про втрату зв’язку з наземним роботизованим комплексом. Один оператор пропонує встановити Starlink, інший — використати ретранслятор, третій працює в умовах, де Starlink недоступний, і говорить про mesh-мережу.

Якщо записати висновок як «користувачам потрібен Starlink», команда підмінить проблему одним із запропонованих рішень.

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

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

Гучність скарги не визначає пріоритет

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

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

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

Як працювати без прямого доступу

Пряма розмова з кінцевим користувачем залишається найціннішим джерелом, але доступна не завжди. Частину інформації можна отримати через проксі-канали:

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

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

Фідбек має завершуватися наступною дією

Кожен повторюваний сигнал повинен пройти повний цикл: факт → патерн → гіпотеза → безпечний тест → критерій успіху → продуктове рішення.

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

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

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

Закупівельник відкриває продукту шлях до постачання. Поле показує, чи заслуговує він на наступне.

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