Дубль один, дубль два: как я делала одну фичу дважды

#почитать

Я бизнес- и системный аналитик, и у меня редкий кейс: две последние работы делают почти одинаковые продукты — по сути, конкурентные. Так что часть задач я делаю второй раз в жизни. Первый, как выяснилось, был генеральной репетицией. Жаль, никто не предупредил — я бы записывала.

Оба продукта — CDP (Customer Data Platform) для маркетинга. По сути это база данных, которая собирает информацию о клиенте отовсюду и нарезает её в сегменты, — а сверху на эту базу наслаиваются рассылки, бонусы и акции, ласково выманивающие клиента с дивана. Задача-дубль — конструктор сценариев: визуальный редактор, где кампания собирается цепочкой блоков. Классика жанра — сценарий на день рождения.

⏱Читать статью

Логарифм для аналитика: где он спасает отчет, а где его ломает

#почитать

Стабильное смещение — это уже не шум, это баг, поэтому я полезла в модель. Модель была нормальная, на логарифме выручки, обученная коллегой, метрики на валидации приличные, так что сначала я смотрела вообще не туда. Ошибка нашлась в последней строчке пайплайна: прогноз в логарифмах возвращали в рубли через np.exp(), просто экспонента, безо всего, и выглядит это абсолютно логично, преобразование же обратимое. На нашем распределении это занижало прогноз примерно вдвое, не на процент и не на пять. Чинится тремя строчками, и об этом будет раздел 7. Но сначала про то, о чем меня всегда спрашивают, когда я эту историю рассказываю: как такое прожило в проде несколько месяцев и почему не сработала валидация.

А валидация не могла сработать в принципе, и вот это самое интересное. Модель обучалась минимизировать ошибку на логарифме, метрики качества считались там же, на логарифме, и в этой системе координат она была честной: остатки центрированы около нуля, смещения нет, MAE и RMSE в порядке. Смещение рождается не в модели, а в момент выхода из логарифмов, потому что exp() от несмещенной оценки среднего логарифма дает оценку медианы, а не среднего. То есть ошибка была структурно невидима для проверок: они жили в той же системе координат, в которой ошибки еще нет.

⏱Читать статью

Как мы описали 15 000 таблиц за полгода вместо 500 за год — и перестали писать документацию руками

#почитать

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

В Яндексе одних только таблиц с данными — десятки миллионов, общим объёмом в экзабайты данных. Даже когда мы оставляем из всего этого количества только самое востребованное, остаётся несколько десятков тысяч таблиц, которые кто‑то должен описать словами: что внутри, откуда взялось, можно ли этому доверять. Без таких описаний аналитик не находит данные через поиск, не понимает, что лежит в таблице, и заново собирает то, что уже собрал коллега. И страдает не только человек: ИИ‑агенты, которые всё чаще сами решают аналитические задачи, на неописанных данных также теряют в качестве — чем меньше известно про таблицу, тем хуже результат.

Год мы уговаривали людей описывать таблицы вручную — и собрали описания всего на 500 таблиц из 40 тысяч. Если описывать все данные с такой скоростью (при учёте, что постоянно появляются новые) — страшно представить, на сколько десятков лет мог бы растянуться этот процесс.

⏱Читать статью

2 года в Obsidian: мой workflow, архитектура заметок, плагины и синхронизация

#почитать

Около двух лет я использую Obsidian как основное приложение для ведения заметок, планирования и написания статей. В этой статье я хочу поделиться своим полным workflow: от распределения заметок по папкам и горячих клавиш до детального Cheatsheet по хранилищу и организации метода Zettelkasten.

Сразу уточню: Obsidian становится действительно удобным только тогда, когда человек сам собирает под себя хранилище и находит подходящий ему метод. Ниже я разбираю реализацию по частям, чтобы каждый мог изучить интересующий блок, взять полезные идеи или настроить всё аналогично у себя.

⏱Читать статью

Проект признали успешным. А бизнесу стало легче?

#почитать

Мы перешли в опытно-промышленную эксплуатацию. До полноценного промышленного запуска было ещё далеко, но отчитываться уже было о чём. Основные контуры работали, подразделения начали собирать консолидированную потребность не в Excel, а в единой системе, пользователи осваивали новые процессы.
На управляющем комитете я именно об этом и рассказывал: что запущено, что работает, какие задачи ещё остаются. Спонсор выслушал и задал вопрос, который я помню почти дословно:

Хорошо, вы всё замечательно рассказываете. А давайте сейчас спросим бизнес. Что скажут директора заводов? Как закупщики отреагировали на систему? Им легче стало работать? Система действительно помогает им по сравнению с тем, что было раньше?

У меня не было хорошего ответа.

⏱Читать статью

Всё по полочкам или как мы создавали единую метрику для сотен моделей антифрода

#почитать

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

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

⏱Читать статью

Замороженная работа: метрика, которая считает непринятые решения

#почитать

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

Начал я с самого очевидного — померить, кто из аналитиков сколько делает. Провозился неприлично долго, получил красивые графики и всё выбросил. Дальше — почему выбросил и что нашлось, когда я перестал смотреть на людей.

Сразу оговорюсь про две вещи. Первая: это не статья про оценку эффективности сотрудников, скорее наоборот — про то, почему у меня не получилось её написать.

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

⏱Читать статью

Армия в терминале

#почитать

Как coding agents превратили разработчика в диспетчера машин — и запустили гонку оркестраторов, песочниц и ИИ‑фабрик.

⏱Читать статью

Компании одного хита: почему один гениальный продукт так трудно повторить

#почитать

В ноябре 2016-го дрон GoPro Karma начал падать с неба. У части аппаратов прямо в полёте пропадало питание, и меньше чем через три недели после старта продаж GoPro отозвала все проданные экземпляры, около 2500 штук. Провалился даже не один гаджет — провалилась попытка компании стать чем-то большим, чем автор одной удачной идеи.

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

⏱Читать статью

Чек‑лист по настройке системы дашбординга

#почитать

Дашбордами в современных технологических компаниях уже никого не удивить, однако хорошо структурированную, актуальную и стабильную систему BI‑отчетов можно встретить далеко не всегда.

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

⏱Читать статью

Docker Fundamentals: хранение данных в Docker

#почитать

Контейнеры в Docker изначально не предназначены для постоянного хранения данных. Если удалить контейнер, всё, что было записано внутрь него, исчезнет вместе с ним. Поэтому для баз данных, пользовательских файлов и других важных данных используют отдельные механизмы хранения.

⏱Читать статью

Архитектура «Гегелло», или как мы создали собственную платформу для анализа состояния оборудования

#почитать

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

⏱Читать статью

Крашенная и не накрашенная…

#почитать

Предлагаемое решение не только хорошо тем, что является простым. Его главным преимуществом является возможность разным сторонам обмена ресурсами (даже в случае покупателя и продавца заинтересованных сторон всегда больше, чем две) указывать свои способы окрашивания, что бы ограничить передачи ресурсов. Достаточно тонко настроить потоки обмена, при этом не обременять систему избыточными вычислениями.

⏱Читать статью