Улучшая можно и ухудшить

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

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

Есть у вас какой-то ручной труд, вдобавок сопровождаемый человеческими ошибками? Вот кандидат на автоматизацию. Станет быстрее и качественнее.

Есть неэффективный инструмент, с которым и работа медленно идет, и людей на рынке труда мало? Вот еще кандидат на оптимизацию, замену, стандартизацию.

Конечно, надо искать в процессах, инструментах, командах, управлении места для улучшения и работать над ними.

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

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

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

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

Что именно надо оптимизировать?
Примеры выше – классические примеры локальных оптимизаций. Эта проблема идет из того, что при улучшении мы смотрим на какую-то конкретную часть, забывая о том, что конечный продукт выпускает вся система. Следовательно, улучшения нам нужны такие, которые будут влиять на всю эту систему в положительном ключе.

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

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

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

Элияху Голдратт «Цель. Процесс непрерывного совершенствования»
Джин Ким, Джордж Спаффорд, Кевин Бер «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему»

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