Как подойти к дизайну визуализации?🪜

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

👩‍💻1. Понимание домена – кто целевая аудитория и что они делают?
Самое опасное тут – неправильно понять конечные цели пользователей. Решать можно через качественный сбор требований:
- Dashbaord Canvas Ромы Бунина
- Про пользовательские интервью от Nielsen Group
- Jobs to be Done

🔎2. Задача и данные – какие данные мы показываем и зачем люди на них смотрят?
Из опасностей – выбор не тех данных и трансформация к ним, непревильно подобранные аналитические вопросы к данным
- Lean Anlaytics
- Как измерять?
- Дата команды и пониманием метрик бизнеса
- Одинаковые данные, разные вопросы

📊3. Визуальное представление – как это визуализировано?
Важен правильный выбор визуализаций.
- Как выбрать график?
- Эффективность базовых графиков
- Когнитивные искажения

🛠4. Валидация алгоритма – можем ли мы это сделать?
Проверка, что с визуализаций реально взаимодействовать и она технически реализуема.
- Про перфоманс дэшбордов в Tableau и перфоманс тестирование

#devops #mlops

я знал, что так будет, но не думал, что так скоро; плюс авторы сделали целый сайт, на котором публикуют свои обзоры своей сетки

#career #softskills

Шестой месяц. Управление процессами

Прошел шестой месяц курса Стратоплана «Руководитель отдела». Две трети позади

Контент первого, второго, третьего, четвертого и пятого месяцев я описывал ранее.

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

О чем было
- Типы оргструктур (плоская, линейная, матричная, функциональная, проектная и т.д.). Надо понимать, когда какая нужна, плюсы и минусы разных подходов. Особенно важно в небольших компаниях, чтобы при росте уметь сформировать подходящую, а в больших компаниях, чтобы не страдать на тему «Ну почему же так? Ведь в моей прошлой маленько было иначе, и нормально же жили!»
- Ну и дальше всё связанное с оргструктурой и ролевой моделью. Типа не просто берите оргструктуру, наложите её на людей и погнали. А у вас должны быть роли лидеров, интеграторов, поддерживающие всякие, и разберитесь, кто какую роль будет закрывать в вашем конкретном случае, а не в базовом трафарете.
- Очевидная, вроде бы, история про систематизацию и формализацию бизнес-процессов. Кажется, что капитанство, однако очень часто нет процесса, а есть клубок в паре голов старожилов с лейблом «так исторически сложилось».
- Вторая тоже очевидная мысль, но редко проваливаемая — делегирование через бизнес-процесс. Хочешь делегировать и пойти заниматься другими делами? Сделай процесс, формализуй, опиши, научи и гуляй смело.
- Матрица «доверие-прозрачность». Золотая классика, всем рекомендую так работать. Чем понятнее и прозрачнее то, что вы делаете, тем больше к вам доверия и отношения как к профессионалу.
- Разные способы оптимизации бизнес-процессов, типа теории ограничений, 7 потоков потерь и прочего. Всё это очень интересно, но за один урок так, чисто по верхам рассмотрели, и дальше надо самим углубляться. Во что-то я когда-то уже ходил и пробовал, что-то так и осталось на поверхностном уровне.
- И кууууча всего про метрики продуктовые, канбановые, скрамовые, HEART, PROJECT, и т.д.
- Системы отчетности: кому, когда, как, в каком формате, на основе каких метрик.
- KPI и как они совместимы с работой. Например, видел в одной компании, как человеку поставили KPI для премии — ряд доработок и нового функционала на одном из важных сайтов компании. А разработчиков не дали. Вот и крутись как хочешь. Ну, как вы понимаете, премии, конечно же, не было 🙂

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

С одной стороны, практически всё мне было известно и понятно. Только мало кто всё это разумно делает. Основной вызов для меня лично тут не в том, чтобы что-то новое узнать, а чтобы унести это в практику, да еще и никому не навредить. А то знаете эти приколы, когда кто-то наслушается на конфе про метрики, прибежит на работу и как давай внедрять во все места всё, что услышал? 🙂

Вышел мой большой пост про рассуждающие модели (large reasoning models, LRM), которые начались с OpenAI o1-preview в конце прошлого сентября, а самой громкой новостью начала года стал DeepSeek-R1.

https://synthesis.ai/2025/02/25/large-reasoning-models-how-o1-replications-turned-into-real-competition/

Как обычно, я постарался рассказать всю структуру происходящего:
— сначала про chain-of-thought методы и как они развивались;
— потом про o1 и новые законы масштабирования;
— в середине небольшое отступление про самые последние новости — модель s1, которая за $50 обучилась почти до того же уровня;
— а потом уже подробно о том, что происходит в DeepSeek-V3 и DeepSeek-R1;
— в частности, о том, как там используется RL и какой именно (здесь у DeepSeek тоже есть своё новшество, алгоритм GRPO).

Думаю, рассуждающие модели — это самое главное, что произошло в AI за последние несколько месяцев. И, как всегда в последнее время, прогресс невероятно быстрый: только появилось, а уже прочно вошло в обиход, у всех есть свои варианты reasoning models, а где-то уже есть и следующие уровни надстройки над этим вроде deep research. Надеюсь, пост тоже интересный получился — или хотя бы познавательный.)

#career #softskills

ЗВОНИЛ И НЕ ДОЗВОНИЛСЯ

Недавно жизнь занесла меня на Белградский митап QA. Кстати, очень приятное сообщество, всем его очень рекомендую. Надеюсь, я не сильно пошатнула ребят экзистенциальными вопросами к докладам.

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

Помню, когда-то давно в одной моей команде был стажер. У него была задача договориться с разработчиком из соседней команды об интерфейсах взаимодействия. И вот утро, стендап, мы его спрашиваем, как дела с задачей, а он отвечает: "Я ему два раза звонил, и не дозвонился!" И серьезно видимо думает, что все правильно сделал.

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

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

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

QA со мной, кстати, согласились.

#softskills