软件外包项目，怎么配合才不容易烂尾？

做软件外包这行久了，会发现一个挺有意思的现象：项目能不能顺利交付，技术方案固然重要，但更关键的往往不是代码写得多漂亮，而是甲乙双方怎么配合。

我们见过需求书写得潦草、最后却顺利上线的项目，也见过合同厚厚一沓、中途却越做越拧巴的项目。差别很多时候不在技术，而在协作方式。下面这些，是我们自己踩过坑、也被客户教过之后，慢慢总结出来的几点实在话。

需求阶段，客户不能当“甩手掌柜”

有些客户觉得，我把大概想法说了，剩下的你们是专业的，你们看着办。这话听着信任，实际上风险很大。因为“看着办”的结果，大概率跟您脑子里想的不一样。

软件这东西很具体。您说“做一个审批功能”，开发人员会问：谁发起？谁审批？能不能退回？退回以后改哪几个字段？金额超过多少要加签？这些细节不落实，写出来的东西就只能靠猜。猜对了是运气，猜错了就是返工。

所以我们一般会拉着客户一起把流程过一遍，哪怕您不懂技术也没关系。您只需要告诉我们，现在这件事线下是怎么干的，谁最头疼，哪个环节最容易出错。这些信息比一份漂亮的需求文档管用。

原型不是成品，别等上线才提意见

有的客户看到原型图，觉得“这不挺简单吗”，就等着最后验收。结果系统真跑起来，发现操作路径太长、字段太多、报表不是自己想要的样子，这时候再改，成本就上去了。

原型阶段其实是提意见最好的时候。页面长什么样、按钮放哪儿、哪些信息要突出，这时候改一行画图工具里的东西，比改代码便宜太多。我们不怕客户提意见，怕的是客户没看、没空看，最后上线了才说“这不是我要的”。

沟通得有个能拍板的人

项目里最怕的情况是：对接的人很认真，但每件事都要回去问一圈，问完回来意见又变了。不是说不能内部讨论，而是最好有一个能拍板的人。需求有争议的时候，这个人能说“就按这个做”，项目才能往前走。

我们做开发的时候，会尽量把问题攒一攒集中问，而不是一天发十几条消息。但客户这边也得有个相对稳定的接口人，不然信息散在好几个人手里，最后谁说的都算，谁说的又都不算。

改需求很正常，但得有个规矩

做软件几乎没有不改需求的。业务在变，老板想法在变，看到原型以后有新想法，这些都正常。问题不在于改不改，而在于怎么改。

我们的做法是，小调整随手记，不影响当期进度的就顺手做掉；影响范围大的，拿出来单独评估，是加时间还是加预算，还是放到下一期，双方说清楚再动。最怕的是嘴上说“这个简单，先加上”，加着加着工期就崩了。不是开发方小气，是每一处改动背后都有联调、测试和文档要跟着动。

验收标准，最好提前写在纸上

“能用”和“好用”之间差得很远。验收的时候，最好有一条一条能对的东西：这个流程能不能走通，这个角色能不能看到该看的数据，这个报表数字跟手工算的对不对得上。别等到最后凭感觉说“我觉得不太行”。

我们通常会在开发中期就让客户参与试用，别等到全部做完再来看。早一点看到半成品，早一点提问题，比最后推翻重来强。

上线以后，维护的事也要说清楚

系统上线不是终点。后面还有bug要修，数据要备份，服务器要看着，业务变了可能还要加功能。这些事谁来做、怎么收费、响应多快，最好在签合同的时候就聊明白，别等出了问题再扯皮。

我们自己的习惯是，交付的时候把源码、部署文档、操作说明都整理清楚。客户后面想自己团队接手，或者换人维护，至少能看得懂。这行做久了，口碑比一单生意重要。

说到底，软件外包不是把需求扔过去就完了，它更像双方一起把一件模糊的事慢慢变清楚。客户懂业务，我们懂怎么把业务变成能跑的系统，两边都往前一步，项目烂尾的概率就小很多。

如果您手头正好有个项目在犹豫怎么启动，或者之前做过一半不太顺利，可以找我们聊聊。不一定非要合作，先帮您看看问题出在哪儿，也是件挺有意义的事