Как обещал, добавил FAQ в комментариях к посту у себя в тг: https://t.me/managershield/21

гипотезы это хорошо, регулярно их сам выдвигаю) попробуйте проверить, когда появится возможность! Единственное, скажу, что без контекста о системе, это будет сверический конь в ваккуме. От того с чем вы имеете дело очень многое зависит. Я кстати не видел еще кейсов, чтобы ограничивали пропускную способность вконце, обычно это как раз вначале, ДО тестирования, которое часто узкое место. И все этапы до него ограничиваются как раз чтобы не заваливать бедных qa:)

Дмитрий, ваши слова многое значат для меня, спасибо! Продолжайте читать, делиться своим впечатлением и вопросами)

По поводу 3 и 4 пунктов, у вас довольно много высказываний, о которых я мог бы что-то сказать. Скажите, а какая у вас сейчас дилемма, связанная с этим, есть на работе? Возможно, так я буду полезнее со своим ответом. Попробую угадать) Считаю ли я, что расположение узкого места само себе повлияет на предсказуемость? Нет. Если оно вконце, то все этапы до него нужно будет ему подчинить этому узкому месту. Это значит буквально, что люди на этапах ранее должны меньше производить. И только вот тогда будет меньше ненужного старения в очередях и больше предсказуемости. А если узкое место будет вначале, такого же эффекта легче или тяжее добиться? Даже легче. Вам как менеджеру не нужно подчинять систему до узкого места. После него вся работа пролетает дальше. Это самый менее геморный вариант для менеджера.

А по поводу расчета вип лимита формулой Кингмана, тут вы уже научите меня это делать, пожалуйста) Можете на своих данных пример показать, как вы это видите?

Рафик, во первых, пишите еще. Почти случайно наткнулся на вашу страницу и с интересом все прочитал. Во-вторых, не увидел обещанного FAQ в коментариях к статье ;)

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

В-третьих, из теории ограничений следует, что наибольшая предсказуемость возможна, если узкое горлышко находится в конце производственной цепочки - оно задает среднюю скорость всему потоку. А чем ближе элемент к началу процесс, тем больше избыточной мощности он должен иметь для "погашения" статистических колебаний. В IT в конце, в общем случае, стоит тестирование. Дальнейшие этапы (пси, внедрение, etc) можно опустить. Мы можем при формировании команд обеспечить, чтобы ресурс аналитики был избыточен, ресурс разработки чуть меньше, но превышал тестирование, а ресурс тестирования был элементом с самой низкой пропускной способностью. При этом он должен быть всегда загружен, но не завален благодаря WIP-лимиту. И тогда Lead Time = (Размер очереди перед тестированием) × (Скорость тестирования). Это позволяет уменьшить колебания, потому что мы не учитываем разброс в аналитике и разработке. Также это позволяет с большей точностью сказать, что когда тестировщик заболевает или уходит в отпуск, проток команды уменьшается на среднюю производительность тестировщика. В-четвертых, (еще дисклэймер: все дальнейшее основано на данных, которые мне собрал ИИ), совсем для гиков эффективности, в теории очередей существует формула Кингмана, позволяющая определять WIP-лимит не эмпирически, а рассчитывать его, Причем динамически, основываясь на данных в таск-трекере. Считается довольно мудрёно, но для MVP самые сложные расчетные параметры можно взять дефолтными, а дальше уже докручивать точный расчет.

Что скажете по поводу 3 и 4 пунктов?