随笔- 15  评论- 310  文章- 0 

工作感言:项目收尾阶段管理

       项目从无到有,中间解决了一个个技术难题,有时为了赶进度,不知加了多少次班,终于到了收尾阶段,看到胜利的署光了,是不是该松口气了,不要忘了黎明前是最黑暗的,这时候对外的交流将更加明显和重要,项目将全部移交给测试人员进行测试,销售、实施人员将拿着产品去给客户演示、实施,中间一但出了问题,处理不当,责任将会像皮球一样踢来踢去,并极有可能上演“狗咬狗”大会。
       项目是否真的到了收尾阶段?对照开始写的需求,是不是所有的功能都搞定,只要有一个没弄好,即使这个功能再小,也是还没做完!当然你可以对外说都弄好了,但到底是怎么回事,自己心里要有数;中国不是有句古话叫宁可欺人,不可欺已,在没有达到收尾的要求时,便要进行相应的延时了,一般的延时有:
      1, 正规延时。到了规定时间做不完。对照需求、任务文档统计每个人未完成的任务,并将未完成的任务重新进行分配(注意要形成任务文档),上报上级,待批准后,按照正常的开发任务一样进行。(最好能把小组的人招集到一起,谈谈为什么出现了延时,找找原因,打打气,延时时间内抓抓紧,因为延时之后再完成不了就说不过去了)
      2, 蒙着延时之占用测试的时间。到了规定时间还有一部分功能未做完,但是测试那里一下子不可能测到所有的功能,把未完成的项目打包交给测试,一般情况下测试的流程跟开发的流程顺序差不多(不是的话,可以跟测试说下),这样的话测试就先测做好的功能,一般会每天上交BUG表,开发的进行更正(同时完成未完成功能),更新程序时一并更新过去即可,神不知鬼不觉??组内的人都知道,潜规则?
      3, 蒙着延时之与客户相互忽悠。功能未能全部完成(中间很可能没有测试环节),但要急着见婆家,只好说做完了,然后去做客户做演示,或先装一个试用,未完成部分能忽悠尽量忽悠(避而不谈、扯东扯西、问东说西等伎俩),客户难免会提修改意见,自然要加时间,这就达到目的了,未完成的功能就可以插到这段时间里面去完成了。

      对于这几种项目延时的方法,尽量使用第一种,规范化操作,是最好的;少用第二种,因为由于各种原因不能进行正规延时(如已经延时了多次),用下这招也是可以的;能不用则不用第三种,个人最痛恨这种方法,延时得很痛苦,拖得越久客户想法越多(新的需求,对开发方有意见),往往不断反复下去,变成无尽的需求。(我在大学里做的项目延时几乎都是第三种延时,苦不堪言;跟朋友交流时,发现不少的公司延时也常常用第三种方法,难道又是潜规则?!)
      对照着需求文档,客户要求的所有功能都实现了,恭喜,项目可以进入到收尾阶段了。剩下的工作分为组内和组外分别进行处理。

小组内部,不过份放松,打起精神,做好后续工作,等待验收完毕。

       不过份放松,打起精神。任务都做完了,辛苦了那么久,当然要放松一下罗,但放松不能过了度,一但超过了度,再做起事来效率好低好几倍(任务是做完了,但随时要做事呀,测试发现了大问题、销售的说客户要加功能等),在这点上我是吃过大亏的:刚开始领一个项目时,做完了,交到相关人员,全体开发人员休息两天,休息回来突然有要求要对一些流程进行修改,发现大家都没劲(包括我),本来按平时的效率做一天就OK了,结果弄了3天,后来回想起来其实也正常呀,试想一下:一群人在跑5000米,跑完了之后一个个都累得躺在地上了,然后突然来个人叫大家再跑50米,谁还跑得动呀!不要过份放松,仅仅向组员说说是不起作用的,本人做法是给他们分配一些其它的工作,来保持一个基本的状态。
(1) 对自己的任务进行测试,发现错误自行进行修改。对测试发现BUG进行更正。
(2) 不足的地方进行改进,哪些地方的代码是体力劳动、重复劳动,能否用技术进行替代。(平时不是说没时间研究技术吗,现在不正是时候么?)
(3) 好的地方继续发扬,哪些模块可以抽象成通用模块,形成通用模块并编写文档,下次开发就省时省力了。
(4) 把一些小问题、小技巧形成文档,下次有疑问一查不就知道了吗?
      上面的工作尤其要注意形成文档,公司的知识库不就是这样丰富起来的吗,个人认为上面的工作(2-3)是比较有意义的,又没有正式任务的压力,即保持了一种开发的状态又适度地放松了自己。

小组外部,明确责任,是自己的不推卸,多交流,不斗气,以解决问题为目的。
      以前听老师说开发与测试是对立,之间矛盾尖锐,当时觉得有点夸张;在实际的操作中发现确实是这样的(特别是有严格的绩效考核、相关利益分配的时候),测试人员以为找出程序中的错误为主要目的,而在程序员这边素有把程序看做自己的孩子这一说,试想一下别人为了找你孩子的错误为乐,你能不着急吗?再加上假如再有销售人员掺和进来,那真的是热闹了,出了问题,三方协调的时候,测试的骂开发:拖延时间造成测试时间不够;销售的反映:程序没及时完成,或质量有问题,或功能不全,使他丢了客户;开发的反骂:测试的对错误的分级不正确,还有销售人员对软件不熟悉,演示时自己造成了失误。。。我一同学戏称这为“狗咬狗”大会(汗,好像他也是其中的一员呀),我想造成这种现象这主要原因是责任不清,交流不够。

对责任划分的一点个人看法
       当前的责任划分模式比较模糊、不明确,出了一个问题,即可以说是销售的,也可以是开发的,还可以说是测试的;更有甚者,发现问题,居然说“只要是与程序有关的就是你们开发的”,我当时就想反问一句“你能找出完全与程序没关的问题来吗?”,可能是这种想法在作怪,出了问题开发的人员都有份,极容易造成开发人员身心疲惫。


个人认为责任要划分要有明确的界线,总结为一句话:谁发现了什么类型的问题责任归属于谁,如图:
      

 

     
 如图中所标1,2,3部分同时对号入座,即可唯一地确定问题责任者。当1,2,3不能对入到相关责任规定时,疑罪从无,本轮不追究责任人;讨论后再形成责任规定,以后按规定执行。
例如:同为一个程序中的严重错误
      假如是客户发现,则是测试人员的责任(因为经过了测试人员的测试,测试人员有责任保证程序中不存在严重的错误)
      假如是测试人员发现,则是开发人员的责任。(这条应该不用说明了吧)

      这样的话,责任划分得一清二楚,对号入座,又怎么总会出现责任推来推去的情况?但我只是开发小组的组长而已,不能将自己的想法实行到小组之外,所以只能够通过多交流来解决问题,虽然治标不治,都总比没的强!

       (写到这里发现文章已经很长了,还有与组外人员交流的一些心得想法没写,作为组长刚开始处理时觉得与组外人员交流很麻烦,因为大家的利益经常是对立,很容易把关系弄僵,但是后来细心观察、思考、实践后,发现一些小技巧,可以巧妙地解决很多问题,又何必大家争得脸红耳赤呢,现在回想起来还是别有一番乐趣的)

posted on 2009-09-18 23:06 小山982 阅读(...) 评论(...) 编辑 收藏