|
项目从无到有，中间解决了一个个技术难题，有时为了赶进度，不知加了多少次班，终于到了收尾阶段，看到胜利的署光了，是不是该松口气了，不要忘了黎明前是最黑暗的，这时候对外的交流将更加明显和重要，项目将全部移交给测试人员进行测试，销售、实施人员将拿着产品去给客户演示、实施，中间一但出了问题，处理不当，责任将会像皮球一样踢来踢去，并极有可能上演“狗咬狗”大会。www.mypm.net
项目是否真的到了收尾阶段?对照开始写的需求，是不是所有的功能都搞定，只要有一个没弄好，即使这个功能再小，也是还没做完!当然你可以对外说都弄好了，但到底是怎么回事，自己心里要有数;中国不是有句古话叫宁可欺人，不可欺已，在没有达到收尾的要求时，便要进行相应的延时了，一般的延时有：项目管理者联盟
1， 正规延时。到了规定时间做不完。对照需求、任务文档统计每个人未完成的任务，并将未完成的任务重新进行分配(注意要形成任务文档)，上报上级，待批准后，按照正常的开发任务一样进行。(最好能把小组的人招集到一起，谈谈为什么出现了延时，找找原因，打打气，延时时间内抓抓紧，因为延时之后再完成不了就说不过去了)项目管理者联盟
2， 蒙着延时之占用测试的时间。到了规定时间还有一部分功能未做完，但是测试那里一下子不可能测到所有的功能，把未完成的项目打包交给测试，一般情况下测试的流程跟开发的流程顺序差不多(不是的话，可以跟测试说下)，这样的话测试就先测做好的功能，一般会每天上交BUG表，开发的进行更正(同时完成未完成功能)，更新程序时一并更新过去即可，神不知鬼不觉??组内的人都知道，潜规则?bbs.mypm.net
3， 蒙着延时之与客户相互忽悠。功能未能全部完成(中间很可能没有测试环节)，但要急着见婆家，只好说做完了，然后去做客户做演示，或先装一个试用，未完成部分能忽悠尽量忽悠(避而不谈、扯东扯西、问东说西等伎俩)，客户难免会提修改意见，自然要加时间，这就达到目的了，未完成的功能就可以插到这段时间里面去完成了。项目管理者联盟
对于这几种项目延时的方法，尽量使用第一种，规范化操作，是最好的;少用第二种，因为由于各种原因不能进行正规延时(如已经延时了多次)，用下这招也是可以的;能不用则不用第三种，个人最痛恨这种方法，延时得很痛苦，拖得越久客户想法越多(新的需求，对开发方有意见)，往往不断反复下去，变成无尽的需求。(我在大学里做的项目延时几乎都是第三种延时，苦不堪言;跟朋友交流时，发现不少的公司延时也常常用第三种方法，难道又是潜规则?!)项目管理者联盟
对照着需求文档，客户要求的所有功能都实现了，恭喜，项目可以进入到收尾阶段了。剩下的工作分为组内和组外分别进行处理。www.mypm.net
小组内部，不过份放松，打起精神，做好后续工作，等待验收完毕。training.mypm.net
不过份放松，打起精神。任务都做完了，辛苦了那么久，当然要放松一下罗，但放松不能过了度，一但超过了度，再做起事来效率好低好几倍(任务是做完了，但随时要做事呀，测试发现了大问题、销售的说客户要加功能等)，在这点上我是吃过大亏的：刚开始领一个项目时，做完了，交到相关人员，全体开发人员休息两天，休息回来突然有要求要对一些流程进行修改，发现大家都没劲(包括我)，本来按平时的效率做一天就OK了，结果弄了3天，后来回想起来其实也正常呀，试想一下：一群人在跑5000米，跑完了之后一个个都累得躺在地上了，然后突然来个人叫大家再跑50米，谁还跑得动呀!不要过份放松，仅仅向组员说说是不起作用的，本人做法是给他们分配一些其它的工作，来保持一个基本的状态。项目管理者联盟
(1) 对自己的任务进行测试，发现错误自行进行修改。对测试发现BUG进行更正。项目管理者联盟
(2) 不足的地方进行改进，哪些地方的代码是体力劳动、重复劳动，能否用技术进行替代。(平时不是说没时间研究技术吗，现在不正是时候么?)项目管理者联盟
(3) 好的地方继续发扬，哪些模块可以抽象成通用模块，形成通用模块并编写文档，下次开发就省时省力了。项目管理者联盟
(4) 把一些小问题、小技巧形成文档，下次有疑问一查不就知道了吗?项目管理者联盟
上面的工作尤其要注意形成文档，公司的知识库不就是这样丰富起来的吗，个人认为上面的工作(2-3)是比较有意义的，又没有正式任务的压力，即保持了一种开发的状态又适度地放松了自己。PgMp.mypm.net
小组外部，明确责任，是自己的不推卸，多交流，不斗气，以解决问题为目的。项目管理者联盟
以前听老师说开发与测试是对立，之间矛盾尖锐，当时觉得有点夸张;在实际的操作中发现确实是这样的(特别是有严格的绩效考核、相关利益分配的时候)，测试人员以为找出程序中的错误为主要目的，而在程序员这边素有把程序看做自己的孩子这一说，试想一下别人为了找你孩子的错误为乐，你能不着急吗?再加上假如再有销售人员掺和进来，那真的是热闹了，出了问题，三方协调的时候，测试的骂开发：拖延时间造成测试时间不够;销售的反映：程序没及时完成，或质量有问题，或功能不全，使他丢了客户;开发的反骂：测试的对错误的分级不正确，还有销售人员对软件不熟悉，演示时自己造成了失误。。。我一同学戏称这为“狗咬狗”大会(汗，好像他也是其中的一员呀)，我想造成这种现象这主要原因是责任不清，交流不够。项目管理者联盟
对责任划分的一点个人看法项目管理者联盟
当前的责任划分模式比较模糊、不明确，出了一个问题，即可以说是销售的，也可以是开发的，还可以说是测试的;更有甚者，发现问题，居然说“只要是与程序有关的就是你们开发的”，我当时就想反问一句“你能找出完全与程序没关的问题来吗?”，可能是这种想法在作怪，出了问题开发的人员都有份，极容易造成开发人员身心疲惫。项目管理者联盟
项目管理者联盟
个人认为责任要划分要有明确的界线，总结为一句话：谁发现了什么类型的问题责任归属于谁，如图：项目管理者联盟
项目管理论坛
如图中所标1,2,3部分同时对号入座，即可唯一地确定问题责任者。当1,2,3不能对入到相关责任规定时，疑罪从无，本轮不追究责任人;讨论后再形成责任规定，以后按规定执行。项目管理者联盟
例如：同为一个程序中的严重错误项目管理者联盟
假如是客户发现，则是测试人员的责任(因为经过了测试人员的测试，测试人员有责任保证程序中不存在严重的错误)项目管理者联盟
假如是测试人员发现，则是开发人员的责任。(这条应该不用说明了吧)blog.mypm.net
|
