为什么花费了那么多时间在文档方面

每逢周一，都需要写上周工作总结和本周工作计划，以及对项目进度进行跟踪比较。今天亦然。看了一下小组内另一同事的上周总结，发现在项目如此紧张的阶段(3月中旬完成所负责模块的所有开发/测试工作，输出概要设计/详细设计/系统测试文档/集成测试文档/单元测试文档，为3月下旬的FDA提交做最后的冲刺)居然一周时间的2/3在做文档工作！！！具体的工作时间分配是：2天输出集成测试方案、0.5天参与及组织系统测试方案评审、1.5天用于更改评审后的系统测试方案、1.5天完成单元测试平台的搭建、0.5天归档另一项目的文档。而原来我和他所商量的计划是上周必须完成2/3的单元测试任务。

为什么有如此大的进度偏差？并且这类的进度预估与实际偏差在我所经历过的几个项目中经常出现。

看完他的周记后，我第一次感觉很有必要需要整理一下此类问题了。

稍微分析了一下近期的相关进度变更和外在的资源冲击等，主要是如下几个原因：

1、系统测试方案不符合专家评审的要求，导致额外多出1~1.5天的整改。此乃历史问题，涉及到系统测试方案/报告的内容组织问题。无论是规格需求到测试点的封闭，乃至测试用例号的划分、测试记录表格是否应该出现在测试报告中，测试用例是按照原有的EXCEL管理还是跟着项目走等问题，之前的做法与其他测试部门的要求和风格不一致，自然在评审中其他部门的老大会提意见。

2、系统测试中几个测试点的测试方法一直未明确，处于TBD状态，期间与整机测试、硬件开发及系统测试人员的沟通过程花费了一些时间。此问题本来在前期与北美那边分公司交流时理应就可以确定的，但整机测试部和算法预研究人员没有重视和解决。

3、将软件转移到VC平台搭建基于CUNIT的单元测试环境时，多花费0.75天时间。这里面有因他是新人的关系，也有本人没有及时给予支持有原因，重要的一个方面是该模块是嵌入式模块软件，移植到VC环境下需要对数据类型、驱动模块等进行更改和隔离，特别是测试代码的组织等方面需要在开发的前期就应该规划好。正常的步骤是该环境的搭建应该是编码时就应该实施，到最后的测试阶段再搭建时暴露出来的问题会影响到代码结构等方面，效率自然低下。

 

 

怎么办？还是两个字:"规划"！

很多工作前期就应该规划好，部门的文档体系应该考虑到产品线的风格统一问题和借鉴一些经验并在部门内各组间形成共识。从概要设计阶段就应该考虑测试架构，编码阶段就应该搭建单元测试环境。

其实这些规范以前都已经确定和制定，并在部分小项目中实施，但一旦到项目紧张阶段，就有点置之于脑后了。

所以，技术经理的审核、组织、关键点检查是很重要的。