第一个项目经验教训总结

项目背景：

   此项目的客户是一个英国的软件公司，他们主要做设备管理系统、地产管理系统等，这一次是为Hertfordshire政府做一个软件用于各服务点（service point）的数据收集、整理、评估，以前他们是用Excel来处理这些数据的，现在需要将其自动化。后来客户决定将这个软件项目外包，我们公司就争取到了这个项目。

情况介绍：

　　这个项目主要包括两个部分：前台的Web端，主要用于数据收集处理；后台管理端，用于管理用户、制定数据计算标准、导入数据等。

　　我们公司是将其作为一个加班项目来处理的，所谓加班项目也即也是说在每工作日规定的８小时内，不得做此项目，需要自己安排晚上或周末时间来完成任务。若有问题需要与项目成员沟通，则一般采用邮件形式，或者是在中午以及临近下班的时间开小会。在来这个公司前，对此我是闻所未闻的，后来了解到，大约这在外包公司比较常见，项目多任务紧时，为了压缩成本（大概也为了日后考虑），并不会立即招人，而是将部分小项目以加班项目的形式分配下来，当然，项目奖金也是很可观的。然而加班项目无论在成员沟通、时间进度把握以及项目成员的心理认知都会存在一定的问题，所以，这也就为项目后来的进展埋藏了不少的隐患。

　　还值得一提的是，公司的很多项目都是以ODC报价，可是这个项目却采用的是固定报价形式，不管你花多久的时间做，最终成功交付了，才能得到所有钱。这种形式本身没多少不对，可是，有时在一种心理的影响下，可能就会令项目进入一个恶性循环。

　　我是今年６月中旬应聘进入公司的，从另一个测试人员手上接手了这个项目的测试任务。当时了解到，按照最初的计划，还有一个月的时间就该交付系统了，而此前交付某一部分时，因为延期，使得客户很不满意，而原因就是最初低估了工作难度而致实际使用时间大大超过预算。我进入项目组时，成员是这样的，有一个项目经理，一个测试人员，五个开发人员，不过，几天后我明白了，实际只有三个。当时之所以有五个，是因为其中两个才开始介入，为另两个的退出作准备。后来，基本上就是一个负责Win Form，一个负责Web，另一个技术比较牛、负责的项目多，只有当Web有难题时，就会找他出山。在我加入前，包括测试人员的所有项目成员都是把它当作加班项目做的，我因为没有其他项目，所有就当作正常项目来处理了。

在正式介入测试之前，我大概花了三天的时间理解需求，毕竟产品已基本成形，可以一边用一边读需求，直观容易多了。但即使在这种情况下，我在后来的测试中还是渐渐发现当初对很多数据处理的细节方面是没有理解透彻的。那时，摆在我面前的难题有三个：一是所有项目文档都是英文，报告bug也要用英文，尽管我自诩英文读写能力不错，可还是花了好些时间才适应；二是尽管项目已进入中后期，除了mantis上的bug，没有任何测试方面的文档产出，包括测试计划、测试用例等；三，内部成员之间的沟通不及时，因为加班项目的特殊规定，有问题只能等到中午或下午下班后才能沟通，这种情况下，不可避免地会影响测试及至项目进度。

但是后来渐渐发现，问题远不止这三个。由于是外包，我们的直接客户却并非最终客户，这就有两个问题，一是我们提交版本后，他们要测试，然后还要交给最终客户测试，这就使得每次反馈的时间拖长，由于没有新需求做，所以这边就只能处理等待状态；另一方面，最终客户反馈回来的bug，好些都是颠覆了原来的需求，更有甚者，有的还会改过来又改回去如此这般地往返几次，虽然客户不乏真诚地道歉，但是打击项目成员的积极性是不可避免的，同时，以后对于客户再提出的bug，不免报怀疑态度，大大降低了我们对客户的信任度。而对于用户的需求，又只包括了功能方面，对性能等方面的需求，没有在前期沟通确定，导致项目待结束时，客户突然提出，这种性能是不可接受的，我们不得不对Web部分大刀阔斧地进行修改。而后导致的一系列问题的处理，大大延迟了项目的进度。

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

首先检讨我自己，由于介入项目匆忙再加上自己测试能力有限，没有及早地发现某些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. 项目管理上，强硬也许比疲软更有效。即使强硬会让项目成员一时难受，但最终会另整个项目组受益的。

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