无数的教训，为什么要做一个好的甲方？

作者：张海龙， CODING CEO ，技术创业者。 CMU 计算机硕士，原 Oracle 高级软件工程师。 2010 年回国创业，曾联合创办开源中国社区， 2014 年创办 CODING 。
Coding.net 是国内最大的一站式云端开发平台提供包括代码托管，项目管理，产品演示， WebIDE 等工具，帮助软件开发者提高生产效率，并实现 “ Coding anytime anywhere ” 的愿景。Coding.net 目前已经积累了 15 万开发者， 20 万项目，并且获得了 IDG 和光速的两轮投资共计 1200 万美元。
2015 年 8 月， CODING 推出 码市，旨在通过云端众包的方式提高软件交付的效率，帮助软件开发行业实现高效的资源匹配。

这个世界上有很多的甲方也有很多的乙方，我们在生活和工作中，不是充当甲方角色就是充当乙方角色，往往两个角色交替着来。看起来，甲方给钱，在交易中应该是主导地位，那为啥软件外包领域的甲方经常在项目交付的过程中狼狈不堪？

我平时常常充当第三方，看了形形色色的甲方和乙方，也算是看透了：软件开发项目要成功，更多的取决于甲方，取决于甲方的能力，态度，还有期望。项目换乙方不难，但是换甲方，基本就死了。我们常见，公司换一任领导，之前没完工的项目黄掉的可能性极高。所以，做一个好的甲方很重要，我们来谈谈为什么，以及如何做一个好的甲方。

没有人知道你在想什么

这个世界之所以有那么多矛盾，就是因为我们的思想是不透明的（是不是想起了三体人？），没有人知道你在想什么！你找人帮你做软件开发，你得明确的告诉乙方你想做什么，软件的使用场景是什么，解决什么问题。你在你的领域混了很多年，你觉得有些问题很显然，但是乙方没有。你觉得理所当然的问题，乙方可能完全没有听说过。所以，作为甲方，你应该不厌其烦，尽可能详细的说明白你的需求。很多软件项目做出来效果不理想，追根究底都是甲方一开始没说清楚。你不能觉得你的需求很常见，很简单，所以乙方应该理所当然的做出你想要的东西。如果你要的软件真的这么常见，那你就不用定制开发了，直接买现成的。每个需求都是独特的，所以请不要用这样的语言来描述需求“做一个跟 xxx 软件差不多的就行了”。你说你想要一辆车，乙方好不容易做出来了，结果你说其实你想要的是四驱的，座椅加热的，还得是敞篷的。这样的结局只有一个，就是加钱，延期，否则乙方不干，但是你不爽，埋下了不欢而散的种子。

由于国内的甲方大部分不够成熟，所以很多国内的开发者和外包团队都倾向于接国外的单子，包括香港和台湾的。我参与的海外项目，无一例外，都是非常详细的需求文档，并且对接的人非常耐心的跟乙方解释业务逻辑。更重要的是，甲方非常清楚，他的责任在哪里。在出现问题的时候，他会判断这个问题是谁的原因，不会把所有责任往乙方身上推。这是我们值得学习的地方，也是我经常跟甲方讲的需要改进的地方。

一分价钱，一分货

大家都知道买东西是一分钱一分货，凭啥到了软件开发就不是了呢？凭啥要求乙方给你免费干活呢？有些甲方意识不到软件的价值，因为看不见摸不着。所以才有一些厂商把软件装到服务器内再卖高价的情况，因为服务器是实实在在存在的，掏钱就很乐意。显然，这是不对的。定制开发软件的价值就是人工，虽然很多时候计费是按项目收，但实际上也是按人工时间算的，跟装修一样。刷墙看起来是按平米收费的，但实际上也是折算成刷这么多面积的人工来算的。所以你装修的时候刷墙刷完了发现颜色不满意，重刷，不得再给钱么？任何功能的开发，调整都是有成本的，你想在有限的预算内做很多的功能，那你必须接受的事实就是做的比较粗糙，或者你得接受周期拉长，等乙方安排空闲时间帮你慢慢做。

我记得有一个理论是餐馆理论“好吃，便宜，服务好”这三点不可兼得。很有道理，几乎所有的餐馆都不可能兼顾这三点，假如有，那一定会很多人去吃，排队排死，自然服务也就不好了。这条理论放到其他行业也一样，你怎么可能要求软件开发做到“质量好，便宜，交付快”呢？

我是甲方，我是爷？

现实中的交易有时候会存在一种情况，给钱之前甲方是爷，给钱以后乙方是爷，所以才有了所谓的第三方。软件开发由于不是实体产品，很多时候的定义无法完全明确，这样的情况尤其明显。但是，一个成功的软件项目，往往甲乙双方都不是爷，就是纯粹的甲方和乙方，各有各的责任，各有各的义务。乙方作为收钱的一方，对甲方态度好点，耐心一点是应该的，但是特别要强调的是：甲方并不凌驾于乙方之上。先来说点不正规的，还拿装修说事儿。 21 世纪都进入第二个十年了，然而我们在装修的时候不还是得给装修师傅送香烟么？这是为什么呢？明明给你装修费用了，为啥还得买烟？这是一种态度，师傅你工作辛苦了。结果是，师傅高兴了，活儿干的也快了，质量也好了，横平竖直，保证不偷工减料。有的地方看的见，有的地方看不见。软件开发也是一样，你对乙方尊重，乙方自然会有体会，别的不说，同样的功能，我可以把代码写写好，注释多写点以便后期维护。

再来说点正规的。软件开发项目如果完全按照合同来，估计甲方也有很多小尾巴，大家谁都不让谁事情就很难办。所以把关系处好是有必要的。还有，软件项目总有小修小改，如果严格按照产品定义来，乙方完全可以不做这些修改，或者要求加钱。但是如果大家相处的好，这些小改动就顺手做了。这些都是很现实的状况。毕竟，软件开发还算是门手艺活儿。

这篇文章是写给甲方看的，所以乙方的问题就不详细讨论了。说一个结论：如果你觉得乙方不靠谱，或者你给了钱就的听他的，请尽快更换乙方，后面的钱不要再支付了。虽然前期的投入会让更换乙方的成本很高，但毕竟比项目烂尾要好。而且多次实践经验表明，如果乙方前期不靠谱，后期变的靠谱的可能性为零。除非你愿意忍辱负重，凑活把项目做了，否则尽快终止交易，换人。

纠结还是交付？

所有程序员都知道，程序不可能没有 Bug ，而且 Bug 往往越修越多，然而这在很多甲方那里是不能理解的。我经常跟甲方讲的是要看主要功能，主要流程是否能走通。除非一些特殊领域的软件，例如金融，工业控制等等，其他的软件，特别是互联网领域的，都应该是先上线，然后再完善。我看到的几乎所有互联网产品都是这个路子。所以，在绝大多数情况下，我们应该选择尽快交付上线，而不是纠结于一些小问题。一般的软件项目都有质保期的，所以这些小问题可以在质保期慢慢修。这有几个好处，首先是不用赶时间，做的质量会好一些。其次，上线以后有了实际的用户和运营数据，可以更加准确的定位一些问题。

另外就是从心理上来讲，大家做一个软件一般都好几个月，如果一直拖着不上线势必会影响士气。虽然，理论上乙方只是帮你开发而已，是否上线跟他关系不大，但成就感多少还是有一点的。上线以后，大家修 Bug 的情绪都会不一样，而且大家都知道已经上线了，有问题得及时修。总而言之，我建议甲方在交付阶段不要纠结，先交付，然后利用质保期完善。

在软件开发这件事情上，你可能是甲方，但在你工作的领域你可能是乙方，换位思考一下会让你成为一个更好的甲方。

最后，如何判断你是不是一个好的甲方呢？很简单：乙方是否下次愿意降价 10% 跟你继续合作。

（完）

原文链接： https://blog.coding.net/blog/a-good-partner