Стаття написана Катериною Безсудною – директоркою TEKEVER Ukraine
TEKEVER Ukraine — провідний європейський виробник оборонних безпілотників з командою 1200+ людей та офісами в Україні, Великій Британії, Португалії та Франції. З 2022 року платформи TEKEVER налітали 50 000+ годин разом із ЗСУ.
10+ років досвіду в продажах, виробництві, IT та автомобільній галузі. З початку повномасштабного вторгнення очолювала українське представництво Nova Ukraine — координація гуманітарної допомоги на мільйони доларів.
Досвід роботи з Brave1 та Міністерством оборони України.
Спікерка на курсі Miltech Product Management від Choice31&IAMPM
Контракт закрито. Строки витримано. Закупівельник підписав акт і лишився задоволений. Здається, продукт готовий. А потім він потрапляє в підрозділ, і не спрацьовує так, як задумано. Екіпаж втрачає час, ламає звичний процес, шукає обхідне рішення. Обмеження, яких не було видно ні в документації, ні під час приймання, вилазять саме тоді, коли виріб опиняється в тому сценарії, заради якого його взагалі створювали.
Це не завжди помилка закупівельника. Просто він і військовий дивляться на продукт з різних боків і бачать різне.
Чому підпис закупівельника ще нічого не гарантує
Закупівельник оцінює те, що входить у його зону відповідальності. Вартість. Відповідність процедурам. Строки постачання. Здатність виробника масштабувати випуск, тримати логістику, забезпечувати сервіс і навчання. За цими критеріями продукт може бути бездоганним.
Військовий бачить інший зріз. Чи підходить виріб під конкретне завдання. Як він поводиться під вогнем, за складного рельєфу, у негоду, під тиском ворожого РЕБ. Де відмовляє. Скільки зайвих зусиль вимагає. Ці два погляди майже ніколи не збігаються повністю, бо відповідають на різні запитання.
Проблема ще й у самій структурі ринку. В обороні платить одна сторона, а користується інша. Виробник рідко чує оцінку кінцевого користувача напряму — між ним і фронтом стоїть закупівельний контур. Тому польова перевірка потрібна навіть після ідеально виконаного контракту. Тільки вона показує, чи перетворилися технічні характеристики й виробнича спроможність на реальну перевагу для підрозділу. І чи варто розраховувати на довгу співпрацю, а не на разове постачання.
Якщо продуктова та біздев-команди не мають цього досвіду або спираються на випадкові уривчасті відгуки, вони ризикують масштабувати разом із продуктом і його приховані вади. Ті самі, що проявляються вже в застосуванні.
Два різні запитання, на які немає спільної відповіді
Кваліфікований закупівельник справді багато що вміє оцінити: технологічну перевагу виробу, виробничу інфраструктуру, надійність логістики, потенціал нарощування постачань, якість сервісу, строки введення в експлуатацію. Це серйозна експертиза. Але навіть вона не відтворює досвід людини, яка працює з виробом у конкретній місії — за певної погоди, протидії, підготовки екіпажу.
Складніше, коли закупівельнику бракує глибокої технічної компетентності. Тоді на рішення починають впливати репутація виробника, чиїсь особисті рекомендації, поодинокі схвальні відгуки. У такій ситуації перевірені польові дані стають критично важливими — вони повертають оцінку до вимірюваних критеріїв і реальних сценаріїв, а не до вражень.
Кінцевий користувач бачить точку, де теорія розробника стикається з практикою. Зайвий крок у підготовці. Незручний інтерфейс. Зв'язок, що плаває. Складне відновлення після збою. Потреба тягнути з собою додаткове обладнання. Ці дрібниці рідко доходять до закупівельного звіту, хоча нерідко саме вони вирішують долю місії. Для команди розробника користувач — головне джерело правди про якість виробу й водночас двигун подальшого розвитку технології.
Є ще один момент, суто прагматичний. Довіра військових формує запит знизу і часто підштовхує наступну закупівлю. Тобто прямий контакт із користувачем працює одразу на два фронти: покращує продукт і допомагає йому поширюватися. Організувати такий контакт непросто, тут без ілюзій. Але реально. І в перспективі — дуже цінно.
Дослідження починається задовго до першої розмови
Питання «Що користувачі думають про наш продукт?» майже гарантовано принесе купу загальних вражень. Комусь подобається, комусь ні. Перетворити це на продуктове рішення потім майже неможливо.
Корисне питання завжди конкретне. Чому екіпажі в такому-то сценарії втрачають час саме на цьому етапі? Це через конструкцію, навчання, сервіс чи умови застосування? Ось із таким формулюванням уже можна працювати.
До старту дослідження команді варто зафіксувати чотири речі:
що саме треба зрозуміти;
яке продуктове рішення залежить від відповіді;
які факти підтвердять або спростують гіпотезу;
кого треба почути, щоб висновок не спирався на досвід лише одного типу користувачів.
Проста перевірка: якщо відповідь на питання не здатна змінити жодного рішення — питання сформульоване надто широко. Переформульовуйте.
У полі ніхто не проводитиме годинних інтерв'ю. Розмова має вкладатися в 10–15 хвилин, а на випадок зовсім короткої бесіди тримайте напоготові скорочену версію з трьох ключових запитань.
Найбільше дає розбір останнього конкретного епізоду, а не абстрактні роздуми «взагалі». Що людина виконувала і в яких умовах. Що робила крок за кроком. На якому етапі втратила час чи результат або мусила ламати процес. Як викрутилася сама. Як збій вплинув на завдання, екіпаж, техніку. Наскільки часто це стається і що буде, якщо не чіпати проблему далі.
І ще одна тонкість. Питання «Чи подобається вам продукт?» вимірює ставлення. А от «Що ви робили б, якби цього продукту не було?» — вимірює реальну цінність і показує, які альтернативи вже існують. Різниця величезна.
У нотатці має бути факт, а не емоція
«Користувачу не сподобалася батарея» – це нуль інформації. А от «батарея відпрацювала 40 хвилин замість заявлених 90 за високої температури» – це факт, який можна перевірити, відтворити й полагодити. Цифри й конкретика вирішують.
Якісна польова нотатка тримається на кількох елементах:
загальний контекст використання — без точних локацій, координат, частот і складу підрозділу;
конкретний факт із вимірюваним параметром, якщо він є;
коротка дослівна цитата користувача;
обхідне рішення, до якого він вдався;
вплив проблеми на час, результат, навантаження чи надійність;
окремо — інтерпретація команди, чітко відділена від самого факту;
рівень довіри до сигналу.
Емоцію фіксувати теж можна. Але роздратування чи захват самі собою не задають пріоритет. Куди важливіше зрозуміти, що сталося, за яких умов і з якими наслідками.
Окремі нотатки раз на тиждень зводьте за темами, а не за датами чи підрозділами. Тоді стає видно, які проблеми повторюються незалежно одна від одної в різних контекстах, а які лишаються поодинокими випадками. Це різні речі, і реагувати на них треба по-різному.
Контекст вирішує, а не запропоноване рішення
Уявімо ситуацію. Кілька підрозділів скаржаться на втрату зв'язку з наземним роботизованим комплексом. Один оператор радить поставити Starlink. Другий — ретранслятор. Третій працює там, де Starlink узагалі недоступний, і говорить про mesh-мережу.
Якщо команда запише висновок як «користувачам потрібен Starlink», вона підмінить проблему одним із рішень. І, найімовірніше, помилиться.
Повторюваний сигнал тут – втрата зв'язку за певних умов. А технічне рішення залежить від території, рельєфу, забудови, задуму місії й десятка інших обмежень. Те саме з волоконно-оптичним керуванням: воно стійкіше до РЕБ, але додає вагу, а вага тягне за собою компроміс по інших характеристиках апарата. Зміна одного параметра оборонного виробу майже завжди відлунює в усій системі.
Тому команда фіксує проблему, контекст і наслідки. А рішення, яке запропонував користувач, розглядає лише як одну з гіпотез для перевірки. Не більше.
Гучність скарги не дорівнює пріоритету
Один запит на нову функцію не повинен автоматично переписувати продуктовий план. Інакше дорожню карту диктуватиме той, хто голосніше скаржиться. Робоча логіка пріоритезації враховує чотири складові разом: повторюваність сигналу, тяжкість наслідків, кількість контекстів і рівень довіри до даних.
Далі все залежить від того, як поводиться сигнал. Одиничний випадок фіксують і перевіряють. Якщо схожий патерн виринає в кількох незалежних джерелах — команда формує гіпотезу. Коли проблема повторюється і серйозно б'є по результату місії, часу, справності техніки чи людях, вона стає пріоритетною для дослідження й тестування. І лише після підтвердження кількома методами можна ухвалювати продуктове рішення.
Окрема історія — сигнали про безпеку людей або критичну відмову. Тут навіть один випадок вимагає негайної перевірки. Хоча й він сам по собі ще не привід без аналізу викочувати нову функцію.
Що робити, коли прямого доступу до фронту немає
Пряма розмова з кінцевим користувачем — найцінніше джерело. Але доступне воно далеко не завжди. Тоді частину картини збирають через проксі-канали:
навчальні центри та інструктори, які бачать типові труднощі десятків людей;
сервісні й ремонтні центри, де накопичуються дані про реальні поломки та замовлені запчастини;
телеметрія продукту — логи використання, коди помилок, частота відмов компонентів;
інженери, які тимчасово працюють у зоні застосування;
ветерани, що перейшли в оборонну індустрію й зберегли контакт із підрозділами;
відкриті звіти та публічні виступи військових, обов'язково з перевіркою актуальності й контексту.
У кожного каналу своє спотворення, і це треба тримати в голові. Інструктор добре бачить помилки новачків, але може не знати всіх умов бойового застосування. Ремонтний центр показує поломки й не показує успішних місій. Телеметрія фіксує, що сталося з технікою, та не завжди пояснює, що робив екіпаж. Тому брак прямого контакту компенсують двома-трьома незалежними джерелами, а не сліпою довірою до одного посередника.
Фідбек, що не закінчується дією, це просто шум
Кожен повторюваний сигнал має пройти повний цикл: факт → патерн → гіпотеза → безпечний тест → критерій успіху → продуктове рішення. Без цього ланцюжка фідбек залишається балаканиною. Тому в кожного сигналу мусить бути відповідальний за перевірку, строк і заздалегідь прописані дії для обох сценаріїв, і якщо гіпотеза підтвердилася, і якщо ні.
В оборонного продуктового менеджменту рідко бувають тепличні умови. Дані приходять уривками, доступ до користувачів урізаний, продукт і середовище його застосування змінюються швидше, ніж встигаєш реагувати. Саме тому дисципліна роботи із сигналами перетворюється на частину технологічної переваги. Не додаток до неї, а її складову.
Кожен контакт із користувачем має лишати по собі структурований факт. Кожен повторюваний факт – гіпотезу. Кожна підтверджена гіпотеза – конкретну зміну в продукті, навчанні, сервісі чи процесі застосування. Наскільки серйозно компанія ставиться до фронтового фідбеку, добре видно з практики самого TEKEVER: за даними Forbes, український офіс компанії відкрили саме заради швидшої взаємодії між фронтом і командами розробки в Португалії, Франції та Британії.
Якщо коротко: закупівельник відкриває продукту шлях до постачання. А поле показує, чи заслуговує він на наступне.
Ідіть у дефенс, поки фронтовий досвід ще на вагу золота
Ринок оборонних технологій виріс швидше, ніж встигла перебудуватися система підготовки кадрів. Це означає одне: людей, які вміють правильно збирати й обробляти фронтовий фідбек, критично не вистачає, а саме ця навичка сьогодні відрізняє продукт, що виживає в полі, від продукту, що красиво виглядає на прийманні.
Спілкуючись з іноземними виробниками, я не втомлююся повторювати: українські інженери й військові зараз мають величезний вплив на розвиток військових засобів — на їхнє застосування, на функції, що здатні змінити хід війни. Україна – це місце, де варто забути про GPS, вчитися обходити ворожий РЕБ і, обираючи роботу в дефенсі, паралельно вчитися відповідальності та лідерству. Якщо хочете системно розібратися, як влаштований продуктовий менеджмент в обороні й перетворити цей досвід на професію, починайте з фундаменту, наприклад, із курсу Miltech Product Management від Choice31 & IAMPM. Заходьте в напрямок, поки він ще не став мейнстрімом.
