项目从无到有，中间解决了一个个技术难题，有时为了赶进度，不知加了多少次班，终于到了收尾阶段，看到胜利的署光了，是不是该松口气了，不要忘了黎明前是最黑暗的，这时候对外的交流将更加明显和重要，项目将全部移交给测试人员进行测试，销售、实施人员将拿着产品去给客户演示、实施，中间一但出了问题，处理不当，责任将会像皮球一样踢来踢去，并极有可能上演“狗咬狗”大会。

　　项目是否真的到了收尾阶段？对照开始写的需求，是不是所有的功能都搞定，只要有一个没弄好，即使这个功能再小，也是还没做完！当然你可以对外说都弄好了，但到底是怎么回事，自己心里要有数；中国不是有句古话叫宁可欺人，不可欺已，在没有达到收尾的要求时，便要进行相应的延时了，一般的延时有：

　　1、正规延时。到了规定时间做不完。对照需求、任务文档统计每个人未完成的任务，并将未完成的任务重新进行分配（注意要形成任务文档），上报上级，待批准后，按照正常的开发任务一样进行。（最好能把小组的人招集到一起，谈谈为什么出现了延时，找找原因，打打气，延时时间内抓抓紧，因为延时之后再完成不了就说不过去了）

　　2、蒙着延时之占用测试的时间。到了规定时间还有一部分功能未做完，但是测试那里一下子不可能测到所有的功能，把未完成的项目打包交给测试，一般情况下测试的流程跟开发的流程顺序差不多（不是的话，可以跟测试说下），这样的话测试就先测做好的功能，一般会每天上交BUG表，开发的进行更正（同时完成未完成功能），更新程序时一并更新过去即可，神不知鬼不觉？？组内的人都知道，潜规则？

　　3、蒙着延时之与客户相互忽悠。功能未能全部完成（中间很可能没有测试环节），但要急着见婆家，只好说做完了，然后去做客户做演示，或先装一个试用，未完成部分能忽悠尽量忽悠（避而不谈、扯东扯西、问东说西等伎俩），客户难免会提修改意见，自然要加时间，这就达到目的了，未完成的功能就可以插到这段时间里面去完成了。

　　对于这几种项目延时的方法，尽量使用第一种，规范化操作，是最好的；少用第二种，因为由于各种原因不能进行正规延时（如已经延时了多次），用下这招也是可以的；能不用则不用第三种，个人最痛恨这种方法，延时得很痛苦，拖得越久客户想法越多（新的需求，对开发方有意见），往往不断反复下去，变成无尽的需求。（我在大学里做的项目延时几乎都是第三种延时，苦不堪言；跟朋友交流时，发现不少的公司延时也常常用第三种方法，难道又是潜规则？！）

　　对照着需求文档，客户要求的所有功能都实现了，恭喜，项目可以进入到收尾阶段了。剩下的工作分为组内和组外分别进行处理。

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

　　不过份放松，打起精神。任务都做完了，辛苦了那么久，当然要放松一下罗，但放松不能过了度，一但超过了度，再做起事来效率好低好几倍（任务是做完了，但随时要做事呀，测试发现了大问题、销售的说客户要加功能等），在这点上我是吃过大亏的：刚开始领一个项目时，做完了，交到相关人员，全体开发人员休息两天，休息回来突然有要求要对一些流程进行修改，发现大家都没劲（包括我），本来按平时的效率做一天就OK了，结果弄了3天，后来回想起来其实也正常呀，试想一下：一群人在跑5000米，跑完了之后一个个都累得躺在地上了，然后突然来个人叫大家再跑50米，谁还跑得动呀！不要过份放松，仅仅向组员说说是不起作用的，本人做法是给他们分配一些其它的工作，来保持一个基本的状态。

　　（1）对自己的任务进行测试，发现错误自行进行修改。对测试发现BUG进行更正。

　　（2）不足的地方进行改进，哪些地方的代码是体力劳动、重复劳动，能否用技术进行替代。（平时不是说没时间研究技术吗，现在不正是时候么？）

　　（3）好的地方继续发扬，哪些模块可以抽象成通用模块，形成通用模块并编写文档，下次开发就省时省力了。

　　（4）把一些小问题、小技巧形成文档，下次有疑问一查不就知道了吗？

　　上面的工作尤其要注意形成文档，公司的知识库不就是这样丰富起来的吗，个人认为上面的工作（2-3）是比较有意义的，又没有正式任务的压力，即保持了一种开发的状态又适度地放松了自己。

　　小组外部，明确责任，是自己的不推卸，多交流，不斗气，以解决问题为目的。

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

对责任划分的一点个人看法

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

 

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

 

 

如图中所标1，2，3部分同时对号入座，即可唯一地确定问题责任者。当1，2，3不能对入到相关责任规定时，疑罪从无，本轮不追究责任人；讨论后再形成责任规定，以后按规定执行。

　　例如：同为一个程序中的严重错误

　　假如是客户发现，则是测试人员的责任（因为经过了测试人员的测试，测试人员有责任保证程序中不存在严重的错误）

　　假如是测试人员发现，则是开发人员的责任。（这条应该不用说明了吧）

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

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