Ну и самый спорный тезис, который хочу высказать по теме "Оружие победы".
Система, если взять её в сегодняшнем виде, оперирует категорией "изделие" — оценивает ТТХ, проводит НИРы и ОКРы, выдаёт литеры, ставит на вооружение и т.д.
Но на войне даже в большей степени, чем в мирной жизни, работает маркетинговая банальность — "люди покупают не дрели, а дырки в стене". Применительно к армии — она "покупает" не оружие, а дырки в боевых порядках противника.
Качественный скачок произойдёт тогда, когда получится научить систему оперировать не "изделиями", а "решениями".
Это очень просто — есть задача, и есть набор технических средств для её решения, работающих с разной эффективностью, которая меняется по мере того, как, к примеру, противник изобретает средства противодействия. Собственно "изделие", отвечающее за реализацию решения, в процессе может изменяться довольно сильно, вплоть до неузнаваемости. Но остаётся Главный Конструктор, который отвечает за то, что новая версия решения справляется с поставленной задачей лучше, чем старая. Или, если задача видоизменена либо поставлена новая, что его решение вписывается в эту задачу.
Если, опять-таки, брать за пример дрон КВН, надо сказать, что за 9 месяцев активного применения он претерпел несколько изменений, подчас довольно радикальных. Те дроны, которые поступают в войска сейчас, это по целому ряду параметров другие изделия, чем те, которые приехали в августе на курский фронт. И этот процесс всё время продолжается и будет продолжаться. Но, к примеру, в логике Гособоронзаказа такое попросту невозможно — каждое существенное изменение в конструкции, софте, системе управления и т.д. означало бы прохождение всей процедуры заново.
Обратите внимание, какое количество оружия и техники с "дополнительными буквами", чаще всего типа "М" (модернизированное, Т72Б3М, моярыдалъ) — это как раз когда в конструкцию внесены изменения, и оружейникам пришлось оформлять его как новое изделие, поскольку глазами военной приёмки это уже нечто другое, чем было. Но каждая такая "буква" — это месяцы, а то и годы сложной и громоздкой процедуры.
Пока не очень понятно, как должна работать процедура при переходе от логики "изделий" к логике "решений". На ум приходит только метафора рынка софтверных (да и хардверных — взять тот же айфон) продуктов с его концепцией "версий" — вот есть, к примеру, windows или iOS такой-то версии или сякой, но любая из них это именно windows или iOS. В целом, это проблема "управления изменениями", она же "управление жизненным циклом продукта", и тут более чем уместна конверсия гражданских организационных технологий в военную сферу. Апдейты, патчи, альфа- и бета-релизы, "переходные" версии (не 2.0, а 1.5), возможность отката к предыдущей версии в случае, если новая признана неудачной, спинофф-версии (специализированные сборки для отдельных категорий пользователей с особыми запросами), пользовательские конференции, сбор и обработка пожеланий к следующему апдейту — всё как в нормальной софтверной индустрии. Вплоть до открытого (условно, конечно) кода и "репозиториев" с пользовательскими "примочками" к базовому продукту в рамках единой экосистемы — эдакий военный Гитхаб.
Офф. Вот бы, к примеру, было круто, чтобы к дронам на оптике какая-нибудь независимая софтверная компания написала модуль дополненной реальности, где оператору прямо на экране стрелочками показывать, куда лететь и где цель, с указанием расстояния до неё и прогнозом расхода лески и аккумулятора. Дроноделам это делать особо некогда — они всё-таки в первую очередь дроноделы, а не айтишники. А вот любая IT-контора, минимально умеющая в AR — вполне на такое способна. Причём это нужно не как часть базового софта, а именно как подключаемый (и отключаемый) модуль, виджет. И такого типа задач — "на столе" много, они возникают буквально каждый день.
Это, что называется, "на подумать".
