Анализ и проектирование систем *

Когда экономика продукта не сходится, команда почти всегда делает одно и то же: смотрит в воронку. Видит, что просела конверсия. Идет чинить эту конверсию: меняет интерфейсы, добавляет мотиваторы. Или видит низкий ретеншн и низкий LTV, экономика не складывается, и начинает пытаться двигать ретеншн с помощью геймификационных механик. Логично, измеримо, под каждый шаг можно подвести цифру.

Меня зовут Александр Козуб, в симптомах вижу систему, об этом и пишу. Ранее я уже разбирал, как лучшие практики сужают рамку продакта, и собирал методики оценки пользователя в одну систему. Сегодня про метрики.

Тезис простой, но неудобный: деньги не могут быть целью продукта. Деньги это запаздывающий отчет о его работе. По отчету нельзя рулить. Кто управляет продуктом по выручке, тот пытается ехать вперед по зеркалам заднего вида.

Сразу уберу легкое прочтение: это не «продукт против денег» и, ни в коем случае, не призыв забыть про экономику. Деньги обязательны, но они приходят последними и уже как результирующий все действия итог. Рулить надо тем, что приходит раньше. А раньше всего приходит ценность для пользователя, и видна она в качественных сигналах, а не в рублях.

На презентациях EAM-системы часто выглядят почти одинаково: учет активов, ремонты, дефекты, материалы, аналитика. Но в реальной эксплуатации эта похожесть быстро исчезает. Производственная линия, электросетевая инфраструктура, транспортный узел или метрологический контур живут по разным правилам - с разными рисками, ограничениями, регламентами и ценой ошибки.

Именно поэтому рынок постепенно уходит от идеи универсальной «системы ремонтов» к отраслевым и преднастроенным EAM-контурам. Для бизнеса это уже не вопрос удобства интерфейса или количества модулей. Гораздо важнее, насколько точно система понимает модель активов предприятия, умеет работать с техническим состоянием, ремонтной логистикой, мобильными бригадами, МТО и обязательными процедурами.

В статье для журнала Connect WIT ведущие специалисты Инфостарта - руководитель отдела корпоративных решений Станислав Субботин, корпоративный архитектор Дмитрий Исаев и руководитель проектного офиса Александр Пищальников - разбирают, где именно проявляется отраслевая специфика EAM и почему преднастроенные решения становятся привлекательнее для сложных производственных и инфраструктурных предприятий...

В менеджерской среде есть изречение: «Управлять можно только тем, что можно измерить». Рискнем его дополнить — данных сейчас генерируется так много, что одного измерения уже мало: «…а эффективно управлять — лишь когда результаты измерений представлены наглядно». В предыдущих статьях про адаптивное администрирование Sigla Vision мы описывали, как собирать данные об изменении объектов BI-системы. Теперь покажем, как представить эти данные наглядно, и приведем примеры наших дашбордов — мы назвали их «системными», чтобы отличать от пользовательских.

Статья пригодится BI-разработчикам и ИТ-специалистам, которые развивают или сопровождают Sigla Vision и другие BI-системы.

Здесь мы разбираем, как системные дашборды помогают решать задачи администрирования Sigla Vision, и прикладываем код для PostgreSQL, который готовит таблицы-источники датасетов для комплексного дашборда «Состояние системы». В нем можно отслеживать, как меняются во времени количественные показатели по объектам: дашбордам, подключениям, ролям, пользователям, рабочим книгам, элементам корзины и т. д.

Любой инструмент для «понимания кода», которым я пользовался, рано или поздно упирался в одну из двух стен.

Первая — цикл «grep → открыть → прочитать → перейти по импорту → снова grep». Работает, но медленно, и у него нет ни малейшего представления о том, что process_order, найденный в services.py — это тот самый process_order, который вызывается из api.py, а не однофамилец из tests/. Когда этим занимается LLM-агент, он ещё и сжигает на этом тонну токенов.

Вторая стена — моноязычность. Инструмент прекрасно понимает Python, но слепнет в ту секунду, когда фронтенд на TypeScript дёргает ручку FastAPI на Python. Реальные системы полиглотны. Инструменты вокруг них — обычно нет.

graphlens — это open-source фреймворк (MIT), который спроектирован так, чтобы обойти обе стены. Он парсит исходный проект, нормализует его структуру в общий граф-IR и отдаёт этот граф вам — делайте с ним что хотите: анализ зависимостей, навигацию, поиск мёртвого кода или подачу точных ответов LLM-агенту вместо вываливания файлов в контекст.

Подделка рейтингов окончательно перешла с бирж фриланса на автоматизированные конвейеры. Сегодня отзывы генерируют локальные LLM, а публикуют скрипты через антидетект-браузеры и резидентные прокси. Такая ботоферма самостоятельно формирует цифровой след: собирает cookies на сторонних сайтах, закладывает лексические ошибки в текст и подменяет отпечатки железа, чтобы система приняла профиль за живого человека с реальным провайдером.

В ответ маркетплейсы и геосервисы перестали анализировать исключительно сам текст и переключились на графовый анализ. Антифрод отслеживает микродвижения мыши, скорость скроллинга и сетевые пересечения аккаунтов. Математически идеальный рейтинг 5.0 или шаблонные тайминги публикации становятся для алгоритма прямой командой к действию. Площадка не просто удаляет сомнительные комментарии, а отправляет карточку товара в теневой бан, срезая органические показы в поиске.

Как устроен Data Mesh, какие требования подход предъявляет к бизнесу и почему большинству российских компаний сегодня зачастую важнее построить зрелое DWH, чем пытаться перейти к распределенной архитектуре данных

Каждый год в мире выпускают больше миллиарда смартфонов. Люди меняют устройства каждые два-три года, потому что хотят новые функции, лучшую камеру или просто более быстрый отклик. В итоге тонны вполне работоспособной техники оказываются на свалках, хотя их процессоры, память и накопители ещё способны выполнять серьёзные задачи. Как-то это не очень здорово, согласитесь.

Авторы одного интересного проекта решили попробовать создать из телефонов вычислительный кластер. В ходе реализации этого плана выяснилось, что отдельные ядра современных мобильных процессоров по скорости в однопоточном режиме не уступают серверным решениям, а иногда и превосходят их. Как это работает и что может получиться? Давайте посмотрим.

Это вторая из двух статей про бэклог. В первой я разбирал, почему бэклог это не план, а коллегиальный документ, в котором лоббируют свои интересы все, кроме пользователя, хотя платит за продукт именно он. Диагноз был поставлен. В этой статье сконцентрируемся на лечении.

Меня зовут Александр Козуб, я двадцать лет в финтехе, последние несколько из них CPO. В симптомах вижу систему, об этом и пишу.

Главный вопрос, на котором мы остановились, звучит так. Допустим, я согласен, и в бэклоге голосуют все, кроме плательщика, и надо вернуть его голос. Но как это сделать, если у меня недостаточно власти отклонить задачу CEO, переспорить маркетинг или отклонить инициативу разработки? Я же не могу запретить им хотеть.

Запретить не можете, но управлять потоком, не запрещая, можете и, более того, должны.

Приветствую!

На связи корпоративный архитектор банка Уралсиб - Моне Даниил!

СА говорит ''это срочно для бизнеса'', а КА — ''это не по стратегии''? Узнаете себя? Мы нашли способ, как помирить их в одном домене, не жертвуя ни скоростью, ни качеством

Хочу поделиться небольшой историей о том как появилась идея продукта, почему я пошел первым делом к рынку и что именно в ответах потенциальных пользователей заставило меня полностью пересмотреть все исходные гипотезы.

Хабр, Привет! Пожать заветную сотку, добрать белка, закрыть углеводное окно и просто попозировать после тяжелой потной тренировки — всё это не пустые значимые вещи для любого посетителя зала, который старается держать режим. Спортпит сейчас — это какая‑то генеративная машина по случайным наборам цифр (могут меняться в день по несколько раз). Уже устаёшь мониторить не только то, что показывает на весах, но и на маркетплейсах! Мне как человеку имеющему базовые знания в дате хочется понять почему и как этот беспредел работает. Есть ли в этих акциях хоть что‑то отдаленно походящее на правду и смысл в мониторинге? Постараюсь выяснить пошагово и понять как это всё безобразие работает и работает ли.

На первый взгляд, медиалента в мобильном приложении выглядит как стандартная задача: список карточек, автоплей, предзагрузка соседних роликов, несколько состояний загрузки. На практике это оказался один из самых сложных iOS‑компонентов, с которыми мне доводилось работать.

Проблема в том, что медиалента — это не один виджет и не просто плеер внутри ячейки. Это система, которая живёт на пересечении сразу нескольких тяжёлых доменов: динамически собираемый интерфейс, сетевые ограничения, декодирование медиа, менеджмент памяти, жизненный цикл вложенных контейнеров, UX‑требования к мгновенному старту, интеграция в чужие экраны и такие сложные системы, как BDUI, рекомендации, пагинации, и при этом — высокий трафик на массовом сценарии. 

Само собой, любая ошибка в этой конструкции редко проявляется как локальный баг. Обычно она масштабируется: фризы при скролле, чёрные экраны, нестабильный автоплей, рост памяти на длинных списках, нагрев устройства и трудноуловимые падения, которые воспроизводятся только на части устройств и только в условиях реального использования, а не эмуляции.

Самое интересное в таких задачах начинается не на этапе «как добавить медиаленту», а на этапе ограничений и деградаций. В статье я разберу именно эту сторону задачи на примере приложения Яндекс Еды: как мы проектировали медиаленту, какие архитектурные решения не сработали, какие баги всплыли только на реальных данных, как мы строили observability для дебага и какие компромиссы в итоге оказались эффективнее красивой реализации.

Популярная тема в ИТ-сфере сегодня — локальная работа с ИИ-агентами. На этой волне мы в Beeline Cloud решили посмотреть на подходящие инструменты с открытым исходным кодом и подготовили подборку фреймворков, которые помогут управлять ИИ-агентами у себя «под боком» и с нуля писать интеллектуальных помощников под свои задачи.

Спойлер: архитектура AIналитика полностью переписана, теперь Платформу можно запускать практически под любым харнесом (OpenCode, Kodik, Codex, Claude Code), а также подключать любые LLM, включая локальные. Добавлено/в разработке много новых фич: многоагентная система, доска навигации и дашборд для тимлидов.

Пару месяцев назад я опубликовал на Хабре статью «Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось». Коротко: я разработал AI Платформу AIналитик - ai-ассистента, который работает рядом с бизнес-аналитиком, как опытный коллега. Он знает методологию BABOK v3 и ведёт BA по проекту, может: спланировать, подготовить интервью, собрать требования, провести трассировку, приоритизировать, оценить риски и изменения. Покрыты все задачи пяти областей знаний, главы с 3 по 7, за исключением 8-ой.

Исходный код AIналитика v1 на Github. Канал с новостями проекта AI Платформа AIналитик.

Идея первой версии AIналитика умещалась в одно слово: рельсы. Бизнес-аналитик перемещается по проекту, как трамвай по рельсам. Платформа не даёт свернуть в сторону и начать творить отсебятину, пропустить шаг или забыть про дедлайны. Бизнес аналитик с Платфорой выполняет задачи так, как это рекомендует методология BABOK. Пользователь общается с Платфрмой человеческими словами, никаких специальных команд знать не надо. Платформа подсказывает следующий ход и берет на себя всю рутину.

Новости про очередной этап «развития ИИ» выходят чуть ли не каждый день. И со временем меняются не только ИИ-инструменты, но и отношение к ним у ИТ-специалистов, их представление о назначении таких инструментов. Эта статья — о сдвиге понимания роли искусственного интеллекта в работе архитектора ПО. 

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и старший преподаватель Учебного центра IBS. 

Недавно я пересматривал вебинар «Генеративные нейронные сети в работе архитектора ПО», который сам же и проводил год назад. Слушать собственные мысли из прошлого — опыт специфический. С одной стороны, идеи кажутся логичными, с другой — сейчас я остро вижу, насколько за этот год изменилось понимание того, как ИИ на самом деле встраивается в инженерные процессы.

В инженерии программного обеспечения есть метрика bus-factor — минимальное количество людей, одновременная потеря которых останавливает систему. Чем выше число, тем устойчивее операция к кадровым изменениям.

В IT эту метрику считают регулярно. На складах — почти никогда. При том что текучесть персонала в складской отрасли составляет около 49% в год. Склад, который не знает своего bus-factor, не знает, насколько каждый такой уход приближает его к операционному сбою.

Важная оговорка до расчёта: bus-factor — не оценка компетентности. Высокий bus-factor у конкретного человека означает, что склад правильно спроектирован вокруг этой роли. Низкий — что знание об операции сосредоточено в одном месте и нигде больше не зафиксировано.

Прошел очередной Летний аналитический фестиваль. В этом году он проходил в Иваново: в связи с тяжелой ситуацией на рынке ЛАФ вернулся из Подмосковья на ту площадку, на которой начинался в далеком 2010 году. И к тому же формату: суббота – в офисе Консультанта, вечером – переезд за город, на турбазу, там шашлыки и движуха, а в воскресенье – продолжение мастер-классов уже на турбазе. И громадная благодарность организаторам, что провели фестиваль! Было много нетворкинга и интересные доклады, два трека выступлений и два – мастер-классов. А относительно камерный формат, в котором было всего 120 человек, многие из которых были на фестивале многократно, создал прекрасную атмосферу. Обсуждения многих насущных тем продолжались практически всю ночь до утра. А началось это на препати, который был еще в пятницу вечером.

Продолжаем изучать моделирование спутниковой связи в симуляторе сетей NS-3. В этой статье мы завершим краткий обзор классов модуля Satellite.

Как узнать, что внутри .exe, собранного через Nuitka? DeNuitkanizator — инструмент с открытым кодом для анализа таких файлов. Извлекает строки, модули, хэши, информацию о защите и многое другое за один запуск.

Мир технологий меняется быстро, и создать большое приложение, которое можно поддерживать несколько лет, становится непростой задачей.

Лет двенадцать назад создание большого монолита было обычной практикой. Семь лет назад многие подсели на микросервисную архитектуру. Причем микросервисами часто называли все подряд: и сервисно-ориентированный подход (SOA), и набор крупных сервисов, и распределенный монолит. Главное было быть в тренде.

Сейчас маятник снова качнулся. Микросервисы уже не выглядят универсальным ответом: слишком хорошо видна их цена в инфраструктуре, отладке, версионировании контрактов и сопровождении. Поэтому все чаще можно услышать про модульный монолит.

В этой статье я попробую набросать архитектурные и программные решения, которые позволяют создать и поддерживать веб-приложение в течение нескольких лет.