「叫後端去做前端」 這句話雖然有問題，但如果改成「叫後端去幫前端」就不一定有問題了，因為幫忙有很多種方式。
如果有看懂《#目標》那本書點出來問題的本質，就不會覺得這有啥好奇怪的。
前端如果是 #瓶頸，而且前後端要一起搭配才能出貨產生價值，那前端卡住了，後端如果自顧自的一直去做後面的 item，只是花資源在產生無法交付價值的 #庫存品。
更別說，軟體開發的話，這還會造成 #延遲整合 的問題。
如果產品開發團隊裡面就這麼 #壁壘分明，就不容易達到把 #團隊能量交付價值最大化 的目標，因為每個人都在挑工作（喜歡的、擅長的、好做的、有亮點的），而不是依據產品價值排序在交付最大化價值。
如果前後端加起來有 10 個人，各分 5 個人的情況。
那當前端吃重時，團隊能量仍然只有 5，怎麼樣比 5 多，就是團隊的競爭優勢所在。團隊如果無法成為 #學習型組織，那始終都還是得面對 #穀倉 跟 #局部最佳化 的迷思與問題。
※ 簡單地說，如果再一次碰到前端吃重，或是後端吃重的情況，我們能做點什麼比現在的處理更好？這問題會不斷不斷地發生，而我們應該為此做點改善，而不是視若無睹，雙手一攤。
我都開玩笑說，站在價值交付的角度來說，可能後端工程師（非瓶頸）去幫前端工程師（瓶頸）買便當、倒水、處理雜事，都還比他們去做後面的 item 來得有意義。（這也是為了解決 WBS 常見的弊病）
但以 engineer/developer 來說，後端工程師應該只能說自己不喜歡、不擅長前端的需求，但學習、pair 都不會有問題的，有問題的通常是人的態度，而不是專業領域的差異。
