Я аналитик данных и люблю бумажный формат книг (если есть сомнения, сначала пробую электронную версию, но, если книга заходит, всегда потом беру бумажную).
В этой статье честный обзор, без рекламы, тех книг, которые я купила не так давно в бумажном формате.
За последние 1–2 месяца ИИ системы разработки сделали довольно значительный шаг вперед, стали меньше ошибаться, подключили планирование и обратную связь. Задавались ли Вы вопросом почему? Казалось бы, ИИ взял лучшие шаги из разработки ПО, разбил разработку «на промпты» (по агентам) и — прорыв. Вы удивитесь, все это было раньше, и даже сама разработка ПО — это лишь это часть универсальной базы, причем даже сейчас еще не до конца реализованной.
За последние полгода произошел большой слом — написание кода с AI перестало быть забавой и стало серьезным инструментом, способным писать хороший код, проектировать архитектуру и принимать сложные решения. Меня не отпускают вопросы о том, куда из-за всего этого движутся профессии, нужны ли будут программисты и как вообще изменится продуктовая разработка.
Но чтобы не стать еще одной статьей про размышления и спекуляции, я провел большой эксперимент: залез в самые внутренности AI-генераторов кода, создал сложный продукт с нуля, все сломал и починил, а затем с циферками поприкидывал насколько скоро нам всем на мороз.
Я долго думала, что PEP — это про оформление. PEP 8: называй переменные вот так, PEP 257: пиши докстринги вот так.
Потом начала использовать их по‑настоящему и выяснилось, что часть из них вообще не про то, как выглядит код!
Привет, Хабр.
Год назад мой босс выдал фразу, которая застряла во мне надолго: Что‑то какой‑то «пипец»... я как‑будто играю в «волк и яйца», цифры есть, отчёты есть, а радости нет, хотя мы вроде делаем грандиозные проекты. Прозвучало странно для технаря, но я как‑то для себя понял сразу, что это важно.
Компания выросла, отделов стало много, наняли уже больше 110 человек! Каждое подразделение живет своей жизнью. Продажи гонятся за деньгами, маркетинг рисует «красивые картинки» с яндекс‑метрики, проектный отдел тупо выполняет ТЗ, даже если видит реальные «косяки».
Я был нанят как аналитик Битрикс24. Поднастроили систему, дашборды, воронки, смарты, автоматизацию... Но понятно стало, что всё это какая‑то фигня, потому что на сайте компании была прописана миссия, а когда я спросил, оказалось её никто даже не читал. И я подумал «А мы, как компания, вообще что такое и куда идем?».
В какой‑то момент я перестал тупо следить за системой. Начал просто участвовать во всех ВКС, слушать, смотреть, реденько задавать неудобные вопросы. Через полгода гендир спросил: «А что ты вообще делаешь? Вроде ты не обязан быть на ВКС, но мы уже без тебя даже не начинаем».
Я тогда пошутил и придумал слово — Меридиант. Не спрашивайте, почему так. Наверное, потому что мне нравится фильм «Медиатор», и я любитель всяких древних практик связанных с чакрами, меридианами, каналами, медитациями и тому подобное, вот увидел что коммуникации в бизнесе, как линии на теле человека, тоже соединяют важные точки. Он меня потом еще раз пять переспрашивал, что за слово такое, ну а мне понравилось.
«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.
Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».
А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.
Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.
Казалось бы, сейчас мы наблюдаем всё, но факт в том, что не управляем ИТ-ландшафтом в целом. Упор на автономию команд и разрозненные инструменты приводит к «разрывам» в управлении: нет единой картины при инцидентах, SLA считаются в табличках, корреляция событий происходит «в головах людей», интеграции держатся на 1–2 специалистах, а построение CMDB и моделей ИТ ландшафта часто игнорируется. В этой статье мы постараемся переосмыслить роль зонтичного мониторинга, и докажем, что это не еще один мониторинг, а важный архитектурный слой.
Зачем бизнесу новая позиция в C-suite и что она означает на практике
Когда одни компании обсуждают, нужен ли им ИИ, другие уже нанимают человека, который будет отвечать за него (или сейчас сам сидит и пилит ИИ-агентов ) и все это на уровне совета директоров. Chief AI Officer — позиция, которая ещё три года назад звучала как фантастика, сегодня становится такой же обычной как СТО (ТехДир), CFO (ФинДир)или CHRO (HR).
Ну и что это за роль такая, откуда она взялась, чем отличается от CTO и CDO(Chief Digital Officer — директор по цифровой трансформации (это в больших банках есть такая позиция)), какие технические компетенции требует — и нужен ли он вам сегодня или как обычно, уже вчера.
Внутренние инструменты — это странный жанр. Ты не делаешь продукт для миллиона пользователей. Ты делаешь для двадцати человек, которые будут использовать это каждый день. И если облажалась — они скажут тебе об этом лично. Прямо на созвоне. Иногда с демонстрацией экрана, где всё сломано.
Я занимаюсь этим несколько лет. Python, внутренние сервисы, утилиты, автоматизация. За это время появился довольно конкретный взгляд на то, как надо работать. Не из учебника, а через синяки.
Сегодня уже можно говорить о том, что налоговый мониторинг перестал быть экспериментальной моделью. По данным ФНС России, с 1 января 2026 года в этом режиме уже работают 870 компаний из более чем 20 отраслей экономики. Это подтверждает, что мониторинг становится устойчивым форматом взаимодействия с налоговой службой для крупного бизнеса. А с учетом текущего вектора цифровой трансформации налогового администрирования можно предположить, что в ближайшее время количество участников режима будет только увеличиваться.
В статье «Налоговый мониторинг: режим «постоянной готовности»» я подробно разбирал саму модель налогового мониторинга, какие требования предъявляются к компании и как строится взаимодействие с ФНС. Поскольку налоговый мониторинг - это постоянное раскрытие данных, передача первичных документов и функционирование системы внутреннего контроля, для многих компаний, рассматривающих переход на этот режим, ключевым становится выбор подхода к организации этого процесса. А от того, насколько удобно выстроен процесс, зависит и то станет ли мониторинг управляемым инструментом или дополнительной нагрузкой.
Поэтому чтобы показать, чем отличаются подходы на практике, я решил пройтись по наиболее распространённым решениям, которые уже сейчас используют компании для работы в режиме налогового мониторинга. В этой статье я рассмотрю пять наиболее востребованных платформ и сопоставлю их по прикладным параметрам: удобству ежедневной работы, полноте раскрытия данных и первичных документов, поддержке системы внутреннего контроля (СВК), а также устойчивости и масштабируемости решения.
Системные аналитики на связи?
Тоже сталкиваетесь в работе со сложными распределенными системами, большим количеством интеграций и микросервисной архитектурой?
Тогда предлагаю вам узнать больше про модель C4 – отличный инструмент для проектирования, анализа и коммуникации между участниками команды.
Это не туториал и не истина в последней инстанции. Я просто делюсь своим опытом — как у меня родилась идея и как я её воплощала. Возможно, кому-то это поможет не наступать на те же грабли или подтолкнёт к собственным экспериментам.
Привет! Меня зовут Николай Олигеров, я работаю продуктовым аналитиком в Яндекс Путешествиях. В этой статье я расскажу, как мы применяли PSM (Propensity Score Matching) — статистический метод, который позволяет корректно сравнивать группы, уменьшая систематические различия между ними. Подробно разберу, как выровнять группы теста и контроля с помощью PSM, расскажу о типичных ошибках (например, утечке признаков), дам практические рекомендации по сбору и выбору фич для мэтчинга, а также покажу, как валидировать полученные результаты и оценить их достоверность.
SQL для аналитика: разбор 4 задач со скриптами и примерами данных
Собрала 4 задачи, которые решала на старте карьеры на реальных проектах, и показываю:
- как обычный GROUP BY превращается в полноценный ABC-анализ;
- как оконные функции помогают увидеть динамику, которую в Excel считать часами;
- как найти неэффективные категории (даже если по цифрам всё "нормально");
- как построить прогноз на паре оконных функций.
Внутри:
- Скрипты с пояснениями;
- Сгенерированные данные (можно скопировать и проверить);
- Пример бизнес-вывода к каждому запросу.
Статья для аналитиков, которые хотят прокачать SQL и понимать, что на самом деле происходит в их данных.
CJM в аналитике: почему ваши клиенты уходят и как это увидеть в данных
Вы наверняка видели красивые CJM-картинки с эмоциями, лицами и стрелочками, это красиво, но бесполезно, потому что настоящая карта пути клиента строится на данных, CJM – это не про «нарисовать портрет клиента», это про цифры, воронки и узкие места.
В этой статье я рассказываю:
- Что такое CJM с точки зрения данных (и почему это не про эмоции);
- SQL-скрипты для построения воронки, расчета времени между этапами и анализа переходов;
- Как искать узкие места, где клиенты реально страдают (и теряются деньги).
👉 Без абстракций, с кодом и готовыми данными для проверки.
Пользовательское требование описывает, что нужно пользователю. Критерии приёмки — фиксируют, как это проверить. Но между «что нужно» и задачей в Jira — пропасть. Чтобы её закрыть, я пишу функциональные требования — с use case'ами, из которых тестировщик может собрать тест-кейсы, а разработчик — понять ожидаемое поведение системы.
Маленькая шпаргалка для тех, кто хочет понять что это и как называется. Изначальная цель написания - предоставить заинтересованным лицам краткую справку и возможность более эффективно воспользоваться поисковыми системами. Здесь перечислены как классические паттерны и антипаттерны проектирования от банды четырёх (GoF), так и прочие общепринятые.
В НормЦРМ есть раздел «Контакты». В него я добавил теги. И есть раздел «Регулярные платежи». В него я добавил категории. По сути — одно и то же.
Задача: показать новым пользователям заранее заготовленные примеры тегов и категорий, чтобы они быстрее сориентировались.
Ограничения: два языка интерфейса (дальше — больше), а также непредсказуемость того, с какими тегами и категориями будут работать разные пользователи.
Начал я, разумеется, с проектирования. Сейчас расскажу и покажу процесс, поделюсь результатом и промптом, с помощью которого Codex справился с задачей с первой попытки.
Современные нейроморфные системы сталкиваются с двумя независимыми проблемами.
Проблема 1: Кодирование информации
Бинарные спайковые сети (SNN) передают градации сигнала через:
Частотное кодирование (множество тактов на одно значение)
Увеличение количества линий передачи
Проблема 2: Аппаратная реализация
Аналоговые мемристорные кроссбары обещают естественную нейроморфность, но содержат следующие проблемы:
Шум и дрейф параметров
Недетерминизм вычислений
Каждый чип требует индивидуальной калибровки
Традиционные Network-on-Chip (NoC) добавляют overhead:
~40% площади кристалла уходит на маршрутизаторы
~70% энергии тратится на пересылку данных, а не вычисления
Decima-8 предлагает:
Level16: кодирование уровня активации (0..15) в одном такте на одной линии. Это компромисс между бинарным представлением и аналоговой непрерывностью.
Цифровые кроссбары (эмуляция мемристорных матриц): детерминизм, воспроизводимость, отсутствие шума
Эстафетную активацию вместо пакетной маршрутизации: тайлы не передают данные друг другу, активация распространяется через граф зависимостей
Результат: фиксированная задержка, предсказуемое поведение, 0% площади на роутеры.
Привет! Меня зовут Фаина, я системный аналитик с опытом более 5 лет. В последнее время все чаще стала задумываться как системному аналитику в текущих реалиях применять в работе ИИ. Так началось мое погружение в увлекательный мир LangChain, ИИ, RAG и векторные БД.
Для начального исследования я решила попробовать что-то достаточно простое и базовое. Так в мою голову пришла идея создать ТГ бота, который напоминает о запланированных делах
