某项目 V5.0D30项目工作总结

注：本总结只是如实反映项目组状态以及各部门或小组（包括客户）配合情况，目的是把本项目组在开展过程面临的问题描述出来，以期在以后的项目中得到改善和提高，因此本总结不抱有埋怨或者追究责任的态度。希望各相关人不要因此项目总结心存芥蒂。

对客户的问题反映也只把问题暴露出来，目的也只是在以后的项目合作中改善这些问题，以更好更快的速度满足客户的要求，共同更好地为客户提供高质量的版本。同样没有抱怨的意思，也请理解。

本总结将抄送项目组每个相关人以及公司领导和客户项目经理。

总结人：jamesjao

 

本项目从3月2号开始接触，经过项目组所有同事的努力，目前已经项目已经验收通过，尽管项目由于客户和我们的问题引起该项目比预期延长了近十多个个工作日，但项目的总体状况良好，这和项目的每个成员的辛苦是分不开的。

我和开发的大部分同事都是第一次合作，但兄弟们给我的配合以及辛勤工作的态度使人感动。测试的兄弟大部分对业务不熟，但能很快熟悉业务，并且能发现一些比较深层次的问题，总体来说能很好地完成任务。QA的工作很负责任，对各个时间点以及产出监督很到位，在很大程度上保证了整个项目的进度。

在本项目中客户相关人员给予了很大的帮助，***和***在需求和设计阶段为我们解答了很多问题，即使在后期的开发阶段，也通过电话帮助我们。**作为平台的接口人为我们在开发和测试中定位问题给予了有相当价值的指导，使开发少走了不少弯路。

裴芬奇作为客户方项目经理为本项目的开展提供了很大的帮助，积极协调人员为我们解答问题，并对项目开展过程中遇到的困难积极协助我们解决。在测试过程中，为我们争取到某模块的测试环境，在我们测试该模块以及后来验收测试的时候，不论是否是正常上班，只要我们员工过去，都亲自接送。更为难得是***从项目管理角度提了很多建设性的意见，项目顺利开展很大程度上得益于他的帮助。

**在本项目中从头至尾一直在跟踪本项目，由于他负责几个公司的外包项目，非常忙，但也能抽出时间给我们解答问题，本项目的成功和他的辛勤工作是分不开的。这里对他表示感谢。

另外，在资料的开发上客户***给了我们很大的帮助，对文档的问题批注的非常细，使资料开发人员很快明白了问题，并能很快解决。

但项目的开展过程中还是存在一些问题的，问题是多方面的。主要表现在如下方面：

项目管理方面

1，  前期关注不够

由于前期人员没有全部到位，在前期我主要关注人员到位问题，经常面试。在需求和设计阶段，几乎没有时间关注需求和设计，也没能关注文档的质量。这直接影响了后期的开发质量。造成后期测试阶段发现几个地方开发和需求不一致，又重新修改。

2，  任务分配不合理

由于在开发的过程中*部分设了两个项目组长，在任务的分配上有两个组长自己考虑如何分配，尽管在前期我强调了任务分配要合理，主要要考虑相关和类似的任务由一个人处理，不要出现一个任务出现多人参与的情况。但实际的情况是：由于原始需求没能做好需求的合并，项目组长分配任务按照原始需求的编号进行任务，没有先对需求进行整理然后在分配任务。

3， 人员分配不合理

在开发之前，由于对某模块估计过高，投入开发人员5人，但在实际的开发中发现，其实不需要那么多人，实际上大部分的工作两个人都可以搞定，因此在开发过程中某模块人员比较轻松，但某模块人员则需要经常加班，造成人员不能合理运用，不能充分发挥每个人的潜力。后期在系统测试阶段才陆续把某模块开发人员投入到某模块中处理问题单，情况有所好转。

4， 进度控制力度不够

开发这边对需求和设计以及编码实际上每个里程碑点都有延误，当然这些不是一个方面造成的。在需求分析和设计阶段，我们无法及时得到客户模板，并且在写文档的过程中既定模板又做了改动，这在某种程度上造成了时间的延误。在开发阶段，开发的兄弟对编码完成的理解不够到位，总想追求完美，在一个功能上的细节上花费太多时间，影响了其他功能的开发。造成代码Review流于形式，不能发现深层次问题，由于时间不多，单元测试也不充分，第一轮测试发现了300多个问题单，和代码Review以及单元测试力度不够有直捷关系。

5， 需求控制不足

后期由于平台不支持或其他原因，需求变动较大，需求变动只有具体的开发人员知道，没有形成一个统一的文档或者是可追溯的依据，也没能对项目组成员进行通报，造成其他开发人员不知道需求变动，也不能有效通知测试部。尽管我在后来要求把需求变动的地方整理成文档，但由于开发任务较紧，整理出的文档实际上还是不能反映全部的变动。

 

开发方面

1， 需求理解不到位

这主要体现在两个部分，第一是没有人对整个需求都熟悉，这主要是我的失职，我应该对所有需求都熟悉，都需求之间的联系以及与现有版本之间的联系都应该很清楚，但由于我在需求和设计阶段由于招聘新人，没能完全投入了解。第二是开发的有些兄弟对需求不能很好理解，这有一部分原因是对平台的接口不够熟悉，在和**和***沟通的时候由于不清楚平台是否支持，于是对需求进行调整。还有部分同事对彩铃的整体业务不熟悉，在新需求的理解上不够到位。

2， 系统设计没有起到更好的效果

诚然，在系统设计的过程中，对开发人员理解彩铃业务以及平台接口的运用启动了良好的积极作用，但也必须承认的是系统设计对开发并没有起到良好的效果。由于在彩铃业务的开发采用既定的模式，我在设计前曾和两个项目组长强调，我们不需要对每个功能都做详细设计，只对比较大或者复杂功能的部分做设计，但实际上最终对每个功能都做了概要设计和详细设计，在这个阶段投入了过多的没有必要的工作，由于没有把握好重点，在实际开发时，代码中调用的平台接口和设计描述的平台不完全一致。

3， 进度把握有偏差

开发的进度把握总体比较好，但在里程碑点上都有不同程度的偏差，最后造成转测试时间点延迟了一个星期。究其原因，主要在设计上投入了过多时间，代码开发没有把握好工作安排，且开发人员在开发过程中过分关注细节。

4，  平台出现问题定位

由于本彩铃项目是基于平台开发的，在需求，设计，开发以及测试阶段都设计到和平台开发人员打交道（这里要再次感谢**对我们的帮助）。由于无法统一平台相关问题，只能有开发人员自己和**联系，确定平台接口、业务是否支持、以及平台的处理方式等。尽管**一般都给予了解释，但开发人员还是比较被动。也容易产生心理疲劳，影响工作进度。

5， 不够仔细

在转测试之前以及期间，组织过很多次开发人员进行测试，也尽管发现了不少问题，但还是在开发验收期间发现一些不应该出现的问题，比如分页。

6，  人员变动

在项目设计阶段，黄安福被分配到南京办事处，在开发阶段新增员工才到岗，在测试阶段李庚分配到其他项目组这些都对项目造成了一定的影响。后期的测试中原来黄安福负责的部分需求出现和需求不一致的现象，李庚的离开造成他开发的问题不能及时得到解决。另外，新进员工由于在编码前才到位，对需求和整个业务的熟悉需要时间，因此新进员工对整个项目组的作用有限，只是在后期过程中才慢慢能承担任务。

测试方面

1， 不了解业务

测试部的兄弟除了***其他人对彩铃业务不太熟悉，尽管在转测试前由开发做了一次业务培训，但根据后来分析，效果并不明显。因此在测试过程中测试和开发的互动交流超出了预期，对测试的整体计划是个不小的挑战。

2， 进度把握有偏差

由上所述，在和开发交流的过程中熟悉业务，造成测试在计划的时间点内总不能保证完成预期目标。而且在回归测试期测试部不能很好地安排时间，造成测试报告不能按时完成。另外，由于时间紧，性能测试等到第二轮验收测试前才做完。

3，  责任心不强

测试部的兄弟在后期的测试过程中表现出了疲软，甚至到第四轮测试时还在发现一些比如页面提示不明确的问题，不能深刻理解业务，对功能的关联性测试很不充分。另外，测试的某些兄弟竟然在测试过程中有一两天都没有问题单提出来的情况。

在客户验收时发现，我们的验收测试用例不能使用，也就是说按照我们写的测试用例无法进行测试。

资料方面

1， 对客户的资料要求不熟悉

资料的开发我没有重视起来，因此关于资料的开发并没有和客户做过沟通。造成资料部分的问题比较多，尤其是《业务概述》。

资料开发在总体进度上和总体质量上基本都是不错的。但由于客户在开始没有对资料做具体要求，因此在实际的资料开发中有部分不合乎客户的资料要求，尤其是在《业务概述》文档上，验收时，客户提出要按照他们新发的模板重新画流程图，对资料开发员造成不小压力。但这也主要是资料开发人员早期没有和客户资料人员做好沟通造成的。资料开发人员以及我对资料的开发都有想当然的态度，忽略了和客户资料人员沟通具体要求。

 

QA

1，  对CMMI不熟悉，造成要后期补部分文档

由于QA对公司CMMI流程以及要求并不太熟悉，造成后期要补充一些文档，比如里程碑跟踪计划，项目进展报告。另外，在产出物的质量方面，QA的监控力度还是不够。但QA对进度的监控比较到位。

客户方面

1， 相关资料不能及时到位

主要表现在《系统设计规格说明书》我们在3月2号拿到了初稿，之后按照我们公司模板进行需求分析，但后来《系统设计规格说明书》做了调整，尽管是对原有需求做了合并，但对我们已经形成的《需求规格说明书初稿》还是造成了一些影响。《需求规格说明书》在后来按照客户要求又做了格式上的变动，增加了页面跳转图，后来在设计阶段，由于需要对设计裁减，把概要设计和详细设计放到一个文档中形成《软件设计说明书》，但该模板实际上是在以及将要完成的时候才得到。

2， 需求变动较大

前面已经有提到，由于平台不支持改动了部分需求，有不少是在开发过程中改动的。比较典型的是在随意铃开发完成后，后由于平台32不支持而要取消该功能。且这些需求变动没能很好的记录下来，只记录部分内容。还好**对所有变动都比较清楚，才没有造成验收时出现这方面的问题。

3， 基线版本问题无法直接进行开发测试

基线版本的开发环境编译后无法访问平台，后来对基线版本中安装包进行分析，发现基线版本的代码和安装包中的类不一致。也就说代码包和安装包实际上是不一致的，该问题由于开发人员在开发过程中一直通过基线安装包的运行环境做调试，没有及时发现，在我需要检查开发情况时发现。

4，  基线版本提供补丁过多。

在系统就要提交第三轮测试的时候，基线版本提供了11个补丁，这些补丁其中有四个在开发前提供，有2个补丁没有原代码，不能进行升级。后由于电子流也未能及时申请下来，这个两个补丁的代码只有在提交第四轮测试的才更新到版本中。这对开发和测试造成了很大的压力。

5， 后期升级到平台32。

在4月27号将要提供验收版本的时候，V5.0D30需要从平台31移植到平台32上去，同时增加中央音乐平台的功能。后音乐平台需求可以通过一个补丁实现，我们不需要开发。但平台32平台由于电子流的问题直到4月30号才走到我们这里，整体影响了项目进度【五一加班实际上只投入了两天，如果27号能到达我们这里，估计30号晚上即可以提供验收版本了】，而且补丁中无相关连接配置内容。

6， 平台还存在问题

平台存在一些文档上和程序不一致的问题，我们开发过程中在处理这类问题时存在一些困难。而且在测试过程中，因为平台的问题，造成开发人员和测试人员存在争吵。测试人员认为开发人员在逃避问题。而开发人员在和客户确定问题时，总不能得到确认。

以后工作建议与调整：

项目管理方面

项目计划做到精确时间点，多关注里程碑时间点，和QA一起做好计划监控。监控不但要保证按计划完成，更主要是监控每个产出物的质量，切实做好每一段的工作和产出都是保证产品的质量，而避免流于形式。

另外，在任务的分配和人员协调上还需要进一步加强。彩铃项目涉及到多个部门或人员的协作，QA，配置管理员，测试部，资料组，开发以及客户，在本项目中，各个部门的协调比较流畅，整个项目组成员经过本项目的合作，配合还算比较默契，没有出现因部门配合而造成的问题。但在任务的安排上还是欠考虑的，开发内部的任务分工不够明确，甚至出现任务交叉的情况。在以后的工作中要尽量杜绝这种情况。

还有，需要对需求的变动做好记录。由于客户的项目时间都是非常紧的，需求的变更走公司变更流程是很耗时的，但要考虑记录下来每个变动的需求，然后走变更流程。

开发方面

开发目前分为某模块和某模块两个部分，每个部分安排一个主要负责人，该负责人对开发质量以及开发进度负责。

多熟悉彩铃业务，包括对平台的配置、接口、开销户策略、计费策略，减少因业务不熟悉而重新学习的时间，提供开发效率。

项目组成员的工作方法有待于进一步的提高，要养成高效工作的习惯，减少不必要的时间浪费。

测试方面

建议加强业务熟悉，提供业务技能。增强责任心。

资料方面

资料开发人员的业务技能不错的，但需要了解并理解客户资料开发要求，对文档，图表，流程图等要多理解。资料开发是比较细致的工作，资料开发人员对客户要求的文档格式，命名规范要多熟悉，同时还需要对彩铃业务多熟悉，避免业务描述不够准确。

QA

在本项目中QA起到的作用是积极的，很好的监督了项目的进度，但对各个产出物的质量控制不足，工作有些流于形式，不能通过QA活动很好保证产品质量。另外，QA需要加强对CMMI的熟悉，需要按照CMMI3的要求真正监控项目。

客户方面

由于某项目是基于平台开发，规划版本是需要考虑好平台是否支持，对那些平台不支持而某项目也不能提供的功能尽量不要规划在版本中，不然开发过程中等待平台出补丁或者让平台解决都会延误整个项目进度。

另外由于现在的彩铃是基于平台开发，客户需要安排专有人员解答平台相关问题，并能积极协助某项目开发人员进行定位和分析问题，这样可以保证进度，不至于在平台的问题上浪费太多时间。