Приличная статья как провести канбан-митинг (он же стендап митинг) в канбане. Четко, ясно, с чеклистом — все как мы любим.

https://systemskill.ru/tpost/eacanrfh51-kak-provesti-kanban-miting-kanban-meetin

👉Онлайн-интенсив “Управление проектом и продуктом с LeanDS”

NB: осталось немного мест,

С 4 по 6 августа пройдет девятый онлайн-курс в формате интенсива:
три дня подряд в рабочее время — с 10-00 до 18-00 с перерывом на обед и кофе.

Цитаты из отзывов с прошедшего (8-го) курса:

🎙 “Собраны полезные техники, подходы, методы, и, в дополнении к этому, максимально профессиональная команда, терпеливо и доходчиво отвечающая на каждый заданный вопрос. Всё это не дает пройти мимо. Попробуйте, вам точно понравится :)”
🎙 “Сразу попробовала на практике применить AI Project Canvas и подход User Story Map в интерпретации, которая задана в курсе для 2х новых проектов - получилось быстро вовлечь команду в обсуждение и мозговой штурм, быстрее написать и согласовать ТЗ.
🎙 “Очень понравился урок, посвященный экономике проекта. Во многих командах не всегда об этом задумываются, а стоило бы. Как правильно сказано в курсе - ROI вовремя отмененного проекта выше ROI большинства проектов вашей компании. И большое спасибо лекторам - Асхату, Юлии Алексею за то, что вы так хорошо потрудились и сделали такую крутую программу.”

Проходим весь путь создания ML продукта — от идей, оценки экономической эффективности, проектирования, планирования, оценки до деталей управления проектом

✅🤼‍♂️Практика. Занятия состоят из небольшого количества обязательной теории и много практики, где мы совместно решаем реальные кейсы и отвечаем на вопросы.
✅👀Видео. Дополнительно вы получаете доступ к видео. Они состоят из небольшого количества видео по “ядру” LeanDS и множества дополнительных по самым разным аспектам управления DS — от сбора команды до управления ожиданиями заказчика в заказной работе.

🎤Ведущие курса Асхат Уразбаев, Алексей Могильников и Юлия Рубцова
🗓 Курс пройдет с 4 по 6 августа

‼️ПРОМОКОД (25% скидка для читателей этого канала — leandsaugust)
🗓 Регистрация и подробности: https://leands.university/leands-intensive

На этой неделе веду твиттер dsunderhood https://twitter.com/dsunderhood Буду стараться писать про разное вокруг LeanDS.

Давайте поговорим про зрелость Data Product Owner. (из твиттера dsunderhood).

По моим наблюдениям практически каждый PO проходит в своем развитии 5 уровней зрелости. Каждый последующий уровень дополняет предыдущий, а не отменяет:

1. Уровень первый, старательный. Надо изо всех сил стараться. Если кто-то из руководителей ласково улыбнулся на сбивчивый рассказ о чудесной идее — пора за работу!

Проблемы возникают при сдаче результата. Заказчики меняют свои показания, большинство вещей вообще забыли обсудить.

2. Уровень второй, сдательный. Проекты нужно сдать заказчикам. Надо определить критерии успеха и в конце по ним сдавать.

Результат: Ура! Появляются требования и планы.

Проблемы возникают, если заказчик не знает чего он хочет. Или (что чаще) — то, что он хочет ему не нужно. В итоге мы получаем модель, ценность которой сомнительна и в прод ее вытаскивать никто не собирается.

3. Уровень третий, удовлетворительный. Нужно максимизировать удовлетворенность заказчиков. Дело не в проектах, а в довольных улыбках наших заказчиков.

Результат: клиенту показываются промежуточные результаты, собирается обратная связь, результат доводят до прода.

Проблема: Заказчиков много, удовлетворенность понятие субъективное. В итоге делаем работу того, кто громче кричит.

4. Уровень четвертый, ценный. Нужно максимизировать бизнес-ценность для компании

Результат: Начинаем считать эффективность продуктов с бизнес-точки зрения и оценивать эффект пост-фактум, приоритизируем проекты по степени влияния на бизнес

Проблема: разные команды бегут в разные стороны в организации, иногда взаимно уничтожая эффект от реализации.

5. Уровень пятый, сфокусированный. Нужно максимизировать бизнес-ценность в нужном для компании направлении.

Результат: появляются фокус организации, разные команды синхронизируют цели (например, через OKR). Фокусируемся на стратегических задачах компании.

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

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

Чинится это как минимум двумя способами. Можно раздать представителей инфраструктурной команды в продуктовые команды на 30-50% времени, чтобы они в полях глубже проникались проблемами и понимали что реально нужно командам. Это также будет полезно в рамках развития DevOps культуры в компании. Альтернативным вариантом, или дополняющим, является управление приоритетами в бэклоге задач представителями продуктовых команд (лучше всего для данной роли подходят техлиды). Для этого они собираются на регулярные встречи, где обсуждают самые горячие проблемы и расставляют приоритеты на ближайшее время в разработке платформы.

Вторая ловушка называется «убивающая поддержка». Чем больше начинают использовать платформу, тем больше времени начинает забирать ее поддержка. Дефекты, мелкие улучшения, инциденты и другие виды запросов начинают сильно перегружать платформенную команду. Без четко организованных процессов и SLA недовольство продуктовых команд растёт и начинается противостояние «мы - они», которое к добру не приводит.

Лечится снова таки как минимум двумя способами. Во-первых, все компоненты платформы должны быть максимально задизайнены на самообслуживание (self-service). То есть, любые типовые задачи как выделение ресурсов, модификация конфигурации и т.д. должны быть доступны для выполнения продуктовыми командами. Для общих задач поддержки четко поставленный процесс и SLA. Во-вторых, на старте использования платформы каждая команда должна найти выделенного инфраструктурного инженера на одну или несколько команд, который закрывает для них все вопросы платформенной поддержки. Это может быть инженер из платформенной команды на % времени.

Третья ловушка называется «а нам этого не говорили». Любая платформа предполагает определённые правила использования и стиль работы. Если он никак не формализован, то люди начинают работать как им кажется правильным, со всеми вытекающими проблемами. Ситуация усугубляется, если на платформу загоняют насильно, без мотивации ее использовать, знаний и опыта в используемом технологическом стеке.

Лечится традиционно двумя способами. Во-первых, формализацией гайдлайнов по использованию всех компонентов платформы. Чем большее количество вопросов они покрывают, тем меньше граблей и шишек будут собирать продуктовые команды. Во-вторых, программы обучения, онбординга и менторства для начинающих работу на платформе команд. Это позволит им получить не только начальные теоретические знания, но и поддержку на время адаптации.

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

Мы начинаем новый сезон LeanDS!

Тут интересная штука выяснилась. LeanDS помогает останавливать ненужные проекты — например, если нет данных или заказчик не понимает, какого результата хочет добиться — мы можем остановить проект на этапе создания канваса. Это лучше, чем потратить кучу денег на ветер.

Но, кажется, просто развести руками "так сложилось" недостаточно. Нужно перестроить работу в организации, чтобы таких проблем становилось меньше.

В этом сезоне Lean Data Science мы будем фокусироваться на том, как системно выстроить работу в той части компании, которая занимается Data.

Первый митап на эту тему пройдет 16 сентября в 19-00

ДОКЛАДЫ

1️⃣ Cовременный Дата Офис: статус, тренды и новые практики, Асхат Уразбаев, основатель LeanDS
2️⃣ Data Governance "на коленке, Наталья Хапаева, МТС
3️⃣ Карта данных, глоссарий. Наводим порядок в данных, вырабатываем общий язык, Николай Трошнев, частный консультант Data Governance, Data science, BigData

🗓 16 сентября в 19-00 онлайн
Регистрация на митап: Онлайн митап и начало сезона: Cовременный Дата Офис

Через час, в 19-00 начинаем!

👉Онлайн курс “Управление ML продуктами с LeanDS 🦊 ”

12 октября стартует 10 поток курса по управлению проектами и продуктами в AI/DS.

✅ Практика каждый вторник 3 часа с 19:00
Занятия состоят из небольшого количества обязательной теории и много практики, где мы совместно решаем реальные кейсы и отвечаем на вопросы.
✅ Теория. Видео по “ядру” LeanDS и множества дополнительных по самым разным аспектам управления

ТЕМЫ КУРСА

🟢 12 окт. Обзор LeanDS. AI canvas. Как спроектировать ML Product
🟢 19 окт. Формулирование, декомпозиция и приоритизация продуктовых гипотез методом ICE/RICE
🟢 26 окт. Планирование AI/ML продукта
🟢 2 ноя. Расчет ROI продукта
🟢 9 ноя. Data Science метрики ML продукта
🟢 16 ноя. Тестирование улучшений продукта при помощи A/B теста
🟢 23 ноя. Внедрение LeanDS методом STATIK

🎤Ведущие курса Асхат Уразбаев, Алексей Могильников и Юлия Рубцова
🗓 12 октября — 23 ноября, каждый вторник с 19:00-22:00 МСК онлайн

ПРОМОКОД (6.000 р скидка для читателей этого канала — leandsoct21)
Регистрация и подробности: Lean Data Science Practitioner - Онлайн Курс

Видео и слайды с митапа:

Cовременный Дата Офис: статус, тренды и новые практики.
Асхат Уразбаев, основатель LeanDS

Мы посмотрим, что происходит в современном мире в области построения дата-офисов организаций. Некоторые из затрагиваемых тем:

• Что такое дата-продукт
• За что отвечает дата-команда
• Роль Data Governance в организации
• Структура и ответственность дата-команд

Видео: https://youtu.be/-_c5rpnBFMs
Слайды: https://drive.google.com/file/d/1jL7A8p36KpLM7ax8f_pam2bmprreXWxH/view?usp=sharing

Data Governance "на коленке"
Наталья Хапаева, МТС
Окончила ВМК МГУ. Более 14 лет опыта в ИТ-индустрии в финтех и телеком компаниях в качестве разработчика, архитектора, эксперта по data governance и владельца продукта. Сейчас строит MLOps платформу в МТС.

В докладе расскажу, что можно сделать, когда в компании уже приняли решение, что нужен Data Governance, но еще нет ни стратегии, ни тактики.

Видео: https://youtu.be/DJKnIr1y9So
Слайды: https://drive.google.com/file/d/1culJ4WkN2LZhOsV6_uQ_XEvddzvBo3jW/view?usp=sharing

Карта данных, глоссарий. Наводим порядок в данных, вырабатываем общий язык
Николай Трошнев, частный консультант Data Governance, Data science, BigData

Видео: https://youtu.be/oZZJdFbQQXU
Слайды: https://drive.google.com/file/d/1U_rqisenhSF0WYhXfA7VC7dp9kgpZpcy/view?usp=sharing

Тема: Lean CANVAS для тех, у кого вокруг не Lean
————
Доделал LeanCanvas под себя. Особенность - команда зависит от смежников и их много. Например, данные получаю в пресейлах, где кроме ML-команды есть сейл, PM внедрения, 1-2 инженера внедрения, эксперт по настройке правил, 2-3 стейкхолдера от заказчика.

Цель изменений: помимо прочего провести водораздел между нами и ими и поработать с ожиданиями всех участников.

1) Разделил поле DATA на ДАННЫЕ и ПЛОЩАДКА, чтобы отдельно обсуждать датку и способ её получения. У меня это фонограммы, их надо специально записывать и можно запороть на этом этапе.

2) SKILLS превратился в СКИЛЛЫ+ЗАДАЧИ и тоже разделён на две части: ВНУТРИ моей команды и СНАРУЖИ. Так же раздвоилось поле INTEGRATION

3) VALUE и OUTPUT уже и были в паре - первое заботит проектную команду, второе DS-команду

4) CUSTOMERS. Есть пользователь у заказчика. А есть эксперт по настройке кейсов на правилах - внутренний потребитель технологии. Два отдельных поля.

5) COST, REVENUE и STAKEHOLDERS без изменений. К последним стоит приписать их ЦЕЛЬ или KPI

6) Новый блок ОЖИДАНИЯ - тут манифестирую риски, связанные с тем, что тонкости ML смежники часть не понимают. Потом можно будет сделать зеркальное поле, где смежники работают с моими ожиданиями.

7) В подобном CANVAS мы имеем 5 пар блоков-близнецов, которые помогают провести границу ответственности между DS-командой и смежниками. Делается это явно и однозначно, стикер клеим или туда или сюда.

Канвасы можно скопипастить отсюда: https://miro.com/app/board/o9J_lv3Wa0U=/

Дмитрий Попов, управляю agile-командой в ЦРТ, пилим технологию для речевой аналитики.

Канвас, описанный в книге — стартовая точка. Дима рассказывает ☝️☝️☝️о том, как он доработал канвас для своей ситуации в своей компании.