上面都只说的是一些比较客观的原因，有些主观原因也是不可规避的。

首先检讨我自己，由于介入项目匆忙再加上自己测试能力有限，没有及早地发现某些bug；另外，自己在某些方面的认识上，也有待加强，以web的性能为例，一直以来，我都觉得速度不理想，尤其是数据大的情况下，但当时考虑到页面处理的特殊性（每个页面似一个excel的sheet，每个cell里都包含有控件，并且cell与cell之间还有大量的数据关联处理，而客户又要求不分页处理）以及客户没提这方面的需求，我也没有这认为应该作为一个bug报告出来，而待项目接近尾声时，客户却要求我们改进性能。在采用了诸多方法，均达不到用户理想的速度时，终通过与客户沟通，采用了分页形式。如果我能够不把眼光局限于浅显的bug，而多从整体或是用户角度去考虑，这个问题或许可以早日提出解决，也不会引起那么多的后续问题。后，作为一句测试人员，我不应该放弃原则。前面已经说过，这个项目是固定报价，项目拖得越久于我们而言是越不利的，可在这种因素的影响下，我们项目时间大大逾期，大家尤其是开发人员不免急躁。同时，由于客户多次报一些与起初需求不符的bug，也令开发人员莫名窝火。在这种情况下，bug分为两类对待了，客户报的都是高优先级，测试人员报的都是低优先级，并且总是认为只要不是太严重，且客户没报不修改也罢。后果可想而知，一方面，bug总归是bug，始终还是要被客户发现的；另一方面，对于测试人员而言，这是一种比较尴尬的境遇，很容易产生消极心理。

对于整个项目而言，除去因是加班项目而引起的一些沟通不及时的问题而外，也还存在一些问题。比如，需求方面不完整，这又得提到性能问题了，如果在初沟通需求时，在此问题上能与客户达到一致，在设计过程中，必不会漏考虑这块儿。还有，文档不完善，即至项目完成，除需求文档、bug报告而外，仍没有其他文档产品，这于一个项目而言是危险的。另外，责任心问题，在项目中出现过多次这种情况，对于一个bug，开发人员始终认为无法处理，而在客户一直强调要解决的时候，后还是想办法fix了，当然很多时候是那位比较牛的开发人员露面了。如果遇上这种问题后，多沟通或者是有更强的责任心，也不会令客户光火。后，在项目管理上，或许还是有些疲软，尤其是后期阶段，在所有项目成员心思都比较涣散时，项目管理人员应该更坚持原则。

说了这么多，全是问题，其实闪光点也是不缺的。比如，虽然沟通不便，大家也会抽出时间定期开小会，介绍自己的情况及问题；还如，当项目组遇上了难题时，大家能够齐心协力地想办法解决掉；另外于我而言，才进公司时，项目经理给了我很大的帮助和信心，而在初阶段，有时报的bug不正确或是难以理解，开发人员也没有责难；等等。作为我进入公司后的第一个合作团体，他们之中的每一个人我都是很感激的。

总结：

此项目终于在计划的deadline之后几月的11月中旬成功交付，在拖了如此之久后，大家心里已没多少成功的喜悦。前事不忘，后事之师，于我而言，在忘掉这个项目之前，做做总结也许是很重要的。当然，有了前面这一大篇幅的铺垫，总结将是十分简洁的：

1. 需求沟通阶段，一定要尽可能地考虑全面，不只是功能、界面，还包括可接受的性能标准等方面。

2. 在项目启动之初，应该确定合理的内部沟通方式，确保不会因为沟通障碍影响项目成员及至整个项目组的进度。

3. 无论时间多紧迫，必要的文档还是要有的，哪怕只是一个大纲也好。

4. 无论是测试人员还是开发人员，遇上问题要尽早抛出，即使不一定得修改，拿出来讨论后大家有了这样一个意识，总错不了。

5. 遇上解决有难度的问题，应该只有两种方法：一是想尽一切办法（如请教高手）解决；二是让客户了解解决的成本，希望他能妥协放弃，而不应该有第三种：拖延。

6. 无论是对于bug，还是对于客户，任何时候，我们都不应该抱有侥幸心理。作为项目成员，每一个都应该对质量负责，而不应该只是测试人员，更不应该是客户。

7. 项目管理上，强硬也许比疲软更有效。即使强硬会让项目成员一时难受，但终会另整个项目组受益的。

大约因为自己是公司项目规范检查小组的成员之一，不禁会考虑到这诸多方面。而自己加入公司不久，所处的项目又有如此多的问题，所以当我检查其他人时，总会有些心虚。不过，意识到了是一个好现象，待等到机会加入一个新项目，我希望自己能做得更好。