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