标签：
上一篇我们讲了，我们通过对任务进行切分，确定项目的真实任务量，保证劳动付出和报酬收益之间的等价匹配。但就像一次交易，除了价格以外，还有其他很多需要考虑的因素。本篇将继续探讨在软件开发过程中，如何进行流程控制和责任划分。
有一次，一个朋友约我接一个私活。客户之前已经花了3万，做了一个仿凡客的网站，都交付使用了，才发现bug一大堆，根本没办法用。想让我们给接着做，让我们给报个价。看他演示了一会儿，我告诉他，这价格我们报不了，因为需求都不清楚。
“怎么就不清楚了呢？”客户很是不解，“你们就把这些问题解决了就完了呀！”
“这些问题，究竟有哪些问题？”我追问道。
“就我刚才给你们演示的呀！”
“是不是就只有这些？”，我一定要把这一点弄明白，“那我们用笔把他们一条一条的记下来，修完这些问题就完事？其他的不管！”
他不说话，似乎还不太明白，我接着解释，“比如你这个页面，现在是打不开，崩溃了，我们是不是只要做到这个页面能打开，就OK了？至于这个页面打开后，上面的功能是不是已经实现了，我们不管。”
“那不行！”，他马上就跳起来了，“必须得做完啊！得好好的跑起来。你看，就像凡客这样……”
我基本上失去了和他谈下去的兴趣。直接给他两个选择：1、我们做兼职，在他眼皮子底下做，多少钱一天/小时；2、把bug一个一个列出来，根据bug的难度，确定每个bug的价钱，按时结算。客户两个都不愿意，一定要我们报个总价。
下来之后，我那朋友还和我联系，说客户其实很欣赏我做事的风格，希望能继续谈。我直接回她，“如果他真的欣赏我做事的风格，就按我说的方案做。需求都定不下来，总价没法报。‘照着凡客做’，那不是需求！你坑死我啊，一个凡客，3万就做出来了？而且凡客里面，估计都还有一堆bug，大部分时间普通用户没发现而已……”
这种注定扯皮的活我坚决不做！又不缺这点钱，以前做律师做装饰，扯皮真的是扯伤神了！这种稀里糊涂又已经上过当的客户，百分百扯皮。最后我那朋友另外找人，报了个总价，也还是没做成这业务，因为客户要留50%的质保金，1年内付清。我哈哈大笑，想起当年我装饰公司请人做网站，最后也是把做网站的小伙子烦得连尾款都不要了，直接闪人。
现在想来，应该就是这件事，让我动了念头，开发目前这个任务管理系统。
“像凡客那样”，“参考阿里巴巴”，“类似于QQ”……这些话，我听到就害怕。还不如通过任务切分，把需求一条一条的真正的固化下来，然后我们再开始做。这些土豪客户是绝对没有这种耐心的，你嫌麻烦，整理需求（切分任务）这事我们做都可以，但你要“认账”。至少这些需求，你或者你指定的人，要一条一条的去看，不要凭空想个大概，三言两语打发就完事。
验收的时候，你就认认真真的验收，一项一项的，验收完了就完了，不要稀里糊涂的系统上线几个月了，这里有问题那里有毛病。我做维护这么久，接手的这些项目，哪一个不是交付上线了的？而且还是专业人士验收通过的，运行了这么多年，bug都还是一堆一堆的。你说这项目算不算“合格”？你说系统都交付验收正常运行这么多年了，哪个系统没bug呢？windows都还蓝屏呢。但按普通客户的观点，还有这么多问题，怎么能算合格呢，你得给我改，是你自己事没做好，加钱？门都没有！
所以，除非是800-1000的企业宣传网站，或者政府机关验收主要靠喝酒公关的项目，稍微复杂一点的、客户用心一点的外包项目，按项目整体报价签合同的，陷进去就是个泥潭。怎么赚钱，是八仙过海各显神通，但我看来，都没几个走正道的。我以前面试，一些非IT行业的公司，我了解他们的项目之后，就建议他们，干脆外包算了，干嘛自己招程序员，不划算啊？他们头摇得像拨浪鼓似的，“算了算了，这个当已经上过了！坑死人！”我周围接私活的朋友，是碰到肥羊就宰，碰到钉子就甩，接单的秘诀就是看这个客户“好不好说话”，想想也都是些可怜人啊！
需求方的深度参与，是项目成功的前提。这是毋庸置疑的，但很遗憾，很少有人真正的足够的重视这一点。
行业外人士，上面已经很多吐槽了。就是行业内，部门与部门之间，一个项目组内部，需求分析这事，都做得不尽人意稀疏平常。我经历的，大致有这些个情形：
以上这些，如果没工期要求，问题都不大，就多做点无用功而已。但哪有没工期要求的项目呢？（我的这个玩具项目，呵呵，不要求工期。）所以，扯皮的事就来了！我记得印象最深的是，有一次，deadline的前一天，我们项目经理在办公室破口大骂，“妈个逼的，现在还在改需求！我们怎么做？”但业务部门也有话说啊，“你们做之前怎么不仔细审查需求文档呢？”这中间又还夹着其他一些乱七八糟的事，官司打到上头，还是项目延期加班完事。
我发现有很多程序员喜欢“捞到半截就开跑”，需求还是迷迷糊糊的时候，凭着自己的想象就开始写代码，老是做无用功。（还有更奇葩的，他自己一路狂奔九头牛都拉不回来，最后你和他说需求是怎样怎样的，他还特别不服气，觉得他做出来的效果比需求要好！按他的想法，应该改的，是需求而不是代码。）除此以外，需求常常也给得模糊有歧义，所以这个官司就有得打了。我记得有一个研究结果：日常的单向沟通，大概有80%的信息会被忽略或误解。所以需求其实也不好弄，这个我们以前提到过，使用测试化文档是一个方法。
但本文，我们主要讲责任。正如我们上文所述，鞭子还是必须的。没有监督和责任约束的制度最后肯定是一纸空文。
所以我反复的考虑，觉得还是业务部门说得更有道理一些。这就像货物交割，交货前理应由收货方进行仔细验收，货物到手之后才说我刚才没看清楚要求退货，这肯定是没道理的。对应到软件开发，如果需求方是外部客户，这就涉及到报价预算商业信誉等一系列问题；即使是内部人员，也有可能影响别人的工作安排。所以，承接任务时对需求的审查责任应该在开发人员一方。
同理，任务完成之后，验收的责任就在验收人一方。一旦任务已经被验收合格，今后就不要再说什么当时没考虑周全。
既然确定了这种指导思想或制度，就需要一个顺手的工具来予以贯彻执行。我们任务管理系统的做法就是，把功能切分成一个个的任务，每个任务都有：发布 > 承接 > 验收 三个大的阶段：
(以下统一使用任务发布人/承接人/验收人表明相关人员，也就是责任人的身份)
在阶段与阶段交接的时候，确立相关人员的责任，具体来说：
任务一旦被承接：
任务一旦被验收：
换言之，这些规则就是针对的下面这样一些现象：
通常，任务发布人就是业务部门需求方，承接人就是开发人员。但也有例外，完全可以灵活应用，比如我就让开发人员发布任务给业务人员，任务内容就是需求文档，验收人也是开发人员。所以业务人员的需求文档一样要开发人员审核验收，这样就可以提高需求文档的质量，让需求反过来配合开发。
当然，实际工作中，事情往往没有这么简单。需求会不时更改调整，验收也会有疏漏。但正是因为如此，我们才更应该坚持本系列文章所提到的原则。
比如一个任务，需要进行调整。那么，首先看它是不是已经被人承接了？如果还没人承接，OK，随便改；如果已经被承接了，那么就必须得到承接人的许可之后才能修改。承接人的许可有以下作用：
任务验收也是同样的道理。干脆一些，一个任务，验收了，就完了，不要再纠缠了——哪怕以后在其基础上再发现了问题，都不能再“重开”这个任务。
这一个原则的理由很不好讲，算是一种实践体会吧！你如果硬要说，以后又出现的bug是之前一个任务带来的，逻辑上也说得过去，因为确实是他完成那次任务时提交的代码，造成了现在的这个问题。但是，当时谁都没发现啊？！很多代码其实就是这样改过来又改过去，修改代码引起复杂的连锁反应是很正常的事，不能因此就抹杀了这过程中承接人的辛勤劳动吧？这对承接人不公平。
所以，再开一个新任务吧！或者，验收时你就使劲想长远点。如果自己想不到，就不要要求别人能想到。
本文花了大量的篇幅，描述项目开发中，需求从发布到实现以及验收过程中的纠结或问题，就些都是极其常见、反复出现的。看起来这是一沟通问题，很多团队也反复强调沟通，这并没有错。但如何进行有效沟通呢？就像我们说要提高效率，这当然没有错，但这个效率怎么才能提高呢？看到大家在办公室里经常吵架，就拉出去吃个饭喝喝酒消消气，其实治标不治本；就像项目延期，加班加人一样，最终效果如何，我想大家都知道。
所以，我认为，制度或者流程上的改进才是最核心的力量。而明确的责任划分，是其关键。
好像没多少人对项目管理敢兴趣啊？上一篇反响平平，码字这么多，唉……
标签：
原文地址：http://www.cnblogs.com/freeflying/p/4957384.html
