• home > OMD > PM >

    责任划分-责任划分

    Author:zhoulujun Date:

    “像凡客”,“参考阿里”,“类似QQ”……这些话,我听到就害怕。还不如通过任务切分,把需求一条一条的真正的固化下来,然后我们再开始做。这些土豪客户是绝对没有这种耐心的,你嫌麻烦,整理需求(切分任务)

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

    缘起

     

    有一次,一个朋友约我接一个私活。客户之前已经花了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%的信息会被忽略或误解。所以需求其实也不好弄,这个我们以前提到过,使用测试化文档是一个方法。

     

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

     

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

     

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

     

    工具

     

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

    1. 发布:相当于阐述需求,但同时要指明任务的难度、工作量、完成日期等其他相关属性。

    2. 承接:开始工作,以完成任务

    3. 验收:任务完成后检查是否合格

    (以下统一使用任务发布人/承接人/验收人表明相关人员,也就是责任人的身份)

     

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

     

    任务一旦被承接:

    • 除非承接人同意,其发布内容就不能再更改。任务发布人就必须尽可能的认真对待需求,减少随意修改。但是,

    • 如果任务发布内容有多种合理解释,将按照有利于发布人的原则进行解释。这是不是就要求承接人在承接的时候要慎重,多考虑一下了?

     

    任务一旦被验收:

    • 任务结束,谁都改不了。验收人甭想再回头把“合格”变成“不合格”!

     

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

    1. 不认真发布需求 (人家承接了任务就不能改了哟!)

    2. 不认真审核需求 (出现分歧时按有利于需求发布方解释哟!)

    3. 不认真验收任务 (验收合格就合格了,没后悔药哟!)


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

     

    异常处理

     

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

     

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

    1. 承接人得到及时的通知。必须的!

    2. 给承接人一个机会,考量任务(需求)变动的实质是什么。究竟是新功能覆盖了旧的功能,还是在新功能的基础上添加了其他的功能,或者是两者的混合?进而采取相应的措施,比如建议新加一个任务,拆分原任务再更改等。

    3. 承接人已经付出的劳动应该得到认可。我做都开始做了,是吧?不能不算我的工作量。

     

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

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

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

     

    总结

     

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

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

     

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

     

    本文转自:http://www.cnblogs.com/freeflying/p/4957384.html

     


    转载本站文章《责任划分-责任划分》,
    请注明出处:https://www.zhoulujun.cn/html/Operation/PM/2017_0419_7994.html