«Роботу трьох бійців можна замінити одним скриптом». Lead QA Room 8 про автоматизацію процесів у полку УСБС «Фенікс»
Володимир Бортюк відомий геймдев-спільноті насамперед як відеооглядач та стример. Разом з тим, його ім’я є в титрах Assassin’s Creed Odyssey та інших міжнародних проєктів Ubisoft Kyiv, Dragon’s Lake Entertainment і Room 8 Group. Вже майже півтора року він служить в одному з найрезультативніших підрозділів ДПСУ, який перебуває в оперативному підпорядкуванні командувача СБС ЗСУ. Володимир працював на командному пункті, координував бойову роботу підрозділів та розробляв інструменти для автоматизації рутинних бюрократичних процесів.
Ми поговорили з ним про роботу стримера ISTAR, про те, як QA-мислення допомагає оптимізувати завдання, чому армії критично бракує бізнес-аналітиків та що у війську робити 3D-художнику чи левел-дизайнеру.
«Повноцінно освоїтися в новій ролі Lead QA/SDET я не встиг». Про кар’єру в геймдеві
Усе закрутилося у 2017 році. Я працював системним адміністратором і побачив вакансію в Ubisoft Kyiv. За два з половиною роки я виріс від інженера з геймтестування до девтестера. За цей час встиг долучитися до розробки Assassin’s Creed Odyssey, Trials Rising і трохи попрацювати над Skull & Bones.
Починав із тестування та портування на ПК, а також трохи працював із Nintendo Switch. Але це був «хитрий» Switch. Тоді ми одними з перших в Ubisoft (та й загалом в індустрії) мали справу з хмарними портами для цієї консолі. Відповідно, Assassin’s Creed Odyssey для Nintendo Switch стала одним із перших таких проєктів. Вже потім на цій технології виходили Control і Resident Evil 7.
Після Odyssey я перейшов до команди девтесту проєкту Trials Rising. Гра виходила практично на всіх платформах: ПК, Nintendo Switch, PlayStation, Xbox. Навіть у Google Stadia. Коли ми передали проєкт на довгострокову підтримку, команда взялася за Skull & Bones. У підсумку вже після мого звільнення колеги довели гру до релізу.
Далі трохи працював у різних навколоігрових компаніях. Зокрема у фірмі, що розробляла програмне забезпечення та прошивки для геймерської периферії. Зрештою долучився до Dragon’s Lake Entertainment, де переважно займався портами. Ми співпрацювали з Deck Nine та Square Enix над Life is Strange 2 — портували гру на Nintendo Switch і Stadia. Роботу було повністю завершено, ми пройшли всі сертифікації, але буквально за місяць до релізу на Stadia нам повідомили: «Ми закриваємо платформу». Звісно, роботу виконали, рахунки оплатили, але все одно було трохи прикро.
Також у Dragon’s Lake я працював над портами для Supermassive Games. Ми портували дві частини антології The Dark Pictures на Nintendo Switch. Якщо в Ubisoft це була глибша робота з геймплеєм, то тут — суто техарт. Ми намагалися «запхати невпихуване» й адаптувати гру під консоль із дуже обмеженими ресурсами. Нашим техартистам вдалося зробити майже неможливе:
«Після релізу Man of Medan ми бачили на Reddit коментарі на кшталт: „Нічого собі, на Switch вона виглядає краще, ніж на моїй PS4!“. Для нас це була надзвичайно висока оцінка»
До речі, Man of Medan став одним із найцікавіших проєктів із погляду комплаєнсу з Nintendo. Це був мій перший досвід, коли ми отримали офіційний вейвер через те, що частота кадрів була нижчою за 30 FPS. На момент релізу ми фізично не могли оптимізувати гру до 30 кадрів на секунду, тому зупинилися на «кінематографічних» 24 FPS. Щоб пройти сертифікацію, знадобився окремий дозвіл від Nintendo, а також низка попереджень на сторінці гри про те, що вона працює з частотою 24 кадри на секунду. Це був дуже цікавий досвід.
Після The Dark Pictures у мене було ще кілька проєктів під NDA, які досі не вийшли. У результаті реструктуризації я опинився в материнській компанії Room 8 на перехідній посаді — від Lead QA до SDET (Software Development Engineer in Test). Саме тоді я мобілізувався, тож повноцінно освоїтися в новій ролі вже не встиг. Відтоді я вже рік і чотири місяці служу у війську.
«Фактично це щось середнє між оператором кол-центру та таск-менеджером». Про особливості роботи стримера на командному пункті
Я вважаю себе лінивою людиною, тому завжди намагаюся знайти слабкі місця й оптимізувати процеси, щоб працювати менше, але ефективніше. Раніше полегшував собі життя різними «милицями» — макросами та скриптами. Тепер, коли досвіду побільшало, можу з кількох інструментів і скриптів зібрати повноцінне рішення для автоматизації.
На початку служби та під час підготовки на полігоні без автоматизованих систем усе відбувається за принципом «гасіння пожеж»: що сьогодні на тебе звалилося, тим і займаєшся. Про якесь довгострокове планування годі й говорити. Але коли потрапляєш до конкретного підрозділу й стикаєшся із щоденною рутиною, QA-мислення дуже допомагає.
«Ось тут і знадобиться розуміння того, що роботу трьох бійців можна замінити одним скриптом, написаним за пів години»
Це дає змогу виконувати завдання якісніше й водночас звільняє людей від безглуздої рутини для справді важливих завдань.
Як спеціаліст ISTAR, або просто стример, я своєрідний диспетчер чи таск-менеджер. Я маю чітко розуміти, які сили та засоби перебувають в оперативному підпорядкуванні. Я не можу віддавати прямі накази бійцям — наприклад, пілотом екіпажу може бути двічі Герой України, а я лише солдат. Проте саме командний пункт у межах оперативного управління визначає цілі та пріоритети роботи.
Головне завдання стримера — тримати в голові актуальну картину бою й досконало знати свою зону відповідальності. Не менш важлива частина роботи — комунікація із суміжними підрозділами. На лінії зіткнення ви не самі: поруч працюють інші екіпажі безпілотників, артилерія, піхота. Треба постійно координувати дії, знати, хто де перебуває — і в повітрі, і на землі.
Фактично це щось середнє між оператором кол-центру та таск-менеджером. У періоди активних боїв, коли поруч діяло багато різних підрозділів, на моєму робочому місці було вісім різних мікрофонів — для восьми окремих каналів зв’язку. На кожному була наліпка з назвою підрозділу, і я постійно узгоджував із черговими, хто летить, хто працює і яка ситуація на ділянці.
Другий важливий аспект роботи стримера — вміння миттєво орієнтуватися на місцевості за відеозображенням. Більшість розвідувальних дронів літають із вимкненим GPS, щоб уберегтися від засобів РЕБ і супутникового спуфінгу. На початку повномасштабної війни всі літали з увімкненою навігацією, але DJI має цивільну систему AeroScope, яка сканує простір і показує точки зльоту та координати пультів керування.
Для цивільної безпеки аеропортів це чудове рішення, але в умовах бойових дій — смертельно небезпечне. Якщо AeroScope фіксує точку зльоту, туди майже миттєво може прилетіти що завгодно — від КАБів до «Іскандерів». Тому зараз літають фактично наосліп. За таких умов оперативний черговий має за п’ять секунд відеостриму з дрона зрозуміти, що це за посадка, де вона розташована та в якому напрямку рухається техніка чи особовий склад.
За кілька тижнів роботи в режимі 24/7 у нас із колегами це чуття розвинулося настільки, що ми визначали координати з точністю до п’яти метрів лише за картинкою. Причому зображення з різних типів безпілотників і тепловізорів виглядає зовсім по-різному.
Робота оперативного чергового — це безперервна аналітика та координація в режимі реального часу. А після бою потрібно відтворити хронологію всіх подій для звітності, журналу бойових дій та аналізу ефективності.
Теоретично в майбутньому процес верифікації можна буде автоматизувати за допомогою ШІ, але на практиці все впирається в неідеальність умов на фронті. Штучний інтелект чудово впорається, якщо картинка якісна й чітка. Проте більшість уражень на відео виглядають як скупчення кількох розмитих пікселів, оскільки ми спостерігаємо за процесом через систему стримінгу.
Камера на дроні може знімати в розкішній якості 4K або навіть вище. Якщо записувати відео безпосередньо на внутрішню SD-картку, зображення буде майже ідеальним. Але на позиціях ніхто не має часу чи можливості діставати ці картки. До того ж обсяги даних величезні, а зі зв’язку в найкращому випадку є Starlink, у найгіршому — нестабільний мобільний інтернет. Тому відеопотік стискають, щоб заощадити трафік. В нашу систему ситуаційної обізнаності «Дельта» транслюється відео з роздільною здатністю 720p і частотою близько 20 кадрів на секунду.
Спочатку картинка стискається під час бездротової передачі з дрона на пульт керування. Потім — ще раз, коли її передають із пульта на сервер. І нарешті оперативний черговий записує цей стрим із екрана свого ноутбука, що додає третій етап. Після такого багаторазового перекодування будь-який штучний інтелект лише розведе руками й скаже: «Я не знаю, що це: дерево, бліндаж чи ворожа техніка». А людське око завдяки досвіду й розумінню контексту бою здатне це розпізнати. Тож поки що ручна перевірка залишається найнадійнішим варіантом.
Можливо, згодом ми перейдемо до використання автономних дронів-ретрансляторів, які самостійно наближатимуть ціль, зніматимуть усе в надвисокій якості, локально аналізуватимуть результат і надсилатимуть на базу лише короткий звіт про успішне ураження. Але поки ми воюємо на дронах за
«Маємо те, що маємо. Посадити навченого солдата за монітор досі банально дешевше й ефективніше»
«Військо — буткемп, де функціонують мільярди мікростартапів». Про роботу аналітичного відділу та ефективність «Фенікса»
Якщо роботу операторів і командного пункту всі бачать і більш-менш розуміють, то аналітичний відділ для багатьох залишається «невидимим фронтом», де нібито просто «перекладають папірці». Насправді ж ми займаємося повним обліком та аналізом усього, що відбувається у підрозділі: від майна й особового складу до детального аналізу бойової роботи.
Ми фіксуємо, скільки безпілотників запустили за день, який у них статус, чи успішно вони відпрацювали, чи були збиті або вийшли з ладу через технічні несправності. Ця статистика дозволяє бачити динаміку. Наприклад, якщо прогнозуємо пожвавлення бойових дій, завчасно ініціюємо доставлення додаткових дронів на позиції.
Аналітика потрібна і для звітування перед вищим командуванням. Коли хтось із військових чиновників запитує, чому цього місяця ми уразили менше цілей, ми маємо чітку відповідь, підкріплену цифрами: наприклад, у лютому — на три дні менше, тому й менше цілей.
Особисто я в аналітичному відділі займаюся підготовкою звітів та автоматизацією рутинних завдань для колег. У середньому ми посідаємо третє місце серед усіх підрозділів безпілотних систем ЗСУ та стабільно тримаємося в топ-2 усередині УСБС. Водночас наша головна перевага — ефективність. Якщо аналізувати Сили безпілотних систем загалом, існує базовий показник: скільки людей потрібно для забезпечення одного вильоту й одного ураження. За офіційними даними «Мадяра» та інших командирів, у середньому по УСБС це близько
Завдяки оптимізації процесів усього
Є ще один цікавий факт про нашу ефективність: ми єдині в структурі УСБС, хто досі має статус полку, а не бригади. Водночас показуємо результати на рівні великих бригад. Ми щодня працюємо над тим, щоб покращувати ці показники й робити так, аби наші дрони літали ще далі та влучали ще точніше.
Багато процесів в УСБС не створювалися з нуля, адже це частина вже наявної військової структури. Все часто впирається в те, що командування умовно поділяється на бойове й кадрове. Це вічне протистояння підходів. Кадрові офіцери вимагають суворого дотримання статуту, тоді як бойове крило зосереджується на реальній ефективності й тому, як усе працює на практиці.
Тому, як і всюди в армії, це переростає в певну «політичну» історію. Люди, які мають експертизу й справді вміють робити свою справу, намагаються переконати консервативніше командування в доцільності нових технологічних рішень. Коли керівництво, яке спочатку скептично ставилося до нововведень, бачить реальні цифри уражень, воно погоджується: «Гаразд, це працює. Впроваджуємо». Так, крок за кроком, нам вдається просувати зміни.
Проте для реальних зрушень на різних рівнях потрібні ініціативні люди, яким «найбільше треба» і які готові особисто рухати ці ідеї. Коли набирається критична маса таких однодумців, процес нарешті зрушує з місця.
Якщо ж говорити про атмосферу стартапу, то головна проблема армії, як і будь-якої великої корпорації, — людський чинник. Завжди є ті, хто працює на спільний результат, і ті, хто більше переймається демонстрацією власної значущості. Сьогодні військо загалом — це величезний буткемп, у якому функціонують мільярди мікростартапів. Кожен розробляє щось своє й по-своєму. На вищих рівнях, зокрема в УСБС, ці процеси стають більш уніфікованими, а підрозділи поступово займають конкретні технологічні ніші.
Та через брак прозорої комунікації й системного обміну досвідом виникають абсурдні ситуації. Десять команд незалежно одна від одної намагаються розв’язати проблему, яку одинадцята вже давно вирішила. Але про це ніхто не знає, бо суміжники не діляться напрацюваннями за принципом: «Це наша розробка, ми нікому нічого не скажемо». Це нерозумно, але така реальність.
Зараз держава намагається покращити ситуацію, та й самі військові на середній ланці дедалі краще розуміють критичну потребу в обміні досвідом. Поки глобальна бюрократична модель армії не зміниться, процеси й надалі працюватимуть у такому компромісному форматі. Чи добре це? З одного боку, децентралізація породжує багато унікальних і сильних рішень. З іншого — ми втрачаємо час. Якби всі працювали в межах єдиної жорсткої вертикалі, це могло б або дати чудовий результат, або повністю заблокувати будь-яку творчу ініціативу, бо «все вже вигадано до нас». Тож однозначної відповіді тут немає.
«Мій сервіс вивільнив для медіавідділу близько 72 людино-годин на тиждень». Про автоматизацію процесів всередині та перші результати
Мені простіше витратити пів дня на автоматизацію процесу, ніж щодня по годині виконувати одноманітну рутинну роботу. Саме так у нас з’явився бот, який працює з Журналом бойових дій (ЖБД) та автоматизує облік бортів. Найбільша складність під час розробки таких інструментів — людська непередбачуваність. Якщо створювати софт, розраховуючи лише на ідеальний сценарій використання, він «ляже» вже в перший день. Користувачі обов’язково зроблять усе навпаки.
Мій досвід у тестуванні допомагає заздалегідь бачити, де користувач може помилитися, і закладати відповідні запобіжники в код. Але навіть я іноді дивуюся тому, наскільки винахідливо люди примудряються припускатися помилок.
Наприклад, класична історія: вносимо в систему дрон Mavic 3T, де літера «T» має бути латинською, але хтось умудряється посеред слова вставити кириличну «Т». Або все написано правильно, але парсер однаково видає помилку. Починаєш розбиратися, а в слові Matrice замість латинської i стоїть українська «і». Як людина примудрилася перемкнути розкладку клавіатури посеред слова — загадка.
Крім того, люди часто намагаються обійти правила. Наприклад, у нашому цифровому Журналі бойових дій суворо заборонено видаляти чи редагувати повідомлення — можна лише додавати уточнення повідомленням-відповіддю. Якщо припустився помилки, маєш написати: «Уточнення: виїхав такий-то екіпаж замість такого-то на такій-то машині». Це прозоро й правильно. Проте користувачі все одно намагаються щось видалити чи тихцем переписати. Програма має це враховувати й блокувати такі спроби.
Водночас військові цифрові системи самі по собі не завжди стабільні. Якою б якісною не була автоматизація, завжди має залишатися можливість ручного коригування.
«Логи та можливість ручного втручання — це наше все»
Трапляється, що бійці випадково прив’язують уточнення не до тієї довідки, дані викривлюються, вони це помічають і видаляють запит, а парсер уже все зафіксував. У таких випадках без ручного аналізу логів просто не обійтися.
Навіть якщо автоматизація здається надто нішевою чи простою, її все одно варто робити. Рано чи пізно прийде колега із сусіднього відділу з аналогічною проблемою, ти даси йому готовий інструмент, а він скаже: «Чоловіче, ти щойно заощадив мені два тижні життя!». Коли розумієш, що завдяки твоїй десятихвилинній роботі людина обробляє величезний масив даних за хвилину, а не колупається в таблицях вручну тижнями, це справді мотивує.
Головне правило розробки в армії — робити інтерфейси максимально простими й інтуїтивно зрозумілими, щоб людина могла користуватися ними без жодних інструкцій. І, звісно, не боятися ділитися своїми напрацюваннями з іншими підрозділами.
Зараз у нас працює система парсингу, яка аналізує повідомлення з робочих чатів за заданими шаблонами. Вона автоматично витягує всі дані, що стосуються бойових звітів, втрат майна та технічного стану бортів. Також я створив інструмент для нашого медіавідділу. Він сканує локальний Журнал бойових дій, самостійно знаходить усі відеозаписи успішних уражень і зберігає їх на внутрішньому файловому сервері, автоматично розкладаючи по теках із правильними назвами.
Тепер, якщо пресофіцерам потрібно знайти конкретне відео або зібрати всі успішні вильоти окремого пілота (наприклад, щоб привітати його з днем народження чи підготувати матеріали до нагородження), достатньо просто ввести його позивний у пошук і система миттєво видасть усі його найкращі ураження.
Раніше цією монотонною роботою фактично на повну зайнятість займалися двоє людей з медіавідділу. Вони вручну зберігали, систематизували та перейменовували файли. Тепер усе відбувається у фоновому режимі. У результаті вдалося звільнити фахівців, які перемкнули свою основну увагу на інші важливі завдання. Загалом мій сервіс вивільнив для медіавідділу близько 72 людино-годин на тиждень.
В армії часто простіше просто «завантажити роботою солдата». Але коли виникають нові завдання, виявляється, що всі люди зайняті механічною роботою, яку давно можна було автоматизувати.
«Якщо людина з ІТ чи геймдеву має клепку в голові, її суперсила — уміння розв’язувати нестандартні й неочевидні завдання». Про єБали та спеціалістів, яких бракує
Певною мірою це дуже схоже на роботу рейд-лідера (Raid Leader) у World of Warcraft або координатора в Lineage. Тобі доводиться одночасно тримати під контролем безліч процесів. В іграх у тебе є хілери, DPS, танки, а тут — розвідувальні та ударні екіпажі.
Ти маєш постійно стежити за ситуацією. Наприклад, бачиш, що в нашого розвідувального дрона сідає батарея, а другий борт не встигає. Треба або тримати дрон над ціллю та ризикувати потенційно втратити його заради підтримання «каруселі», або просити суміжників підстрахувати й підсвітити ціль.
Якщо працюємо за відеотрансляцією суміжних підрозділів, потрібно постійно підтримувати з ними зв’язок: «Хлопці, у вас батареї залишилося на п’ять хвилин. Вас хтось замінить чи нам піднімати свій борт для підсвічування?». Це дуже динамічний і напружений процес координації.
Потрібно вміти аналізувати великі обсяги інформації та виявляти закономірності в діях ворога. Навіть навички швидкого зчитування координат допомагають. За місяць безперервної роботи ти вже автоматично за першими цифрами розумієш: «Ні, 4700 — це вже не наш квадрат, туди навіть дивитися не варто». Здавалося б, що заважає просто скопіювати координати й вставити їх у карту? Але на практиці секунди вирішують усе.
Також мені дуже згодився мій минулий досвід із відеомонтажем. Я навчив своїх колег користуватися простим відеоредактором CapCut. У системі верифікації уражень за програмою «Лінія Дронів» («єБали») діють дуже суворі правила підтвердження результатів.
Щоб ураження зарахували, потрібно надати три ключові докази. Найважливіший із них — запис безпосередньо з засобу ураження (FPV-дрона, важкого бомбера тощо). Без цього неможливо довести, що ціль знищив саме твій підрозділ. Адже я можу записати на Mavic, як хтось інший підірвав техніку, і сказати: «Це наша робота». Перевіряючий одразу запитає: «А де запис із самого FPV?» Якщо його немає — результат не зарахують.
Потрібен і сам момент влучання, і підтвердження детонації, адже дрон міг просто врізатися й не вибухнути. Коли ворог біжить відкритим полем і відбувається чіткий вибух, питань не виникає. Але часто ураження доводиться підтверджувати в складних умовах — під деревами чи в окопі. Я, як людина, яка супроводжувала цю ціль, чітко бачу: ось силует бронетехніки, ось момент влучання, ось уламки.
Натомість верифікатор переглядає сотні таких відео щодня. Після кількох годин безперервної роботи очі просто втомлюються, і фізично неможливо роздивитися кожну деталь на замиленому зображенні. Тому ми почали використовувати CapCut: наближаємо ключові моменти, додаємо стрілки, робимо стоп-кадри. Здавалося б, дрібниця, але це суттєво спрощує взаємодію та пришвидшує підтвердження результатів.
Те саме стосується й підготовки польотних завдань для екіпажів. Оскільки вони літають без GPS, їм потрібні чіткі візуальні орієнтири. Ми робимо скриншоти з розвідувальних дронів, наближаємо потрібні ділянки, додаємо позначки й пишемо: «Ось тут три високі дерева, за ними — менші. Вам туди». Навички QA — швидко зробити скриншот, зрозуміло його розмітити й миттєво відправити в чат — теж виявилися дуже корисними в щоденній роботі.
По суті, не лише в УСБС, а й загалом у війську критично бракує якісних бізнес-аналітиків.
«Будь-яка війна — це набір процесів, у яких завжди є свої bottlenecks, які можна оптимізувати й хакнути»
Нам дуже потрібні люди, здатні бачити процес цілісно — від початку до кінця — і розуміти його глибинну логіку.
Іноді стикаєшся з речами, які організовані відверто безглуздо, але банально немає кому навести лад. Ба більше, навіть якщо ініціативний боєць намагається щось змінити, він часто перебуває на занадто низькій посаді, щоб його голос почули. У нашому суспільстві є певна упередженість до поняття «ефективний менеджмент», але саме його грамотне впровадження сьогодні життєво необхідне армії.
Величезна кількість безглуздої роботи виконується лише тому, що «колись так наказали». Потрібно сісти й розібратися: чи справді цей етап необхідний, чи система не зламається і без трьох додаткових кроків, які давно застаріли та стали непотрібними. Таких аналітиків дуже мало.
Звісно, більшість фахівців, які хотіли мобілізуватися, уже у війську. Проте є й ті, хто хоче допомогти, але вагається, хоча роботи для них — неозоре поле. Я теж свого часу пасивно готувався: волонтерив, працював, але під дверима військкомату не стояв. Коли ж настав час, усе склалося дуже швидко: зі мною зв’язалися рекрутери полку «ФЕНІКС», запропонували приєднатися, і я погодився.
У війську потрібні фахівці практично всіх спеціальностей. Наприклад, людина може думати: «Я 3D-художник чи левел-дизайнер — що мені робити в окопі?». По-перше, ваші навички структурування простору й організації роботи знайдуть своє застосування. По-друге, у підрозділах безпілотних систем активно використовують 3D-друк для виготовлення комплектуючих та елементів боєприпасів. Там потрібно проєктувати моделі, оптимізувати топологію сітки тощо. Здавалося б, де геймдев, а де 3D-друк бойових засобів? Але на практиці ці сфери безпосередньо перетинаються.
Якщо людина з ІТ чи геймдеву має клепку в голові, її суперсила — уміння розв’язувати нестандартні й неочевидні завдання. А саме з таких завдань і складається військова рутина. Це вміння полегшує життя і вам, і вашим побратимам. Тому не варто боятися йти до війська — тут не так страшно, як може здаватися зі сторони. Платформи на кшталт Lobby X чи власні рекрутингові сайти підрозділів постійно шукають кваліфікованих людей. Нам потрібні ваші мізки.
Немає коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів