之所以中美少用瀑布模型，就是因为中美市场多样性很丰富，日欧市场单一

【本文来自《屡战屡败：德国汽车工业的软件危机》评论区，标题为小编添加】

• 洪流平推

• IT行业可真是太熟悉大众的软件危机了……有多少项目死在用deadline来“倒推”开发软件呀？

  有时候，往往在章程还在规划，软件开发就已经上马了

  开发人员在无整体计划的状态下东一榔头西一棒子的做些“能做的”

  只要在推进，中层就敢给高层拍胸脯说到时间肯定能交付，因为这关系到整个团队的KPI

  至于交付的是什么，反正高层自己没想清楚给不出来定义，只能照单全收

  然后开发人员就为了在deadline时给出来能看的过去的玩意鸡飞狗跳，至于里面埋了多少坑，那只有天知道了，为了赶进度，什么“邪术”用不出来呀？

  如果是不涉及硬件的纯软件，最后或许还能圆回来，搞敏捷，小步快跑的迭代，一周三更新的爆肝

  但涉及硬件还这么玩，那是找死。软硬结合只有瀑布和迭代两种选择。中美选的都是迭代，饼先画出去，然后OTA解决；德日好像玩的还是瀑布，那可不就凉了吗。

说白了就是高层也没有想好做啥，这时候写需求的才是最重要的。他们要搞清楚2件事：一是老板要什么，二是客户要什么。这个事最好要对业务精通，从业经验丰富的IT出身的项目经理牵头做。如果没有，优先业务精通表达能力强的人，因为他能帮助老板搞清楚他要什么，能把老板需求与客户需求的坑提前填上，不至于死于起步。

至于技术与需求的坑，可以靠经验丰富的IT项目经理来做，一般成品完成度能到7成。如果项目太大，还要找个靠谱的架构师，保证项目具备不错的伸缩性应付客户随时变更的需求。

之所以中美少用瀑布模型，就是因为中美市场多样性很丰富，日欧市场单一，特别是中国作为世界供应链主体和人口大国，各种需求千奇百怪。美国作为英语区市场消费终端，需求也是千奇百怪，反而美国工业软件需求被垄断，迭代不快。