Чому все починається з проблеми
Чимало команд починають з того, що вони вже вміють робити, і переходять до технології до того, як перевіряють саму проблему. Тому перший крок — зрозуміти, що саме відбувається, кого це стосується і чим це можна підтвердити. Частину відповідей дають військові, але самого їхнього запиту недостатньо. Проблему могли вже розв’язати інакше, а для нового рішення може бракувати умов для інтеграції, підтримки або закупівлі.
Технологія сама по собі теж ще не продукт. Продукт з’являється разом із сервісом, обслуговуванням і підтримкою користувача, тому до вартості дрона чи наземного комплексу треба додавати розгортання, навчання, запчастини, ремонт й інтеграцію із системами, які вже використовують у підрозділі. Тож нижча ціна не завжди означає нижчу вартість використання.
Читайте такожЯк виробники і військові шукають рішення для якісного та швидкого зворотного зв’язку і співпраці
Як розібрати завдання підрозділу
Фраза «зв’язок ненадійний» ще не описує проблеми. Треба зрозуміти, який саме зв’язок зникає, за яких умов, що в цей момент робить оператор і до яких наслідків призводить відмова.Тому я прошу військових розповісти про конкретний недавній випадок від початку до кінця, але лише на тому рівні деталізації, яким вони можуть ділитися, без розкриття чутливої інформації. Технічного завдання в них не прошу, бо складати його не їхня робота. Спершу важливо зрозуміти задачу, потрібний результат і обмеження. А вже потім команда разом з відповідними фахівцями переводить це у вимоги до рішення.
Під час таких розмов я насамперед слухаю, а структуруємо почуте вже після них. Для кожного етапу фіксуємо, хто про нього розповідає, як підрозділ діє зараз, чого намагається досягти, що заважає і чим це підтверджує.
Однієї розмови зазвичай недостатньо, тому, коли є можливість, розмовляю з кількома людьми. Командир бачить проблему на рівні підрозділу, оператор знає, як техніка поводиться під час роботи, а в майстерні розуміють, як її обслуговувати, ремонтувати, поєднувати з іншими системами і чи доступні потрібні компоненти. Їхні відповіді можуть не збігатися, бо кожен бачить свою частину системи.
Що можна вважати доказом
Військові добре орієнтуються у своєму сегменті, але не можуть знати все, що вже є на ринку. Тому прототип треба порівняти з тим, як це завдання розв’язують зараз, із готовими продуктами, сумісними компонентами й можливими партнерами. Іноді команді вигідніше стати частиною вже наявного продукту або об’єднатися з іншим виробником. Почати пошук таких можливостей можна на Brave1 Market, у проєктах з НАТО, на європейських челенджах, хакатонах і у відкритих викликах Defence Builder і Brave1.
Для кожного варіанта важливо окремо зафіксувати, що саме він дає, чим це підтверджено і що залишається невідомим. Заява виробника, демонстрація, відгук з підрозділу й незалежна оцінка мають різну доказову вагу. Важливо, не лише хто оцінював рішення, а й що перевіряли та наскільки умови відповідають вашій задачі. Згадка в каталозі чи участь у програмі сама по собі цього не доводить.
Навіть кілька однакових скарг від військових ще не означають, що для нового продукту є ринок. Окремо треба з’ясувати, чи може саме ця команда щось змінити і довести своє рішення до застосування, хто може його придбати й через який закупівельний шлях.
Читайте такожСкільки інженерів в Україні і яка ситуація по регіонах. Що показав проєкт від Lobby X «Країна інженерів»
Коли ідею варто відкласти
Після такої перевірки команда може почати розробку, глибше дослідити проблему або відкласти ідею. Такий вибір часто вважають невдачею, хоча на ранньому етапі це дешевше, ніж дізнатися після місяців розробки, що продукт не потрібен.
Візьмімо умовний приклад з портативним комплектом зв’язку. Проблема в цьому випадку полягає в тому, що через втрату зв’язку зривається завдання, а відсутність конкретного комплекту проблемою не є. Тому команда може змінити саму схему роботи, використати готове рішення, доробити власний прототип або інтегруватися з виробником роботизованих чи комунікаційних платформ.
Разом з гіпотезою варто одразу записати умови, за яких вона виявиться хибною. У цьому прикладі резервного каналу в потрібних умовах може не бути, комплект може не підходити до платформи, а працювати з ним може бути надто складно для операторів або техніків. Різні припущення потребують різних перевірок. Частину можна перевірити через документацію або лабораторні тести. Інші лише під час погоджених випробувань з користувачами у відповідних умовах. Важливо заздалегідь визначити, що саме має підтвердити кожна перевірка. Сама готовність прототипу до тесту ще не доводить його цінності для користувача.
Кому потрібен ваш продукт
Людина, яка безпосередньо стикається з проблемою, не обов’язково вирішує, що купувати. Хтось працює з виробом, хтось інтегрує його в систему підрозділу й навчає людей, а хтось погоджує та оплачує закупівлю, і цінність для кожного з них різна.
Уявімо оператора, який спостерігає за великою ділянкою і має швидко помічати цілі, на які треба реагувати першими. Зараз він робить це вручну, постійне спостереження його виснажує, а разом з втомою зростає ризик пропустити важливу ціль. Цю частину проблеми підтверджують самі оператори.
Тоді команда може перевірити гіпотезу, чи допоможе автоматичне виявлення об'єктів швидше знаходити цілі й визначати їхній пріоритет. Менше навантаження й швидша реакція поки лише очікувані переваги, які ще треба довести. Якщо гіпотеза підтвердиться, оператор отримає менше навантаження й зможе швидше реагувати; технікові важливо, щоб систему було легко підключити й обслуговувати; а командир зможе краще використовувати наявні ресурси. Окремі вимоги матимуть інструктор, логіст, закупівельник і бухгалтер. Але підтверджена проблема ще не означає підтвердженого рішення, і чи зможе система стабільно знаходити потрібні цілі без надмірної кількості хибних спрацювань, ще треба перевірити.
Чим (не) варто ділитися
На ранній стадії команда постійно балансує між тим, щоб не розкрити зайвого, і тим, щоб залишатися помітною для інвесторів і партнерів. Обсяг інформації має залежати від аудиторії й мети розмови, а для різних слухачів корисно готувати різні презентації. Для публічної презентації достатньо пояснити проблему, цінність рішення й результати, які можна розкривати. Технічні деталі, чутливі дані й інформацію про застосування потрібно обговорювати окремо, з урахуванням мети розмови, конфіденційності й захисту інтелектуальної власності.
Надмірна закритість теж може шкодити, бо сильний продукт, про який ніхто не знає, може не знайти ні партнера, ні інвестора, ні користувача. До того ж за останні роки військові частіше беруть участь у міжнародних конференціях, виставках і бізнес-місіях, тож познайомитися з ними можна й за межами України. Але знайомство на заході не замінює роботи з користувачами, які знають відповідну задачу й умови застосування.
Такий підхід не гарантує, що продукт знайде покупця. Але він допомагає якомога раніше побачити, де припущення команди не збігаються з реальністю, і не витрачати час і гроші на розробку, яка не розв’язує потрібну задачу або не має зрозумілого шляху до застосування й закупівлі.
Думки, викладені в цій колонці, є особистою позицією автора і можуть не збігатися з позицією редакції LB.ua.
Читайте також«Сильного продукту вже недостатньо». Підсумки MSPO-2026 — однієї з найбільших оборонних виставок Європи