Соло, з партнером чи командою: як IT-підприємцю стартувати в DefTech
Оновлено: 10 годин тому
IT-команда може швидко зібрати програмну частину, налаштувати процес розробки й запустити першу версію продукту. У DefTech цього досвіду вистачає лише на частину маршруту.
До розробки додаються польові сценарії, військовий користувач, апаратна частина, випробування, інтеграції, інтелектуальна власність, виробництво та окрема логіка фінансування. Кожен із цих напрямів потребує відповідальної людини.
Через це IT-підприємці часто стикаються з кількома запитаннями:
Чи можна перевірити ідею самостійно?
Коли до проєкту залучати партнера?
Які функції варто залишити всередині IT-компанії?
Як тестувати DefTech-напрям і зберегти керованість основного бізнесу?
Що зафіксувати до передачі частки партнеру?
Відповіді залежать від продукту, його складності та поточного етапу. Розберемо їх на досвіді Дмитра Костарєва, CEO FLEXSYS і співзасновника Panoptes. Він понад 15 років працює з програмно-апаратними системами та пройшов шлях від сервісного й інженерного IT-бізнесу до створення DefTech-продукту.
Технологічний досвід ще не визначає продукт
Команда Panoptes розробляє систему виявлення й супроводу повітряних цілей. Вона працює з оптико-електронними станціями, програмним забезпеченням та даними від партнерських сенсорів.
Перед стартом проєкту команда вже мала інженерну базу, лабораторне обладнання, досвід промислової автоматизації та розробки програмного забезпечення. Також були контакти з науковцями й військовими користувачами.
Ідея формувалася близько пів року. Команда вивчала роботу наявних систем, спілкувалася з користувачами та шукала прогалини в засобах виявлення. Перший тест провели у спортивній залі університету: станція супроводжувала Mavic у контрольованих умовах.
Цей приклад показує важливий принцип для IT-підприємця. Стартовий прототип може перевіряти одну критичну функцію. Для першої ітерації потрібні чітка гіпотеза, доступ до користувачів і зрозумілий критерій результату.
Перед розробкою варто відповісти на п’ять запитань:
Яку повторювану проблему ви перевіряєте?
Хто використовуватиме продукт у реальних умовах?
Яка функція визначає життєздатність рішення?
Де й за яких умов її можна безпечно перевірити?
Який доказ дозволить перейти до наступної ітерації?
Без цих відповідей команда ризикує витратити бюджет на функції, які не впливають на результат для користувача.
Який етап може пройти солофаундер
Солофаундер може самостійно дослідити проблему, провести перші інтерв’ю, сформувати концепцію та перевірити вузьку технічну гіпотезу.
Такий формат працює за кількох умов:
проблема має чіткі межі
засновник володіє потрібною технічною експертизою
є доступ до користувачів або профільних консультантів
перша перевірка не потребує складної інфраструктури
відсутні критичні прогалини в безпеці та юридичній частині
Солоетап допомагає швидше перевіряти рішення й оцінювати людей до формального партнерства. Його варто сприймати як фазу розвитку проєкту.
Потреба в партнері виникає, коли засновник одночасно веде розробку, спілкується з військовими, заповнює грантові заявки, шукає фінансування, проводить перемовини й готує випробування. Кожен із цих процесів забирає фокус. Частина задач починає сповільнювати весь проєкт.
Сигналом для залучення партнера стає критичне вузьке місце, яке блокує наступний етап.
Наприклад:
бракує технічної архітектури
нікому відповідати за польову перевірку
потрібна постійна робота з інвесторами та грантодавцями
команда готується до виробництва
продукт потребує інтеграції з іншими системами
Партнер має взяти відповідальність за окремий результат компанії. Загальна допомога й перелік знайомств не визначають такої відповідальності.
Партнер, радник, підрядник або працівник
Дефіцит компетенції ще не означає, що людину потрібно одразу робити співзасновником. Спочатку варто визначити тривалість і критичність її ролі.
Наприклад, юридичну консультацію щодо договору може закрити підрядник. Технічна архітектура багатокомпонентного продукту потребує постійного власника. Комерційний партнер із часткою має відповідати за вимірюваний напрям: фінансування, контракти, партнерства або вихід на визначений ринок.
Які функції потрібні DefTech-команді
На ранньому етапі одна людина може поєднувати кілька функцій. Зі зростанням продукту їх потрібно розподіляти.
Засновник
Тримає візію, визначає пріоритети й розподіляє ресурси. Також приймає фінальні рішення щодо продукту, партнерств і темпу розвитку.
Технічний керівник
Відповідає за архітектуру, код, апаратну частину та технічні вимоги. Його зона відповідальності охоплює стабільність рішення й технічні ризики.
Власник продукту або польового напряму
Працює з користувачами, збирає фідбек, уточнює сценарії застосування та передає висновки технічній команді. У цій функції важливий військовий або польовий досвід.
Керівник випробувань
Готує сценарій перевірки, визначає метрики, фіксує результати й формує звіт. Після тесту команда має розуміти, що спрацювало, які проблеми виявлено та яку гіпотезу перевіряти далі.
Власник виробничого напряму
Відповідає за повторюваність виробу, комплектуючі, документацію, контроль якості, ремонт і сервіс. Ця функція з’являється під час переходу від окремих зразків до стабільного виготовлення.
Окремої уваги потребують бізнес-розвиток, фінанси, юридичні питання та робота з інтелектуальною власністю. Формат залучення цих фахівців залежить від навантаження й етапу проєкту.
Як перевірити партнера до передачі частки
Дмитро Костарєв радить починати зі спільної роботи над реальною задачею. На таку перевірку можна виділити близько двох місяців.
За цей час варто оцінити:
який результат людина погодилася дати
чи дотримується вона строків
як приймає рішення
як працює з невизначеністю
чи бере відповідальність за помилки
як комунікує з командою
чи здатна обговорювати конфлікти
чи збігаються ваші цінності й горизонт планування
До передачі частки потрібно визначити внесок партнера. Ним можуть бути гроші, технологія, обладнання, код, робота з клієнтами або відповідальність за окрему функцію.
Також варто відповісти на запитання: чи буде ця роль потрібна компанії через рік або два?
Тимчасову прогалину часто закриває підрядник або радник.
Сигнали ризикового партнерства
Обережності потребують ситуації, коли кандидат:
просить частку до спільної роботи
описує свій внесок лише через контакти
передає код або розробки з незрозумілим походженням
має конфлікт інтересів з іншим проєктом
уникає розмови про невдалий сценарій
не готовий зафіксувати відповідальність і критерії результату
До старту партнерства варто погодити роль, частку або опціон, права на розробки, порядок прийняття рішень, умови виходу та спосіб розв’язання конфліктів.
Чому інтелектуальну власність потрібно фіксувати з першого дня
У DefTech-проєкті код, креслення, конструкція, дані, моделі й результати випробувань можуть створювати різні люди та компанії.
Без документів складно довести, кому належать ці активи. Це створює проблеми під час грантової заявки, залучення інвестора, створення окремої компанії або виходу на інші ринки.
Команді варто зафіксувати:
хто створив кожен компонент
на яких умовах передано права
яка компанія володіє розробкою
як використовуються дані
які обмеження встановлює NDA
що відбувається з правами після виходу учасника.
Для підрядників та інженерів потрібні договори про передачу майнових прав. Для партнерів і співзасновників потрібні окремі умови щодо часток, опціонів та виходу.
Як IT-компанії тестувати DefTech-напрям
Сервісна компанія може дати новому проєкту людей, інфраструктуру, контакти й перший бюджет. Водночас DefTech-продукт потребує іншого циклу розробки, фінансування та юридичного оформлення.
На старті можна використати ресурси чинного бізнесу для дослідження й першого прототипу. Після підтвердження напряму доцільно створити окрему структуру та передати їй права на розробку.
Такий підхід допомагає:
бачити реальні витрати нового проєкту
розділити відповідальність команд
підготувати зрозумілу структуру для інвестора
контролювати передачу інтелектуальної власності
зберегти керованість сервісного бізнесу
Власнику також потрібно визначити людину, яка керуватиме основною компанією під час його переходу в DefTech. У кейсі Дмитра частка часу на новий проєкт зростала поступово: від обмеженого залучення на старті до основного робочого фокусу після підтвердження напряму.
Для такого переходу варто заздалегідь встановити:
бюджет першої перевірки
склад команди
частку часу засновника
критерій продовження проєкту
умови створення окремої компанії
порядок переходу працівників і розробок
Що показати грантодавцю або інвестору
Опис ідеї дає мало підстав для фінансування. Сильнішу позицію створює практичний доказ.
На ранньому етапі ним може бути:
прототип критичної функції
зафіксований результат контрольованої перевірки
відгуки профільних користувачів
опис сценарію застосування
перелік технічних обмежень
бюджет наступної ітерації
план випробувань
Перший доказ не обов’язково потребує повної системи. У випадку Panoptes команда спочатку перевірила здатність станції супроводжувати невеликий дрон у контрольованих умовах. Цього вистачило, щоб підтвердити технічний напрям і перейти до складніших ітерацій.
Кожна наступна витрата має відповідати на конкретне запитання. Чи працює ключова функція? Чи витримує виріб потрібні умови? Чи інтегрується він з іншою системою? Чи може команда повторити результат?
Такий підхід допомагає обґрунтувати бюджет і визначити, які компетенції потрібні на наступному етапі.
Робочий орієнтир на перші 90 днів
За три місяці IT-підприємець може перевірити основу майбутнього DefTech-проєкту.
Перші 30 днів
обрати вузький напрям
знайти повторювану проблему
провести інтерв’ю з користувачами й експертами
описати сценарій застосування
визначити технічні та безпекові обмеження
Наступні 30 днів
сформувати концепцію
визначити критичну функцію
скласти вимоги до першої версії
залучити потрібного інженера, радника або підрядника
підготувати контрольовану перевірку
Останні 30 днів
провести тест
зафіксувати метрики та фідбек
визначити технічні прогалини
скласти бюджет наступної ітерації
ухвалити рішення щодо партнера й команди
Результатом такого циклу стають докази для наступного рішення: продовжувати розробку, змінити концепцію, залучити партнера або закрити гіпотезу до більших витрат.
Як пройти цей шлях на DefTech Sprava
На програмі DefTech Sprava ви працюватимете зі своєю ідеєю або продуктом: перевірите потребу серед користувачів, сформуєте концепцію й технічні вимоги, визначите склад першої версії та підготуєте план перевірок.
Окремі блоки присвячені команді, партнерству, інтелектуальній власності, юридичним обмеженням, фінансовій моделі та плану розвитку. Результат залежатиме від вашої стартової точки, технічної бази, складу команди й ресурсів.
Солоучасник зможе визначити, кого залучити до проєкту та на якому етапі. Команда розподілить ролі, відповідальність і наступні кроки.
Коментарі