之所以中美少用瀑布模型，就是因為中美市場多樣性很豐富，日歐市場單一_風聞

【本文來自《屢戰屢敗：德國汽車工業的軟件危機》評論區，標題為小編添加】

• 洪流平推
• IT行業可真是太熟悉大眾的軟件危機了……有多少項目死在用deadline來“倒推”開發軟件呀？

有時候，往往在章程還在規劃，軟件開發就已經上馬了

開發人員在無整體計劃的狀態下東一榔頭西一棒子的做些“能做的”

只要在推進，中層就敢給高層拍胸脯説到時間肯定能交付，因為這關係到整個團隊的KPI

至於交付的是什麼，反正高層自己沒想清楚給不出來定義，只能照單全收

然後開發人員就為了在deadline時給出來能看的過去的玩意雞飛狗跳，至於裏面埋了多少坑，那只有天知道了，為了趕進度，什麼“邪術”用不出來呀？

如果是不涉及硬件的純軟件，最後或許還能圓回來，搞敏捷，小步快跑的迭代，一週三更新的爆肝

但涉及硬件還這麼玩，那是找死。軟硬結合只有瀑布和迭代兩種選擇。中美選的都是迭代，餅先畫出去，然後OTA解決；德日好像玩的還是瀑布，那可不就涼了嗎。

説白了就是高層也沒有想好做啥，這時候寫需求的才是最重要的。他們要搞清楚2件事：一是老闆要什麼，二是客户要什麼。這個事最好要對業務精通，從業經驗豐富的IT出身的項目經理牽頭做。如果沒有，優先業務精通表達能力強的人，因為他能幫助老闆搞清楚他要什麼，能把老闆需求與客户需求的坑提前填上，不至於死於起步。

至於技術與需求的坑，可以靠經驗豐富的IT項目經理來做，一般成品完成度能到7成。如果項目太大，還要找個靠譜的架構師，保證項目具備不錯的伸縮性應付客户隨時變更的需求。

之所以中美少用瀑布模型，就是因為中美市場多樣性很豐富，日歐市場單一，特別是中國作為世界供應鏈主體和人口大國，各種需求千奇百怪。美國作為英語區市場消費終端，需求也是千奇百怪，反而美國工業軟件需求被壟斷，迭代不快。