У меня в отделе появился Project Manager (буквально родился)
Можете посоветовать прям хорошо описанный трек по развитию PM?

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

Спасибо

#мысливслух

Добыл картинку из внутреннего чатика.

В самой картинке и смех и грех.
Но, есть важная деталь – лучше таблички для контроля выполнения работ ничего не придумали, и в общем контроля на проектах бальшого масштаба.

Коллега мой занимаясь одним из самых больших проектов, где взаимодействует большое количество команд перепробовал разное.
И dependency table, и Gantt, и задачки на одной доске Jira.
Но, пришел к выводу, что на больших масштабах лучше таблички, с указанием отвественных и сроков, в том числе когда с ними нужно провзаимодействовать ничего не нашел.

#мысливслух
#забавное

Лестница в Т, считает формулу продуктивности так.

Мне кажестя тут куча ошибок

Это фото с прошлого года.
И меня тут можно найти

В этом году так же подал заявку. Если примут, то будет интересное путешествие до Новосибирску

#забавное

👉 На доске всех Kanban метрик, сегодня добавил объяснение того как на Aging Chart расчитываются цветные области.

Aging Chart — один из самых удобных форм отслеживания операционной работы, на мой взгляд, для руководителя.

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

Что позволяет очень быстро выявить аномалии.

Однако не всем ясно как именно он считатьеся, по этому добавил чуточку более подробную схему объяснения.

#артефакты

Про обозначение тегов в этом канале

Пока все мужчины поздравляют своих дам с днем 8 марта.

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

#проинструменты - что может пригодиться в работе (не про теорию, а про инструменты для практики)

#мысливслух - нечто быстро выдуманное или пришедшее на ум, не факт что несет полезность

#забавное - шутки прибаутки

#артефакты - это пост с ссылками за которыми может быть для вас полезная информация

#благодарности - эмоциональное выражение благодарности

#интересное - про события которая может быть интересны

#доклады - про доклады как мои так и не мои

#подкаст - про подкасты и о чем там было

#задачки - посты с задачками за ответы на которые могут будут подарки

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

#уменячтотополучилось - хвастаюсь, чтобы не было так стеснительно вставляю этот тег

#прокниги - посты связанные с книгами

Продолжаю улучшать информацию Kanban-метрики на доске Unidraw.

- Обновил “Глоссарий”
- Исправил несколько ошибок в текстах, в том числе заменил слово “задачи” на “рабочий элемент”
- Упростил для восприятия текст “One-Time Delivery”

Напомню, что если хочешь стать соавтором, то напиши мне, я добавлю тебя в редакторы.

Использование Unidraw для этой справочной информации позволяет сделать две удобные вещи:
1. Предоставить информацию бесплатно
2. Кидать коллегам ссылки прямо на конкретные примеры.

Для того чтобы скинуть ссылку на нужную метрику, выделите фрейм с ней, нажмите ПКМ (правая кнопка мыши) вызвав контекстное меню и в нем нажмите “Скопировать ссылку на объект”.

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

Пример на картинке

#артефакты

Чем и кому полезна книга "Код: Тайный язык информатики"?

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

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

Понимание этих базовых вещей позволяет находить не тривиальные решения для талантливых ребят.

И потому я бы рекомендовал коллегам 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. Графическая революция

#прокниги

Что не так с методом Монте-Карло, почему он такой разный?

В личные сообщения я получаю иногда вопросы которые связаны с непониманием того, как действует метод Монте-Карло.

Давайте разберемся что с ним не так.

Монте-Карло — это метод, который появился благодаря азартным играм, и довольно часто используется, например в покере Холдем в уме, например для ответа на вопрос: "У меня на руках Туз и 7 на префлопе, стоит ли играть с ними если за столом еще 10 человек?".

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

Вероятность выиграть с разномастными A и 7 на префлопе против 9 оппонентов в Техасском Холдеме составляет примерно 7-8%. Это значение учитывает equity (шансы на победу) руки A7o против случайных рук остальных игроков

Сам по себе метод очень прост в нем оговаривается главное правило:
— Повторить расчеты большое множество раз, и сопоставить сколько раз выпало событие интересующего вас варианта к сумме всех событий определяя вероятность получения результата.

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

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

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

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

Добавляя разные случайные величины (риски) в свою модель, и увидеть как может меняться результат вычислений.

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

Моделирование может помочь так же в выявлении совокупности рисков которые могут влиять на результат.

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

Решая обратную задачу с Монте-Карло, можно ответить на вопрос:
— Как понять какие из рисков наиболее сильно влияют или не влияют на результат выполнения в срок задач?

Давайте расширим спектр вопросов, в исследуемом стахостическом процессе, на которые можно отвечать применяя метод Монте-Карло:
— При условии имеющихся ресурсов когда закончим проект/задачу?
— Сколько мне нужно ресурсов, чтобы успеть в срок?
— Какие риски наиболее сильно влияют на результат?
— Как лучше произвести комбинаторику построения критической цепи для уменьшения рисков (привет PERT)?
— Как измениться динамика завершения проекта/задачи если будет изменяться вероятность возникновения тех или иных рисков со временем?

Для ответа на все эти вопросы, вы будете собирать разную модель для расчетов.

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

#артефакты
#интересное
#МонтеКарло

Моделировать можно в том числе и данные которых у вас может быть не достаточно.

Что делать если данных не достаточно для Монте-Карло?

Вы можете прибегнуть к использованию схожих моделей. Например для Lead Time известно, что подходит распределение Вэйбула, по этому можно взять данные которые у вас есть и сделать интерполяцию их подгоняя под них параметры распределения, чтобы понять наиболее вероятный срок завершения задач.
А вот для Throughput больше подходит нормально распределение, и если у вас не достаточно данных по Throughput вы можете взять аналогию нормального распределения и использовать его.

А делае уже с большим набором данных вы можете применить метод Монте-Карло для ответов на свои вопросы.

И так, сам метод Монте-Карло совершенно не говорит о том:
— на какой вопрос вы хотит ответить, прмиеняя его
— какую модель вы для отета на этот вопрос применяете

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

Ответы на вопросы: "Какие риски влияют или не влияют на результат?" — это более глубокое исследование вашего процесса при помощи метода Монте-Карло.

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

Что, несомненно, является более сложной и интересной задачей.

Более подробно о проблеме я описал на Unidraw.io о том как понять Монте-Карло

#интересное
#артефакты
#МонтеКарло

Можно ли использовать Монте-Карло на основе Throughput, если Lead Time с жирными хвостами?

Разбор по мотивам обсуждения из чатика "Kanban Talks".

И так, исходим из предположения, что в моделировании используется только Throughput.
При этом используем допущение, что все задачи попадающие в процесс завершаются (не выбрасываются).

Можно ли использовать данные по Throughput для моделирования Монте-Карло, в случае наличия жирных хвостов (есть задачи которые залёживаються в процессе)?

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

Система получается закрытой, а процесс сходящимся.

Причём так как мы используем конкретный набор задач, и с достаточной стабильным WIP, прогноз будет вполне точным.

И даже простая экстраполяция графика касательных к CFD диаграмме по завершением задачам может дать примерные сроки завершения.

Эта максима, от которой дальше можно двигаться в рассуждения.

Но, как же так?
Ведь есть долгие задачи?

Да, но в система стабильна относительно пропускной способности, и эти долгие задачи это лишь признак их типовой обособленности.

Это просто другой тип задач.

Даже если используем моделирование на основании ограничения WIP, и Lead Time, мы так же получим сходящийся результат в конкретные сроки, при правильном подборе WIP, примерно в те же, что и с чисто Throughput.

Идея в том, что моделирование будет строиться от объёма который надо выполнить и характеристики либо пропускной способности либо WIP и Lead Time, отвечая на вопрос: а когда выполним этот объем данных?

А вот если мы задаёмся вопросом — когда конкретная задача будет выполнена?

То тут как раз нас ожидают проблемы.
Очевидный ответ будет — во всем диапазоне сроков по распределению Lead Time. Увы. И то, если в LT достаточно данных для такого ответа.

Ок, а что если наша система не замкнутая, а объем меняется?
Или, у нас есть процесс по удалению задач из процесса?

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

Итог:
— Если система стабильна по пропускной способности и объем задач конечен, то прогноз будет хорошим, для оценки сроков по завершению совокупности объёма
— Для оценки сроков по конкретной задаче, мы действительно будем испытывать трудности

Дополнительно:
В случае изменения входящего объёма и изменения объёма который дропаеться, для точности оценки нужно вносить функцию оценки сходимости, которая будет отвечать на вопрос: "при какой динамике добавления и удаления из процесса задач, мы можем успеть к сроку".

Однако, и её можно свести к вопросу о "получения диапозона дат завершеия всего объема", если задать вероятности появления/дропа новых задач и какого объёма, как вам уже знакомая работа с рисками. И ответ вполне может быть (бесконечность, для расходящегося процесса).

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

В случае если вы наблюдайте динамику роста рисков (или в общем объёма повышения задач относительно завершения) вот точно надо принимать меры, по сдерживанию динамики и приведению её в порядок – сведению к динамике решаемых задач.
Либо увеличению динамики решаемых задач, так чтобы она покрывала и риски.

Сейчас, наверное посмотрите на свое CFD, и скорее всего сядите подумать, чего делать с эти растущим бэклогом?
- что от туда дропать?
- нанимать ли ещё людей?
- автоматизировать ли что-то?
- отказаться ли от какого-то функционала фокусируясь на важном в рамках объёма возможностей?
- а что в этом всем важное?
- можете ли себе позволить отказаться, если рыночек требует?

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

#интересное
#throughput
#МонтеКарло

Оптимальный размер команды какой он?

GPT технологии от Яндекса и Китайские други дают такой ответ:
………………………………………………………………
— Маленькие команды (3–7 человек)
Подходят для стартапов, Agile-проектов или задач с четко определенным объемом.
Плюсы: Быстрая коммуникация, гибкость, минимальная бюрократия.
Минусы: Риск перегрузки, ограниченная экспертиза в узких областях.

— Средние команды (8–15 человек)
Оптимальны для средних проектов, например, разработки продукта с несколькими модулями.
Плюсы: Баланс между специализацией и управляемостью.
Минусы: Требуют четкой структуры (например, разделения на подгруппы).

— Крупные команды (15+ человек)
Используются в корпорациях или для сложных систем (например, ERP-внедрение).
Плюсы: Широкая экспертиза, возможность параллельной работы над множеством задач.
Минусы: Риск бюрократии, замедление принятия решений.
………………………………………………………………

Давно известно, что кто-то где-то из Agile тусовки выразил фразу, что 7±2 это оптимальный размер команды.

В свое время, Сергей Баранов @sergey486 (Scrum Trek) как-то приходил к нам на внутренний митап и рассказывал про свои исследования,
где он подтверждал тезис о том, что 7 человек - самый оптимальный размер команды.

Но, к сожалению видео и этого выступления я запамятовал куда делось.

А вопрос на самом деле интересный, в том числе и для повышения эффективности работы компаний.

Из около-научного что мне удалось найти так это вот эту статью.

А ещё, при анализе графа связей, на своих данных, мы обнаружили, что мощность связей естественным образом растёт только до 7, а после 8, уже не даёт сильного прироста.

Получается экономический расчёт из статьи для коммерческих организаций подтверждается анализом на фактических данных.

Что дает нам эта информация?
Как минимум ответ, на вопрос:
— "А понадобятся ли дополнительные затраты на коммуникацию команд больше размера чем 7,8?", ответ будет: Да.
— "будет ухудшаться эффективность команды с увеличением роста?", теоретически да, фактически надо ещё проверить, как минимум определить процент исключений

#интересное
#teamsize
#agile
#статистика
#артефакты