记得8月20号从上海出差回来，就直接投入到XX项目测试中，编写用例加系统测试，到现在，只休息过一个周末，其他时间都是加班到晚上9点后。这样的项目，已经参加过三个，每次都是以延长工时来弥补进度落后而告终。作为项目末端环节的执行人，压力倍增。我也曾尝试过通过过程改进来纠正项目的进度，同时也为了维护自己的利益，但终究还是发现一个人的力量太薄弱，抵御不了习惯。眼看下周又要出差投入其他项目，实在是感觉身心俱疲。但无论如何，事情可以没做好，人要成长起来。项目可以失败，但我自己要知道如何改进，尽管这不是我一个人的事。
经历过三个项目，各有各的特点。记得大学时候，学习项目管理这门课程，老师给我们一个案例，如果有一个项目，由于需求变更，导致项目组内成员加班加点，最后终于在最终期限前完成了项目，这算不算是一个成功的项目。当时我选择的是肯定的答案，因为时间上和客户满意度上都没有明显缺陷。但是老师否定了这个项目，其原因有两点，一，需求不应该在项目中途变更，即使变更，也要估量其风险，做相应的调整，一个好的项目必须有好的需求控制；二，项目组内人员加班加点，是项目资源控制不到位，表明项目开始的时候对工作量评估以及资源分配有误，而在出现问题的时候，没有找到合适的解决方案。通过延长工时来干项目进度，是最差的选择。当时对这个案例感触很深，因为我知道了一个成功的项目，不仅是对外，还有对内成功的含义。为什么在项目初期要做工作量评估，要做需求调研，不仅仅是为了能让客户最终在预期的时间内看到满意的产品，也是本着对项目资源负责的态度，让项目资源能够得到充分利用的同时，避免过度利用导致内部满意度降低。我参加的三个项目，都有类似的问题。其中两个都失败在时间上，两个失败在需求不明确上。其实现在大多数项目都有这两个问题。我只是想谈谈我看到的可以改进的方面。
- 先来说说从入职以来就参与的一个项目，是给证券公司做的客户关系管理的业务系统。其实CRM系统已经发展有很长时间了，我所在的部门也已经从1.0做到了3.0。先撇开业务没有积累，开发平台不成熟，人员流动大等因素，从项目本身来讲，这种系统往往券商的个性化需求会比较多，项目是以其中一家券商的需求作为模型来开发的。需求调研大概做了1个月时间，接着进入了开发阶段，1个月后，基础业务框架初步形成，开始进入集成测试，同时进行基础数据采集，即ACRM的开发以及OCRM业务模块的开发，大概2-3个月后，业务模块开发完毕，跳过集成测试，直接进入系统测试，系统测试1个月，拿到现场演示，发现需求不符，很多模块需要重构，便开始了一轮轮的迭代，一个月后，基本功能满足，需要上线。第一次上线失败，由于基础数据采集不正确，因为没有做集成测试，ACRM和OCRM是分开测试的。于是又开始现场开发，重新测试，2个月后，第二次上线失败，原因，不符合业务流程。这时候介入了专业的需求人员开始调研需求，系统重构。这个项目一直拖延至今都不算正式上线。
- 这个问题应该很明显，一开始的需求没有做到位，虽然有过需求调研，但是明显时间不足，而且形成的文档过于抽象，开发人员很多都是参照老系统进行的开发，肯定会与原始需求有误差。
- 项目开始时没有做工作量评估，项目计划过于主观，没有考虑到需求变动因素。
- 作为敏捷开发的项目，要时时刻刻拥抱变化，需要时刻与客户确认需求，问题发现的越早，花费成本越小。
- 项目内人员沟通协调不到位，集成测试需要各模块开发人员互相沟通好，集成测试也不应该有两个测试人员来测。这个项目内有一个角色，模块经理，个人认为模块间的协调应该有一个总揽全局的人来做，或者是架构师，或者是项目经理或技术经理，模块经理显然在这方面没有多加注意。还有很客观问题导致了这个项目的失败，希望最后的补救可以让大家认识到这点。
- 第二个项目，呼叫中心基于新CRM系统框架的整合改版，在做这个项目的时候，正好是基于第一个项目的框架基础，当时第一个项目刚刚出了基线，必然有一些不成熟的因素，也造成了第二个项目延期的原因。但是这个项目显然在时间控制上和整体架构上吸取了上一次的经验，引入了有经验的技术经理把关产品架构，也在我们测试人员的协助下，是项目的整体进度每隔几天都能有一次反馈，无形中起了督促作用。这个项目的问题在于：一个是闭门造车，是模仿之前的老系统，只是根据自己内部人员的意见优化了某些功能，没有任何客户见过需求原型，导致后期在向客户推广的时候得不到认可，需要进行翻新。还有一个是前期测试人员分配不合理，测试时间被压缩的情况下，使用老带新的方式，有可能让双方都感觉很累，老人在测试重要模块的时候，还要教新人，而且有限的时间内，无法顾及新人的一些问题；新人本来就一头雾水的情况下，疑问得不到解答，产生了厌倦的情绪，不能专心测试，测试人员内部沟通不畅，直接会导致产品的质量把关不是很理想。后来也采取过补救措施，比如尝试AB岗交叉测试，或者日报跟踪等方式来促使双方的工作效率提高。
- 第三个项目，薪酬测试。一个已经上线使用了五期的老产品，大幅度改动了薪酬计算方式，以及数据产生流程。项目看似很简单，但是了解过管理系统的人都知道薪酬计算是管理系统中最复杂的一部分，也是核心部分，可以说牵一发而动全身。所以本身对测试人员的要求非常高。这个项目在项目计划的时间分配上就出现了问题，给测试的时间太少了，需求调研持续了一个月，开发持续了将近两个月，测试时间原定20个工作日，最后被压缩到两周。不仅在时间上，项目经理的职责没有做到位，在控制项目进度上也出现了问题，开发的时间一拖再拖，在需求文档已经成形的同时，客户的需求还在不断变更，但需求变更后没有对应提出交付时间变更，导致开发环节测试环节做了不少无用功，只能靠加班加点来弥补。也怪这家客户比较强势，但这种情况下，虽然我们作为乙方，也不能听之任之。原本计划有两个测试人员参与，2*20天的工作量，到了系统测试阶段，就只有我一个测试人员，真是顶着各方压力在加班加点，有苦难言啊。不过幸好我在测试薪酬业务上比较顺手，还是能按时完成任务，不过，我还是认为这个项目失败了，的最大原因就是，内部满意度没有做好。
--------------------------------------------------------------------------------------------------------------------------------
转自：http://www.51testing.com/?uid-478599-action-viewspace-itemid-823421
