A项目在经过最后一个星期的加班赶工，终于可以结束掉前期对客户承诺的阶段性工作了，也从强大的竞争者手中争取到了此项目后期的开发权（因为此项目还有另外一家软件公司在争这个项目的开发权）。虽然算是一个段落的结束，从项目经理的口中也可听出，客户对项目组交付的演示成果物算是“满意”，不过项目经理与项目组员对自己最后的成果，可没那么乐观，后面要做的工作将更加艰巨！作为这个项目的质量保证人员，也很高兴项目组最后能有这样一个结果，起初也是紧捏一口气，生怕这项目最后过不了客户认同这一关。现在总结一下项目这5个月的过程实施情况，希望能够避免掉一些问题的再度发生，同时也希望对其它项目有所借鉴。
1.
缺少整体设计规划与分析
由于A项目前期预研立项时，公司给予的开发周期是3个月，开发人员也只有4人（项目经理要求是6人），要做的功能需求60多个。为了节省项目时间，项目经理决定采用一个已设计好的技术框架，在此框架基础之上进行开发。开发人员进项后，只是大概的对这个已设计好的开发框架进行了一下熟悉，了解了三层开发模式相应的目录路径，没有仔细深入到框架结构设计内容及已存在的一些封装好的公共代码。举个例子，开发组在代码里程碑时，发现每个人写的标签代码都不统一，而且这些标签代码，本身框架中已存在封装好的标签库了，项目组员在写这些标签页花了好些时间，最后被否定。想想看，项目本身仅有三个月宝贵时间，现在还出现无用的无价值的重复劳动，结果会如何?所以，后面项目计划变更也在情理之中了。再则，项目组内没有形成一个统一的界面设计规范，不同的人员设计出来的界面风格迥异。在项目经理检查成员工作成果时，发现此问题后，开了将近一天的界面讨论会，逐一说明了每个页面应该如何去布局与设计。后来的返工时间比预期的多了两倍！！
yobin：几个人的小公司，没法讨论这个。但大公司人多就方便了，只需规范一下流程
2.
业务领域知识缺乏
在编码工作进行到一半时，项目经理与全体项目人员（开发人员，需求人员，开发经理，测试员）开会检查这段时期的开发成果时，有开发人员提出，对项目整体业务流程走向不是很清楚，导致自己负责的模块开发工作实现上有些问题，自己做出来的功能是不是符合项目原本所要求的，没有太大把握。平时项目组员间的沟通也不是很频繁，遇到问题时就自己“潜心研究”，到了任务计划完成期之时，所遇问题仍未有其解。。。造成任务延期。。。使得项目工期延期。。。项目经理责问？由此，后续项目应有所启示，在进入编码阶段之前，确保项目组开发人员熟悉整体业务流程（可以通过组内培训的方式/需求评审方式），知道每一个所要实现功能的前因后果，来胧去脉，这样可以减少开发过程中出现一些问题。同时，对开发过程中所遇问题，如果自己经过了一翻探索后，仍无结果的话，就应该去请较组内的其他开发人员或请求组外相关人员协助解决。
3.
项目组员开发规范意识薄弱
虽然项目组在组织级提供的代码规范基础之上，进行裁剪后形成了本项目的编码规范，并且项目组也统一开了说明会，来讨论了这个编码规范。不过，后期在开发经理进行代码Review时，还是发现有些人员在写代码时，会出现与规范要求不一的地方。个人代码风格很突出，写出来的一些代码，其他人看来很吃力，这不仅会导致项目后期维护工作困难，也会造成后期项目扩展与再开发，不易进行，同时对后期代码的优化与重构工作注入隐患。 还想说的一点是，开发人员在提交自己代码时，应首先进行功能自测与代码自检工作，这是避免返工工作的有效方法，也可为项目节约有限时间。
yobin评：编码规范学习考查、静态检查、代码走查、同行评审等可规避这些现象。
4.
测试矛盾问题
A项目有两位测试人员，其间进了两次项，也出了两次项。在测试人员第二次进项时，测试人员对发布给她们的版本是无法再进行测试了，原因：一是，开发环境与测试环境布署在同一台服务器上，开发那边一有问题重启一下机器，测试这边的工作就跟着断了；二是，项目的整体页面布局与以往相比，是换了一个样，每个界面上都多出了好多内容，这些内容如何获得也无从知晓，再去看看需求人员写的需求文档，文档里也没涉及到这些内容。问及为何不同步更新需求，得到的回应是没时间写，项目再过一个星期就要交付演示，项目全体人员都将精力投放在编码与检查上，根本没时间去完善文档。。。那测试还要不要进行了？测试用例如何去写？经过与项目经理与测试经理的沟通，最后达成的一致意见是，由需求分析人员给测试人员讲解目前做的系统，帮她们理一下思路，知道大体流程的走向。后面主要针对一些重要的模块、容易出错的模块进行测试（这里的测试是无用例的）。
yobin：XP，小团队敏捷开发，利益共同体就可以了。
5.
项目经理对项目的整体进度监控力度不够
yobin：过程改进！
...