У нас проблема, давайте улучшим
Очередной пост уставшего капитана очевидности.
Цена всей цепочки производства, равна пропускной способности самого узкого звена. Как ты не оптимизируй все вокруг, если узкое место работает по-прежнему не оптимально, ничего не получится, т.к. эффективность всей цепочки останется прежней.
Проблема в том, что оптимизация узкого звена, задача обычно сильно нетривиальная. Поэтому люди склонны уклоняться от этой задачи и оптимизировать все вокруг, т.к. там риски меньше. Ведь страх допустить ошибку, у многих доминирующая мотивация.
Вот так и рождается хождение по кругу. Мы улучшили процесс, но в лучшем случае ничего не изменилось в лучшую сторону. Давайте улучшим еще что-то, но вот этих не трогаем, т.к. они и так перегружены. Мы улучшили процесс, но ничего не изменилось...
У этой же проблемы есть другое лицо. Узкое звено перегружается и начинает допускать ошибки из-за усталости. Внимание, что делать? Конечно, запихать туда дополнительные итерации в цепочку, чтобы надежнее делали. В результате вместо оптимизации цепочки, получаем ее удлинение. Вся система начинает работать еще медленнее, а т.к. внешние требования, скорее всего не изменяются, то дедлайны начинают жать узкое звено еще сильнее.
Самое сложное в этой ситуации заключается в том, что зачастую узкое место, возникает по объективным причинам. Т.е. или там требуются уникальные навыки или еще что-то, что не позволяет быстро вводить туда новых людей. И почему-то это зачастую рождает ощущение, что улучшить нельзя. Фразы типа, вот если мы отдадим это делать параллельно Коле, а не Васе, то он провозится две недели, вместо двух дней Васи. Вопрос, а какова польза двух недель Коли, если все равно все отложится из-за перегрузки Васи, как-то ускользает от глаз. Хотя он по сути ключевой. Зачастую, если Вася не успевает, то Колю можно в отпуск отправить и проект не потеряет скорость.
Но вот тут есть еще один важный момент. Если Коля среднестатистический исполнитель, то он хочет получать з.п. не сильно напрягаясь, а не продвигать проект. Поэтому ему гораздо комфортнее ситуация, когда в любом раскладе, будет виноват Вася. Ведь даже если Коля продолбает сроки на две недели, никто не заметит, т.к. все ждут Васю. Поэтому найти добровольцев на работу в подобных местах, весьма сложно. Туда идут люди, которым реально не пофиг, а их всегда мало. Но тут важно понять, что умение наладить работу на узком участке, критическое, для любого управленца. Поэтому если он заливает про хорошую мотивацию, везде кроме узкого места, значит, он просто работу свою не выполняет. Т.к. создавать условия для оптимизации, это его работа.
Итог всего этого простой. Если есть желание улучшить всю систему, то надо рисковать и пробовать оптимизировать именно узкие места. И да, возможно кто-то будет работать сильно не эффективно, но если это позволит оптимизировать узкое место, то значит это оправдано.
Цена всей цепочки производства, равна пропускной способности самого узкого звена. Как ты не оптимизируй все вокруг, если узкое место работает по-прежнему не оптимально, ничего не получится, т.к. эффективность всей цепочки останется прежней.
Проблема в том, что оптимизация узкого звена, задача обычно сильно нетривиальная. Поэтому люди склонны уклоняться от этой задачи и оптимизировать все вокруг, т.к. там риски меньше. Ведь страх допустить ошибку, у многих доминирующая мотивация.
Вот так и рождается хождение по кругу. Мы улучшили процесс, но в лучшем случае ничего не изменилось в лучшую сторону. Давайте улучшим еще что-то, но вот этих не трогаем, т.к. они и так перегружены. Мы улучшили процесс, но ничего не изменилось...
У этой же проблемы есть другое лицо. Узкое звено перегружается и начинает допускать ошибки из-за усталости. Внимание, что делать? Конечно, запихать туда дополнительные итерации в цепочку, чтобы надежнее делали. В результате вместо оптимизации цепочки, получаем ее удлинение. Вся система начинает работать еще медленнее, а т.к. внешние требования, скорее всего не изменяются, то дедлайны начинают жать узкое звено еще сильнее.
Самое сложное в этой ситуации заключается в том, что зачастую узкое место, возникает по объективным причинам. Т.е. или там требуются уникальные навыки или еще что-то, что не позволяет быстро вводить туда новых людей. И почему-то это зачастую рождает ощущение, что улучшить нельзя. Фразы типа, вот если мы отдадим это делать параллельно Коле, а не Васе, то он провозится две недели, вместо двух дней Васи. Вопрос, а какова польза двух недель Коли, если все равно все отложится из-за перегрузки Васи, как-то ускользает от глаз. Хотя он по сути ключевой. Зачастую, если Вася не успевает, то Колю можно в отпуск отправить и проект не потеряет скорость.
Но вот тут есть еще один важный момент. Если Коля среднестатистический исполнитель, то он хочет получать з.п. не сильно напрягаясь, а не продвигать проект. Поэтому ему гораздо комфортнее ситуация, когда в любом раскладе, будет виноват Вася. Ведь даже если Коля продолбает сроки на две недели, никто не заметит, т.к. все ждут Васю. Поэтому найти добровольцев на работу в подобных местах, весьма сложно. Туда идут люди, которым реально не пофиг, а их всегда мало. Но тут важно понять, что умение наладить работу на узком участке, критическое, для любого управленца. Поэтому если он заливает про хорошую мотивацию, везде кроме узкого места, значит, он просто работу свою не выполняет. Т.к. создавать условия для оптимизации, это его работа.
Итог всего этого простой. Если есть желание улучшить всю систему, то надо рисковать и пробовать оптимизировать именно узкие места. И да, возможно кто-то будет работать сильно не эффективно, но если это позволит оптимизировать узкое место, то значит это оправдано.