Что оптимизировать? Сегодня мы обсудим тему, которую необходимо понимать CTO и полезно понимать архитектору и менеджеру. Я ее уже поднимал ранее, но тема для многих неочевидная. Кажется от повторения в новой обертке хуже не станет 😁 В соц сети сатанистов и вурдалаков (по версии РКН) поспорили мы с моим бывшим коллегой а ныне архитектором в Епам. Рекомендую тред со спором прочесть. Алексей описывает тактики повышения пропускной способности разрабов – У них на проекте узкое место это приемочное тестирование, которое выполняется клиентами месяцы из-за зарегулированности и неэффективности – Релиз каждой фичи возможен только после окончания приемочного тестирования – Алексей предлагает использовать фича флаги на стероидах, чтобы разрабы штамповали фичи и не ждали релизов На первый взгляд может показаться, что Алексей внедрил мега оптимизацию – дал возможность разрабам творить в условиях заблокированных релизов. Но в реальности эта оптимизация значительно ухудшила общую пропускную способность. 1. Каждая созданная но не зарелизенная фича – это work in progress (WIP) 2. Для увеличения производительности WIP уменьшают а не увеличивают 3. Увеличение WIP перед узким горлышком значительно ухудшает пропускную способность. Тестировщики уже выполняют свою работу месяцы. А мы вводим оптимизацию, которая в десятки и сотни раз увеличивает нагрузку на них. 4. Во время релиза может оказаться, что фича больше уже не нужна. Нам было мало месяцев ожидания релиза для одной фичи и мы сами превратили это ожидание в годы. За годы даже регуляции меняются. 5. Управление WIP затратно. Управления фича флагами, рефакторинг базы, переключение флагов, удаление флагов. 6. Ошибки, найденные в приемочном тестировании, требуют реворка остальных фич. 7. Реворк становится очень затратный. Попробуйте вспомнить фичу, которую делали год назад. Или которую даже не вы делали, а уволившийся коллега. Ладно, отбросим скучную теорию и порассуждаем на пальцах. Зачем штамповать фичи в стол, если в релизе их увидят через месяцы и годы? Что делать в этой ситуации? 1. Ускорять приемочное тестирование. Но в случае с Алексеем это похоже невозможно. 2. Сократить производительность разрабов (например уменьшить значительно их количество). Удивительно да? Чтобы увеличить общую производительность, нам необходимо уменьшить производительность разрабов 🤣 Welcome to мир управления процессами. Для детального изучения рекомендую прочесть классику The Goal, или современную переупаковку The Phoenix Project + The Unicorn Project А вы сокращаете или увеличиваете WIP на своих проектах?