Control Quantitative Laboratory
713 subscribers
67 photos
4 videos
77 links
Меня зовут Павел Ахметчанов
Этот канал я создал для того, чтобы делиться своими мыслями и наработками, исследованиями в области менеджмента, науки о данных, и синергии этих областей.
Download Telegram
Вариант № 1. По Lead Time и схожести

Мы можем использовать прошлый опыт по задачам с похожим контекстом и изучить их Lead Time. Построив распределение по этим задачам, мы сможем прогнозировать время выполнения задачи с определенной вероятностью.

Недостатки:

* Необходимо учитывать изменения контекста со временем, и оценка будет актуальна только при стабильной организации процесса работы. Можно использовать контрольную карту для наблюдения за стабильностью.
* Lead Time отвечает на вопрос о времени выполнения задачи и вероятности, но не говорит о количестве задач, которые можно взять на выполнение.
* Для крупных проектов сложно найти аналогии.
* Распределение имеет логарифмический вид, поэтому нельзя просто взять среднее значение.
* Требуется хорошо настроенная система сбора метрик или использование современных трекеров задач, таких как kaiten.ru, где уже предусмотрены сбор метрик.

Плюсы:
* Дает наиболее достоверные данные по срокам выполнения задачи
* Легко найти риски, которые могут произойти по аналогии с задачами попадающими в "хвост" распределения
* При понимании dead line позволяет лучше выбрать стратегию принятия решения
* Легко показать другим по факту как долго делается работа.
1
Вариант No 2. По пропускной способности подобию.

Вы можете посмотреть в статистике сколько задач делали за какой-то период и какие это работы

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

Так же можно использовать моделирование методом Монте-Карло. Особенно для случая с вероятными рисками.

Вот пример кода на JS для расчета вероятности завершения сроков проекта
https://gist.github.com/pavelpower/97625088b6cdbde9cfdd4f181fb33a39

А тут подсчет плотности вероятности количества работ на итерацию
https://gist.github.com/pavelpower/dc824f3d31ab6c29bd9ff307b927d73f

Для моделирования с учетом рисков можно использовать эту форму https://rodrigozr.github.io/ProjectForecaster/ сделанную по лекалам Троя Магиннеса.

Минусы:
* Метод будет хорошо работать если вы в часто берете разные по объему и типу задачи, чтобы количество выполняемой работы имело хорошее нормальное распределение. Либо у вас должны быть однотипные работы, что так же повлияет на распределение в сторону его нормальности. В случае если вы последовательно делали один тип работ, потом другой, то данные одного эксперимента вам нельзя использовать для другого.
* При использовании Монте-Карло, нужно перебрать несколько начальных условий, чтобы лучше понимать влияние рисков. Недостаточно одной модуляции и об этом можно легко забыть.
* Не отвечает на вопрос когда закончится конкретная задача
* В случае проведения изменений, статистика будет бесполезна.

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

#артефакты
Стоит ли рассказать подробнее о том как работает метод Монте-Карло?
Final Results
85%
Да, это было бы интересно
9%
Нет, давай лучше про наблюдения за командами
6%
Может быть
Метод Монте-Карло

Понимаю, что в рамках поста в Telegram очень сложно будет уместить объяснение работы Монте-Карло.

Поэтому описал статью отдельно 👉 тут

В статье привел примеры как можно моделировать завершение проекта используя данные пропускной способности.

Постарался сделать самый простой пример.
Который можно использовать для развития своих идей моедлирования.
Добавил и пример с возможными наступления и рисков.

Конечно, это не единственный способ. Однако для большенства случаев он вполне подходящий.

В статье привел пример кода на JavaScript который можно запустить даже в браузере.

Но, а если у вас нет навыков программирования, вы можете воспользоваться готовой формой Rodrigo Rosaulo создавший удобную форму на сонове работ Troy Magennis' и Dimitar Bakardzhiev

Если вам статья понравилась дайте знать - поставьте свой emoji.

Будут вопросы, задавайте в тред (прикрепленный чатик к каналу)

#статья
#артефакты
🔥18👍81🍾1
Статью про Монте-Карло, начали активно копировать и пересылать.

Спасибо, значит было не зря.

Сообщество Delivery Managers из Тинькофф предоставили Open Source площадку, где docisaurus оформлении получилось чуточку улучшить описание.

К тому же статья будет рядом с другой полезной информацией на этом сайте

#артефакты
#статья
🔥161👍1
Пока готовил статью про Монте-Карло, хотел найти ответ на вопрос — "можно ли найти хороший существующий пример изложения?". Но, на момент написания статьи не нашел.
А тут из закрамов достал книгу Scrumban, Аджая Редди.
И в качестве справочной информации достаточно подробно расписан метод, и даже с формулами.

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

#интересное
#прокниги
👍10🔥1
А тем временем вышел подкаст с небольшим юмором, про оценки с моим участием.

Называется “Письма Лиды Таймовой”

Вместе с ним обсудили:

🔶 что такое оценка и почему оценка задачи — частый запрос;
🔶 как проходят тренинги по оценкам задач;
🔶 часы, сторипойнты или No estimate? Как оценивать задачи и стоит ли это делать?
🔶 почему человечество до сих пор не изобрело идеального похода по оценке?


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

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

За основу материала для наблюдения коллеги взяли статистику по Lead Time команды.

И для решения своей задачи выдвинули гипотезу "H":
"В гистограмме Lead Time обнаруженные моды являются обособленным признаком сложности решаемых задач, а значит выделив эти мо́ды можно определить сложность решаемой задачи."

Живой пример распределения смотри на картинке

Мо́да — одно или несколько значений во множестве наблюдений, которое встречается наиболее часто (мода = типичность)

На картинке явно видны отличные мо́ды.

Чтобы далее верно решать задачу, нам нужно сформулировать "обратную" нулевую гипотезу "H0":
"Мо́ды в частотной диаграмме Lead Time не являются признаком сложности решаемой задачи, и связаны с другими явлениями".

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

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

Что позволит создать алгоритм оценки задач.

Давайте вместе с вами попробуем помочь коллегам с решением задачи и ответим на вопрос ниже:

#интересное
Оши́бка пе́рвого ро́да (α-ошибка, ложноположительное заключение) — ситуация, когда отвергнута верная нулевая гипотеза (об отсутствии связи между явлениями или искомого эффекта).

Оши́бка второ́го ро́да (β-ошибка, ложноотрицательное заключение) — ситуация, когда принята неверная нулевая гипотеза.

#интересное
И так, пока продолжаю писать статью о том, "что же такое предсказуемость и как ее понять?”, в канале обсуждаем тему создания алгоритма для оценки задач.

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

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

Мода в Lead Time графике нам лишь говорит о том, что какая-то категория или категории за этот период закрываются чаще. Такое может быть, например, связано с рабочей неделей или спринтом.

Как и в этом случае.

Внимательные читатели заметили, что моды формируются по 5-дневным отрезкам.

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

По этому нулевая гипотеза: “Моды в частотной диаграмме Lead Time не являются признаком сложности решаемой задачи, и связаны с другими явлениями", как в этом случае, имеет большее обоснование для подтверждения.

А алгоритм прогнозирования надо строить относительно входящих характеристик, на Lead Time же стоит проверять фактический результат по времени решения:

1. Определяем характеристики задач по которым выбираем категории. Например, описание, приоритет, автор
2. Выделив категории, строим отдельный график Lead Time.
3. Строим прогноз, если для новой задачи характеристики близки к категории N, то и время решения этой задачи будет соответствовать распределению для этой категории.

#мысливслух
#статья
👍2
Я являюсь продюсером трека "Принятие управленческих решений на основании данных"
в конференции Flow Days. Эта конференция про опыт.

Возможно у тебя есть хороший Case о котором стоит рассказать.
Чтобы было проще поделится своим опытом у меня есть подсказка которую можно прочитать.
Если хочешь поделится подавай заявку
В подготовке доклада буду обязательно консультировать.

Видео о чем будет эта конференция
https://www.youtube.com/watch?v=3TMIeFODQJo

Подавай заявку, делись опытом!
Приходи на конференцию, пообщаемся и поделимся своим опытом и кейсами.
Будет полезно и тем кто делает доклад, и тем кто слушает
👍6
Подготовил статью про предсказуемость
Остается понять куда ее лучше разместить, на какой площадке.

Если у вас есть предложение, напишите в тред!
Спасибо

#мысливслух
👍6
“Что такое предсказуемость выполнения задач и как ее понять?”

Я решил выбрать в качестве площадки, для статьи про “предсйказуемость” будет kanbangude.ru.

Размещаю как и обещал 3 сентября.
Но, думаю, что кое-какие корректировки в статью еще буду вносить.

Так как один из моих читателей при первом прогоне сказал о том, что пока статья написана “сложновато”.

Попрошу и вас оценить ее

Ставьте
👍— если считаете, что статья хорошо раскрывает тему
🔥 — оказалась полезной
😱 — если статья все таки сложная, и ее стоит упростить

Спасибо!

#статья
👍5🔥3😱2