Команда пока разбирается, жду от них обратной связи 🤷‍♂

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

Я оперирую двумя терминами, которые называются "тип рабочего элемента" и "класс обслуживания", что есть сильно разные вещи, в твоем сообщении выглядело все как смесь этих двух утверждений. На графике распределения мы видими всего 5 кластеров в выборке данных, и эти кластеры могут относиться и к моему первому и ко второму утверждению

Типы рабочего элемента в фильтре диаграммы...

А так да, пока изучают.

Тогда другой вопрос, от чего зависит попадание в тот или иной сегмент?

@pimenaus а есть ли какие-то формальные правила позволяющие понять насколько мелко нужно крошить задачи?

Lead time, это по оси X... или я не понял вопроса)

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

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

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

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

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

Можешь подробнее мысль раскрыть про басню? Не совсем понял)

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

Не мне, а им!

Прогнозируемость ну и основное - поиск снижения lead time для классов/кластеров

Я пытаюсь последние 10 минут с тебя вытрясти то, как картинка превращается в прогнозирование. Но я так понял что ты сам не знаешь как это делать и тебе это не интересно, ты готов это свалить команде

Ответ выше в сообщении у Алексея :)

Спойлеры! 😃

На практике пока не знаю, как превратится, и превратится ли?

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

Лично я в этом вижу снятие иерархии и самоорганизацию)

Кстати, про эстимацию на основе статистики я тут как-то перепёрла презентацию Славы (был тут такой классный чувак раньше) на английский язык, если кому интересно https://docs.google.com/presentation/d/1QqZklnKtz5FsrIdQzB-oSG7ctUNoKGg90W8BznrfeSU/edit?usp=sharing

TL;DR

-To have a reliable estimation you don’t need to have experienced engineers who estimate
- Statistics knows about the Team and impediments and risks everything that could affect the due dates
- If you would like to improve your estimated due dates - you need to minimize the influence of the external factors and you can always measure the result by looking at your statistics
Там просто внутри интересные (позаимствованные) графики