Анализируй и проектируй
Большинство продуктовых дискуссий о ценности заканчиваются на «пользователю станет удобнее». Это не ценность, а ее отсутствие, прикрытое словом «ценность».
Разбираю на живом кейсе T&S Циана, как разложить это слово на пять координат, и какая асимметрия вылезает за 5–6 часов работы.
Александр Козуб. CPO в финтехе. В симптомах вижу систему.
В статье рассмотрим, почему эволюционная архитектура и модульный монолит превосходят современные архитектурные подходы. Обсудим, в каких случаях стоит отказаться от микросервисов, как документировать архитектурные решения с помощью ADR и какие методы помогают спасать проекты.
Проект автоматизации склада согласован. Бюджет выделен. Поставщик решения уже выбран или находится в шорт‑листе. Запуск намечен на следующий квартал. Следующий квартал наступает, и дата сдвигается снова. Потом ещё раз. Потом появляется новый блокирующий фактор, который выглядит абсолютно объективно.
Для этого явления есть название — синдром вечного пилота. Это состояние, при котором WMS, роботизация или другая складская автоматизация формально есть в планах компании, но де‑факто не движется с места уже год, два, три. Склад работает «как всегда»: объёмы растут, персонала не хватает, а стоимость операционных ошибок постепенно становится привычной строкой в P&L.
Привет, Хабр! С вами команда Russtech — разработчики IT-решений ведущего российского оператора рекламы вне дома Russ. 13-14 марта 2026 года компания RWB (Объединенная компания Wildberries & Russ) совместно с Национальным исследовательским ядерным университетом «МИФИ» провела командный хакатон на территории университета. Студенты решали бизнес‑задачи из сферы рекламы вне дома, создавали прототипы цифровых инструментов и представляли свои наработки экспертному жюри. Рассказываем, как это было.
Сейчас рынок складской роботизации во многом строится на китайских роботах и готовых аппаратных решениях. И в этом нет ничего плохого: у китайских производителей сильная инженерная база, большой выбор техники и понятная экономика.
Но у такого подхода есть важная особенность, о которой часто вспоминают уже после покупки. За последние несколько лет мы не раз сталкивались с ситуацией, когда заказчик в попытке сэкономить фактически приобретает дорогой металлолом.
Логика на старте понятная:
Привет, Хабр! Меня зовут Данила Ляпин, я Senior Data Scientist в Яндексе и автор курса «Специалист по Data Science» в Яндекс Практикуме.
В современном мире анализа данных пользу библиотеки Pandas трудно переоценить — она используется везде экспертами любого уровня: от стажёров до техлидов, а последние годы это де-факто стандарт в аналитике.
У Pandas есть огромная экосистема с большой базой знаний и интеграциями в различные библиотеки (тут и встроенная визуализация от matplotlib, и переход к данным в numpy формате, и много чего ещё). Практически каждый разведывательный анализ данных начинается с таких слов, как: read_csv, describe, head, isna().sum().
Но объём данных растёт ежегодно, память дорожает, а пайплайны усложняются. Чтобы загрузить локально большой датасет и обработать его, приходится не один раз словить "kernel crashed". И вот на этом моменте самое время поговорить про Polars, потому что там с этим как раз всё в порядке (и не только с этим :-)
Статья о том, как решить проблему «забывчивости» LLM между AI-сессиями разработки. Рассматривается причина деградации контекста и предлагается практический подход с использованием ai_readme файлов и агентских хуков, которые принудительно возвращают модель к важным инструкциям. Материал ориентирован на опытных промт-инженеров и показывает, как повысить стабильность и качество генерации кода в реальных больших проектах и при больших контекстных окнах.
Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.
Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».
Локально всё работает идеально: политики ловят нарушения, логи пишутся, система стабильна.
В проде Kubernetes‑кластера — теряются события, появляются дубли, а дедупликация ломается от одного скрипта.
Разбираю реальные проблемы, с которыми мы столкнулись при интеграции Tetragon и eBPF в реальный ИБ продукт, и почему Kubernetes ломает наивные предположения.
Agile и системная инженерия часто описывают так, будто это два несовместимых подхода.
С одной стороны — короткие циклы, быстрые гипотезы и готовность менять решение по мере появления новых фактов. С другой — требования, архитектура, интерфейсы, верификация, эксплуатация, риски и все то, что не помещается в backlog.
На практике сложные системы плохо живут в любой из крайностей. Если опираться только на жесткую последовательность этапов, команда слишком поздно узнает, как система ведет себя в реальности. Если опираться только на короткие итерации без дисциплины описаний и решений, наблюдения быстро теряются, а изменения начинают расходиться между собой.
Именно поэтому выход ISO/IEC/IEEE 24748-10:2026 выглядит важным событием. Это первая редакция стандарта из серии 24748, полностью посвященная systems engineering agility. Документ не предлагает «внедрить Scrum в системную инженерию», а задает стратегические аспекты гибкости и рекомендации по их выбору и применению.
Главная мысль стандарта, на мой взгляд, звучит так: agility в системной инженерии — это не набор ритуалов, а стратегическая рамка, делающая жизненный цикл отзывчивым к неполному знанию и изменяющейся операционной среде.
Если вы видели «С этим товаром покупают…», «Попробуйте этот урок дальше» или ощущали необычную точность автоподбора треков в музыкальных сервисах — вы сталкивались с рекомендательной системой.
Но стоит ли конкретному бизнесу вообще её строить? И если да, то с чего начать, чтобы не потратить впустую месяцы инженерного времени на «чёрный ящик», который никто не понимает?
Эта статья написана мной РУКАМИ (не «ИИ») и основана на моём выступлении‑вебинаре для инженеров, предпринимателей и продуктовых специалистов. Я не ML исследователь и не публичный спикер — я фулстек‑разработчик, который создавал и поддерживал рекомендательные системы в разнообразных коммерческих проектах.
Целевая аудитория — все, кому интересна эта тема.
Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». Это четвёртая статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом 1,5-2 млн рублей. Сегодня разбираем Biplane24.
Понимание данных прошло эволюционный путь от структуры хранения информации до ключевого элемента в конкурентной борьбе. Сегодняшние информационные технологии, такие как: искусственный интеллект, машинное обучение, предиктивная аналитика, рекомендательные технологии, существуют благодаря большим данным, анализу данных и стремительному развитию вычислительной техники.
Раньше все было иначе. Изначально данные рассматривались как составной, но обязательный элемент компьютерной программы, наряду с командами и алгоритмами. Постепенный функциональный рост софтверных программ от приложения до программного обеспечения, программной системы, информационной системы и корпоративной информационной системы менял взгляд на данные. Уходя от рассмотрения данных только лишь в контексте нормализации данных и СУБД, акцент последовательно перешел к вопросам миграции данных, поддержания их качества и, наконец, бизнес‑процессу управления данными.
В этой статье мы поговорим о том, как работать с мировыми финансовыми данными через Yahoo Finance и как получать котировки с российских площадок — Московской биржи и Тинькофф Инвестиций.
С чего начинается Родина для искусственного интеллекта? С датасета на русском языке? С гигантских кластеров H100, закупленных по параллельному импорту? С вывески корпорации на фасаде модели, архитектуру которой придумали в Google? Родина начинается с отказа от вероятностей. С собственных чертежей. С опоры на национальную научную школу.
Всем привет! Практически любая организация — от муниципалитета до стартапа — постоянно принимает поток разнообразных обращений. Навести порядок и ускорить их обработку можно с помощью простой заявочной системы: назначить ответственных, быстро подготовить нужные документы. Для этого подойдут готовые Helpdesk- или Servicedesk-системы, но их часто нужно интегрировать с уже имеющимися инструментами. Они хорошо работают для сложных бизнес-процессов с большими объемами заявок, но стоят дорого и требуют затрат на внедрение и поддержку. В общем, это развлечение для крупных и средних компаний. Для более простых кейсов можно собрать свою небольшую систему, используя no-code-платформы.
Меня зовут Иван, я бизнес-аналитик в MWS. В этом материале расскажу о реализации заявочной системы на платформе MWS Tables, где я взял на себя не только свою работу, но и функции всей команды — от архитектора до тестировщика. Таких примеров много, и на этом видно, как no-code и разумное использование нейросетей позволяют быстро автоматизировать бизнес-процесс и адаптировать его под меняющийся ИТ-ландшафт.
Это заключительная статья серии. Экспертная система, состоящая из информационных блоков и словаря, реализованная на принципах технологии поиска решений управляемого данными, позволяет накапливать и сохранять прикладные знания. Наполнение системы знаниями целиком и полностью доступно прикладным специалистам. Появляется возможность реализации прикладных задач в самых разных предметных областях с минимальным привлечением ИТ-специалистов, и практически без традиционного программирования. Опираясь на сохранённые знания, узкие прикладные специалисты могут автоматизировать свои насущные задачи. Радикально снижаются затраты на разработку и одновременно получается качественный, масштабируемый и легко сопровождаемый продукт.
Поиск решений, управляемый данными предполагает постоянное взаимодействие с пользователем. База знаний должна позволять одновременно обслуживать несколько клиентских мест. В статье рассматриваются принципиальные вопросы различных вариантов организации взаимодействия пользователей с экспертной системой (локально, в локальной сети, через интернет).
В статье не рассматриваются вопросы технической реализации типа: REST/SPA‑подход или long polling / WebSocket / server‑side session / event sourcing.
В данной статье рассматривается создание сервиса для динамического изменения размеров изображений с функциями проксирования и кэширования, а также приводится вариант его применения.