所以我反复的考虑，觉得还是业务部门说得更有道理一些。这就像货物交割，交货前理应由收货方进行仔细验收，货物到手之后才说我刚才没看清楚要求退货，这肯定是没道理的。对应到软件开发，如果需求方是外部客户，这就涉及到报价预算商业信誉等一系列问题；即使是内部人员，也有可能影响别人的工作安排。所以，承接任务时对需求的审查责任应该在开发人员一方。

同理，任务完成之后，验收的责任就在验收人一方。一旦任务已经被验收合格，今后就不要再说什么当时没考虑周全。

既然确定了这种指导思想或制度，就需要一个顺手的工具来予以贯彻执行。我们任务管理系统的做法就是，把功能切分成一个个的任务，每个任务都有：发布 > 承接 > 验收 三个大的阶段：

(以下统一使用任务表明相关人员，也就是的身份)

在阶段与阶段交接的时候，确立相关人员的责任，具体来说：

任务一旦被承接：

任务一旦被验收：

换言之，这些规则就是针对的下面这样一些现象：

通常，任务发布人就是业务部门需求方，承接人就是开发人员。但也有例外，完全可以灵活应用，比如我就让开发人员发布任务给业务人员，任务内容就是需求文档，验收人也是开发人员。所以业务人员的需求文档一样要开发人员审核验收，这样就可以提高需求文档的质量，让需求反过来配合开发。

当然，实际工作中，事情往往没有这么简单。需求会不时更改调整，验收也会有疏漏。但正是因为如此，我们才更应该坚持本系列文章所提到的原则。

比如一个任务，需要进行调整。那么，首先看它是不是已经被人承接了？如果还没人承接，OK，随便改；如果已经被承接了，那么就必须得到承接人的许可之后才能修改。承接人的许可有以下作用：

任务验收也是同样的道理。干脆一些，一个任务，验收了，就完了，不要再纠缠了——哪怕以后在其基础上再发现了问题，都不能再“重开”这个任务。

这一个原则的理由很不好讲，算是一种实践体会吧！你如果硬要说，以后又出现的bug是之前一个任务带来的，逻辑上也说得过去，因为确实是他完成那次任务时提交的代码，造成了现在的这个问题。但是，当时谁都没发现啊？！很多代码其实就是这样改过来又改过去，修改代码引起复杂的连锁反应是很正常的事，不能因此就抹杀了这过程中承接人的辛勤劳动吧？这对承接人不公平。

所以，再开一个新任务吧！或者，验收时你就使劲想长远点。如果自己想不到，就不要要求别人能想到。

本文花了大量的篇幅，描述项目开发中，需求从发布到实现以及验收过程中的纠结或问题，就些都是极其常见、反复出现的。看起来这是一沟通问题，很多团队也反复强调沟通，这并没有错。但如何进行有效沟通呢？就像我们说要提高效率，这当然没有错，但这个效率怎么才能提高呢？看到大家在办公室里经常吵架，就拉出去吃个饭喝喝酒消消气，其实治标不治本；就像项目延期，加班加人一样，最终效果如何，我想大家都知道。

所以，我认为，制度或者流程上的改进才是最核心的力量。而明确的责任划分，是其关键。

好像没多少人对项目管理敢兴趣啊？上一篇反响平平，码字这么多，唉……

++++++++++ 精华评论答复 ++++++++++++

虽然说的很对，但是解决不了问题，所谓分清责任，一是人都习惯推卸责任，二是即便是分清了又能怎么样？该改的是时候还是得改，因为客户都是甲方。小单子，私活可以不管不顾，可以牛。大项目遇到客户说话时候，还敢说不？你不干后面很多人在排队了

--   这是个非常好的问题。有两种方式解决：

1、把需求和项目管理隔离开来。开发人员不要直接面对最终用户，应该设置一个“门面”或“窗口”，由他们专门的面向客户，了解需求，并将需求转化成一个一个的任务。我待过的一家公司这一点就做得相当好。至少，有了这样一个“隔离墙”之后，开发人员很舒服，至于和最终用户打交道的那些家伙怎么过日子的，呵呵，我就不知道了……

2、站在公司/团队的角度，能挑选用户的时候还是挑一下吧。我做装修的时候就体会到了：有的客户注定是要扯皮的客户，他的钱赚起来太累太累了，不如放弃，这里面还有一个机会成本的问题呢！