项目日志2-突然的变化

客户方的《工作任务书》原计划应该前天下来,而且《设计规格》也在调整中,由于《设计规格》是我们写需求的依据,没有这个最终稿我们无法对需求进行理解并形成需求规格(这个与该公司合作项目的独特性),因此,我原计划在2月28号开始启动该项目,开开工会,结果只能延后,在昨天与客户的沟通中,得到的答复工作任务书以及设计规格虽说已经调整结束,但还需要评审,基于对该客户流程的理解,评审完成后到达我们手里至少还需要两天时间,而由于该项目时间非常紧,我们必须在4月中旬完成该项目的交付,我只能告诉兄弟们开始基于《设计规格》的初稿（未经过评审和修改的）开始进行需求理解并做需求的分解。

下午得到通知，需要到客户方进行评审《工作任务书》和制定项目计划，4点开始。我们为防止路上塞车，提前出发，结果3点半到达后，客户项目经理告诉他们刚才开了一个会，我们项目中的一部分可能要剥离出去，估计有7K的工作量，原因是我们没有这方面的人才，而且项目验收的质量要求非常高，每千行代码只允许有0.5个缺陷，比原来的标准还要高。并且如果第一次验收如果通不过，只有一次补救机会，第二次验收再通不过将把项目无限期挂起。而且客户方测试部提出他们验收测试时间要用一个月时间，考虑项目五月份要上线，因此要求占用我们半个月的时间，也就是说要在给予我们原来的时间（一个半月）上要抽出半个月时间留给客户方。

把项目中的一部分剥离出去，这是我原来没有想到的，质量要求是无可厚非的，我们要严格控制质量，而且为此项目专门配置了QA人员，专门负责工作进度和质量的监控，而且在工作计划中我也充分考虑了测试的时间，尽管项目周期非常短，只有一个半月，我还是考虑留出1/3的时间提交到测试部进行测试。

由于项目的紧迫性以及客户方也是初次采用这种方式与我们合作，里面会有诸多的苦难和不方便，客户方项目经理对我们是否能按时按质量完成表示了关切。并询问了我们对质量保证的一些做法和项目计划中的详细安排，后来和客户方产品线级的QA进行了交流，由对方QA对我们的计划和质量管理提出了一些建议，并对计划中不合适的地方进行了指正。

　在后来和客户方项目经理讨论了如何保障项目的质量，由于本项目的部分功能已经在其他项目中通过补丁的方式提供了，我们提出了把这些补丁能发给我们，客户方考虑发源代码是受限制的，答应可以给我们编译后的class文件，并要我们提供一个清单发给他，他尽量准备。