Comments 8
ТОС - крутая штука, сам использую её постоянно в работе.
К подобным абстрактным идеям, о том сколько ангелов уместиться на кончике иглы, следует относиться не более чем как к развлекательной беллетристике.
С одной стороны, идеи кажутся простыми и разумными, с другой -- будучи примененными к реальным вещам, сразу провоцируют стопицот нюансов.
Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи. Но кто когда признается в собственной некомпетентности? Всегда найдется причина вовне!
Или загруженный девелопер стал еще загруженнее, потому что теперь этим двум дебилам надо еще все объяснять
Пример: сильно загруженный девелопер был идентифицирован как узкое место. К нему добавили двух новых человек в надежде ускорить процесс разработки. И получили обратный результат, ибо узкое место в проекте -- это менеджер, не умеющий грамотно планировать и распределять задачи.
И понятно почему так произошло.
ТОС это как раз не про то, чтобы найти ограничение и быстрее его расшить. В этом и автор статьи ошибается.
ТОС говорит, что найдя ограничение мы должны всю систему подчинить ему. И вот если и этого не хватает, то только потом расшиваем ограничение.
Если это разраб, то:
Задачи к нему должны приходить максимально продуманные, так чтобы он не тратил время на переуточнение запроса
Задачи ему надо отдавать не всякие, а только те, что принесут максимальную прибыль за единицу времени работы разраба. Это называется проход на ограничение: прибыль минус полностью переменные затраты на эту задачу (в IT обычно это 0, так как нет прямых затрат на задачу, разве что мы можем покупать под каждый заказ стороннюю лицензию, тогда её и вычитаем), разницу разделить на время работы ограничения
Надо убедиться, что разраб не занимается работой, которая не приносит нам профит: всякие скрипты для других - пусть пишут другие, данные для аналитиков или ещё кого-то - тоже пусть собирают другие и т.п.
Если сделать так, что путём изменения способа работы, то мы получим максимум прибыли минимальными затратами. А расшивать ограничение - это часто большие траты.
Теория ограничений она про конвейерное производство. Применять его к инженерной и проектной (или продуктовой) работе не очень подходит. Я бы даже сказал пытаться натягивать сову на глобус можно но лучше сконцентрироваться на других подходах.
Но в разработке этот подход зато подходит для "конвейеров" данных (дата пайплайнов и цепочек вызовов апи, или цепочек шагов обработки запроса.) вот там для оптимизации это прям применимо непосредственно. Например нет смысла ускорять обработку запросов если ботлнек в базе. Все прям по теории ограничений.
У человеков всегда есть термин на всё подряд.
Даже на "Есть проблема, которая замедляет - пойди исправь". Целая теория... матрицу ей в бубен.
Просто пошел и сказал - автоматизирует тесты. Никто не слушает...
А потом такой - ну ребята ну ТОС же... Ну вы чё. И все такие хоп и пошли делать. Ибо слово ТОС лень гуглить
Что такое теория ограничений и как она помогает улучшать процессы разработки продуктов?