Данные в ДейSTвии – Telegram
Данные в ДейSTвии
1.06K subscribers
209 photos
13 videos
10 files
186 links
Менеджмент на основе данных и прогнозирования.
Инструменты, примеры, разборы кейсов.
Авторский канал Василия Савунова
https://scrumtrek.ru/trainer/4646/vasiliy-savunov/
Download Telegram
🔮 Угадывать срок задачи - основной метод оценки сроков (и он не правильный)

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

И это НЕ работает для 80-90% задач!

\\ Пример 1: 👮тимлид говорит, что разработка задачи займет 7️⃣ неделю. НО в итоге эту задачу делает 👨 другой человек, с другим багажом знаний и опыта, и срок разработки затягивается на 🤷 3 недели.

\\ Пример 2: Scrum-команда с помощью 🃏Planning Poker произвела анализ задачи, поделилась друг с другом своими экспертными мнениями, и сообща оценила задачу в 15 стори пойнтов, что соответствует целому спринту (2 недели). Но в процессе разработки проявилась непредусмотренная зависимость от смежной команды и в итоге задача заняла 🤷 3 спринта (1.5 месяца)

В результате: менеджер 👊 кнутом и 💰 пряником подгоняет сотрудников, чтобы уложиться в тот срок, который он напророчил бизнес-заказчику, хотя всем понятно, что в срок не успеть. 🤬 Бизнес бьется в истерике, а сотрудники тихо 🤮 ненавидят менеджера, и обновляют резюме на HeadHunter.

Что на самом деле стоит тут поменять?
1) Перестать верить в том, что можно 🔮предсказать будущее
2) Использовать 🎲 🎲 🎲 теорию вероятностей для прогнозирования сроков задач

\\ Пример из практики:
🔫 Дано:
Отдел аналитики делает 📝 регулярные отчеты для директоров бизнес-направлений. Каждый отчет - это мини-проект. Регулярно ошибаются по срокам, что злит бизнес

🛠 Что сделали:
Использовали статистику из трекера задач, чтобы построить 📊 вероятностную модель по срокам создания разных типов отчетов

🏁 Что в итоге:
Договорились с бизнес-заказчиками на эксперименте, в ходе которого срок брался из 📊 вероятностной модели. Через 6 месяцев эксперимент был признан успешным, и данный подход стал основным.

Подробнее про этот кейс можно посмореть тут: https://youtu.be/TiLirIGAERM

Вывод: знание методов теории вероятностей позволяет делать прогнозы сроков задач на основе данных, с большой вероятностью попадания
Please open Telegram to view this post
VIEW IN TELEGRAM
👍61
Чеклист: как менеджеру узнать срок выполнения любой задачи не отвлекая подчиненных?

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

Знакомая ситуация? ☠️
🤔Что же делать? Люди так несовершенны, они не умеют предсказывать будущее!

Нам поможет наука! ⚛️
А именно - теория вероятностей

Вот 6 шагов, которые позволят вам системно решить эту проблему:
1️⃣Использовать современные способы трекинга задач - JIRA, Kaiten, Asana и т.п. - чтобы легко собирать исторические данные о работе вашего подразделения

2️⃣ Регулярно - минимум раз в квартал - выгружать из трекера задач данные по завершенным задачам: дату начала работы 🚀 и дату конца 🏁 работы над задачей.

3️⃣ По каждой задаче вычисляем время выполнения - Lead Timeв днях

4️⃣ Строим в Excel диаграмму Lead Time Distribution, которая показывает сколько раз мы наблюдали то или иное время выполнения задачи. Звучит страшно, но все довольно просто: по оси X отмечаем длительности задач , которые мы наблюдали в выгрузке, а по оси Y - сколько раз эта длительность задач в этой выгрузке повторялась 🔤.

5️⃣ Применяя формулы теории вероятности к этим данным, получаем время выполнения любой задачи с вероятностью 80-90%

6️⃣ Теперь мы можем уверенно отвечать на вопрос "когда будет сделана задача" без необходимости привлекать к оценке исполнителей

P.S. На картинках видны дополнительные метрики, которые можно использовать для прогнозирования. Но о них - в следующих постах

Именно это (и многое другое) мы и учимся делать на курсе Основы Канбан-систем
Если у вас остались вопросы, задайте их мне в личку
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍81
Пока у вас нет данных, вы будете спорить до посинения👊, но не сдвинетесь с места!
 
Частый спор между бизнесом и IT:
 
Опять IT не сдержал обещание по срокам! Давайте уволим технического директора! Этот не справляется! Наймем нового, и он все исправит!
 

И что в итоге? Смена техдира провоцирует отток разрабов, и ситуация повторяется
 
— Это бизнес виноват! Вы постоянно меняете приоритеты! Вы не даете нам нормальное работать! Но хватит! Отныне будут четкие правила поступления задач в IT, обязательные для всех!
 
IT придумывает кучу новой бюрократии. И стало только хуже
 
🏃‍♂️Что делать, чтобы сдвинуться с мертвой точки?
 
Прежде всего нужно:
1. Собрать статистические данные о том, как ведется разработка

2. Бизнесу и IT посмотреть на эти данные, и прийти к единому мнению о причинах проблем

3. Договориться о плане постепенных улучшений и начать его выполнять
 
Вот пример из двух разных областей:

1. Аналитический отдел (АО) крупной ювелирной компании. Делает сложные управленческие отчеты для бизнес-направлений. Заказчики недовольны сроками. АО захлебывается от нагрузки. Обе стороны обвиняют друг друга

Задача: наладить доверие между бизнесом и АО🤝

Окей, IT собрали и показали бизнесу статистические данные о времени выполнения задач. Договорились взять за основу планирования вероятные сроки задач

Результат: через 6 месяцев 90% задач выполняются в срок, доверие между бизнесом и АО восстановлено🤝 (подробнее тут)

2. Российская fashion-компания. Противостояние IT и бизнеса. Бизнес не доволен сроками и результатами. IT работает на износ

Задача: найти корневую причину проблемы и устранить ее

Собранные данные показали, что причина в отсутствии регулярного процесса приоритезации задач. Совместно договорились о метриках и формате. Запустили

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

Это я всё к чему — хорош ругаться. Собирайте статистические данные, и сможете договориться
This media is not supported in your browser
VIEW IN TELEGRAM
Мягко было на бумаге, да забыли про овраги

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

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

Прошло несколько месяцев. Он попросил о созвоне, и рассказал: сразу после обучения, собрал из трекера задач статистические данные по времени выполнения задач и из этого вывел некоторое среднее значение времени проекта.
После этого он выставил всем подчиненным KPI, согласно которому каждый из них должен был уложиться в это среднее время реализации проекта. Иначе - штраф.

Круто, правда?

🤷Только в ответ он получил тотальное непопадание в KPI и волну увольнений

В чем он ошибся? В процессе расчетов, и в том, как коммуницировать с подчиненными.

Что можно было сделать иначе?

1️⃣ Рассказать своим сотрудникам, чем им может помочь новый подход. Иначе мы сразу получим кучу сопротивления, и желания обмануть систему

2️⃣ Найти добровольцев. Они помогут начать жить по новому, и донести смысл до остальных коллег.

3️⃣ Максимальная прозрачность результатов. Чтобы нарастить группу поддержки, и подготовить всех к грядущим изменениям.

4️⃣ Не стесняйтесь привлечь эксперта для валидации результатов. Эксперт, который занимается этим профессионально, может быстро подсказать решение, и вы достигните результата за значительно более короткий срок.

Так что не стесняйтесь 😉, если есть вопросы и вам нужна помощь в использовании Канбан-метода для прогнозирования, пишите мне в личку: @vsavunov

#как_не_надо
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Случай на дейли митинге :))

Жиза?... 😀

#юмор
🤣1
🎓Обратился давний клиент с запросом:

- Если нас есть входящий бэклог работ из, например, 1000 задач, и то как сделать прогноз того, за какой срок команда его сделает с большой долей вероятности?

- А зачем это надо? - спрашиваю

- Бизнес свои планы долгосрочные хочет создавать на основе этой метрики. И по этой метрике будет видно, нужно ли еще ресурсов добавить, или всего достаточно?

🤔И тут я задумался... Как это сделать, с большой долей вероятности прогноза?

И есть вопрос на засыпку... Относительно чего этот срок рассчитывать?

👉[Читать дальше]👈

#не_просто
#прогнозирование
👍31
Не слишком сложно написал? Я старался максимально просто изложить.
Если остались вопросы - лучше их задать 🙂

#вопрос_в_зал
🔫 Как выстрелить себе в ногу, собирая и анализируя данные о рабочем процессе

☝️ Измерять отдельных людей в команде и их производительность.
Совершенно бесполезная деятельность, которая ничего кроме тревоги, страха и недоверия не вызовет.
В большой компании человек - часть рабочей системы, в которую он встроен. Если система не позволяет ему работать хорошо, и у него нет харизмы Майка Тайсона, то он смирится и будет работать на том уровне, на котором ему позволяет работать система. Например, если каждый шаг требует согласований, то это будет влиять на работу всех сотрудников. И как бы мы не измеряли производительность отдельного человека - она будет лежать в определенном коридоре значений, который обусловлен тем, как устроена рабочая система.

✌️ Метрики тщеславия
Это метрики которые интересно рассматривать, и хвастаться ими, но они не несут никакой практической пользы.
Например метрика "сколько разработчиков приходят на работу вовремя, минута в минуту". На что она влияет? Что она улучшает?
В современном мире, особенно после covid'а, когда всех загнали на удаленку, всем стало ясно, что главное - результат, сделанный в срок, а не сколько времени ты на работе просиживаешь.
Избегайте таких метрик. Как говорил Даниэль Ваканти, нужно собирать те метрики, которые подсказывают вам, как действовать, чтобы улучшать бизнес-показатели.

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

🌟 Удивительно, но такие ошибки порой совершают даже опытные менеджеры.
Будьте умнее. Думайте о последствиях, когда выбираете ту или иную метрику

#просто
#как_не_надо
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥2
Как Scrum-команде давать оценки с вероятностью 85% и не тратить на это много времени?

📈2 года назад я выступал на конференции TeamLead Conf, где рассказывал про то, как тимлиду прогнозировать срок выполнения задач, и не привлекать внимание санитаров отвлекать сотрудников от работы.

👏Доклад был воспринят очень хорошо и после него, в коридоре, десяток тимлидов целый час бодро закидывали меня вопросами по нюансам прогнозирования.

🤔 И тут один парень сказал: "Скажите как мне быть? У меня в подчинении несколько тимлидов, и когда я пытаюсь заговорить с ними о том, чтобы проанализировать сколько нас самом деле занимают задачи по времени, они не хотят ничего слышать! Они считают, что в IT самый правильный способ оценки - это Story Points. При этом, мы даже не работаем по Scrum! Как мне убедить их, что нужно анализировать реальное время, которое их команды тратят на задачи?"

😵 Я был так удивлен!
Буквально 5-7 лет назад разработчики воротили нос от всего этого Agile, а кое-где могли послать на йух, стоило тебе произнести слово "Story Point". За слово "Scrum" можно было получить вечный бойкот от коллег-разработчиков. Я знаю, о чем я говорю - я сам был разработчиком.

🌀И вот прошло несколько лет, и все пользуются относительными оценками в Story Points, а про реальное время забыли!

Но что такое на самом деле Story Points? И какое отношение они имеют к сроку выполнения задачи?

Об этом читайте ниже 👇

https://vc.ru/u/2611688-vasiliy-savunov/1165178-prokachivaem-ocenku-scrum-komandy

#просто
#прогнозирование
🔥51
🎓 Канбан-доска - это совсем не то, что вы думаете!

Меня недавно позвали провести тренинг по Канбан-методу для известной российской соцсети

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

Голоса распределились таким образом:
10 % - Канбан? А что это такое? Впервые слышу

80% - Канбан - это когда мы клеим стикеры на доски и наступает счастье!

0% - Умею делать вероятностные прогнозы с помощью метрик Канбан-метода

0% - Я знаю что такое WIP-лимит, зачем он нужен и как работает

0% - Я улучшил бизнес-метрики моего подразделения с помощью Канбан-метода

🔭 Очень характерные результаты.

Видимо, стикеры и доски- самые запоминающиеся артефакты Канбан-метода, поэтому подавляющее большинство ассоциирует метод именно с ними.

И с одной стороны, это безусловно важные элементы метода.
🛠Но с другой стороны - это лишь инструмент для кое-чего большего!

🛫Хорошая Канбан-доска, это приборная панель для менеджера. Так же как пилоты самолета могут вести воздушное судно "по приборам", так же и менеджер может с помощью Канбан-доски в каждый момент знать, что происходит с его подразделением и с каждым проектом или продуктом, за которое оно несет ответственность.

📈Имея продуманную, хорошо спроектированную Канбан-доску, менеджер получает возможность измерять работу своего подразделения вдоль и поперек, и в результате - прогнозировать его работу с вероятностью 80-90%!

👉 Продолжение в моей статье "Канбан-доска, это не то, что вы думаете!" https://scrumtrek.ru/blog/kanban/4827/kanban-doska/

#просто
#доска
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥2
Первый день тренинга "Масштабирование Канбан-систем"

Подробно разобрали что такое Upstream

🥲Печально, но факт - во многих компаниях процесс подготовки требований, и валидации идей поставлен из рук вон плохо.

Я уж молчу про Технико-финансовое обоснование....

Как итог - производственные подразделения (Downstream) молотят работу и днем и ночью, пар от них валит, люди падают с ног...

📉А прибыль не растет, продуктовые метрики падают, и к целям компании мы не приближаемся.

Почему? Потому что нет регулярного процесса Upstream, задачей которого является выбор, валидация и подготовка именно тех задач, которые принесут наибольшую выгоду, и которыми действительно стоит загружать наши производственные подразделения (downstream)

🚧Ведь мощности Downstream - всегда ограничены. А придумывать новые идеи - всегда проще, чем их реализовывать.
Придется соразмерять частоту генерации новых идей с возможностями к их производству.

В реальном производстве эти ограничения обусловлены возможностями станков, а в интеллектуальном труде подобных ограничений не видно. Но они есть - это физические возможности людей работать. В сутках только 24 часа, рабочий день 8 часов, и бесконечно заполнять это пространство задачами - не получится

🔦Чтобы опрозрачить эти ограничения в интеллектуальном труде (программирование, аналитика, юристы и тд) надо визуализировать поток работ и на Upsttream и на Downstream, чтобы привести их к балансу. Тогда можно увеличивать прибыль и продуктовые метрики, не перегружая производство, предсказуемо и с нужным уровнем качества

#upstream
#просто
🔥7
Всем кто пользуется JIRA и знает Канбан-метод рано или поздно приходит в голову вопросы:
- А как сделать WIP-лимиты на человека?
- А можно ли сделать единый WIP-лимит на несколько колонок (CONWIP)?
- И как сделать WIP-лимит на беговую дорожку, чтобы классы обслуживания ограничить?
- А как построить Lead Time Distribution Chart?
- А симуляцию Монте-Карло для прогнозирования проекта можно в JIRA сделать?

🥲Увы и ах, но "из коробки" JIRA так делать не умеет 🙁
Она вообще много чего не умеет, но мы ее любим. Как старого коня, который борозды не испортит, но и рекордов на ипподроме от него ждать не стоит.

Как же быть, если все перечисленное попробовать хочется, а у вас JIRA?

🔥Выручают плагины. Причем, как ни странно - плагины не к JIRA, а к Google Chrome.

1️⃣Например, можно поставить плагин Jira Helper для Google Chrome, например - и все перечисленные трюки с WIP-лимитами становятся доступны - персональные WIP, CONWIP, WIP на беговую дорожку, и так далее. Просто при заходе в JIRA с включенным плагином, вы сможете все это делать. JavaScript - и никакой магии :))

2️⃣Второй плагин - Jira Flow Companion - позволяет строить нормальные графики Cumulative Flow Diagram, Lead Time Distribution и даже делать симуляцию Монте-Карло.

Всем JIRA-водам - приятного использования! Не благодарите :))

#инструменты
👍8
Forwarded from ScrumTrek
Привет!
🕕 18-я конференция AgileDays состоится уже в марте следующего года 🎉
Начинаем серию постов для знакомства с командой Программного Комитета конференции👋

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

Итак, первые три представителя Программного Комитета:
🟢 Артемий Анцупов — продюсер конференции и лидер команды Программного комитета, Agile Coach и тренер, в прошлом менеджер проектов;
🟢 Иван Дубровин — CEO ScrumTrek и Agile Coach, эксперт в области гибкого портфельного управления. Продюсер трека «Управление изменениями»;
🟢 Евгений Родионов — Agile Coach и управленческий консультант, эксперт по масштабированию Agile и трансформации операционных моделей. Продюсер трека «Фреймворки и практики».

Подробнее о конференции и команде ПК 🔗
Please open Telegram to view this post
VIEW IN TELEGRAM
Небольшая разминка перед серией материалов про Upstream Kanban.

#анонс