Аналитик в IT: кто это такой и почему без него не запустить ни один "финтех" проект
В этом выпуске подкаста мы разбираемся, как разработчики понимают, что и как им делать. Нашим гостем стал Игорь Мохов, аналитик с нестандартным путем в IT — из сферы технической безопасности.
Мы обсудили:
Личный путь: Как Игорь сменил профессию в 30+ лет и почему выбрал именно аналитику, вспомнив свой опыт написания кода еще в университете.
Суть работы аналитика: Чем на самом деле занимается этот специалист? Игорь выделил три ключевые функции: общение с заказчиком, чтобы понять его истинные потребности; глубокий анализ и проработка алгоритмов; и ответственность за проект «от и до» — от сбора требований до успешного выхода в продакшен.
Ключевые различия: Чем бизнес-аналитик отличается от системного и почему в современных реалиях востребованы универсальные специалисты с широким набором навыков.
Проблемы и вызовы: Почему в команде шутят, что «если все хорошо, значит, команда поработала отлично, а если что-то пошло не так — виноват аналитик».
Этот разговор — отличная возможность понять, кто такой аналитик на самом деле, какую критически важную роль он играет в создании IT-продуктов и с какими сложностями сталкивается каждый день.
Онлайн-трансляция митапа для продуктовых аналитиков. Спикеры Garage Eight и Wildberries
16 октября в 19:00 IT-компания Garage Eight вместе с аналитическим лайфстайл-сообществом «Хи-хи квадрат» проведет открытый митап для продуктовых аналитиков. Места в офлайне закончились, а вот к бесплатной онлайн-трансляции все еще можно присоединиться.
В программе доклады: 19:30 — «AI vs Аналитик: кто кого заменит и почему Excel все еще жив» Спикер: Владимир Сыропятов, Senior Analyst в Garage Eight, PhD экономики, преподаватель СПбГУ.
20:10 — «И сеньору полезно! Или что ты не знал о своем резюме» Спикер: Александр Бондаренко, Senior DWH Analyst в Wildberries.
Приходите на конференцию GlowByte FineDay–2025 – участвуйте в "битве" за будущее данных!
Друзья, компания GlowByte, единственный партнер FanRuan уровня Diamond в России, приглашает на ежегодную конференцию по бизнес-аналитике и большим данным FineDay — 2025: Self-Service BI vs AI — битва за будущее данных!
Мероприятие соберет профессионалов в области Business Intelligence и AI, чтобы обсудить революционные изменения в мире данных и вектор развития BI-индустрии. Вас ждут интересные доклады и горячая дискуссия о том, как self-service аналитика и искусственный интеллект формируют будущее работы с данными.
Ключевыми темами мероприятия станут:
Эволюция Self-Service BI: как демократизация данных меняет корпоративную аналитику.
AI-революция в аналитике: возможности и вызовы интеграции ИИ в BI-системы.
Гибридные подходы: синергия человеческой экспертизы и машинного интеллекта.
В программе конференции будут звучать доклады:
Миграция с Qlik Sense на FineBI: практический опыт смены BI-платформы.
От SAP BW и MS PowerBI к ClickHouse и Sigla Vision: эволюция корпоративной аналитики в Полюсе.
Цифровая трансформация данных в группе Московская Биржа: от централизованной отчетности к культуре Data Driven и стратегической цели AI-Native
Эксперты и компании-участники
На FineDay — 2025 выступят и примут участие представители ведущих организаций: Газпромбанк, Полюс, Московская Биржа, СК «Сбербанк страхование», СИБУР Диджитал, Viz Standart, FanRuan, GlowByte.
Вечная память: необычные идеи зарубежных стартапов
Продолжу свой рассказ о необычных идеях для стартапов, которые реализуются за рубежом. Сферы бизнеса, находящиеся около темы ритуальных услуг и культуры погребения, считаются достаточно стабильными, такова наша жизнь. Но в разных странах отношение к теме смерти разное. Для примера:
And Vinyly - британский стартап, который предлагает необычный способ «увековечить себя» — превратить прах умершего человека в виниловую пластинку. Клиент выбирает музыку, речь или звуки, которые будут записаны, а компания прессует пепел в материал винила. Проект позиционируется как арт-концепт и альтернатива традиционным похоронам.
Прижился бы такой проект на российском рынке? Скорее всего — нет. Российская культура погребения и отношение к смерти слишком консервативны. Однако как арт-объект, перформанс или необычный мемориальный подарок — может найти нишевого потребителя.
При работе с подобным стартапом в России, возможно, всплывут, острые этические вопросы, возможно - непонимание со стороны общества и религиозных институтов. Также сложно будет масштабировать такой бизнес: аудитория крайне узкая.
DiedInHouse - американский сайт, который позволяет проверить по адресу, умирал ли кто-то в выбранном доме. Пользователь вводит адрес и получает отчёт: были ли зарегистрированы смерти, убийства, пожары или другие трагедии. Идея — помочь покупателям недвижимости или арендодателям избежать «плохой энергетики».
Прижился бы такой проект на нашем рынке? Очень спорно. В России такая тема быстро обрастёт мистикой и слухами, а достоверных открытых баз данных просто нет. Однако как развлекательный проект в ивент-индустрии, может вызвать интерес. В качестве дополнительных сложностей - дефицит в России официальных данных. Без интеграции с госреестрами сервис будет скорее развлечением, чем реальным инструментом.
Обеспечиваем качество данных в компании. Подборка open-source-инструментов для Data Quality
Привет, Хабр! Я Алексей Чумагин, Data Quality Team Lead Островка. В компании мы работаем с десятками источников данных: авиакомпании, отели, агрегаторы, платёжные сервисы. При этом источники постоянно обновляются: добавляются партнёры, меняются API и форматы. В таких условиях Data Quality становится непрерывным процессом, встроенным в ежедневную работу, а вовсе не стереотипным «набором тестов, которые раз в сутки что-то проверяют».
Качественные данные зависят от выстроенных процессов: автоматизации, прозрачности, быстрой реакции на инциденты. Мы смотрим на Data Quality как на живую экосистему, где тесты — лишь одна из составляющих. Исходя из этого строим в компании единую Data Quality Platform.
Архитектура нашей платформы организована вокруг следующих задач:
автоматизация создания и выполнения тестов;
их централизованное хранение;
визуализация результатов;
мгновенное оповещение команд об инцидентах.
Вся эта экосистема работает в едином ритме с основными data-процессами компании.
Ниже — подборка инструментов, из которых состоит наша платформа. Их легко внедрить и в других IT-компаниях: стек масштабируемый, гибкий и не требует больших затрат на лицензии.
Какие инструменты мы используем в Data Quality
1. Ядро и автоматизация
В качестве ядра системы мы выбрали Soda Core — движок, который позволяет формализовать правила качества: целостность, уникальность, диапазоны значений. Тесты описываются декларативно, что упрощает поддержку и масштабирование.
После того как тесты написаны, их запуск и оркестрацию мы доверяем Apache Airflow. Он автоматически запускает проверку после ETL-процессов, управляет зависимостями и расписанием, что критично для стабильной работы пайплайнов.
Чтобы не тратить время на рутинное написание DAG’ов для новых тестов, мы используем DAG Factory — генератор DAG’ов, позволяющий держать код тестов и их запусков в едином месте, легко масштабировать количество проверок.
2. Интеграция и доступ
Важной частью платформы стала интеграция с другими системами. Для этого мы подняли сервисный слой на FastAPI: через API можно запускать тесты, получать результаты, интегрировать платформу с внешними инструментами.
Для визуализации выбрали Streamlit — он позволяет быстро собирать дашборды и интерактивные отчёты, которые особенно удобны инженерам для экспресс-проверок и разбора логов ошибок.
Но не все участники процесса хотят разбираться в технических деталях. Менеджеры и аналитики зачастую предпочитают DataHub — каталог метаданных, где хранятся все проверки, их результаты, а также информация о таблицах, lineage и пайплайнах. Это позволяет сделать качество данных частью общего ландшафта данных компании.
3. Оперативность и реакция
Все алерты и уведомления о результатах тестов автоматически отправляются в корпоративный мессенджер, чтобы команды могли оперативно реагировать на проблемы.
Вся DQP-платформа развернута в Kubernetes, — это обеспечивает масштабируемость, отказоустойчивость и централизованное управление компонентами.
И почётное упоминание ещё одной неизбежно важной технологии: для ручных ad-hoc-проверок мы, конечно же, используем старый добрый SQL. Без него ни одна оперативная сверка или исследование гипотез не обходится.
Итого: наш Data-Quality-стек — это комбинация проверенных open-source-инструментов, которые удобны на практике: легко автоматизируем тесты, быстро видим результаты, интегрируемся с чем угодно и не особо беспокоимся о лицензиях. Всё масштабируется, поддерживается инженерами, а не только админами и даёт нам уверенность в качестве данных, даже когда вокруг всё меняется.
А какие инструменты используете вы для контроля качества данных? Что бы вы добавили или изменили в нашем подходе? Будем рады обсудить в комментах!
Мы стали партнером курса Hard Аналитика данных — продвинутой программы для тех, кто хочет вырасти из junior+ в уверенного middle. За 6 месяцев участники прокачают BI, DWH, эксперименты и машинное обучение на реальных данных.
Программа поможет научиться решать задачи, с которыми аналитики сталкиваются в крупных компаниях. А самые сильные выпускники получат шанс пройти отбор и попасть к нам в Garage Eight на позиции продуктового или data-аналитика.
Старт потока — 23 октября Подробнее — на сайте Karpov Courses.
Периодически мне приходят опросы с просьбой оценить какой-то сервис или продукт. И знаете, что поражает больше всего? Когда в таком опросе нет поля для комментария.
Метрики померить — дело важное. NPS, CSAT, баллы, проценты, персентили. Но как вы узнаете, почему людям понравилось или не понравилось? Как поймёте, что именно нужно улучшить?
Я всегда добавляю в формы обратной связи два поля:
— «Ваш комментарий» — напишите, что угодно. — «Если хотите, чтобы с вами связались — оставьте e‑mail».
И знаете что? Только процентов 10 что‑то пишут. Ещё меньше — оставляют контакты. Но именно эти люди дают самую полезную информацию о продукте и взаимодействии с ним.
Давайте вашим пользователям возможность говорить. Даже если комментируют единицы — именно они могут подсказать, что действительно важно.
14 октября присоединяйтесь к нашему вебинару, где мы на примере практических кейсов покажем, как ADQM Control помогает упростить эксплуатацию и повысить производительность кластеров ClickHouse.
В программе
Краткий обзор ADQM Control и новых возможностей, появившихся после майского вебинара.
Разбор типовых проблемных кейсов эксплуатации кластеров ClickHouse.
Live-demo практических примеров их решения.
Тизер релиза начала 2026 г.
Q&A.
Эксперты Группы Arenadata:
Дмитрий Безруков, руководитель отдела технических менеджеров — основной докладчик, Q&A
Антон Коваленко, руководитель департамента продуктового маркетинга — модератор дискуссии, Q&A
Как проходят собеседования аналитиков в международной продуктовой IT-компании Garage Eight
Недавно наш Head of Product Analytics Олег Игнатов в прямом эфире провел публичное интервью с продуктовым аналитиком Юрой.
Процесс собеседования можно посмотреть на YouTube или VK Видео, а концовку готовы проспойлерить прямо здесь — Юра прошел все этапы интервью, принял наш оффер и уже скоро начнет онбординг в Garage Eight.
А если интересно узнать, как сам Олег 6 лет назад зашел в аналитику без опыта, то рекомендуем почитать его интервью для блога Хабр Карьера. В нем он рассказал, как из авиационного инженера за несколько месяцев переучился на продуктового аналитика, поработал в S7 и Литрес, а потом пришел в Garage Eight.
Читай и узнаешь: > что помогло Олегу найти первую работу в IT, и какие советы он дает тем, у кого опыта еще нет; > какой была его первая зарплата; > чему его научили провальные собеседования; > как устроена аналитика у нас в компании.
Карьерный трек продуктового аналитика с разбивкой по скилам на каждый грейд ждет в конце статьи. А открытые вакансии к нам в аналитику — на карьерном сайте и в нашем telegram-канале ;-)
13 дней, которые изменили взгляд на аналитику: итоги ретрита GlowByte по FineBI
С 25 августа по 10 сентября 2025 года команда GlowByte провела уникальный образовательный марафон по современной бизнес-аналитике. Участники со всей России и стран СНГ осваивали FineBI — мощную платформу для работы с данными, которая становится реальной альтернативой западным BI-решениям.
Впечатляющие результаты марафона
✅ 13 насыщенных дней практического обучения
🎥 5 прямых эфиров с экспертами индустрии
🎯 1 большой проект — новички собрали реальный BI-проект с нуля
🏆 12 заданий для опытных пользователей— углубленная практика мастерства
⚡ 10+ фишек FineBI освоили все участники
Что изучали участники
FineBI — Self-Service аналитика
Создание интерактивных дашбордов без программирования.
FineReport — Профессиональная отчетность
Pixel-perfect отчеты, автоматизация рассылок, интеграция с корпоративными системами. Excel-подобный интерфейс, но с возможностями корпоративной BI-системы.
FineVis — Визуализации будущего
3D-графики, интерактивные презентации данных, VR-готовые визуализации.
FineChatBI — Аналитика c помощью ИИ
FineChatBI, автоматическая генерация дашбордов, умный поиск по данным.
10 практических кейсов от ведущих компаний
Реальные истории успеха и внедрения от экспертов T2, Уралсиб, Циан, Альфа-Лизинг, МКБ, ОККАМ, ID-360 и других компаний — от стратегий миграции до конкретных решений бизнес-задач.
Формат: два потока обучения
🤍 Белые драконы (новички)
Задача: создать полноценный BI-проект от идеи до презентации
Результат: готовые дашборды с бизнес-инсайтами и развернутые отчеты
⚫ Черные драконы (опытные пользователи)
Задача: решить 10 практических заданий разной сложности
Результат: портфолио работ и освоение продвинутых техник
Отзывы участников
" FineBI стал моим настоящим открытием, благодаря своей доступности, схожести интерфейса и функционала с известным Power Query из MS Excel, а также бесконечным возможностям построения наглядных графиков и отчетов.
Меня восхитили ежедневные видеоматериалы от Анастасии, мы заглянули в закоулки настройки отчетов, которые серьезно упрощают работу: карточки, "формат по образцу", настройка фильтров и многие другие инструменты.
Каждое задание ретрита оказалось испытанием, которое подтолкнуло меня развиваться дальше."
Анна Мишина, Преподаватель курсов Microsoft Excel
"Хотел бы поблагодарить организаторов за такое отличное мероприятие, которое помогает отвлечься от строгих рамок проектов и технических заданий. Каждый день ждешь сперва задания, потом возможности наконец-то его реализовать."
Федоров Александр
"Круто, когда случается WIN-WIN ситуация, а Ретрит именно так и проходит — все делятся своими решениями и общий уровень FineBI сообщества растёт. О FineBI рассказывает не так много источников, поэтому Ретрит считаю одним из главных событий в этом деле."
Дмитрий Кочанов
Получите доступ к материалам ретрита
Даже если вы не участвовали в ретрите, вы можете изучить материалы!
Книга ретрита — Полный архив знаний
13 структурированных уроков
Видео с практическими фишками
Кейсы от ведущих компаний России
Что вы получите:
✅ Пошаговые инструкции по освоению FineBI ✅ Реальные кейсы внедрения в бизнесе ✅ Доступ к сообществу экспертов ✅ Записи всех вебинаров с экспертами
Сегодня в чате техписателей спросили про разницу между Docs-as-Code и DocOps.
Docs-as-Code — это один из подходов к организации документирования, который рекомендует определенное устройство процессов и диктует выбор инструментов. Звучит сложно? На самом деле строится всё на языке разметки, Гите и SSG.
DocOps — это вообще вся автоматизация вокруг документирования. И хотя в интернетах и в GPT вам будут говорить, что это философия, методология, культура, рамка (простигосподи) и другие аморфные слова. Не верьте.
По сути и на практике DocOps — это набор инструментов для автоматизации всех процессов документирования. Инструментов, которые вы используете у себя в компании для подготовки, проверки и публикации документации. Естественно, о Ворде речь не идёт. Естественно, инструментов без процессов не бывает. Но организация документирования это всё-таки задача руководителя, а не докопса.
Кстати. Человек, роль, должность это не DocOps, это DocOps-инженер. Если из контекста можно понять, что речь о человеке, то, конечно, обычно сокращают до «наша докопс сегодня учудила». Но всем должно быть понятно, что учудила не инженерная дисциплина, а коллега.
Германский умлаут и славянская третья палатализация Кто интересовался историей славянских языков (в частности праславянским), тот наверняка слышал, что современные буквы ъ и ь ранее обозначали звуки ŭи ĭ, сравните, например древнерусское мьзда, стькло и готское mizdo, stikls или древнерусское кънѧзь и финское kuningas. При этом вследствие третьей палатализации «твёрдый знак» мог переходить в «мягкий», например (в дореформенной орфографии) другиня другъ, но княгиня князь. Причиной палатальной перегласовки в данном случае является наличие в слове князь буквы «я», которая как некоторые любознательные читатели, наверное, уже слышали, может переходить в «ин» размять разминать, распять распинать, ну а «и» может переходить в «ь» липнуть, но льнуть (сравните капать / кануть). Иными словами, тем самым фактором из-за которого отражавшийся ранее на конце слов «ъ» перешёл в слове князь в «ь» является засевший в корне ещё один ерь «ь» «сингармонически» уподобляющий идущие за ним гласные себе. Такое уподобление называется прогрессивным.
Теперь же плавно перейдём к умляуту в германских языках по-иному именуемому i-mutation. Сравним, например английское full полный и fill наполнять. Возвращаясь к означенному в самом начале статьи можно заметить некую аналогию и она действительно есть ...
Представьте: вы смоделировали процесс, нажали кнопку, и он работает. Сам назначает задачи, сам контролирует сроки, сам правит данными. Это не фантастика, а реальность с исполняемыми процессами на Camunda. 23 сентября мы покажем, как это сделать на бесплатном вебинаре «Уровни моделирования бизнес-процессов. Исполняемый BPMN».
Что будет в эфире:
✔️ Живой разбор работы в Camunda: от установки до запуска.
✔️ Покажем, как программировать логику шлюзов и создавать пользовательские формы.
✔️ Ответим на вопрос: какую модель пойдет исполнять движок, а какую — нет.
🗓 Дата: 23 сентября
⏰ Время: 17:00–18:00 (Мск)
👨🎓 Спикер: Алексей Тарасов — аналитик с 10-летним опытом.
Наш продуктовый аналитик Кирилл Мазуров и Анастасия Кузнецова, автор канала «Настенька и графики», собрали подборку диаграмм, которые реже попадают в дашборды (а зря!).
Мы с Анастасией сделали классные карточки, которые удобно смотреть и хранить в сохраненках, но Хабр дает прикрепить лишь одну картинку. Поэтому здесь текстовая версия, а сами карточки забрать можно тут.
1) Dumbbell chart Сравниваем два значения по одной оси, например, «до» и «после», или значения в двух точках времени.
Плюс: > Четко показывает разницу между двумя значениями Минус: > Плохо читается при большом числе категорий
Кирилл: В Garage Eight с помощью такого графика мы следим за степенью автоматизации важных участков продукта. Например, как меняется доля автоматически обработанных событий от ручных.
Анастасия Кузнецова: В гантельках важно, чтобы данные на них хорошо легли — была явно видимая разница между группами. Недавно удалось затащить этот график в один из дэшей, очень радовалась. Вместо них еще часто можно посчитать просто разницу между показателями и показать ее обычным барчартом.
2) Marimekko chart Одновременно анализируем структуру и масштаб.
Плюс: > Отражает и размер, и доли внутри категорий Минус: > Тяжело читается, особенно без пояснений
Кирилл: В Garage Eight используем такой тип графиков, например, для определения какая платежная опция популярнее у клиентов.
Анастасия Кузнецова: Этот график назван в честь знаменитого финского бренда Маримекко, и очень он визуально мне нравится. В нем важно, чтобы категории можно было объединить во что-то «целое», например, средние показатели так не визуализировать. Этот тип графика хорошо работает, когда есть явная разница в объеме категорий.
3) Sankey diagram Показываем потоки между источниками и получателями — как распределяются ресурсы, трафик, деньги и сколько людей находится на каждом этапе воронки.
Плюс: > Отлично показывает распределения Минус: > Быстро становится перегруженной
Кирилл: В Garage Eight используем такой тип графиков, чтобы быстрее определять, какие пути пользователей популярнее. Еще сравнивали, как поменялось перераспределение каналов привлечения после внедрения новой модели атрибуции трафика.
Анастасия Кузнецова: Один раз получила запрос от CEO показать, на каком этапе воронки у нас отваливается большая часть пользователей. Именно санкей дал нужный вау-эффект и понимание того, насколько маленький и тоненький поток пользователей доходит до покупки. Отличный инструмент визуальной аналитики.
4) Bullet chart Классический график сравнения с плано-выми значениями, показывает именно достижение цели (альтернатива спидометру). В нем черточка показывает плановое/целевое значение, к которому мы стремимся, а столбец — фактическое, реальное значения метрики.
Плюс: > Компактный, идеально для дашборда Минус: > Требует пояснений для новичков
Анастасия Кузнецова: Очень часто им пользуюсь, но не в классическом варианте с задним фоном, а просто столбик + черточка. Понятно и компактно показывает достижение цели, и в отличие от спидометра позволяет визуально превысить цель.
5) Radar chart Сравниваем характеристики разных объектов.
Плюс: > Удобен для визуального сравнения Минус: > Становится нечитаемым при использовании более 7 объектов
Кирилл: В Garage Eight мы рассматриваем внедрение таких графиков в матрицы развития аналитиков. Так мы сможем сделать прогресс по уровню развития немного интерактивнее.
Анастасия Кузнецова: Редко когда получается эффективный виз с ним, и это действительно чаще про данные из области сравнения навыков. Будет визуально работать только с сильной разницей по характеристикам — когда одна характеристика сильно выбивается на фоне остальных.
Когда «простой» бизнес-процесс превращается в хаос: правила всплывают на ходу, код становится хрупким, а бизнес недоволен…
Как этого избежать? Один из ответов — EventStorming. Метод, который помогает вытянуть скрытые требования, уточнить бизнес-правила и превратить размытые идеи в чёткие DDD-модели.
Как связаны игра «Что? Где? Когда?» и работа в IT?
А вы знали, что методы легендарной интеллектуальной игры могут стать ключом к эффективной работе вашей команды? Рассказываем в нашей новой статье!
«За зеркальным столом я капитан команды, а на работе — бизнес-аналитик. Но в последнее время эти роли размываются, потому что параллели между поведением команды за столом и во время обсуждения рабочих задач…как-то уж очень близки. И однажды мне захотелось исследовать, как методы из игры работают в реальной жизни. Как оказалось, большинство моментов применимо» — пишет автор статьи Евдокия Аверина.
Заказчик отправил архив с десятками айтишных разработок и попросил в короткие сроки дать по нему заключение: что полезно, а что нет. Какие проекты выбросить, а какие выгодно развивать (с указанием потенциальной прибыли и перечня необходимых работ). С подобной задачей мы в лабе сталкивались не раз, но это была внутренняя кухня. А тут большое количество проектов, которые никто прежде в глаза не видел. Сроки сжатые, вникнуть в детали каждого проекта физически невозможно.
Невыполнимые задачи мы любим больше всего. Структурировали требования к оценке проекта и написали протокол для анализа (https://vsempo.xyz/lab/analpro/index.html). Работает так: загружаете исходные файлы проекта в LLM, загружаете файл протокола и в ответе получаете JSON с полным описанием проекта, багами, технологическим стеком, конкурентными преимуществами, потенциальной прибылью от внедрения, алгоритмом развития и необходимым ресурсам. При желании можно сделать все это пакетно: указываете каталог и получаете набор файлов с результатами.
Но сами по себе JSON-файлы изучать сложно. Поэтому на сдачу написали небольшой вьюер на JS (https://vsempo.xyz/lab/analpro/analproview/index.html). Загружаете в него все файлы JSON с описанием проектов и получаете визуализацию, сводную статистику по всем проектам, возможность изучить детали по каждому проекту и общую стратегию развития. Пока эта система больше напоминает концепт, чем промышленное решение, но для нашей конкретной задачи этого более чем достаточно.
Изначально задача казалось совершенно невыполнимой. А в итоге самую большую трудность вызвало придумать название. С одной стороны, мы написали протокол анализа. Но еще мы написали классическую программу для анализа проектов. Долго не могли решить, какое название выбрать: аналпро или проанал. В итоге остановились на первом варианте. Хотя я был против. Нужно было назвать систему "проанал", а название "аналпро" сохранить для расширенной коммерческой версии.
Если вдруг кто не знал, как я. Для обозначения графических схем архитектуры программного продукта, которые изображают маркетологи и продуктовые менеджеры в презентациях, т.е. те которые не совсем технические, существует термин - это "маркетектура".
В общем смысле, это представление программного продукта для не технических специалистов, фокусирующееся на преимуществах и выгодах для пользователей, а не на технических деталях.
Но это ещё не всё. То что мы привыкли считать технической архитектурой, т.е. описывающей компоненты и их взаимодействие, тоже имеет термин - это "тархитектура".
