Про черепаху. Весёлая карусель №11 1980 © (реж. А. Петров)
Всем, кто когда-либо касался радиоэлектроники, хорошо известны понятие макетирования и польза применения макетных плат. Когда решение только появляется голове, нет никакого смысла отливать сразу все в бетоне. От первой идеи до финального результата может пройти не один эксперимент, может многократно поменяться элементая база, по результатам первичных проверок и исходная постановка может претерпеть значительные изменения.
Степень автоматизации и цифровизации в современных компаниях достаточно велика. Фактически, можно говорить о двух плоскостях: плоскость материальных процессов и объектов (машины, каналы, вышки, вагоны, печи, ...) и плоскость цифровых потоков. Различные мобильные приложения, без ограничения общности, для пользователей мы можем рассматривать как «удлинитель» до материальных процессов. Для обеспечения качества и непрерывности материальных процессов необходимо обеспечивать полноту и актуальность соответствующих цифровых потоков, а также оперативно отвечать на вопросы, возникающие у представителей бизнеса.
Учитывая требуемую оперативность ответов, а также скорость изменений в окружающем мире, классический enterprise интеграционный подход с многолетними процедурами выбора решения и потом его долгого внедрения оказывается малопригодным. Да и собственную разработку стартовать на каждый запрос от бизнеса — тоже ничуть не быстрее и не дешевле.
Проведение аналогий с радиоэлектроникой позволяет найти неплохое решение.
Рассмотрим типичный процесс в компании масштаба M+. Возникает потребность от бизнеса. Совсем общая. «Плохо работает...», «Надо бы что-то сократить на 20%...», «Конкуренты атакуют...», «Хочу на карте...», «Сроки отрапортованы, нужен результат...» и т.п. Создается рабочая группа, подключаются аналитики, архитекторы, инфраструктурщики, группа закупок,… Никто точно не знает, что надо получить и как решать. Но у каждого есть свой набор разрешенных инструментов и есть ряд согласованных процедур по проведению тендера, разработке требований, внесению изменений, разработке, доработке и т.п. Начинаются бесконечные совещания (пусть даже в agile формате) по созданию чего-то глобального, отвечающего на исходный запрос или чуть больше/шире.
Отмечу, что речь идет не о проектах типа «YAP» (Yet Another Portal), «YAD» (Yet Another Docflow) и подобных тем, изъеженных вдоль и поперек. Речь о чем-нибудь новеньком для компании. Какая-нибудь Афиша, какой-нибудь VSM, какой-нибудь поведенческий анализ, какая-нибудь HR аналитика, какая-нибудь умная система управления парком умного оборудования, какой-нибудь copilot, ...
Месяц, два, полгода, год… Процесс идет, вовлекается все большее количество людей, появляются бюджетные оценки, они не устраивают, начинаются утрамбовки. По рынку уже идут слухи, что «В компании N планируется классный проект M», собираются интеграторы со своими предложениями… Платформы, фреймворки, интеграции, озера данных… Процесс кипит!
За это время случился COVID, два раза сменился CIO, произошел делистинг компании, уволилась половина сотрудников, сервера купить нельзя, IBM ушел,…
Процесс идет!
Исходный запрос давно уже потерял актуальность. Финансов на эту деятельность пожгли не один человеко-год. Процесс есть, результата нет. Начальники отдела, корпоративные архитекторы, тимлиды НЕ должны, НЕ могут ошибаться — это признак их тотального непрофессионализма. Надо все подстраховать, риски разложить по корзинам, соломку подстелить.
Можно ли что-то изменить? Легко!
Достаточно вспомнить что угодно из не ИТ-шного настоящего или исторического прошлого. Кружки моделистов, радиоэлектроники, R&D лаборатории. Стартапы не трогаем, там другая цель и модель.
Снятие бюрократического и архитектурного обвеса, долженствования непогрешимости, возвращение R&D именно в контексте research позволит быстро и оперативно проверять гипотезы, делать предварительные оценки и принципиальные макеты. Смотреть вместе с бизнесом на макет, собранный «на коленке» при помощи проволоки и изоленты, оценивать востребованность результатов, корректность исходной постановки задачи, полноту и достаточность имеющихся данных, оценивать приемлемую и достаточную точность, делать замеры по производительности и точно оценивать требуемые вычислительные мощности.
Немного затрагивал тему здесь: «Data Science — это не только подсчет пельменей…».
Характерный масштаб интеграторской деятельности или промышенной разработки — 1 год, 20-30 человек. Характерный масштаб Data Science R&D — 1 месяц, 2-3 человека. Есть разница? Два порядка.
При работе в цифровой плоскости data science стек позволяет получить максимум выгоды от прототипирования и макетирования. Есть ВЕСЬ спектр бесплатных инструментов по интеграции, алгоритмике, преобразованию визуализации. Фокус на вопросе «что нужно и как оптимально достичь?» Не заниматься на бесполезных совещаниях досужими размышлениями и допущениями, взятыми с потолка. Есть вопрос — идем, берем данные, измеряем, считаем. Не бояться экспериментировать. Да, много экспериментов будет неудачными. DS может ошибаться, для корпоративного архитектора это смерти подобно. Но это кратно дешевле, чем совещаться толпами и не выдавать результата.
- Хотим площадную закраску на карте — это всё? Так зачем нам для этой цели ГИС, shape файлов достаточно.
- Как делать интеграцию с ERP? Да никак, получим выгрузку, все равно в базу не пустят. Давайте фокусироваться на том, сможем ли мы принципиально решить эту задачу или там ничего нет.
- Как в продуктиве мы будем данные забирать у этого партнера? А оно сейчас важно? За прошлый год партнеры два раза сменились уже. Давайте сфокусируемся на полноте и корректности данных, даст ли нам глубокая интеграция что-то важное?
- Для запуска рекомендательного сервиса нужно копить статистику год? Давайте делать более простую модель, но с запуском сейчас. Потом разберемся. Глядишь, весь товарный ряд изменится, а права на показ фильмов заберут.
- Надо сначала построить онтологию и модель данных! Да? Как, вы еще не смотрели и не читали, но уже про модель обсуждаете? Давайте посмотрим сначала, что нам вообще дадут. Обычно дают мусор.
- У нас есть быстрый насущный вопрос (теряем деньги) и большая космическая цель… Давайте космическую цель отнесете в КБ, а насущный вопрос просто решим здесь и сейчас. Если в борту дыра, то полезно ее обследовать и закрыть. Глядишь, при обследовании станет понятно почему она возникла и как дальше не допускать подобного.
- Шина может не выдержать такую нагрузку! А вы знаете какая нагрузка будет? Нет? Может сначала посмотрим и прикинем? С карандашиком в руках.
Корней Чуковский
Бебека
Взял барашек
Карандашик,
Взял и написал:
«Я — Бебека,
Я — Мемека,
Я медведя
Забодал!»
Испугалися зверюги,
Разбежалися в испуге.
А лягушка у болотца
Заливается, смеётся:
«Вот так молодцы!»Не буду цитировать Алису в Зазеркалье, все и так знают.
Предыдущая публикация — «Сателлит «R Markdown» — что на обратной стороне?».