Nvidia стала первой в истории компанией с капитализацией в $4 трлн (больше крипторынка, который весь составляет $3,6 трлн). Это происходит на фоне бума нейросетей.
Repeater - планировщик для анализа данных, упрощенный Apache Airflow.
Repeater запускает задачи по расписанию. Задачи - последовательности консольных программ - описываются в toml-файлах. Запуски отображаются в веб-интерфейсе.
Пример задачи - запуск скриптов wiki_stats.py и wiki_pageviews.py импорта верхнеуровневой статистики Википедии в локальную базу.
title = "wiki"
cron = "0 55 * * * *"
[[tasks]]
name = "wiki_stats"
cmd = "python3 ./examples/wiki_stats.py"
[[tasks]]
name = "wiki_pageviews"
cmd = "python3 ./examples/wiki_pageviews.py --end_date={{.scheduled_dt}}"Бэкэнд написан на Go. Команды ниже запустят Докер-контейнер с сервисом и окружение для примеров:
- Repeater http://localhost:8080 - планировщик
- ClickHouse http://localhost:8123 и http://localhost:9000 - база данных
- ch-ui http://localhost:8001 - веб-интерфейс к базе данных
- Streamlit http://localhost:8002 - дашборды
git clone https://github.com/andrewbrdk/Repeater
cd Repeater
docker compose up --buildВ примерах импорт количества просмотров страниц Википедии, курса биткоина, статистики репозитория Линукса на Гитхабе. Графики в Streamlit http://localhost:8002 .
Интересны применения проекта. Попробуйте! Впечатления пишите в комментариях. Спасибо!
Репозиторий: https://github.com/andrewbrdk/Repeater
Из разговора с потенциальным клиентом…
Клиент: Сколько страниц будет входить в аудит?
Я: Неизвестно. Почему неизвестно? Потому что у меня нет цели написать определённый объём правок и замечаний. Сколько их увижу — столько и зафиксирую. Если бы я проаудировал систему и не нашёл в ней ни одной проблемы — размер документа не превышал бы одной страницы.
Тут сразу пара моментов, которые хотел бы подсветить.
Я раньше, когда работал над документацией, считал, что «чем объёмнее — тем лучше». Это ещё со школы и универа. Реферат должен быть на пять листов. Эссе на семь. Доклад на три.
Акцент был на форме, а не на содержании. И это ужасно. В начале двухтысячных, когда работал в компании Webmaster.Spb проектировщиком, клиентам нравились толстые ТЗ. Точнее, представителям клиентов. Менеджерам. Сами-то клиенты эти ТЗ не читали, насколько мне известно.
Из строительной тематики тоже была клёвая байка, которую мне рассказал один из клиентов: «Я однажды сдаю своему шефу пачку документации высотой в два сантиметра. А он смотрит на неё и пальцами показывает три сантиметра. Вот столько, говорит, надо. Возвращайся, когда будет пачка высотой в три сантиметра».
Это первый момент. А второй — если во главе стоит форма, а не содержание, то это сродни проектированию главной страницы сайта, когда всё остальное ещё не готово. Спроектировал главную за час, а потом пятьдесят часов подгоняешь остальные сто страниц под неё. Вместо того, чтобы сделать всё без ограничений, а главную рисовать уже в самом конце, когда весь проект будет понятен. В виде вишенки на торте.
Иногда ещё, знаете, решишь написать статью. И придумываешь ей заголовок «пять ошибок начинающих проектировщиков». И вот четыре ошибки легко расписал, а пятую никак придумать не можешь. И сидишь, мучаешься, тратишь время. А мог сначала статью написать, ограничившись четырьмя ошибками, а затем уже заголовок придумывать.
Прикиньте, кто-то сначала бы придумал тематику: пять начал (законов) термодинамики. И после четвёртого сидел бы и страдал.
Возвращаясь к моим аудитам: у меня нет задачи найти конкретное количество косяков. Задача — проверить, достигают ли пользователи интерфейса своих целей. Если достигают — и отлично! Радоваться надо, что в моём документе будет одна строчка текста («Всё идеально, красавчики»). Это как на чек-ап пойти ко врачу и переживать, что ничего не нашли.
К сожалению, на практике такого ещё ни разу не было. Всегда что-то нахожу.
П.С.
Представляете, я бы сказал, например: «Четыре страницы». Сделал бы аудит и нашёл бы ошибок на две страницы. И что бы делал? То же, что в школе и универе? (здесь должна быть какая-нибудь эмодзи с льющейся бессмысленной водой)
Случайна ли случайность? Теория вероятности и личный опыт
Все мы когда-то слышали или читали, что кто-то где-то выиграл джекпот. Столько-то миллионов рублей или долларов, не имеет значения. Важно то, что этого никогда не случится с нами, потому что вероятность этого события – 1 на сотни миллионов.
Однако, со мной кое-что случилось, что, мне кажется, в соответствие с теорией вероятности случится не должно было никогда. И этим оно напоминает джекпот.
На старших курсах ВУЗа проходил практику в школе своего города, который расположен ровно в 1 000 км от Москвы. Преподавал естественные дисциплины школьникам 5-9-х классов. Не суть, что там было по учёбе, главное, что в одном из 9-х классов учился юноша, который в следующем учебном году, т.е., уже осенью, должен был уехать с родителями в Москву. Юноша упомянул как-то про это, и мы даже разговорились с ним, потому что я сам через несколько месяцев собирался уехать в Москву на стажировку. Для нас обоих это был совершенно новый, неизведанный мир. Одно слово - столица!
Наступила осень. Приехала в гости к молодому стажёру мама и я повёл её в театр. И вот садимся мы на свои места, а рядом, на соседнем месте оказывается… тот самый юноша, уже московский десятиклассник, с которым мы полгода назад болтали непринуждённо про столицу нашей Родины.
В пекло теорию вероятности! В соответствии с ней описанное выше событие не могло произойти со мною в принципе. А оно было. И это реальный факт, который до сих пор помню.
Вот так я выиграл свой «джекпот», за несколько сотен рублей, которые стоил билет в театр в далёком 1992-м году. Правда, выигрыш в том «джекпоте» достался мне небольшой, точнее сказать, ничего не досталось, кроме улыбки и взаимного удивления невероятному стечению обстоятельств. Но, надеюсь, что для одного небольшого поста на Хабр этого хватит.
И, конечно, было бы интересно оценить вероятность описанного выше события, однако, я затрудняюсь даже с направлением, с какой стороны следует подступаться к такой оценке, не то, чтобы какими-то цифрами оперировать.
Тут, думаю, нужны кругозор и хватка многоопытного актуария или серьёзного аналитика, для которого подобные задачки – как семечки щёлкать. Есть ли такие на просторах Хабр?
Новая версия Gramax!
Сравнение ревизий. Можно сравнить текущую версию каталога с одной из предыдущих.
Экспорт в корпоративных шаблонах DOCX. Добавили возможность загрузить корпоративный шаблон DOCX и экспортировать статьи и каталоги в этом шаблоне.
Избранное. Каталоги и статьи можно пометить как Избранные для быстрой навигации. Это доступно как в приложении, так и на портале документации.
Связанные статьи. В меню статьи можно просмотреть: куда ссылается статья и какие статьи ссылаются на нее.
Об этих и других изменениях читайте в Release Notes 🔥
Опыт сети гипермаркетов Hoff: перенести резервные копии данных в облако и оптимизировать затраты 🛒
Что за компания
Hoff — Home of furnishing — российская сеть гипермаркетов мебели и товаров для дома. 60 магазинов в разных форматах работают в крупных городах по всей России.
Какая была задача
У Hoff есть интернет-магазин и приложение, которые размещены в основном дата-центре. Компании были нужны резервные копии сайта и приложения на случай, если в работе локальной инфраструктуры произойдет сбой.
Основные требования Hoff к провайдеру и облачным ресурсам: отказоустойчивость, скорость реакции на запросы, круглосуточная связь с поддержкой, качество ответов и компетентность сотрудников.
Как ее решили
Вместо покупки дополнительных серверов и затрат на их содержание Hoff решила разместить копии в облаке. Так компания не только оптимизировала расходы на инфраструктуру, но и обеспечила непрерывную работу бизнеса.
Cloud.ru построила для Hoff инфраструктуру в Облаке VMware, подключила интернет-канал, настроила два выделенных канала связи, коммутацию и маршрутизацию сети, а еще предоставила доступ к API, чтобы автоматизировать процесс переключения между площадками.
Что в результате
В облаке развернута онлайн-реплика боевой площадки — она меньше по количеству вычислительных мощностей, но идентичная по данным и функционалу. При необходимости реплика мгновенно масштабируется по вычислительным мощностям в 10 раз (до 800 CPU, 2 TB RAM, 27 TB SSD), чтобы выдержать весь пользовательский трафик, который будет переключен с вышедшей из строя основной площадки.
План/факт по выручке, запасы, СТМ — все на дашборде. Реальный кейс BI в аптеке.
Клиент: аптечная сеть, работает более 30 лет, с сильной социальной миссией: через нее льготники получают лекарства. Свыше 250 точек, собственные товары, тысячные товарные позиции. Без четкой аналитики такой бизнес трудно масштабировать.
Учет через «СмартАптеку». Программа хорошо заточена под фарму, есть контроль ЖНВЛП, интеграция с «Фармзаказом» и встроенные отчеты. Но как только речь заходит о план/факте, оборачиваемости и автоматических отчетах для руководства, возникает «аналитический дефицит».
Задачи:
автоматические отчеты по ключевым метрикам,
единые витрины данных по остаткам и продажам,
видимость выполнения планов по аптекам,
контроль доли СТМ.
Что сделали
Мы настроили BI-систему и разработали витрины «Анализ остатков» и «Анализ продаж», с учетом специфики клиента. Данные поступают из «СмартАптеки» + Excel-файлов с планами. На витринах отображаются:
план/факт по выручке,
запасы и оборачиваемость,
сезонность и тренды,
доля СТМ.
Отчеты обновляются автоматически. Топ-менеджмент получает актуальные данные каждое утро.
Технические нюансы
Открытый API «СмартАптеки» не позволял вытянуть все нужные данные. Мы подключили разработчиков учетной системы, они подготовили индивидуальную выгрузку. Благодаря этому проект завершился успешно.
👩💼 Хотите увидеть, как это работает? Приглашаем на вебинар!
Тема: BI для аптечных сетей: как привести в порядок остатки, продажи и аналитику
Дата: 24 июня в 12:00 мск
Спикер: Анна Светличная, руководитель проектного отдела
Бонус: Скидка 10% на предпроектное обследование
Кэширование: как работает, обновляется и очищается кэш⁉️
Кэш – быстрый временный буфер для хранения данных. Его цель – ускорить доступ к информации и снизить нагрузку на основное хранилище или систему
Варианты кэширования:
1️⃣Cache Aside. Читаем из кэша. Если нет, то читаем из БД и кладём в кэш
2️⃣Read Through. Запрос идёт в кэш, при необходимости обновляет данные из БД
3️⃣Write Through. При записи сразу обновляем кэш и БД
4️⃣Write Behind. Сначала пишем в кэш, позже – в БД
5️⃣Refresh Ahead. Кэш обновляется заранее, до истечения срока жизни
Алгоритмы обновления кэша:
1️⃣TTL (Time To Live). Данные удаляются по таймеру
2️⃣По записи. Кэш обновляется автоматически при изменении данных
3️⃣По запросу (manual invalidation). Кэш сбрасывается вручную
4️⃣Прогрев (pre-warming). Кэш заполняется заранее
5️⃣По расписанию (scheduled refresh). Кеш обновляется по расписанию
Алгоритмы вытеснения (eviction):
1️⃣LRU (Least Recently Used). Удаляем самый давно неиспользуемый элемент
2️⃣FIFO (First In, First Out). Удаляем самый старый элемент
3️⃣LFU (Least Frequently Used). Удаляем наименее используемый элемент
4️⃣Random. Удаляем случайный элемент
А ещё у меня в боте можно скачать бесплатный методический материал, где ты найдешь шаблоны пяти основных диаграмм на PlantUML в практических кейсах с описанием.
Как компания «Литрес» построила облачное аналитическое хранилище на базе КХД Cloud.ru и сократила время обработки и анализа данных 📚
Что за компания
Компания «Литрес», основанная в 2005 году, сегодня является лидером на рынке лицензионных электронных и аудиокниг в России и странах СНГ. Ежемесячная аудитория сервиса Литрес составляет 11 млн человек, которые скачивают более 2,7 млн книг в месяц.
Какая была задача
«Литрес» подошла к этапу, когда мощностей для быстрого расчета витрин для аналитики и отчетности перестало хватать, поскольку был накоплен значительный объем данных — около 6 ТБ. Компания решила разработать собственное хранилище — создать надежную и масштабируемую платформу для хранения и обработки больших объемов данных, что позволило бы оптимизировать бизнес-процессы и повысить эффективность работы.
Как ее решили
Изначально у нас было два варианта, как можно сделать большую аналитическую базу. Первый и самый очевидный — запустить Greenplum. Но для этого нужно было выделять серверы, оптимизировать решение, нанимать администраторов — это сложно и долго. В качестве второго варианта можно было закупить готовое решение у подрядчика, однако выяснилось, что поддержка такого решения при приемлемом уровне производительности стоит космических денег. В итоге в Cloud.ru нам предложили альтернативу — КХД — облачное корпоративное хранилище, которое дает возможность быстро обрабатывать огромные массивы данных из разных систем хранения и источников. Решение нас заинтересовало.
Кирилл Шевченко
Руководитель отдела разработки информационно-аналитических систем группы компаний «Литрес»
Чтобы понять, какое решение выгоднее и эффективнее, «Литрес» провели исследование и сравнили работу КХД, ClickHouse в облаке и локального ClickHouse компании. Результат — КХД лучше всего справился с поставленными задачами (например, обработка больших запросов на таблицах с JOIN заняла всего 20 минут).
Что в результате
Команда «Литрес» создала собственное хранилище на базе КХД Cloud.ru и в результате сократила время на обработку и анализ данных:
обновление всего хранилища занимает 40 минут вместо 3 часов,
среднее время выполнения процедур — 2 минуты вместо часа,
на обработку простого запроса при обновлении витрин хватает 5 секунд.
раньше на создание одной витрины требовалось несколько дней, а теперь можно создать 3 витрины в день.
Бесплатный гайд с шаблонами диаграмм на PlantUML
В моем канале IT Talks можно скачать бесплатный методический материал, где ты найдешь шаблоны пяти основных диаграмм на PlantUML в практических кейсах с описанием.
Для каждого шаблона подробно описан процесс, для которого построена диаграмма, а также есть сама диаграмма и исходный код на PlantUML. В гайде можно найти диаграмму активности, последовательности, прецедентов, состояний и компонентов.
Ещё вчера у меня вышла новая статья Диаграмма последовательности на практике в реальном кейсе, где я подробно по шагам рассказала про построение диаграммы последовательности на примере реальной задачи.
Как провести быстрый аудит разработки без изучения кода: доклад Андрея Бирюкова на CTO Conf X 2025
В пятницу прошла интересная конференция для технических директоров – CTO Conf X 2025. Вице-президент по исследованиям, разработке и сервисам ГК InfoWatch Андрей Бирюков выступил перед аудиторией с докладом «Как провести быстрый аудит разработки без изучения кода».
«В практике СТО может возникнуть ситуация, когда необходимо оперативно провести глобальную оценку или чек-ап разработки: вы перешли в новую компанию и нужно быстро во всем разобраться, появился запрос на изменение подходов к разработке, или ваша компания собралась покупать другую и нужно понять, что там внутри. В докладе поделился своим видением – какие вопросы и кому важно задавать, стоит ли насторожиться, если нет багов, а план фичей расписан на пять лет вперед, и почему в центре внимания должны быть люди, а не код», – говорит Андрей Бирюков.
В докладе он рассказал о методах оперативной оценки состояния разработки в новых или приобретаемых командах. Его методика поможет понять, насколько модель разработки компании далека от идеальной, выявить и поставить в приоритет потенциальные проблемы.
Общая схема аудита, анализ процесса разработки, оценка инженерных практик — в презентации с выступления.
Здесь кто-нибудь есть?
Давненько не было постов! Теперь посты будут выходить намного чаще, поэтому ждите интересный контент! Сегодня хочу с Вами поделиться своими наблюдениями по самым распространенным страхам при входе или же в начале карьеры в IT, а также конечно же расскажу, как с ними бороться!
Поехали!
Большие деньги - большая ответственность, я еще немного поучусь и можно ходить на собеседования
Самое частое заблуждение и страх - это то, что я не до конца изучил материал и мне рано идти на собеседования. IT действительно кажется сложной сферой, особенно на старте. Куча непонятных терминов, новые технологии, быстрая смена трендов. Главное — не пытаться сразу охватить всё. Дроби путь на маленькие шаги: сначала разберись в основах, потом усложняй задачи.
Признайте, что никто не знает всего, даже сеньоры постоянно гуглят и учатся. Учись радоваться прогрессу, пусть даже небольшому — это отличный способ победить страх перед сложностью. Я часто на работе вижу людей, которые знают намного меньше меня, но при этом зарабатывают больше денег. Думаете, что они думают про это?
Убейте в себе внутреннего "отличника", который хочет всё идеально знать. Начните действовать как можно раньше, ведь главный наш ресурс - это время. Если не начнете ходить по собеседованиям сейчас, то потом может стать поздно!
Я слишком стар/молод/у меня нет профильного образования
Это миф. В IT реально можно войти в любом возрасте и с любым бэкграундом. Большинство компаний смотрит на твои навыки и то, как ты решаешь задачи, а не на диплом. Например у меня еще ни разу не спрашивали про мой диплом и про моё образование, но при этом огромное кол-во людей верит в то, что реально нужен крутой бэкграунд, а не опыт. Важно показывать интерес к профессии, прокачивать навык прохождения собеседований, учиться продавать себя на рынке труда и тогда у Вас всё получится! Как говорил Олег Тинькофф: "Продай свои мозги дорого". Это очень хорошо описывает в целом текущее состояние рынка.
Я буду выглядеть глупо среди опытных коллег Это нормально — не знать и ошибаться, особенно в начале. Важно не бояться задавать вопросы. В IT очень развита культура поддержки: тебе скорее помогут, чем осудят. Воспринимай каждую ошибку как точку роста, а не как провал. Ведь наш опыт - это сумма всех наших ошибок. Думаете, что какой-то сеньор никогда не допускал ошибок?
Я не найду работу без опыта От каждого второго человека слышу это. Мол я не могу найти работу без опыта, всё дело в опыте! А потом я открываю его резюме и вижу, что там полная каша и оказывается, что дело не в опыте, а в резюме или же в чём-то другом. Не бойтесь искать любую возможность попробовать реальные проекты. На старте важно показывать свою мотивацию и учиться командной работе. Не стесняйся писать в компании напрямую, предлагать свою помощь за отзыв или за опыт — так много кто стартует.
Теперь дам общие советы, которые подойдут под любой Ваш страх. Но помните, что я Вам даю всего лишь отмычки, а Вы их уже сами подбираете под Ваши "проблемные" двери:
Разделяй путь на маленькие задачи и радуйся каждому шагу.
Найди ментора, чтобы не оставаться один на один с вопросами.
Веди дневник успехов — записывай даже маленькие победы.
Не сравнивай свой путь с другими, особенно в соцсетях — у каждого свой старт и темп.
Признай: страх — это нормально. Его испытывали все, кто сегодня работает в IT.
Понравился пост? Тогда переходите ко мне в телеграмм канал, там находится много полезного материала, для входа в IT!
Привет, меня зовут Александр, я аналитик в Альфа-Банке. Однажды я устал, что на Feature Store, на платформе для дата-инженеров (DE) и дата-саентистов (DS), невозможно ничего найти.
Поиск по контексту отсутствует. Приходится руками шерстить огромное количество ETL-проектов в поисках той самой полезной информации, полагаясь сначала на удачу, а после — на опыт и помощь коллег.
Feature Store сама по себе — платформа, которая должна упрощать работу коллег с большими данными, упрощает бюрократию жизненного цикла создания ETL, ввода моделей в промышленную эксплуатацию. Но какой же поиск там...В общем, хотелось бы улучшить процесс по поиску данных в ней.
И я сделал MVP с GPT-2: весит около ~400 МБ и, самое главное, не требует регистрации. В статье пошагово описал, как всё прикрутить. Заходите почитать.
Примечание. Для прома MVP, конечно, не прокатит, но после показа решения начали реализовывать решение на OpenSearch.
Ближайшие события
Как строить систему отчетности? Расскажет Рома Бунин!
В мае в гости к аналитическому комьюнити Garage Eight заглянул Рома Бунин, специалист по визуализации данных и развитию BI-систем, Head of Data Nebius Group, а также автор канала Reveal the Data. На встрече он рассказал про Dashboard Map. Этот фреймворк позволяет заранее оценить, какая аналитика нужна внутри команды, и подготовить инструменты для разных типов задач.
Лекцию записали и теперь делимся с вами!
Из нее узнаете:
> зачем нужно заранее проектировать архитектуру системы дашбордов;
> из каких шагов состоит проектирование;
> как заполнять Dashboard Map;
> как провести сессию проектирования;
> что делать после сессии;
> примеры систем дашбордов.
Pull/Merge Request для согласования требований и документации
Аналитики и технические писатели, признайтесь: сколько раз вы теряли время, сравнивая версии документов в MS Word? Компьютер тормозит, красные и синие правки сливаются в кашу, а поиск согласования в бесконечной переписке или Confluence превращается в квест.
Есть решение — берем механизм Pull/Merge Request и применяем его к текстам! Что получаем:
Все правки в одном месте. Редактируйте несколько документов сразу и смотрите изменения в едином окне. Забудьте про переключение между файлами и версиями!
Подробная подсветка. Все правки видны построчно или в удобном визуальном редакторе — сразу ясно, что добавили, убрали или исправили.
Простое согласование. Назначайте проверяющих и получайте их апрувы прямо в интерфейсе. Никаких "ок" в письмах или мессенджерах!
Полная история. Все комментарии, согласования и версии сохраняются. В любой момент можно вернуться и проверить, кто, что и когда утвердил.
Экономия времени. Gramax объединяет редактирование, ревью и согласование в одном месте — больше не нужно жонглировать Word, Confluence и почтой.
И все это в Gramax! Как всегда: бесплатно и с открытым исходным кодом.
Все как в коде, только проще.
💥 Майская версия Gramax 💥
Что нового мы добавили в open source-платформу для управления технической документацией Gramax.
ИИ-поиск для портала документации. Раньше поиск по документации был ограничен точным совпадением слов, теперь можно подключить ИИ-поиск от любого провайдера (например, OpenAI, Anthropic и др.) и искать по смыслу. Даже при неточном запросе пользователь получит релевантные результаты. Поддерживается как облачное подключение, так и запуск собственного сервера — для тех, кому важна приватность.
ИИ для создания и редактирования текста. В пространстве редактора можно также подключить ИИ. Он позволит написать текст с нуля: например, если не удается придумать структуру статьи. А также отформатировать существующий текст. В случаях, если его нужно сократить, сделать более формальным или структурированным.
Шаблоны. Добавили возможность создавать шаблоны со свойствами и использовать их в статьях.
Заметки. Теперь можно прямо в каталоге сохранять идеи и предложения для изменения документации. Заметки сохраняются в репозитории, но не отображаются на портале для чтения.
Расширенный редактор сниппетов. Теперь сниппеты можно оформлять как и обычную статью без ограничений.
Выбор формата для исходных файлов. Добавили 2 дополнительных формата хранения статей — XML и GitHub Flavored Markdown. Изменить формат можно в настройках каталога.
Вход для внешних пользователей в Gramax Enterprise Server. Добавили возможность настроить вход на портал для чтения по почте: таким читателям не нужно иметь учетную запись в SSO. Достаточно указать свою почту при входе и ввести одноразовый код.
О других изменениях читайте в статье — https://gram.ax/resources/docs/whats-new
Если много стараетесь, но результата нет — вот что помогает мне: вместо того чтобы делать всё подряд, я ищу одну главную причину, что тормозит, и фокусируюсь только на ней. Это даёт максимальный эффект.
Вот 2 типичных случая, когда не получается сдвинуться с места:
1. Неясно, за что хвататься — и ничего не работает.
Пример — новички в аналитике, которые ищут работу, часто не понимают, на чём сфокусироваться. Мысли скачут: “Может, выучить ещё один инструмент? А вдруг дело в опыте?”. Паника только усиливает расфокус. Но стоит спокойно разобрать воронку — и оказывается, всё сыпется уже на этапе резюме. Откликов нет, потому что резюме общее и сырое. Когда текст становится чётким и показывает ценность для работодателя — начинаются отклики.
2. Фокус на том, что привычно, а не на том, что важно.
Пример — у многих начинающих предпринимателей с бэкграундом в разработке или аналитике не получается делать продажи. Причина банальна: на сайте нет трафика. Но вместо того чтобы заняться маркетингом и привлечь хотя бы первых 1000 человек, разработчики продолжают улучшать продукт, а аналитики — совершенствовать сбор данных. Продукт еще никто не видит, а данные не на что применять, поэтому пока не решишь вопрос с трафиком — всё остальное делать бессмысленно.
Прогресс начинается тогда, когда находишь и убираешь главное препятствие, а не делаешь всё подряд или то, что привычно.
Эту идею описал Элияху Голдратт в книге "Цель". Главный герой, Алекс, должен за 90 дней спасти завод, и наставник учит его искать главное ограничение — и устранять именно его. Хотя книга о производстве, принципы легко применимы в любой сфере.
Суть: в любой системе есть одно узкое место, которое сдерживает результат. Оно может быть внутренним (процессы, команда) или внешним (рынок, ресурсы). Пока это ограничение не убрано — остальные усилия почти бесполезны.
Недавно увидела, что результаты по проекту не те, которые планировала (а недавно я еще и увеличила планку), поэтому решила применить теорию на практике. Что сделала:
Выделила время на глубокий анализ данных из систем аналитики. Данные подсказывали: проблема — в продукте или его позиционировании. Но не всё можно понять только по цифрам.
Поэтому я подробно описала ситуацию ChatGPT — что происходит, мои сомнения и приложила данные. Попросила найти ограничение через призму Теории ограничений.
Сначала ChatGPT предложил несколько вариантов. После пары итераций с уточняющими вопросами я нашла главное ограничение.
Сейчас фокусируюсь на устранении этого ограничения. Когда решу — перейду к следующему ограничению (это, кстати, один из принципов Теории ограничений).
В чём отличие от обычной расстановки приоритетов?
Приоритеты часто ставят на ощущениях. Теория ограничений даёт чёткий фокус — куда бить, чтобы был максимальный эффект.
Конечно, идеализировать не стоит — у любой теории есть рамки. Теорию ограничений лучше применять, когда:
— Ресурсы ограничены — а так почти всегда: время, деньги, внимание.
— Нужен быстрый результат
— Система (бизнес, команда, проект) не даёт результатов, хотя вроде “всё делается”
Любая теория — не панацея, но помогает по-новому увидеть свою ситуацию.
Alfa Analyze IT Meetup #4
19 июня наше SA-сообщество проведёт четвёртый Alfa Analyze IT Meetup — поговорим о том, как оценивать навыки по матрицам компетенций, принимать решения о повышении и адаптироваться к изменениям от ИИ.
Вы поймёте, как тимлиды ищут таланты внутри команд и выстраивают карьерные треки, а также получите готовые инструменты для оценки и развития аналитиков.
В программе:
процесс ассессмента для аналитиков в Альфа-Банке,
выстраивание и развитие матрицы компетенций системного аналитика Газпромбанк.Тех в эпоху цифровой трансформации,
развитие системных аналитиков в X5 Tech: от внутреннего поиска до повышения с опорой на матрицу компетенций,
архитектура DWH в Яндекс Go: технологии, подходы, матрица компетенций.
Присоединяйтесь онлайн и офлайн — зарегистрироваться можно по ссылке.
Где: Офис Альфа-Банка по адресу Москва, Андропова пр-т., 18 к.3, в трёх минутах пешком от метро «Технопарк».
BI-система помогает аптечным сетям управлять продажами быстро и эффективно
Если вы хотите оперативно принимать решения, опираясь на точные данные, приглашаем вас на вебинар-демонстрацию решения по BI-аналитике специально для аптечных сетей.
Дата: 24 июня
Время: 12:00 мск
Бонус для участников: скидка 10% на проведение предпроектного обследования
С помощью BI-аналитики можно собирать и визуализировать ключевые показатели работы аптечной сети: от продаж до эффективности персонала. Вы получите полную картину в виде понятных графиков и диаграмм. А главное, сможете быстро скорректировать стратегию работы, особенно во время сезонных пиковых нагрузок.
Этим инструментом уже пользуются некоторые аптеки. В одном из недавних кейсов рассказывала, как крупная сеть, включающая более 250 точек, получила возможность анализировать остатки и продажи. Например, система показывает, как долго товары лежат без движения, а также предрассчитывает, на сколько хватит запасов.
На вебинаре руководитель проектного отдела Анна Светличная расскажет:
какое решение поможет управлять аптечной сетью на основе данных,
почему бизнес-аналитика становится стандартом в аптечном ритейле,
как с помощью BI можно находить точки роста и управлять показателями в реальном времени.
Также проведем демонстрацию продукта на примере данных аптечных сетей и ответим на ваши вопросы.
PlantUML | Шаблон для описания таблиц БД
Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.
Всем привет!
Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.
Протестировать можете тут, а сам код шаблона указан ниже:
' Шаблон описания таблицы БД (в PlantUML)
@startuml
skinparam {
' Параметры для управления нижним колонтитулом
FooterFontColor #blue
FooterFontSize 12
' Параметры для управления легендой
LegendBackgroundColor #lightblue
LegendBorderThickness 0
}
' Переменные для ускорения описания таблицы
' - PRIMARY KEY можно указывать как: "$PK"
!$PK=" <size:11><#DarkKhaki:key:></size> (PK) "
' - FOREIGN KEY можно указывать как: "$FK"
!$FK=" <size:11><#DeepPink:key:></size> (FK) "
' - NOT NULL (N-N) можно указывать как: "$NN"
!$NN=" <#LightGreen> **N-N** "
' - NULL можно указывать как: "$N"
!$N = " <#LightCoral> **NULL** "
' Переменные для ускорения добавления информации о таблице
' - Наименование таблицы БД (латинское)
!$table_name="Наимнование_таблицы_БД"
' - Краткое описание таблицы (на русском)
!$description="Краткое описание таблицы (на русском)"
' - Ссылка на описание таблицы (на русском)
!$doc_url="Ссылка"
' Контакты, отображаемые в нижнем колонтитуле
!$autor ="Зимин Антон"
!$email ="antzim_in@ya.ru"
!$telegram="antzim_in"
' Заголовок документа, формируется автоматически из заполненных выше параметров (при необходимости можно удалить)
title $table_name | $description
' Легенда (может быть заполнена любыми необходимыми данными)
' - "right" говорит о том, что легенда будет расположена справа
legend right
**Легенда:**
| Версия документа: | 1.0.0 |
end legend
' Описание таблицы
' - заголовок таблицы, с кликабельной ссылкой (если выгружать в SVG) формируется автоматически
class "[[$doc_url $table_name]] ($description)" as $table_name << (T,#FF5722) >>{
|= PK,FK |= Поле |= Тип |= Обязательность |= Значение\n по умолчанию |= Описание |
| $PK | id | serial | $NN | | Идентификатор записи в таблице |
| $FK | subscriber_id | integer | $NN | | Идентификатор записи в таблице subscriber |
| | electronic_address | varchar(255) | $N | | Электронный адрес \n клиента |
| | created_at | timestampz | $NN | now() | Дата и время создания записи в БД |
| | updated_at | timestampz | $NN | now() | Дата и время обновления записи в БД |
}
' Нижний колонтитул (формируется автоматически из введенных параметров)
footer © $autor | tg: [[https://t.me/$telegram @$telegram]] | email: $email
@enduml
Буду рад Вашим комментариям, отзывам, а если еще и поднимите карму то буду крайне благодарен.
Всем спасибо.
----
Пообщаться со мной можно в telegram: @antzim_in
P.S. Также, если Вам интересно, я веду telegram канал @sa_chulan и буду очень рад Вашей подписке.