今天正式结束了最后一个软件外包项目，也就意味着传统的软件外包模式在我们公司划上了不圆满的句号，以巨亏的结局宣告现有的软件外包模式已经走入了死胡同，新的软件服务模式即将打破传统，进入新的发展模式阶段。在讨论新的模式之前，很有必要剖析这个巨亏10多万的软件项目。
一、大坑从只有1页的需求开始
做过软件外包项目的大体都有这样的体验，客户提出一个很简单的需求，然后让你报个价。而这个时候大部分软件外包公司都会报一个相对高一点的价格，防止后期需求有变化而能维持利润。这个项目同样如此，需求就是一个简单的说明，是要做一个电商的商城，只不过是多了经销商的功能，而且附了经销商的分成方式。咋一看需求不复杂，加上我们有现成的商城模版，即使做成APP+H5的模式，我们如果报20万，应该是有得赚的。而恰恰是这种需求模糊的预估报价模式，为整个项目的失败埋下了巨大的祸根，而这也是传统外包模式的最大弊病之一，对于开发公司及甲方客户都是及不公平的事情，这样的方式会纵容甲方能省事就省事，所有的锅由乙方开发公司来背。
二、4个月的需求确定，让项目一步一步迈入深渊
9月份签的合同，我们就派产品经理跟踪服务客户的需求原型确认。一般的需求原型有一个礼拜都差不多完成了，但是这个项目需求整整做了4个月，甲方以各种理由推翻我们做的需求原型，不断往里加东西，美其名曰细化需求，直到12月底才算终于确定一版。而这个时候出来的需求原型，跟原来已经丰富了相当多的内容。但是，由于前面已经签了合同，跟甲方客户讨论增加费用的时候，已经没有可能了。这个时候有两个选择，我们可以中止合同，或者要求增加工期和费用。善良的我们没有去麻烦客户，结果引来了后面巨大的麻烦。传统的外包模式弊病之二，签合同之前需求尽量模糊，签合同之后需求尽可能的细化和增加，然后以合同要挟，不让增加费用。
三、极低的预付，然后分阶段付款模式，亏损从此开始
这个合同本来想用新开发合作模式来签的，结果甲方不同意，因此采用了折中的合同模式，介于传统及新模式之间的方案。按传统的外包模式，低于60%的预付，我们都不能接的，但是采取的是折中模式，所以正式开发之前，我们只收了35%的钱，也就是7万元。4个月的需求分析及UI设计，刚好也就花了这么多成本。意味着开发之后的钱，我们得垫，这个是非常危险的，从开发正式开始的时候我们已经在亏钱了。正常的商业逻辑是，这个时候我们应该再次叫暂停，但是我们还想侥幸。
传统外包模式弊病之三预付60%乙方肯定不会亏本和吃亏，较低的预付乙方100%是亏本和吃亏的，因为甲方会有各种理由延期支付剩下的款项。四、开发过程中去掉一些功能，补充一些需求，以及极其刁难的阶段付款要求，项目陷入泥潭
2020年2月份，正式开发开始了，我们自己投入了4个人，加上外部投入了4个人的力量，我们想尽快拿到开发款，但是我们又陷入了甲方的圈套。首先，在开发中，去掉了一些已经确定的需求，我们知道程序的逻辑是相通的，去掉一些功能必然会影响一大片，而不像甲方所说的不就是删除嘛，多简单。在基本功能做得差不多，同时进入基本功能测试时，甲方要求主流程跑通，才能付钱，但他们测试的时候可是玩命的在测试，测得那叫一个细。这个时候，我觉察到了不对劲，主流程跑通，不就是大部分功能都做完了嘛，也就是甲方变着法要把所有做完了才能给钱，而不是分阶段给钱啊。坑，一个大大的坑，我居然跳进去了，一个老江湖居然上了这么大的当。交涉中，甲方的一个说法“我只要结果，至于你们付出的劳动和成本，我们不关注”，我听到这个之后，我知道，这个项目我栽了，我要再做下去，我将万劫不复，至少还得赔2个月的人工，而且最后还不一定拿到钱，对方有各种理由和借口，让你不断付出成本，陪他优化，陪他细化，就像需求细化4个月之久一样。到3月22号的时候，我们的开发成本已经超过10万了，也就是说这10多万的成本，我们已经亏掉了。但是如果我继续陪他玩下午，我将亏至少20多万，所以当断则断，我们坚决停止了开发，止血。
传统外包模式弊病之四甲方想要项目尽可能的完美，但不会增加费用，还会不断拖延付款；乙方则想尽快交付，不允许有任何新的需求和改动，这种矛盾的产物必然是双方不满意，产品质量不好。至此，我的最后一个软件外包项目就这样亏了10多万。
其实，在做这个项目的时候，我们的新软件开发模式已经成型了，但是惯性和客户的要求，让我没有坚持新的开发模式。从这方面看，这个项目的失败让我坚信了新的开发模式将在未来发扬光大，下面我一条一条的讲解新模式如何克服以上的弊病，让甲乙双方得到双赢：
1、需求评估，只有预估价
针对目前大部分甲方客户，初始需求都很模糊的状况，我们的新开发模式下，只会出一个预估价，这个预估价不是最终付款价，只是给客户有个大概的成本预估，最终价格有可能更低，也可能更高，完全跟甲方后面需求原型确定后的功能多少有关。
2、需求制作，按时付费
为了避免客户故意拖延需求以及需求无限扩大的问题，所有产品经理的需求制作成本，我们有一套公平公正的计费模式，可以实时统计产品经理的工作时间，客户根据产品经理的工资和工作时间付费就可以了，工作量少就少付钱；如果非要做4个月需求，付4个月的工时费就可以，我们也不会亏本。
3、详细设计，精确算出最后的成本和开发时间
需求原型确定后，这个时候算是真正计算价格和工期的时候，我们会有一套详细设计工具，把需求拆分到小时级别的任务，根据人员的成本和工时费用，再预留一些测试和联调周期，能精确的计算出实际的成本和确定的完成日期。甲方只要根据这个价格和工时付钱就可以。
4、按周验收，按周付费
这个模式前期要收20%的押金作为预付，但是开发开始后，甲方需要每周都来验收开发好的功能，并且验收合格后才进入下一个任务和模块的开发。并且每周验收完成之后，都需要支付本周的钱，否则将停止开发。这样，甲方的充分参与，将大大提高项目的质量和成功率。而乙方由于按周付费，即使亏了，也就是损失一周的钱，能把损失降低到最低。
5、按时计费，工期约束；
区别于传统的60%预付开发费模式；也不限制甲方需求的变动和更改。反正所有的费用按实际发生的时间和人工来计算，好比自己的开发人员一样，甚至比自己的开发人员还好管理，比如不用交社保，不用占场地，业绩直接跟工作时长挂钩，不用领导吩咐就能主动热情的干好工作。所以甲方可以随便加功能，减功能；也可以把项目做成极其的细致，质量要求极其高，反正增加人手和时间就行了，按照实际发生的有效工作时间付费。这样才能真正做一个有质量的好产品，这样才不会爆发甲乙双方的立场冲突。
一个存在20多年的外包旧模式，从一开始的暴利，到目前的人人喊打，项目完了双方都恨得牙痒痒，说明这个模式走到了尽头。新的软件开发模式必将颠覆现有模式，给软件开发公司及客户一个公平公正的商业环境。
原创不易，希望我的分享能帮到大家，有说得不对的，尽可能拍砖，有认同的多点赞和转发。
閱讀更多 軟件開發不求人 的文章
