Архив недели @zibsun
Понедельник
Привет! Эту неделю буду вести я, Асхат Уразбаев. (@zibsun). Я Agile Coach, помогаю выстраивать процессы в компаниях, последнее время делаю это в DS. Вы можете знать меня как основателя ScrumTrek или как основателя сообщества LeanDS
Я закончил МФТИ с отличием в 2000 году, двигался от разраба до менеджера в ИТ компаниях. Потом в Luxoft работал в качестве Архитектора Процессов, в 2008 году основал ScrumTrek и двигаю в массы Agile, Scrum, Kanban и прочие странные слова.
Как видите, я довольно старый чел, повидал некоторое дерьмо🎅🏾. Был свидетелем хайпа вокруг Web, тестирования, автотестирования, девопс. Очень интересно смотреть на новый круг с Data Science. Индустрия DS очень круто и на глазах взрослеет. Я исторически не очень твиттерный человек
Я исторически не очень твиттерный человек, но хочу влиться и в будущем вести свой @zibsun. Буду учиться на ходу :)
Несиньорные синьоры, Давайте поговорим про незрелость индустрии Data Science и как это влияет на проектную работу.
С каждым новым хайпом (DevOps или Data Science для примера) спрос на синьоров и миддлов начинает экспоненциально расти — наверное где-то в 2-3 раза за год. Но чтобы стать сеньором нужно много лет. Они просто физически не успевают вырасти!
Происходит инфляция сеньоров. Есть какой-то опыт? Будешь миддл. Умеешь хоть немного разговаривать с бизнесом? Ты сеньор. Твои системы были в проде? Архитектор.
Помню, много лет назад мы показывали своих разрабов заказчикам из гугла. Приезжал дядя лет 45 (тогда он мне казался старым, хехе), а мы ему отправляли на собеседование 23-летних "синьоров". Под конец дня он вышел к нам и в печатных выражениях уточнил, не издеваемся ли мы над ним
А мы не издевались. Найти сеньора в 2003 году с 10-летним опытом разработки было физически невозможно. Их было может штук пять-десять на страну.
В чем проблема с "молодыми" сеньорами? Сложность заключается в непонимании проблематики. Ребята проваливали в жизни недостаточное количество проектов.
В итоге мы можем пойти в пилот не обсудив с заказчиком критериев его успеха. Наш план — стараться изо всех сил. Мы надеемся, что все сложится хорошо. Но надежда — плохой план!
Но объяснить это сеньору бывает трудновато. "Давай согласуем с заказчиком, что мы поставляем". "Зачем?". "Ну он понимает, что мы отвечаем только за модель?". "Ну он же не дебил, это же очевидно".
Вот что делать? Ждать пока проект провалится и он поумнеет? Жестко настаивать против его воли?
Тред (Асхат Уразбаев)
Как выяснить уровень сеньора? Надо спросить, какая проблема для него сейчас ключевая. Пример "несиньорного" ответа: "Заказчик уже две недели не может мне определить метрику"
Вторник
Вчера говорили про DS сеньора, сегодня поговорим про уровни зрелости Data Product Owner. Можно условно разделить на 5 уровней зрелости, каждый последующий уровень дополняет предыдущий, а не отменяет:
Уровень первый, старательный. Надо изо всех сил стараться. Если кто-то из руководителей ласково улыбнулся на сбивчивый рассказ о чудесной идее — пора за работу!
Проблемы возникают при сдаче результата. Заказчики меняют свои показания, большинство вещей вообще забыли обсудить.
Уровень второй, сдательный. Проекты нужно сдать заказчикам. В начале проекта определяем критерии успеха и в конце по ним сдаем.
Результат: появляются требования и планы
Проблемы возникают, если заказчик не знает чего он хочет или (что чаще) — то, что он хочет ему не нужно. В итоге мы получаем модель, ценность которой сомнительна и в прод ее вытаскивать никто не собирается.
Уровень третий, удовлетворительный. Нужно максимизировать удовлетворенность заказчиков. Дело не в проектах, а в довольных улыбках наших заказчиков!
Результат: клиенту показываются промежуточные результаты, собирается обратная связь
Проблема: Заказчиков много, удовлетворенность понятие субъективное. Делаем работу того, кто громче кричит.
Уровень четвертый, ценный. Нужно максимизировать бизнес-ценность для компании
Результат: Начинаем считать эффективность продуктов с бизнес-точки зрения и оценивать эффект пост-фактум, приоритизируем проекты по степени влияния на бизнес (а не громкости крика)
Проблема: разные команды бегут в разные стороны в организации, иногда взаимно уничтожая эффект от реализации
Уровень пятый, сфокусированный. Нужно максимизировать бизнес-ценность в нужном для компании направлении.
Результат: появляется фокус организации, разные команды синхронизируют цели (например, через OKR)
Тред (Асхат Уразбаев)
Среда
Сегодня поговорим о том, как растет зрелость команды. Как обычно, разложим по нескольким уровням.
Первый уровень. Разделение.Каждый член команды отвечает за свое направление со своим заказчиком. Взаимопомощь происходит несистемно, на уровне дружеских отношений
Работу DS контролирует Лид — насколько у него хватает времени.
Проблемы:
Работать одному одиноко. У некоторых развивается синдром самозванца, частично обусловленный проблемой инфляции компетенций, которую мы обсуждали в понедельник.
(Настоящий DS уже бы все сделал… а я туплю…)
Неконтролируемое качество. Пример — в одной из компаний одну работу (проверки эффективности маркетинговой акции) случайно дали двум DS. Они работали параллельно, и у одного получилось, что эффекта нет, а у второго эффект был большим.
Огромные проблемы с бас-фактором. Уход человека означает полную остановку работы. С высокой вероятностью ее вообще придется начинать заново.
Возвращаются старые задачи и выбивают DS из работы по текущим. Некоторые DS перегружены, а кто-то занимается ресечем.
Совместная работа (стендапы, планирования) выглядят грустно: все просто ждут пока смогут начать говорить: слушать других неинтересно и не нужно.
Второй уровень. Ревью кода
Каждый работает над своим направлением, но члены команды проводят ревью кода друг у друга
Результат:
Стендапы начинают обретать смысл: иногда происходят технические обсуждения
Код ревьювится, находится под версионным контролем, появляются практики документирования результатов, есть с кем проконсультироваться
Time2Value улучшился: проще передавать задачи, меньше тупняка на сложных моментах.
Смена DS на задаче стала проще: код не потерян.
Проблемы:
ревью кода неконтекстное: ревьювер не в курсе проблемы заказчика и не может проверить бизнесовую логику решения.
Перевод задачи на другого человека требует погружения в бизнес-контекст, это не всегда легко сделать и понижает качество работы
Третий уровень, взаимопомощь
Каждый работает над своим направлением, но члены команды вникают в бизнес-смысл и перехватывают работы.
Результаты:
На совместных встречах команда обсуждает смысл задачи с точки зрения бизнеса и может генерировать продуктовые гипотезы. Как минимум двое в курсе бизнес-постановки.
Качество проработки бизнес-части гипотезы (как еще можно решить проблему бизнеса?) становится глубже, качество решений растет.
Time2Value еще улучшился: в случае необходимости бизнес-задачей может заниматься сразу двое человек.
Четвертый уровень, "swarming"
Несколько членов команды могут фокусироваться на одном направлении, совместно разбивая гипотезы на задачи и решая их параллельно или в паре. Теперь бизнес-задачи принадлежать целиком команде.
Результаты:
На совместных встречах команда обсуждает бизнес-задачу всем составом.
Одновременно выполняющихся бизнес-задач становится немного и команда может фокусироваться всем составом благодаря разделению на подзадачи и параллельной / парной работе.
От уровня к уровню растет взаимодействие в команде и улучшается скорость (Time2Value) реализации бизнес задачи. Растет качество за счет взаимной проверки.
Психологический эффект: уровень тревожности падает, так как есть кому подстраховать и поддержать в трудную минуту. Признание членов по команде увеличивает мотивацию и вовлечение.
Тред (Асхат Уразбаев)
Четверг
По ощущениям на одного ML Engineer надо 2-3 Data Engineer, а рынок обучения сильно перекошен в сторону "секси ML". В итоге в компаниях все фрустрированы, хотели ML заниматься, а на деле данные гоняют. Это так? Или у меня bias?
Ок, опрос! Есть мнение, что рынок перекошен в сторону ML. Возможно у вас не так? Сколько DE надо на одного MLE по вашим ощущениям?
🤔
33.6% DS должен делать все!🤔
35.7% 1:1🤔
29.4% 2-3 DE🤔
1.4% 4-5 DE и большеПятница
Метрики эффективности DS команды — с какой скоростью тестируются бизнес-гипотезы (Lead Time)
Туда очень много всего зарыто
Насколько быстро команда может решить блокеры (нет данных, внешние зависимости) — характеристика организации
Насколько команда может фокусироваться совместно на приоритетных гипотезах — метрика командности работы
Насколько быстро команда сможет развернуться, если концепция поменяется — характеристика гибкости
(косвенно) насколько полно решены проблемы автоматизации и инфраструктуры
Тред (Асхат Уразбаев)
Общался с большим количеством продактов и PM в data science и почти у всех проблема #1 - бизнес не понимает DS и не знает как его использовать
Реальная история. Бизнес: пусть ваш искусственный интеллект выучит наши статьи на конфлюенсе и будет отвечать пользователю в чате
Классический вопрос, который можно обсудить вместе с бизнесом — а как эта задача может быть решена без ML?
Очень часто именно с этого можно начать, и получить дешевое решение, которое можно быстро валидировать и бейзлайн, с которого можно начать
Иногда решение без ML может оказаться очень крутым. На каком-то митапе слышал историю:
Делали рекомендашку недвижимости в Испании. Лучший эффект был от показа «однушки в Бибирево» за ту же цену, по цене дома на побережье в Испании.
Тред (Асхат Уразбаев)
Суббота
Что лучше подходит DS команде — скрам или канбан?
Давайте разбираться со скрамом. Он очень популярен в разработке ПО:
Спринт считается успешным, если команда добилась цели спринта. Она обеспечивает фокус на результате. Грубо говоря, есть чем похвастаться каждый спринт
Пользовательские истории начинаются в спринте и доделываются внутри спринта до конца. Это очень упрощает планирование. Пользовательская история разработана, протестирована, баги найдены, исправлены и закрыты, продукт задеплоен на stage или prod
Короткий Time to Market. От момента старта разработки до поставки проходит один спринт, в большинстве команд это 2 недели
Если мы фокусируемся на доделывании до конца историй в спринте, то мы не тянем в следующий спринт доделки и баги с прошлых спринтов. Тогда все прозрачно и понятно!
К сожалению в большинстве DS скрам плохом применим:
Основная проблема: гипотезу практически невозможно доделать до конца (валидировать) в течении спринта. Для валидации гипотезы нужно от нескольких недель до нескольких месяцев.
Второе важное отличие: Data Science — discovery process. Каждая гипотеза может провалится и относительно небольшой процент гипотез доезжает до прода и приносит ценность.
Проблемы Скрама в DS:
Никакой разумной цели спринта поставить не получается. Даже если вдруг мы формулируем цель, достичь ее к концу спринта практически невозможно
В конце спринта есть куча недоделанной работы, которая в конце просто переносится на следующий спринт
Внутри спринта из-за discovery-характера DS проектов может случиться нечто, что полностью уничтожает смысл доделывать спринт до конца
По-сути, в DS проектах спринт превращается в регулярную отбивку времени, просто обозначает частоту встреч команды по планированию.
В Канбан явным образом визуализируется передвижение гипотез по их жизненному циклу.
В большинстве случаев канбан обеспечивает больше прозрачности работы над гипотезами и упрощает планирование
Тред (Асхат Уразбаев)
Воскресенье
Поспекулируем немного на философскую тему «data driven organization”.
Это организация, которая умеет эффективно принимать решения при помощи данных.
Нулевой этап. Для принятия решений менеджеры используют опыт и чуйку. Данным не доверяют из-за их турбулентности.
Первый этап. Организация ориентируется на данные для принятия долгосрочных решений: выставления KPI и квот продажников, планов производственным отделам и и.д.
Второй этап. Организация осваивает экспериментальный подход к работе с данными, но использует локально доступные данные внутри подразделений. Чаще всего это близкие к клиенту подразделения: маркетинг, продуктовый менеджмент, продажи.
Третий этап. Данные становятся важным активом, их польза очевидна. Подразделения начинают использовать данные, собранные по всей организации. Организация накапливает экспертизу для работы с данными.
Четвёртый этап, оптимизационный. Организация оптимизирует инфраструктуру работы с данными. Работа с данными децентрализуется.
Тред (Асхат Уразбаев)
Подводим итоги недели. Несколько избранных тредов
Несиньорные синьоры, Давайте поговорим про незрелость индустрии Data Science и как это влияет на проектную работу.
Тред о незрелости индустрии и о инфляции синьоров
twitter.com/dsunderhood/st…
Вчера говорили про DS сеньора, сегодня поговорим про уровни зрелости Data Product Owner. Можно условно разделить на 5 уровней зрелости, каждый последующий уровень дополняет предыдущий, а не отменяет:
Уровни зрелости Data Product Owner twitter.com/dsunderhood/st…
Сегодня поговорим о том, как растет зрелость команды. Как обычно, разложим по нескольким уровням.
Зрелость команды twitter.com/dsunderhood/st…
По ощущениям на одного ML Engineer надо 2-3 Data Engineer, а рынок обучения сильно перекошен в сторону "секси ML". В итоге в компаниях все фрустрированы, хотели ML заниматься, а на деле данные гоняют. Это так? Или у меня bias?
О перекосе индустрии обучения в "секси ML" twitter.com/dsunderhood/st…
Что лучше подходит DS команде — скрам или канбан?
Что лучше подходит DS команде — скрам или канбан? twitter.com/dsunderhood/st…
Поспекулируем немного на философскую тему «data driven organization”.
Поспекулируем немного на философскую тему «data driven organization”. twitter.com/dsunderhood/st…
Тред (Асхат Уразбаев)
Эту неделю твиттер вел Асхат Уразбаев @zibsun. Подписывайтесь там или на телеграм-канал об управлении проектами и продуктами в DS t.me/leands
Напоследок — бесплатная книжка про управление DS проектами leands.ai/ru Всем пока )
