Про обозначение тегов в этом канале
Пока все мужчины поздравляют своих дам с днем 8 марта.
С утра по раньше сел за канал, и по рекомендациям читателей добавил теги, чтобы было проще найти в канале полезную информацию.
#проинструменты - что может пригодиться в работе (не про теорию, а про инструменты для практики)
#мысливслух - нечто быстро выдуманное или пришедшее на ум, не факт что несет полезность
#забавное - шутки прибаутки
#артефакты - это пост с ссылками за которыми может быть для вас полезная информация
#благодарности - эмоциональное выражение благодарности
#интересное - про события которая может быть интересны
#доклады - про доклады как мои так и не мои
#подкаст - про подкасты и о чем там было
#задачки - посты с задачками за ответы на которые могут будут подарки
#статья - пост про подготовку или публикацию или про резюмировании статьи
#уменячтотополучилось - хвастаюсь, чтобы не было так стеснительно вставляю этот тег
#прокниги - посты связанные с книгами
Пока все мужчины поздравляют своих дам с днем 8 марта.
С утра по раньше сел за канал, и по рекомендациям читателей добавил теги, чтобы было проще найти в канале полезную информацию.
#проинструменты - что может пригодиться в работе (не про теорию, а про инструменты для практики)
#мысливслух - нечто быстро выдуманное или пришедшее на ум, не факт что несет полезность
#забавное - шутки прибаутки
#артефакты - это пост с ссылками за которыми может быть для вас полезная информация
#благодарности - эмоциональное выражение благодарности
#интересное - про события которая может быть интересны
#доклады - про доклады как мои так и не мои
#подкаст - про подкасты и о чем там было
#задачки - посты с задачками за ответы на которые могут будут подарки
#статья - пост про подготовку или публикацию или про резюмировании статьи
#уменячтотополучилось - хвастаюсь, чтобы не было так стеснительно вставляю этот тег
#прокниги - посты связанные с книгами
🔥6
Control Quantitative Laboratory pinned «Про обозначение тегов в этом канале Пока все мужчины поздравляют своих дам с днем 8 марта. С утра по раньше сел за канал, и по рекомендациям читателей добавил теги, чтобы было проще найти в канале полезную информацию. #проинструменты - что может пригодиться…»
Продолжаю улучшать информацию Kanban-метрики на доске Unidraw.
- Обновил “Глоссарий”
- Исправил несколько ошибок в текстах, в том числе заменил слово “задачи” на “рабочий элемент”
- Упростил для восприятия текст “One-Time Delivery”
Напомню, что если хочешь стать соавтором, то напиши мне, я добавлю тебя в редакторы.
Использование Unidraw для этой справочной информации позволяет сделать две удобные вещи:
1. Предоставить информацию бесплатно
2. Кидать коллегам ссылки прямо на конкретные примеры.
Для того чтобы скинуть ссылку на нужную метрику, выделите фрейм с ней, нажмите ПКМ (правая кнопка мыши) вызвав контекстное меню и в нем нажмите “Скопировать ссылку на объект”.
В ваше буфере обмену будет ссылка прямо на описание нужной метрики.
Пример на картинке
#артефакты
- Обновил “Глоссарий”
- Исправил несколько ошибок в текстах, в том числе заменил слово “задачи” на “рабочий элемент”
- Упростил для восприятия текст “One-Time Delivery”
Напомню, что если хочешь стать соавтором, то напиши мне, я добавлю тебя в редакторы.
Использование Unidraw для этой справочной информации позволяет сделать две удобные вещи:
1. Предоставить информацию бесплатно
2. Кидать коллегам ссылки прямо на конкретные примеры.
Для того чтобы скинуть ссылку на нужную метрику, выделите фрейм с ней, нажмите ПКМ (правая кнопка мыши) вызвав контекстное меню и в нем нажмите “Скопировать ссылку на объект”.
В ваше буфере обмену будет ссылка прямо на описание нужной метрики.
Пример на картинке
#артефакты
🔥1💯1
Чем и кому полезна книга "Код: Тайный язык информатики"?
Встречаю переодически коллег разработчиков которые великолепно знают наборы библиотек и хорошо справляются с повседневной работой. Однако у меня складывается впечатление что такого характера работу смогут решать с использованием ИИ вполне и посредственные специалисты.
Однако, когда возникает вопрос о том как решить сложную задачу на более низком уровне, сталкиваются с проблемой понимания того как работает компьютер. Когда нужны суждения того как это работает на самом низком базовом уровне, уровне железа.
Понимание этих базовых вещей позволяет находить не тривиальные решения для талантливых ребят.
И потому я бы рекомендовал коллегам SRE и разработчикам почитать книгу "Код: Тайный язык информатики", Чрьлза Петцольда.
Автор из Нью-Йорка посвятил себя объяснению таких базовых цифровых технологий, и это, кстати, не единственная его книга.
Почему вам может быть интересна эта книга?
Автор рассказывает, как работает компьютер через аналогии привычных нам вещах и постепенно погружая вплоть до того что же такое операционная система.
В конечном итоге после прочтения можно быть вы и сами попробуете написать свою операционную систему для какого-то микроконтроллера.
Чтобы понять лучше путь который вы можете пройти с этой книгой посмотрите на название глав, по которым построите свое путешествие:
2. Коды и комбинации
3. Брайль и двоичные коды
4. Устройство фонарика
5. Заглядывая за угол
6. Телеграфы и реле
7. Наши десять цифр
8. Альтернативы десятке
9. За битом бит
10. Логика и переключатели
11. Логические вентили
12. Двоичный сумматор
13. А как насчет вычитания?
14. Обратная связь и триггеры
15. Байты и шестнадцатеричные числа
16. Сборка памяти
17. Автоматизация
18. От счетов к микросхемам
19. Два классических микропроцессора
20. Набор символов ASCII
21. Шины
22. Операционная система
23. Фиксированная точка, плавающая точка
24. Языки высокого и низкого уровня
25. Графическая революция
#прокниги
Встречаю переодически коллег разработчиков которые великолепно знают наборы библиотек и хорошо справляются с повседневной работой. Однако у меня складывается впечатление что такого характера работу смогут решать с использованием ИИ вполне и посредственные специалисты.
Однако, когда возникает вопрос о том как решить сложную задачу на более низком уровне, сталкиваются с проблемой понимания того как работает компьютер. Когда нужны суждения того как это работает на самом низком базовом уровне, уровне железа.
Понимание этих базовых вещей позволяет находить не тривиальные решения для талантливых ребят.
И потому я бы рекомендовал коллегам SRE и разработчикам почитать книгу "Код: Тайный язык информатики", Чрьлза Петцольда.
Автор из Нью-Йорка посвятил себя объяснению таких базовых цифровых технологий, и это, кстати, не единственная его книга.
Почему вам может быть интересна эта книга?
Автор рассказывает, как работает компьютер через аналогии привычных нам вещах и постепенно погружая вплоть до того что же такое операционная система.
В конечном итоге после прочтения можно быть вы и сами попробуете написать свою операционную систему для какого-то микроконтроллера.
Чтобы понять лучше путь который вы можете пройти с этой книгой посмотрите на название глав, по которым построите свое путешествие:
2. Коды и комбинации
3. Брайль и двоичные коды
4. Устройство фонарика
5. Заглядывая за угол
6. Телеграфы и реле
7. Наши десять цифр
8. Альтернативы десятке
9. За битом бит
10. Логика и переключатели
11. Логические вентили
12. Двоичный сумматор
13. А как насчет вычитания?
14. Обратная связь и триггеры
15. Байты и шестнадцатеричные числа
16. Сборка памяти
17. Автоматизация
18. От счетов к микросхемам
19. Два классических микропроцессора
20. Набор символов ASCII
21. Шины
22. Операционная система
23. Фиксированная точка, плавающая точка
24. Языки высокого и низкого уровня
25. Графическая революция
#прокниги
🔥6
Что не так с методом Монте-Карло, почему он такой разный?
В личные сообщения я получаю иногда вопросы которые связаны с непониманием того, как действует метод Монте-Карло.
Давайте разберемся что с ним не так.
Монте-Карло — это метод, который появился благодаря азартным играм, и довольно часто используется, например в покере Холдем в уме, например для ответа на вопрос: "У меня на руках Туз и 7 на префлопе, стоит ли играть с ними если за столом еще 10 человек?".
И чтобы ответить на него вы начинаете представлять, если вы сыграете эту комбинацию 1000 раз, сколько раз вы выиграете против других комбинаций? Ответ будет больше раз прибегаю чем выиграю.
Вероятность выиграть с разномастными A и 7 на префлопе против 9 оппонентов в Техасском Холдеме составляет примерно 7-8%. Это значение учитывает equity (шансы на победу) руки A7o против случайных рук остальных игроков
Сам по себе метод очень прост в нем оговаривается главное правило:
— Повторить расчеты большое множество раз, и сопоставить сколько раз выпало событие интересующего вас варианта к сумме всех событий определяя вероятность получения результата.
Он не говорит ничего о том, какую модель (формулу) вы используете для получения того или иного события, это остается на ваш выбор.
Т.е. это ничто иное как инструмент для анализа вашего стахастического процесса, с попыткой приблизить ваше понимание того, что может произойти исходя из той информации которая вам известна применяемой вами к вашей модели через которую вы исследуете свой процесс.
Стахастический процесс — это математическая модель, описывающая последовательность случайных событий, развивающихся во времени. В таких процессах будущие состояния зависят от текущего состояния и случайных факторов, а не только от начальных условий (как в детерминированных системах).
Метод хорош в том, что вы можете внести в модель случайные события, о которых вам известна только некая их вероятность возникновения, например на основе предположений или исторического опыта.
Добавляя разные случайные величины (риски) в свою модель, и увидеть как может меняться результат вычислений.
Используя эти знания можно выявлять и ранжировать риски, по их влиянию и понять какие риски стоит митигировать в первую очередь.
Моделирование может помочь так же в выявлении совокупности рисков которые могут влиять на результат.
В вашей модели вы можете учесть вероятность ухода в отпуск сотрудника, и в общем другие вероятности остановки производства в которые могут быть разные риски: блокировки, появление случайных "Expedite" задач, все что вы можете предположить.
Решая обратную задачу с Монте-Карло, можно ответить на вопрос:
— Как понять какие из рисков наиболее сильно влияют или не влияют на результат выполнения в срок задач?
Давайте расширим спектр вопросов, в исследуемом стахостическом процессе, на которые можно отвечать применяя метод Монте-Карло:
— При условии имеющихся ресурсов когда закончим проект/задачу?
— Сколько мне нужно ресурсов, чтобы успеть в срок?
— Какие риски наиболее сильно влияют на результат?
— Как лучше произвести комбинаторику построения критической цепи для уменьшения рисков (привет PERT)?
— Как измениться динамика завершения проекта/задачи если будет изменяться вероятность возникновения тех или иных рисков со временем?
Для ответа на все эти вопросы, вы будете собирать разную модель для расчетов.
Так в статье про Мотне-Карло на самом деле речь идет про один из простых вариантов использования, нацеленных на поиск срока завершения исходя из исторической модели завершения задач в прошлом по Throughput. И в большенмтве случаев его может быть достаточно для ответа на вопрос - когда завершим этот объем задач.
#артефакты
#интересное
#МонтеКарло
В личные сообщения я получаю иногда вопросы которые связаны с непониманием того, как действует метод Монте-Карло.
Давайте разберемся что с ним не так.
И чтобы ответить на него вы начинаете представлять, если вы сыграете эту комбинацию 1000 раз, сколько раз вы выиграете против других комбинаций? Ответ будет больше раз прибегаю чем выиграю.
Вероятность выиграть с разномастными A и 7 на префлопе против 9 оппонентов в Техасском Холдеме составляет примерно 7-8%. Это значение учитывает equity (шансы на победу) руки A7o против случайных рук остальных игроков
Сам по себе метод очень прост в нем оговаривается главное правило:
— Повторить расчеты большое множество раз, и сопоставить сколько раз выпало событие интересующего вас варианта к сумме всех событий определяя вероятность получения результата.
Он не говорит ничего о том, какую модель (формулу) вы используете для получения того или иного события, это остается на ваш выбор.
Т.е. это ничто иное как инструмент для анализа вашего стахастического процесса, с попыткой приблизить ваше понимание того, что может произойти исходя из той информации которая вам известна применяемой вами к вашей модели через которую вы исследуете свой процесс.
Метод хорош в том, что вы можете внести в модель случайные события, о которых вам известна только некая их вероятность возникновения, например на основе предположений или исторического опыта.
Добавляя разные случайные величины (риски) в свою модель, и увидеть как может меняться результат вычислений.
Используя эти знания можно выявлять и ранжировать риски, по их влиянию и понять какие риски стоит митигировать в первую очередь.
Моделирование может помочь так же в выявлении совокупности рисков которые могут влиять на результат.
В вашей модели вы можете учесть вероятность ухода в отпуск сотрудника, и в общем другие вероятности остановки производства в которые могут быть разные риски: блокировки, появление случайных "Expedite" задач, все что вы можете предположить.
Решая обратную задачу с Монте-Карло, можно ответить на вопрос:
— Как понять какие из рисков наиболее сильно влияют или не влияют на результат выполнения в срок задач?
Давайте расширим спектр вопросов, в исследуемом стахостическом процессе, на которые можно отвечать применяя метод Монте-Карло:
— При условии имеющихся ресурсов когда закончим проект/задачу?
— Сколько мне нужно ресурсов, чтобы успеть в срок?
— Какие риски наиболее сильно влияют на результат?
— Как лучше произвести комбинаторику построения критической цепи для уменьшения рисков (привет PERT)?
— Как измениться динамика завершения проекта/задачи если будет изменяться вероятность возникновения тех или иных рисков со временем?
Для ответа на все эти вопросы, вы будете собирать разную модель для расчетов.
Так в статье про Мотне-Карло на самом деле речь идет про один из простых вариантов использования, нацеленных на поиск срока завершения исходя из исторической модели завершения задач в прошлом по Throughput. И в большенмтве случаев его может быть достаточно для ответа на вопрос - когда завершим этот объем задач.
#артефакты
#интересное
#МонтеКарло
👍4
Моделировать можно в том числе и данные которых у вас может быть не достаточно.
Что делать если данных не достаточно для Монте-Карло?
Вы можете прибегнуть к использованию схожих моделей. Например для Lead Time известно, что подходит распределение Вэйбула, по этому можно взять данные которые у вас есть и сделать интерполяцию их подгоняя под них параметры распределения, чтобы понять наиболее вероятный срок завершения задач.
А вот для Throughput больше подходит нормально распределение, и если у вас не достаточно данных по Throughput вы можете взять аналогию нормального распределения и использовать его.
А делае уже с большим набором данных вы можете применить метод Монте-Карло для ответов на свои вопросы.
И так, сам метод Монте-Карло совершенно не говорит о том:
— на какой вопрос вы хотит ответить, прмиеняя его
— какую модель вы для отета на этот вопрос применяете
По этому в разных источниках по применению метода Монте-Карло вы можете встретить разные примеры применения, только потому, что используется разная модель для вычисления, как собственно и вопрос на который отвечает этот метод.
Ответы на вопросы: "Какие риски влияют или не влияют на результат?" — это более глубокое исследование вашего процесса при помощи метода Монте-Карло.
В этом случае вы начинаете применять поверх расчета результата методики исследования решением обратной задачи отсносительно рисков. Иначе говоря — это применение метода Монте-Карло с методами поиска решения в поле рисков.
Что, несомненно, является более сложной и интересной задачей.
Более подробно о проблеме я описал на Unidraw.io о том как понять Монте-Карло
#интересное
#артефакты
#МонтеКарло
Что делать если данных не достаточно для Монте-Карло?
Вы можете прибегнуть к использованию схожих моделей. Например для Lead Time известно, что подходит распределение Вэйбула, по этому можно взять данные которые у вас есть и сделать интерполяцию их подгоняя под них параметры распределения, чтобы понять наиболее вероятный срок завершения задач.
А вот для Throughput больше подходит нормально распределение, и если у вас не достаточно данных по Throughput вы можете взять аналогию нормального распределения и использовать его.
А делае уже с большим набором данных вы можете применить метод Монте-Карло для ответов на свои вопросы.
И так, сам метод Монте-Карло совершенно не говорит о том:
— на какой вопрос вы хотит ответить, прмиеняя его
— какую модель вы для отета на этот вопрос применяете
По этому в разных источниках по применению метода Монте-Карло вы можете встретить разные примеры применения, только потому, что используется разная модель для вычисления, как собственно и вопрос на который отвечает этот метод.
Ответы на вопросы: "Какие риски влияют или не влияют на результат?" — это более глубокое исследование вашего процесса при помощи метода Монте-Карло.
В этом случае вы начинаете применять поверх расчета результата методики исследования решением обратной задачи отсносительно рисков. Иначе говоря — это применение метода Монте-Карло с методами поиска решения в поле рисков.
Что, несомненно, является более сложной и интересной задачей.
Более подробно о проблеме я описал на Unidraw.io о том как понять Монте-Карло
#интересное
#артефакты
#МонтеКарло
👍3
Можно ли использовать Монте-Карло на основе Throughput, если Lead Time с жирными хвостами?
Разбор по мотивам обсуждения из чатика "Kanban Talks".
И так, исходим из предположения, что в моделировании используется только Throughput.
При этом используем допущение, что все задачи попадающие в процесс завершаются (не выбрасываются).
Можно ли использовать данные по Throughput для моделирования Монте-Карло, в случае наличия жирных хвостов (есть задачи которые залёживаються в процессе)?
Ответ:
Мы, вполне, получим прогоз с достаточной точностью, если определим конечный набор входящих в процесс задач.
Система получается закрытой, а процесс сходящимся.
Причём так как мы используем конкретный набор задач, и с достаточной стабильным WIP, прогноз будет вполне точным.
И даже простая экстраполяция графика касательных к CFD диаграмме по завершением задачам может дать примерные сроки завершения.
Эта максима, от которой дальше можно двигаться в рассуждения.
Но, как же так?
Ведь есть долгие задачи?
Да, но в система стабильна относительно пропускной способности, и эти долгие задачи это лишь признак их типовой обособленности.
Это просто другой тип задач.
Даже если используем моделирование на основании ограничения WIP, и Lead Time, мы так же получим сходящийся результат в конкретные сроки, при правильном подборе WIP, примерно в те же, что и с чисто Throughput.
Идея в том, что моделирование будет строиться от объёма который надо выполнить и характеристики либо пропускной способности либо WIP и Lead Time, отвечая на вопрос: а когда выполним этот объем данных?
А вот если мы задаёмся вопросом — когда конкретная задача будет выполнена?
То тут как раз нас ожидают проблемы.
Очевидный ответ будет — во всем диапазоне сроков по распределению Lead Time. Увы. И то, если в LT достаточно данных для такого ответа.
Ок, а что если наша система не замкнутая, а объем меняется?
Или, у нас есть процесс по удалению задач из процесса?
Тогда, для точности прогноза с методом Монте-Карло станет действительно интереснее, нам нужно будет внести функции оценки сходимости процесса, и понять как определить функции дополнения новых задач и удаления из процесса во времени для прогнозирования.
Итог:
— Если система стабильна по пропускной способности и объем задач конечен, то прогноз будет хорошим, для оценки сроков по завершению совокупности объёма
— Для оценки сроков по конкретной задаче, мы действительно будем испытывать трудности
Дополнительно:
В случае изменения входящего объёма и изменения объёма который дропаеться, для точности оценки нужно вносить функцию оценки сходимости, которая будет отвечать на вопрос: "при какой динамике добавления и удаления из процесса задач, мы можем успеть к сроку".
Однако, и её можно свести к вопросу о "получения диапозона дат завершеия всего объема", если задать вероятности появления/дропа новых задач и какого объёма, как вам уже знакомая работа с рисками. И ответ вполне может быть (бесконечность, для расходящегося процесса).
Значит чтобы делать оценку о сроках, нам в общем надо понимать сходимость процесса. А эта сходимость определяется отношением скорости поступающих задач к исходящим.
В случае если вы наблюдайте динамику роста рисков (или в общем объёма повышения задач относительно завершения) вот точно надо принимать меры, по сдерживанию динамики и приведению её в порядок – сведению к динамике решаемых задач.
Либо увеличению динамики решаемых задач, так чтобы она покрывала и риски.
Сейчас, наверное посмотрите на свое CFD, и скорее всего сядите подумать, чего делать с эти растущим бэклогом?
- что от туда дропать?
- нанимать ли ещё людей?
- автоматизировать ли что-то?
- отказаться ли от какого-то функционала фокусируясь на важном в рамках объёма возможностей?
- а что в этом всем важное?
- можете ли себе позволить отказаться, если рыночек требует?
P.S. в не замкнутом процессе, где добавляються задачи даже с той же или большей скоростью, что и завершаются, вполне возможен случай с появлением бесконечной задачи. Если не видить их и не принимать решения о их завершении или дропе.
#интересное
#throughput
#МонтеКарло
Разбор по мотивам обсуждения из чатика "Kanban Talks".
И так, исходим из предположения, что в моделировании используется только Throughput.
При этом используем допущение, что все задачи попадающие в процесс завершаются (не выбрасываются).
Можно ли использовать данные по Throughput для моделирования Монте-Карло, в случае наличия жирных хвостов (есть задачи которые залёживаються в процессе)?
Ответ:
Мы, вполне, получим прогоз с достаточной точностью, если определим конечный набор входящих в процесс задач.
Система получается закрытой, а процесс сходящимся.
Причём так как мы используем конкретный набор задач, и с достаточной стабильным WIP, прогноз будет вполне точным.
И даже простая экстраполяция графика касательных к CFD диаграмме по завершением задачам может дать примерные сроки завершения.
Эта максима, от которой дальше можно двигаться в рассуждения.
Но, как же так?
Ведь есть долгие задачи?
Да, но в система стабильна относительно пропускной способности, и эти долгие задачи это лишь признак их типовой обособленности.
Это просто другой тип задач.
Даже если используем моделирование на основании ограничения WIP, и Lead Time, мы так же получим сходящийся результат в конкретные сроки, при правильном подборе WIP, примерно в те же, что и с чисто Throughput.
Идея в том, что моделирование будет строиться от объёма который надо выполнить и характеристики либо пропускной способности либо WIP и Lead Time, отвечая на вопрос: а когда выполним этот объем данных?
А вот если мы задаёмся вопросом — когда конкретная задача будет выполнена?
То тут как раз нас ожидают проблемы.
Очевидный ответ будет — во всем диапазоне сроков по распределению Lead Time. Увы. И то, если в LT достаточно данных для такого ответа.
Ок, а что если наша система не замкнутая, а объем меняется?
Или, у нас есть процесс по удалению задач из процесса?
Тогда, для точности прогноза с методом Монте-Карло станет действительно интереснее, нам нужно будет внести функции оценки сходимости процесса, и понять как определить функции дополнения новых задач и удаления из процесса во времени для прогнозирования.
Итог:
— Если система стабильна по пропускной способности и объем задач конечен, то прогноз будет хорошим, для оценки сроков по завершению совокупности объёма
— Для оценки сроков по конкретной задаче, мы действительно будем испытывать трудности
Дополнительно:
В случае изменения входящего объёма и изменения объёма который дропаеться, для точности оценки нужно вносить функцию оценки сходимости, которая будет отвечать на вопрос: "при какой динамике добавления и удаления из процесса задач, мы можем успеть к сроку".
Однако, и её можно свести к вопросу о "получения диапозона дат завершеия всего объема", если задать вероятности появления/дропа новых задач и какого объёма, как вам уже знакомая работа с рисками. И ответ вполне может быть (бесконечность, для расходящегося процесса).
Значит чтобы делать оценку о сроках, нам в общем надо понимать сходимость процесса. А эта сходимость определяется отношением скорости поступающих задач к исходящим.
В случае если вы наблюдайте динамику роста рисков (или в общем объёма повышения задач относительно завершения) вот точно надо принимать меры, по сдерживанию динамики и приведению её в порядок – сведению к динамике решаемых задач.
Либо увеличению динамики решаемых задач, так чтобы она покрывала и риски.
Сейчас, наверное посмотрите на свое CFD, и скорее всего сядите подумать, чего делать с эти растущим бэклогом?
- что от туда дропать?
- нанимать ли ещё людей?
- автоматизировать ли что-то?
- отказаться ли от какого-то функционала фокусируясь на важном в рамках объёма возможностей?
- а что в этом всем важное?
- можете ли себе позволить отказаться, если рыночек требует?
P.S. в не замкнутом процессе, где добавляються задачи даже с той же или большей скоростью, что и завершаются, вполне возможен случай с появлением бесконечной задачи. Если не видить их и не принимать решения о их завершении или дропе.
#интересное
#throughput
#МонтеКарло
👍7
Как я вижу применимость Монте-Карло при недостатке данных?
По мотивам обсуждения из этого чата “Kanban Talks”, отмечу еще
(Там речь идет про использование Lead Time для понимания имеет смысл ли использовать Монте-Карло если мало данных или есть хвосты, по этому далее ответ напишу исходя из того, что вы применяете Lead Time в своей модели для прогнозирования)
Для применения Монте-Карло нужны хоть какие-то данные, и чем более достовернее они тем лучше.
При этом, если существуют длинные хвосты у Lead Time, нам это не мешает применять Монте-Карло, просто это покажет очень широкий Lending zone (диапазон решений - дат когда закончим).
Иначе говоря, у вашего процесса много рисков.
И это тоже можно использовать, чтобы очевидно показать проблему длинных хвостов сгенерировав результат через Монте-Карло, вы покажете на сколько большая проблема для результата.
😱 А значит вам надо идти и улучшать процессы!
Если же вернуться к вопросу о том, а сколько надо данных для того, чтобы использовать Монте-Карло, то прямой ответ будет странным, на первый взгляд, - нисколько.
Вы эти данные можете моделировать через известные распределения, или взять похожий по структуре процесс и на основе его статистики использовать.
А дальше, чем больше достоверных данных, именно о вашем процессе, мы имеем, тем больше можем улучшать модель для прогнозирования и она будет давать больше точность.
Если мало данных, их можно интерполировать.
🦾 Сделал страничку на которой вы можете попробовать сделать интерполяцию данных для получения распределения Вэйбула.
👉 Вот эта страничка, попробуйте. Местами помог Nestor
Cтраница это частный пример, чтобы показать, как из небольшого набора данных можно было бы получить недостающие, для того, чтобы использовать далее в Монте-Карло
Конечно, чем меньше ваших данных или данных в виде "пилы” или смешанных мультимодальных данных (простите меня высшие силы), тем больше будет придумано, и тем меньше будет надежность результата вашего конечного расчета по Монте-Карло, при интерполяции.
В этом частном примере интерполяции сделано упрощение:
— Lead Time считается округленными по дням.
Интерполяция достраивает данные, используя формулу распределения Вэйбула подставляя вычисленные λ и k параметры распределения, на основе известных входных данных
Подкатом духота для упоротых:
В этом примере для получения λ и k параметра вэйбула, по входным данным, применены методы:
1. Агрессивное удаление выбросов
2. Робастные оценки центральной тенденции
3. Модифицированный метод моментов
4. Взвешенная функция правдоподобия
5. Градиентный спуск
Если вы используете дробные значения Lead Time, а не целые "дни", то для расчета пропущенных “корзин” (интервалов куда будут дополнятся данные) вам может понадобиться методики для автоматического поиска количества интервалов, это можно получить через методики:
- Правило Стёрджеса: Подходит для небольших наборов данных с нормальным распределением.
- Правило Фридмана-Дайакониса: Подходит для данных с выбросами или нестандартным распределением.
- Правило Скотта: Подходит для больших наборов данных.
- Квадратный корень: Простой метод, но менее точный
👉 Попробуйте разные данные для интерполяции.
💬 Расскажите насколько применим результат для последующего моделирования Монте-Карло, на ваш взгляд
💬 Позже обсудим критерии применимости их.
Вывод:
- Нет данных, не беда, бери примеры близкие
- Нет примеров - выведи сам
- Мало данных - интерполируй, визуально или применяя матан
- Любой расчет на основе недостаточности данных даёт квази результат 😏
И это тоже можно использовать.
Осознавая неточность, ориентируясь на вектора динамики результата.
А хвосты распределений — это индикатор проблем с которыми надо операционно и стратегически работать, а не препятствие к использованию моделирования.
Думаю, что саму идею изложил неплохо.
P.S. Научиться делать перемоделирование при пополнении ваших данных — динамики изменения Lending Zone, тоже показатель на сколько вы улучшились или ухудшились, хороший повод поговорить или эскалировать если что.
#артефакты
#интересное
#leadtime
#waibul
#Вэйбул
#МонтеКарло
По мотивам обсуждения из этого чата “Kanban Talks”, отмечу еще
(Там речь идет про использование Lead Time для понимания имеет смысл ли использовать Монте-Карло если мало данных или есть хвосты, по этому далее ответ напишу исходя из того, что вы применяете Lead Time в своей модели для прогнозирования)
Для применения Монте-Карло нужны хоть какие-то данные, и чем более достовернее они тем лучше.
При этом, если существуют длинные хвосты у Lead Time, нам это не мешает применять Монте-Карло, просто это покажет очень широкий Lending zone (диапазон решений - дат когда закончим).
Иначе говоря, у вашего процесса много рисков.
И это тоже можно использовать, чтобы очевидно показать проблему длинных хвостов сгенерировав результат через Монте-Карло, вы покажете на сколько большая проблема для результата.
😱 А значит вам надо идти и улучшать процессы!
Если же вернуться к вопросу о том, а сколько надо данных для того, чтобы использовать Монте-Карло, то прямой ответ будет странным, на первый взгляд, - нисколько.
Вы эти данные можете моделировать через известные распределения, или взять похожий по структуре процесс и на основе его статистики использовать.
А дальше, чем больше достоверных данных, именно о вашем процессе, мы имеем, тем больше можем улучшать модель для прогнозирования и она будет давать больше точность.
Если мало данных, их можно интерполировать.
🦾 Сделал страничку на которой вы можете попробовать сделать интерполяцию данных для получения распределения Вэйбула.
👉 Вот эта страничка, попробуйте. Местами помог Nestor
Cтраница это частный пример, чтобы показать, как из небольшого набора данных можно было бы получить недостающие, для того, чтобы использовать далее в Монте-Карло
Конечно, чем меньше ваших данных или данных в виде "пилы” или смешанных мультимодальных данных (простите меня высшие силы), тем больше будет придумано, и тем меньше будет надежность результата вашего конечного расчета по Монте-Карло, при интерполяции.
В этом частном примере интерполяции сделано упрощение:
— Lead Time считается округленными по дням.
Интерполяция достраивает данные, используя формулу распределения Вэйбула подставляя вычисленные λ и k параметры распределения, на основе известных входных данных
Подкатом духота для упоротых:
1. Агрессивное удаление выбросов
2. Робастные оценки центральной тенденции
3. Модифицированный метод моментов
4. Взвешенная функция правдоподобия
5. Градиентный спуск
- Правило Стёрджеса: Подходит для небольших наборов данных с нормальным распределением.
- Правило Фридмана-Дайакониса: Подходит для данных с выбросами или нестандартным распределением.
- Правило Скотта: Подходит для больших наборов данных.
- Квадратный корень: Простой метод, но менее точный
👉 Попробуйте разные данные для интерполяции.
💬 Расскажите насколько применим результат для последующего моделирования Монте-Карло, на ваш взгляд
Вывод:
- Нет данных, не беда, бери примеры близкие
- Нет примеров - выведи сам
- Мало данных - интерполируй, визуально или применяя матан
- Любой расчет на основе недостаточности данных даёт квази результат 😏
И это тоже можно использовать.
Осознавая неточность, ориентируясь на вектора динамики результата.
А хвосты распределений — это индикатор проблем с которыми надо операционно и стратегически работать, а не препятствие к использованию моделирования.
Думаю, что саму идею изложил неплохо.
P.S. Научиться делать перемоделирование при пополнении ваших данных — динамики изменения Lending Zone, тоже показатель на сколько вы улучшились или ухудшились, хороший повод поговорить или эскалировать если что.
#артефакты
#интересное
#leadtime
#waibul
#Вэйбул
#МонтеКарло
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Оптимальный размер команды какой он?
GPT технологии от Яндекса и Китайские други дают такой ответ:
………………………………………………………………
— Маленькие команды (3–7 человек)
Подходят для стартапов, Agile-проектов или задач с четко определенным объемом.
Плюсы: Быстрая коммуникация, гибкость, минимальная бюрократия.
Минусы: Риск перегрузки, ограниченная экспертиза в узких областях.
— Средние команды (8–15 человек)
Оптимальны для средних проектов, например, разработки продукта с несколькими модулями.
Плюсы: Баланс между специализацией и управляемостью.
Минусы: Требуют четкой структуры (например, разделения на подгруппы).
— Крупные команды (15+ человек)
Используются в корпорациях или для сложных систем (например, ERP-внедрение).
Плюсы: Широкая экспертиза, возможность параллельной работы над множеством задач.
Минусы: Риск бюрократии, замедление принятия решений.
………………………………………………………………
Давно известно, что кто-то где-то из Agile тусовки выразил фразу, что 7±2 это оптимальный размер команды.
В свое время, Сергей Баранов @sergey486 (Scrum Trek) как-то приходил к нам на внутренний митап и рассказывал про свои исследования,
где он подтверждал тезис о том, что 7 человек - самый оптимальный размер команды.
Но, к сожалению видео и этого выступления я запамятовал куда делось.
А вопрос на самом деле интересный, в том числе и для повышения эффективности работы компаний.
Из около-научного что мне удалось найти так это вот эту статью.
А ещё, при анализе графа связей, на своих данных, мы обнаружили, что мощность связей естественным образом растёт только до 7, а после 8, уже не даёт сильного прироста.
Получается экономический расчёт из статьи для коммерческих организаций подтверждается анализом на фактических данных.
Что дает нам эта информация?
Как минимум ответ, на вопрос:
— "А понадобятся ли дополнительные затраты на коммуникацию команд больше размера чем 7,8?", ответ будет: Да.
— "будет ухудшаться эффективность команды с увеличением роста?", теоретически да, фактически надо ещё проверить, как минимум определить процент исключений
#интересное
#teamsize
#agile
#статистика
#артефакты
GPT технологии от Яндекса и Китайские други дают такой ответ:
………………………………………………………………
— Маленькие команды (3–7 человек)
Подходят для стартапов, Agile-проектов или задач с четко определенным объемом.
Плюсы: Быстрая коммуникация, гибкость, минимальная бюрократия.
Минусы: Риск перегрузки, ограниченная экспертиза в узких областях.
— Средние команды (8–15 человек)
Оптимальны для средних проектов, например, разработки продукта с несколькими модулями.
Плюсы: Баланс между специализацией и управляемостью.
Минусы: Требуют четкой структуры (например, разделения на подгруппы).
— Крупные команды (15+ человек)
Используются в корпорациях или для сложных систем (например, ERP-внедрение).
Плюсы: Широкая экспертиза, возможность параллельной работы над множеством задач.
Минусы: Риск бюрократии, замедление принятия решений.
………………………………………………………………
Давно известно, что кто-то где-то из Agile тусовки выразил фразу, что 7±2 это оптимальный размер команды.
В свое время, Сергей Баранов @sergey486 (Scrum Trek) как-то приходил к нам на внутренний митап и рассказывал про свои исследования,
где он подтверждал тезис о том, что 7 человек - самый оптимальный размер команды.
Но, к сожалению видео и этого выступления я запамятовал куда делось.
А вопрос на самом деле интересный, в том числе и для повышения эффективности работы компаний.
Из около-научного что мне удалось найти так это вот эту статью.
А ещё, при анализе графа связей, на своих данных, мы обнаружили, что мощность связей естественным образом растёт только до 7, а после 8, уже не даёт сильного прироста.
Получается экономический расчёт из статьи для коммерческих организаций подтверждается анализом на фактических данных.
Что дает нам эта информация?
Как минимум ответ, на вопрос:
— "А понадобятся ли дополнительные затраты на коммуникацию команд больше размера чем 7,8?", ответ будет: Да.
— "будет ухудшаться эффективность команды с увеличением роста?", теоретически да, фактически надо ещё проверить, как минимум определить процент исключений
#интересное
#teamsize
#agile
#статистика
#артефакты
Как использовать граф взаимодействия сотрудников для проведения улучшений организации?
В 2023 имел честь вести трек на FlowDays23 и один из докладов там меня очень зацепил.
Доклад был от Павла Колосова @kolosovpavel
С навзанием "Как помочь организации работать в 2 раза быстрее. Или где искать причины низкой скорости?"
В докладе Павел рассказывал про свой метод анализа организации через статистику по которой строил графы связей команд.
Чем мне понравился доклад — это готовый метод для проведения изменений на основе данных и систематичность и научный подход Павла к исследованиям организации.
При прослушивании доклада Павла у него был описан опыт использования подхода, а после рекомендаций о том, что дофолрмулировав этапы и шаги
у него получается полноценный метод, он взялся доработать.
К моменту самого доклада Павел полностью оформил в полноценное решение в виде метода.
На своем примере он уже подтвердил работоспособность этого метода, которые он проводил в своей организации.
Построив граф связей Павел переодически отслеживал динамику изменения, выделяя ключевые проблемы через визуализацию графа.
Что позволяет
1. оценить процесс трансформации
2. явно визуализировать проблемные места коммуникаций
В базисе метода есть тезисы:
1. Оригинальная формулировка: «Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации», Мелвин Конвей
2. Современная трактовка: «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации», Рут Малан
Метод опирается на логику принятия решения:
Изменяем структуру → [Изменение в коммуникациях] → Изменение в процессах → Изменяется результат
Основные принципы метода Павла Колосова:
- Организация создает ценности за счет процессов. Процессы поддерживаются “встречами”
- Информация состоит из данных и эмоций
- Информации трансформируется с количеством узлов передачи и зависит от эмоционального состояния человека, достоверности и полнота информации может ухудшится
- Принятие и реализации управленческого решения зависит от достоверности и полноты информации у участников
- Любая коммуникация оставляет цифровой след (либо моделируется)
А вот про алгоритм метода, я думаю можно узнать у самого Павла.
Отмечу только, что в методе есть и такой прием - обнаружить Bus Fatcors через граф, и это будет точка откуда можно начать проводить изменения в улучшении этих взаимодействий.
Анализируя данные графов связей у нас, я сделал несколько своих предположений, чем же такой анализ может еще помочь,
кроме того, что изложил Павел в своем докладе:
- Наблюдать количественную динамику связей, если частота взаимодействия или количество ребер связей уменьшается - это плохой признак, высокая вероятность того, что и ухудшиться результат
- Сильная связь (жирные ребра) - показатель очень сильной команды, которая создаст с высокой вероятностью хороший результат
- Увеличение количества связей вероятно связано с тем, что сотрудник растет (важно отделить от не целевых взаимодействий)
Кажется утверждения очевидными, но все же надо закончить анализ и подтвердить фактами, по крайней мере по первой выборке пока наблюдения подтверждают тезисы, но для уверенного подтверждения нужно подготовить полноценный эксперимент.
🤔 Думаю, что в самое ближайшее время любые трансформации проводимые без численного анализа и анализа графов останутся анахронизмом.
❗️ По этому понимание статистики, работы с графами, data-инженеринга для Change Manager-ов это уже текущая реальность.
#мысливслух
#интересное
#changemanagement
#используястатистику
В 2023 имел честь вести трек на FlowDays23 и один из докладов там меня очень зацепил.
Доклад был от Павла Колосова @kolosovpavel
С навзанием "Как помочь организации работать в 2 раза быстрее. Или где искать причины низкой скорости?"
В докладе Павел рассказывал про свой метод анализа организации через статистику по которой строил графы связей команд.
Чем мне понравился доклад — это готовый метод для проведения изменений на основе данных и систематичность и научный подход Павла к исследованиям организации.
у него получается полноценный метод, он взялся доработать.
К моменту самого доклада Павел полностью оформил в полноценное решение в виде метода.
На своем примере он уже подтвердил работоспособность этого метода, которые он проводил в своей организации.
Построив граф связей Павел переодически отслеживал динамику изменения, выделяя ключевые проблемы через визуализацию графа.
Что позволяет
1. оценить процесс трансформации
2. явно визуализировать проблемные места коммуникаций
В базисе метода есть тезисы:
1. Оригинальная формулировка: «Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации», Мелвин Конвей
2. Современная трактовка: «Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации», Рут Малан
Метод опирается на логику принятия решения:
Изменяем структуру → [Изменение в коммуникациях] → Изменение в процессах → Изменяется результат
Основные принципы метода Павла Колосова:
- Организация создает ценности за счет процессов. Процессы поддерживаются “встречами”
- Информация состоит из данных и эмоций
- Информации трансформируется с количеством узлов передачи и зависит от эмоционального состояния человека, достоверности и полнота информации может ухудшится
- Принятие и реализации управленческого решения зависит от достоверности и полноты информации у участников
- Любая коммуникация оставляет цифровой след (либо моделируется)
А вот про алгоритм метода, я думаю можно узнать у самого Павла.
Отмечу только, что в методе есть и такой прием - обнаружить Bus Fatcors через граф, и это будет точка откуда можно начать проводить изменения в улучшении этих взаимодействий.
Анализируя данные графов связей у нас, я сделал несколько своих предположений, чем же такой анализ может еще помочь,
кроме того, что изложил Павел в своем докладе:
- Наблюдать количественную динамику связей, если частота взаимодействия или количество ребер связей уменьшается - это плохой признак, высокая вероятность того, что и ухудшиться результат
- Сильная связь (жирные ребра) - показатель очень сильной команды, которая создаст с высокой вероятностью хороший результат
- Увеличение количества связей вероятно связано с тем, что сотрудник растет (важно отделить от не целевых взаимодействий)
Кажется утверждения очевидными, но все же надо закончить анализ и подтвердить фактами, по крайней мере по первой выборке пока наблюдения подтверждают тезисы, но для уверенного подтверждения нужно подготовить полноценный эксперимент.
🤔 Думаю, что в самое ближайшее время любые трансформации проводимые без численного анализа и анализа графов останутся анахронизмом.
#мысливслух
#интересное
#changemanagement
#используястатистику
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
Важнейшая стадия изменения в крупной ИТ компании – формулирование мета-языка процессов управления.
Одним из важнейших этапов в улучшении процессов в нашей компании было началом формирования мета-языка который позволяет оперировать сущностями в построении логики процессов.
Мета-язык, это язык второго порядка, который описывает логику и методы языка, на котором строится уже взаимодействие.
На первых парах, в следствии хорошего маркетинга казалось, что таким мета-языком может служить Agile или Scrum,
Что на самом деле являются совершенно разноуровневыми понятиями.
Между ними явно не хватает более обширного "эфирной" субстанции – способа описать мост между философией и методиками. А проектное управление со своей сложной структурой, не подходит на эту роль.
Мало того, области как самого Agile, так и Scrum явно ограниченны.
Что приводило к интересным дискуссиям которые чем-то походили на эксперименты команды Пиаже с Бушменом.
А эксперимент был жутко интересный. В середине 20 века Жан Пиаже, швейцарский психолог, нашел в Африке бушмена, который ни разу в жизни не видел воду в больших количествах. Посадил его в закрытый вагон и привез прямо к берегу моря.
Пиаже предполагал, что бушмен, увидя столько воды, будет в восторге, начнет ее трогать, радоваться, или наоборот перепугается и т.д.
Но и он и его помощники были шокированы тем, что бушмен со спокойным видом просто ходил по берегу. Оказалось, что он не видит этой воды. Его заставляли в неё заходить, показывали волны, говорили куда смотреть, хлопали по поверхности воды, но все было бесполезно Бушмен видел всё, кроме моря.
Море он не замечал не потому, что не видели его глаза. А потому, что какое-то внутреннее свойство его психики отключало возможность восприятия объективного мира.
Мы видим только то, что позволяет нам наша психика. Все, что в ней не укладывается и требует жесткого переосмысления своего чувственного опыта, для нас просто перестает существовать.
И надо понимать, что чувство недосказанности и нехватки базы для объяснения определённых явлений было у многих, но не хватало такого мета-языка.
При том, что этот мета-язык должен обладать достаточно простыми формами и способностью транзитивности при употреблении его для разных случаев построения логики языка конкретного процесса.
Мне повезло побывать студентом у @pimenaus по KMP, и далее более глубоко изучить Kanban-метод.
И оказалось, что понятийный аппарат из Kanban-метода при применении этого метода на практике отлично служат таким мета-языком.
Фактически разбирая любой процесс через визуализацию, применение таких понятий как:
- состояние
- буфер состояние
- активное состояние
- WIP, WIP-ограничение
- каденция
- сервис
- клиент
- Кабан метрики
- ...
Эти понятия являются более простыми формами чем другие способы описания для процессов в управлении интеллектуальным трудом
И позволяют делать анализ систем в которых существует свой язык, например тот же Scrum, Scrumban или иной готовый фреймворк описания существующего процесса.
Применение Кабан-метода в нашей группе компаний больше всего пользы принёс как мета-язык. И это я осознаю сейчас ретроспективно.
А так же осознаю, что это был важнейший этап, который позволяет применять сейчас к формированию процессов не локальный диалект, применимый в области отдельного процесса, а взаимнообобщающую форму позволяющую для более высоких уровней абстракций в которых строится мидл и стратегическое управление обладать тем самым "эфиром" для построения систем как сбора и анализа метрик, так и формирования управления и обмена опытом, без проблем в связке от философии к интерпретации системы управления.
И теперь понимание этого мета-языка становится важным для любого кто входит в культуру управления ИТ.
Этот мета-язык упрощает в том числе и разработку инструментов для управления интеллектцальным трудом.
Меня удивляет тот факт, что в некоторых местах я ещё встречаю рядом написанные слова Scrum и Kanban.
Буду надеяться что этот пост позволит глубже понять роль Kanban-метода. Особенно тем кто живет в другой парадигме.
#интересное
#мысливслух
Одним из важнейших этапов в улучшении процессов в нашей компании было началом формирования мета-языка который позволяет оперировать сущностями в построении логики процессов.
На первых парах, в следствии хорошего маркетинга казалось, что таким мета-языком может служить Agile или Scrum,
Что на самом деле являются совершенно разноуровневыми понятиями.
Между ними явно не хватает более обширного "эфирной" субстанции – способа описать мост между философией и методиками. А проектное управление со своей сложной структурой, не подходит на эту роль.
Мало того, области как самого Agile, так и Scrum явно ограниченны.
Что приводило к интересным дискуссиям которые чем-то походили на эксперименты команды Пиаже с Бушменом.
Пиаже предполагал, что бушмен, увидя столько воды, будет в восторге, начнет ее трогать, радоваться, или наоборот перепугается и т.д.
Но и он и его помощники были шокированы тем, что бушмен со спокойным видом просто ходил по берегу. Оказалось, что он не видит этой воды. Его заставляли в неё заходить, показывали волны, говорили куда смотреть, хлопали по поверхности воды, но все было бесполезно Бушмен видел всё, кроме моря.
Море он не замечал не потому, что не видели его глаза. А потому, что какое-то внутреннее свойство его психики отключало возможность восприятия объективного мира.
Мы видим только то, что позволяет нам наша психика. Все, что в ней не укладывается и требует жесткого переосмысления своего чувственного опыта, для нас просто перестает существовать.
И надо понимать, что чувство недосказанности и нехватки базы для объяснения определённых явлений было у многих, но не хватало такого мета-языка.
При том, что этот мета-язык должен обладать достаточно простыми формами и способностью транзитивности при употреблении его для разных случаев построения логики языка конкретного процесса.
Мне повезло побывать студентом у @pimenaus по KMP, и далее более глубоко изучить Kanban-метод.
И оказалось, что понятийный аппарат из Kanban-метода при применении этого метода на практике отлично служат таким мета-языком.
Фактически разбирая любой процесс через визуализацию, применение таких понятий как:
- состояние
- буфер состояние
- активное состояние
- WIP, WIP-ограничение
- каденция
- сервис
- клиент
- Кабан метрики
- ...
Эти понятия являются более простыми формами чем другие способы описания для процессов в управлении интеллектуальным трудом
И позволяют делать анализ систем в которых существует свой язык, например тот же Scrum, Scrumban или иной готовый фреймворк описания существующего процесса.
Применение Кабан-метода в нашей группе компаний больше всего пользы принёс как мета-язык. И это я осознаю сейчас ретроспективно.
А так же осознаю, что это был важнейший этап, который позволяет применять сейчас к формированию процессов не локальный диалект, применимый в области отдельного процесса, а взаимнообобщающую форму позволяющую для более высоких уровней абстракций в которых строится мидл и стратегическое управление обладать тем самым "эфиром" для построения систем как сбора и анализа метрик, так и формирования управления и обмена опытом, без проблем в связке от философии к интерпретации системы управления.
И теперь понимание этого мета-языка становится важным для любого кто входит в культуру управления ИТ.
Этот мета-язык упрощает в том числе и разработку инструментов для управления интеллектцальным трудом.
Меня удивляет тот факт, что в некоторых местах я ещё встречаю рядом написанные слова Scrum и Kanban.
Буду надеяться что этот пост позволит глубже понять роль Kanban-метода. Особенно тем кто живет в другой парадигме.
#интересное
#мысливслух
🔥6👍1
📘Книга: "Методы принятия решений".
Постоянно занимаюсь самообразованием, при этом ищу источники для вдохновения и структурированием своих знаний.
В области управления мне очень понравились книги из серии "Harvard Business Review 10 лучших статей".
"Методы принятия решений" – это первая книга из этой серии, которая привлекая моё внимание.
Оглавление:
1. Скрытые ловушки принятия решений
2. Перед тем как принять важное решение
3. Как избежать катастрофы
4. Как преодолеть пассивность
5. Неизвестные факты о принятии решений
6. За кем последнее слово
7. Насколько вы (не)этичны
8. Принятие решений: совершенствуем процесс
9. Почему хорошие руководители принимают плохие решения
10. Хватит строить планы, принимай решения.
У каждой главы свои авторы.
Сама по себе книга имеет хорошую ёмкость информации к объёму и не раздутые примеры, что разительно отличается от воденистых трудов западных книгоиздателей.
Хорошо охватывает основные базисы по проблеме принятия решений, такие как
- контекст в котором оказывается принимающий решение, психо-эмоцмональное состояние
- фактическая неэтичность, присущая абсолютно всем, сложенная в следствии вашего формирования как личности в сообществах в которых жили
- краткие примеры из книги "Думай медленно, решай быстро"
- влияние окружающих
- эффекты: владения, затрат, избегания неудач, привязки
И другие.
Книга, как сборник хороших статей, мне очень понравилась не только концентрацией информации, но и изложенными способами решения проблем с которыми можно столкнуться при пинятии решений.
Основные обсуждаемые вопросы:
1. Рациональные и аналитические методы
- Использование данных, SWOT-анализа, дерева решений.
- Оценка рисков и стоимостного анализа.
2. Психологические аспекты принятия решений
- Когнитивные искажения (например, подтверждение, избыточная уверенность).
- Роль интуиции и эмоций.
3. Работа в условиях неопределенности
- Стратегии для ситуаций с ограниченной информацией.
- Сценарное планирование и адаптивные подходы.
4. Коллективное принятие решений
- Методы мозгового штурма, фасилитация дискуссий.
- Преодоление конфликтов и группового мышления.
5. Этика и ответственность
- Баланс между прибылью и социальными последствиями.
- Долгосрочные vs краткосрочные результаты.
6. Технологии и инновации
- Использование AI и big data в анализе.
- Цифровые инструменты для моделирования решений.
Чем и кому полезна книга, как я считаю:
- Помогает структурировать процесс принятия решений, избегая распространенных ошибок.
- Дает инструменты для анализа сложных ситуаций и работы с данными.
- Рассказывает как управлять рисками и неопределенностью.
- Указывает на особенности в командной работе и этического подхода.
- Подойдет руководителям, менеджерам и предпринимателям, стремящимся повысить эффективность в области принятия решений.
Рекомендую иметь как настольную книгу.
#прокниги
Постоянно занимаюсь самообразованием, при этом ищу источники для вдохновения и структурированием своих знаний.
В области управления мне очень понравились книги из серии "Harvard Business Review 10 лучших статей".
"Методы принятия решений" – это первая книга из этой серии, которая привлекая моё внимание.
Оглавление:
1. Скрытые ловушки принятия решений
2. Перед тем как принять важное решение
3. Как избежать катастрофы
4. Как преодолеть пассивность
5. Неизвестные факты о принятии решений
6. За кем последнее слово
7. Насколько вы (не)этичны
8. Принятие решений: совершенствуем процесс
9. Почему хорошие руководители принимают плохие решения
10. Хватит строить планы, принимай решения.
У каждой главы свои авторы.
Сама по себе книга имеет хорошую ёмкость информации к объёму и не раздутые примеры, что разительно отличается от воденистых трудов западных книгоиздателей.
Хорошо охватывает основные базисы по проблеме принятия решений, такие как
- контекст в котором оказывается принимающий решение, психо-эмоцмональное состояние
- фактическая неэтичность, присущая абсолютно всем, сложенная в следствии вашего формирования как личности в сообществах в которых жили
- краткие примеры из книги "Думай медленно, решай быстро"
- влияние окружающих
- эффекты: владения, затрат, избегания неудач, привязки
И другие.
Книга, как сборник хороших статей, мне очень понравилась не только концентрацией информации, но и изложенными способами решения проблем с которыми можно столкнуться при пинятии решений.
Основные обсуждаемые вопросы:
1. Рациональные и аналитические методы
- Использование данных, SWOT-анализа, дерева решений.
- Оценка рисков и стоимостного анализа.
2. Психологические аспекты принятия решений
- Когнитивные искажения (например, подтверждение, избыточная уверенность).
- Роль интуиции и эмоций.
3. Работа в условиях неопределенности
- Стратегии для ситуаций с ограниченной информацией.
- Сценарное планирование и адаптивные подходы.
4. Коллективное принятие решений
- Методы мозгового штурма, фасилитация дискуссий.
- Преодоление конфликтов и группового мышления.
5. Этика и ответственность
- Баланс между прибылью и социальными последствиями.
- Долгосрочные vs краткосрочные результаты.
6. Технологии и инновации
- Использование AI и big data в анализе.
- Цифровые инструменты для моделирования решений.
Чем и кому полезна книга, как я считаю:
- Помогает структурировать процесс принятия решений, избегая распространенных ошибок.
- Дает инструменты для анализа сложных ситуаций и работы с данными.
- Рассказывает как управлять рисками и неопределенностью.
- Указывает на особенности в командной работе и этического подхода.
- Подойдет руководителям, менеджерам и предпринимателям, стремящимся повысить эффективность в области принятия решений.
Рекомендую иметь как настольную книгу.
#прокниги
👍8❤2
Автор Лю Цисинь.
С детства люблю научную фантастику за то, что удивительным образом меняет сознание и раздвигает границы возможного познания.
Эти произведения открывают восприятие от ретроспективного взгляда на жизнь в сторону будущего, возможностей и новых идей, которые начинают разворачиваться в удивительный макрокосмос воображения, словно разлитое из бидона молоко в небо древними богами превратив наблюдаемое небо в россыпь удивительных загадок из галактик и звёзд.
Лю Цисинь в книге "Задача трех тел" пробегает по самым смелым идеям современности затрагивая сложные ноты не столь далёкого прошлого, обличая при этом структуры социумов которые готовы верить в сверхестественное как в горя от ума.
Изложенные идеи в книги так легко переносятся на современную историю, что местами жутковато.
В этой книге затронуты проблемные ноты как физики, математики, астрологии, так и методики управления социумом, в том числе и формирование радикализма, и показано к чему это может приводить.
Это произведение комбинаторно затрагивает разные области наук, и возможно более полно может раскрыться тем кто так же разнообразно пробует изучать этот мир.
Такие произведения сложно создавать, а уж тем более гармонично вплетать читателя в аллюзию истории так, что буквально в моменте переживаешь как текущую реальность.
Нужно быть разносторонее развитым на порядок больше чем современный интеллектуал обыватель, и интересоваться совершенно разными науками от истории до квантовой физики, чтобы быть автором таких произведений.
Прочитав эту книгу взахлеб, я осознаю, что всю глубину произведения довольно сложно понять, если не пройти своим любопытством самому по областям затронутых наук Лю Цисинем, а это не только физика, астрология, мат. анализ, история, но и идеи тьюринга, формации социологии, в том числе методики формирования религиозных сект, и другое.
Автор задел много паттернов из поведения сообществ и дал анализ проблемы столкновения культур. Через это произведение буквально сейчас можно сделать анализ текущих происходящих событий, от деградации научного потенциала, до столкновений имеющих более развитый НОК против менее развитых цивилизаций.
Про книгу узнал из одного интервью Сурдина, где он о ней упоминал.
Считаю, что среди научной фантастики это пока лучшее что я читал.
А по эмоциям – как будто заново открыл для себя научную фантастику, чем то схоже с впечатлением от 20000 лье под водой в далёком детстве.
Это не произведение из Голливуда, где очень любят хиппи енды, но и этим книга не заканчивается, это только начало трилогии
#прокниги
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
В интерактивном справочнике всех "Канбан Метрик" исправил ссылки, так чтобы кликая по ним можно было перемещаться по доске без открытия новой вкладки.
При этом команда Unidraw.io добавила мини карту, и навигироваться по справке стало удобнее.
Напомниаю, что это наш коллективный проект от сообщества Канбан Толк, и в нем так же можно поучаствовать в улучшении этого материала, обращайтесь ко мне если хотите стать со-автором.
Зачем нужна эта интерактивная карта?
Вы всегда можете сослаться на эту справку при обсуждении метрик, или в поиске решения и ответов для самих себя
При этом команда Unidraw.io добавила мини карту, и навигироваться по справке стало удобнее.
Напомниаю, что это наш коллективный проект от сообщества Канбан Толк, и в нем так же можно поучаствовать в улучшении этого материала, обращайтесь ко мне если хотите стать со-автором.
Зачем нужна эта интерактивная карта?
Вы всегда можете сослаться на эту справку при обсуждении метрик, или в поиске решения и ответов для самих себя
👍11❤3🔥2
Приняли мой доклад на Codefest 15.
Мой доклад будет о "Проблемах поиска эффективности ИТ компаний".
Та тема, которая победила в последнем опросе в этом канале.
После доклада, буду готовить и статью.
Тезисы
Не секрет, что 2025 год станет годом оптимизаций. Слово «эффективность» сегодня в приоритете у руководителей всех уровней, однако не всегда ясно, что именно под ним подразумевается и как формулировать тезисы, которые помогут достичь поставленных целей.
Давайте разберемся с понятием эффективности:
— Где находятся точки соприкосновения разных уровней компании в «вероятностном поле» решений «Эффективности»?
— Возможно ли в принципе повысить эффективность в области вашего влияния?
— Какие инструменты помогут выявить эти точки и создать руководство к действию для повышения результативности бизнеса?
В докладе я раскрою:
— Как связать финансовые показатели (P&L) с операционными процессами (L) и правильно оценить ценность решений (P), для команд разрабатывающие продукты
— Как определять эффективность для команд создающие внетренние сервисы и не связанные на прямую с бизнесом
— Как влияет размер команды на эффективность результата
— Как метрики ИТ-разработки влияют на общую эффективность компании, и какие из них стоит выбрать в вашем контексте.
— Определим, что поиск эффектисности — это вероятностное поле поиска решений
— А так же узнаем, что повышение эффективности может лежать за пределами вашей области влияния
Для кого этот доклад:
— Тимлиды, Project Manager’ы и Scrum-мастера;
— Все, кто работает на стыке бизнеса и разработки.
Что вы узнаете:
— Как определить понятие «эффективность» связанную с вашими целями для вашей ИТ-команды
— Как выбрать метрики процессов, которые влияют на результат, а не создают иллюзию контроля.
В итоге вы получите:
- Гайд вопросов для ретроспективы, которые помогут вам лучше формулировать гипотезы для улучшения результата ваших команд.
- Готовые примеры наборов метрик, для анализа и поиска точек эффективности.
#доклады
Увидимся в Новосибирске?!
Мой доклад будет о "Проблемах поиска эффективности ИТ компаний".
Та тема, которая победила в последнем опросе в этом канале.
После доклада, буду готовить и статью.
Не секрет, что 2025 год станет годом оптимизаций. Слово «эффективность» сегодня в приоритете у руководителей всех уровней, однако не всегда ясно, что именно под ним подразумевается и как формулировать тезисы, которые помогут достичь поставленных целей.
Давайте разберемся с понятием эффективности:
— Где находятся точки соприкосновения разных уровней компании в «вероятностном поле» решений «Эффективности»?
— Возможно ли в принципе повысить эффективность в области вашего влияния?
— Какие инструменты помогут выявить эти точки и создать руководство к действию для повышения результативности бизнеса?
В докладе я раскрою:
— Как связать финансовые показатели (P&L) с операционными процессами (L) и правильно оценить ценность решений (P), для команд разрабатывающие продукты
— Как определять эффективность для команд создающие внетренние сервисы и не связанные на прямую с бизнесом
— Как влияет размер команды на эффективность результата
— Как метрики ИТ-разработки влияют на общую эффективность компании, и какие из них стоит выбрать в вашем контексте.
— Определим, что поиск эффектисности — это вероятностное поле поиска решений
— А так же узнаем, что повышение эффективности может лежать за пределами вашей области влияния
Для кого этот доклад:
— Тимлиды, Project Manager’ы и Scrum-мастера;
— Все, кто работает на стыке бизнеса и разработки.
Что вы узнаете:
— Как определить понятие «эффективность» связанную с вашими целями для вашей ИТ-команды
— Как выбрать метрики процессов, которые влияют на результат, а не создают иллюзию контроля.
В итоге вы получите:
- Гайд вопросов для ретроспективы, которые помогут вам лучше формулировать гипотезы для улучшения результата ваших команд.
- Готовые примеры наборов метрик, для анализа и поиска точек эффективности.
#доклады
Увидимся в Новосибирске?!
CodeFest 15 / 31 мая-1 июня 2025
CodeFest 15. Юбилейный!
👍17
А вот и наконец на сайте CodeFest вывели тезисы моего будущего доклада
https://15.codefest.ru/lecture/3165
#доклады
https://15.codefest.ru/lecture/3165
#доклады
CodeFest 15 / 31 мая-1 июня 2025
Проблемы поиска эффективности в ИТ-компаниях
Management. Павел Ахметчанов, Т-Банк
👍6
Игорь Моисеев написал статью
"К управлению задачами через статистику"
в рамках которой сделал разбор моей статьи на Хабр.
Считаю, что он достаточно интересный сделал разбор, и тем кто занимается статитстикой процессных метрик точно будет полезной
https://habr.com/ru/articles/802361/
"К управлению задачами через статистику"
в рамках которой сделал разбор моей статьи на Хабр.
Считаю, что он достаточно интересный сделал разбор, и тем кто занимается статитстикой процессных метрик точно будет полезной
https://habr.com/ru/articles/802361/
Хабр
К управлению задачами через статистику
О чём это и зачем? Данную статью меня побудило написать знакомство с несколькими статьями и лекциями Павла Ахметчанова ( этой , например), коего я и приглашаю в первую очередь к дискуссии. :)...
👍3
Сегодня посетил ярмарку интеллектуальных книг
https://moscowbookfair.ru/
С целью таки получить книгу Вячаслава Дубынина с подписью.
Цель выполнена.
Но и Ярмарка интересная, столько очкариков в одном месте давненько не видел (сам очкарик так же)
К сожалению на такую Ярмарку нужно много энергии, чтобы проходить мимо кладези такого количества интересных книг.
По сим решил идти от чувства, а чего хочу в ближайшее время для своего развлечения.
И вот собственно на чем остановился.
#прокниги
https://moscowbookfair.ru/
С целью таки получить книгу Вячаслава Дубынина с подписью.
Цель выполнена.
Но и Ярмарка интересная, столько очкариков в одном месте давненько не видел (сам очкарик так же)
К сожалению на такую Ярмарку нужно много энергии, чтобы проходить мимо кладези такого количества интересных книг.
По сим решил идти от чувства, а чего хочу в ближайшее время для своего развлечения.
И вот собственно на чем остановился.
#прокниги
❤🔥3