Инженерная часть команды производит какие-то описания, а затем - физическое воплощение системы по этим описаниям. Физическое воплощение системы - это и есть продукт инженерной части команды. Процесс создания описаний/воплощения - это этап “исполнения”/execution.
На этом этапе зачастую оценивают производительность/performance/efficiency команды, т.к. тут возможно собирать метрики по каким-то видимым/осязаемым показателям - количество строк кода в час, стори-пойнтов за спринт, фич за релиз и т.п, если мы говорим о разработке ПО.
Ну и поскольку деятельность на этом этапе “видима” и даже поддается оценке, то возникает соблазн любые оптимизации проводить именно здесь. Если кому-то хочется, чтобы команда работала быстрее, то естественно предложить инженерам быстрее двигать руками и шевелить мозгами именно на этапе “исполнения”.
Однако этому этапу предшествует этап планирования работ или принятия решений - их производит и претворяет в жизнь управленческая часть команды. Вообще говоря, получается, что менеджеры задают контекст/среду для работы инженеров, управляя потоком работы через решения о том, какие задачи и в какой момент должны быть взяты в работу.
И вот тут возникает проблема - что толку от того, что инженеры быстро-быстро шевелят мозгами и пишут код, если перед ними поставлена не та задача? “Не та” в том смысле, что вообще не нужна или просто недостаточно эффективна, то есть дает меньше плюсов на единицу затрат, чем хотя бы одна другая задача из бэклога. Какой смысл быстро-быстро производить недостаточно полезные результаты?
Это отлично укладывается в системную многоуровневость: конкретные действия (“как?”) лежат на один системный уровень ниже контекста/требований (“что?”). И для того, чтобы по-настоящему оптимизировать деятельность, нужно сначала разобраться именно с частью “что”. Более того, эти разборки безмасштабны, то есть транслируются вверх и вниз по системным уровням.
Если двигаться вниз, то выяснится, что инженерам-программистам необходимо выбирать, скажем, протоколы взаимодействия сервисов (“как”) исходя из нефункциональных требований (“что”), а еще ниже уровнями - подбирать/придумывать алгоритмы, создавать структуры данных и управляющие последовательности операторов исходя из чуть более высокоуровневых “требований”.
А если идти вверх, то прежде чем собирать продуктовую команду и пилить продукт, нужно понять, лучший ли это продукт из возможных.
Вот такое многословное объяснение простого принципа “Семь раз отмерь, один раз отрежь” :)