上一篇我们讲了，我们通过对任务进行切分，确定项目的真实任务量，保证劳动付出和报酬收益之间的等价匹配。但就像一次交易，除了价格以外，还有其他很多需要考虑的因素。本篇将继续探讨在软件开发过程中，如何进行流程控制和责任划分。

有一次，一个朋友约我接一个私活。客户之前已经花了3万，做了一个仿凡客的网站，都交付使用了，才发现bug一大堆，根本没办法用。想让我们给接着做，让我们给报个价。看他演示了一会儿，我告诉他，这价格我们报不了，因为需求都不清楚。

“怎么就不清楚了呢？”客户很是不解，“你们就把这些问题解决了就完了呀！”

“这些问题，究竟有哪些问题？”我追问道。

“就我刚才给你们演示的呀！”

“是不是就只有这些？”，我一定要把这一点弄明白，“那我们用笔把他们一条一条的记下来，修完这些问题就完事？其他的不管！”

他不说话，似乎还不太明白，我接着解释，“比如你这个页面，现在是打不开，崩溃了，我们是不是只要做到这个页面能打开，就OK了？至于这个页面打开后，上面的功能是不是已经实现了，我们不管。”

“那不行！”，他马上就跳起来了，“必须得做完啊！得好好的跑起来。你看，就像凡客这样……”

我基本上失去了和他谈下去的兴趣。直接给他两个选择：1、我们做兼职，在他眼皮子底下做，多少钱一天/小时；2、把bug一个一个列出来，根据bug的难度，确定每个bug的价钱，按时结算。客户两个都不愿意，一定要我们报个总价。

下来之后，我那朋友还和我联系，说客户其实很欣赏我做事的风格，希望能继续谈。我直接回她，“如果他真的欣赏我做事的风格，就按我说的方案做。需求都定不下来，总价没法报。‘照着凡客做’，那不是需求！你坑死我啊，一个凡客，3万就做出来了？而且凡客里面，估计都还有一堆bug，大部分时间普通用户没发现而已……”

这种注定扯皮的活我坚决不做！又不缺这点钱，以前做律师做装饰，扯皮真的是扯伤神了！这种稀里糊涂又已经上过当的客户，百分百扯皮。最后我那朋友另外找人，报了个总价，也还是没做成这业务，因为客户要留50%的质保金，1年内付清。我哈哈大笑，想起当年我装饰公司请人做网站，最后也是把做网站的小伙子烦得连尾款都不要了，直接闪人。

现在想来，应该就是这件事，让我动了念头，开发目前这个任务管理系统。

“像凡客那样”，“参考阿里巴巴”，“类似于QQ”……这些话，我听到就害怕。还不如通过任务切分，把需求一条一条的真正的固化下来，然后我们再开始做。这些土豪客户是绝对没有这种耐心的，你嫌麻烦，整理需求（切分任务）这事我们做都可以，但你要“认账”。至少这些需求，你或者你指定的人，要一条一条的去看，不要凭空想个大概，三言两语打发就完事。

验收的时候，你就认认真真的验收，一项一项的，验收完了就完了，不要稀里糊涂的系统上线几个月了，这里有问题那里有毛病。我做维护这么久，接手的这些项目，哪一个不是交付上线了的？而且还是专业人士验收通过的，运行了这么多年，bug都还是一堆一堆的。你说这项目算不算“合格”？你说系统都交付验收正常运行这么多年了，哪个系统没bug呢？windows都还蓝屏呢。但按普通客户的观点，还有这么多问题，怎么能算合格呢，你得给我改，是你自己事没做好，加钱？门都没有！

所以，除非是800-1000的企业宣传网站，或者政府机关验收主要靠喝酒公关的项目，稍微复杂一点的、客户用心一点的外包项目，按项目整体报价签合同的，陷进去就是个泥潭。怎么赚钱，是八仙过海各显神通，但我看来，都没几个走正道的。我以前面试，一些非IT行业的公司，我了解他们的项目之后，就建议他们，干脆外包算了，干嘛自己招程序员，不划算啊？他们头摇得像拨浪鼓似的，“算了算了，这个当已经上过了！坑死人！”我周围接私活的朋友，是碰到肥羊就宰，碰到钉子就甩，接单的秘诀就是看这个客户“好不好说话”，想想也都是些可怜人啊！

需求方的深度参与，是项目成功的前提。这是毋庸置疑的，但很遗憾，很少有人真正的足够的重视这一点。

行业外人士，上面已经很多吐槽了。就是行业内，部门与部门之间，一个项目组内部，需求分析这事，都做得不尽人意稀疏平常。我经历的，大致有这些个情形：

以上这些，如果没工期要求，问题都不大，就多做点无用功而已。但哪有没工期要求的项目呢？（我的这个玩具项目，呵呵，不要求工期。）所以，扯皮的事就来了！我记得印象最深的是，有一次，deadline的前一天，我们项目经理在办公室破口大骂，“妈个逼的，现在还在改需求！我们怎么做？”但业务部门也有话说啊，“你们做之前怎么不仔细审查需求文档呢？”这中间又还夹着其他一些乱七八糟的事，官司打到上头，还是项目延期加班完事。

我发现有很多程序员喜欢“捞到半截就开跑”，需求还是迷迷糊糊的时候，凭着自己的想象就开始写代码，老是做无用功。（还有更奇葩的，他自己一路狂奔九头牛都拉不回来，最后你和他说需求是怎样怎样的，他还特别不服气，觉得他做出来的效果比需求要好！按他的想法，应该改的，是需求而不是代码。）除此以外，需求常常也给得模糊有歧义，所以这个官司就有得打了。我记得有一个研究结果：日常的单向沟通，大概有80%的信息会被忽略或误解。所以需求其实也不好弄，这个我们以前提到过，使用测试化文档是一个方法。

但本文，我们主要讲责任。正如我们上文所述，鞭子还是必须的。没有监督和责任约束的制度最后肯定是一纸空文。