项目失控的一个情况-设计与开发脱节

最近在一次问题处理会上，发现一个问题。

系统设计员原来对一个功能的开发，提出了要实现3个功能点/关键点。

项目经理在对用户培训时，也提到3个功能点--对应一些特殊情况的处理。

实际上，系统完成出来，程序员只实现了1个功能点。

---

 

从这个情况反思：

我们做项目，一个项目涉及几百个大小不一的功能点，

首先，让系统设计员把这几百个功能点全部列举出来已经是一项不可能的任务。

其次，在整个开发周期里，让程序员理解全部要开发的功能点，并全部实现开发完成，这也是对程序员一个很高的要求。

然后，用户在听项目经理的介绍和承诺后，自然对产品有一种自己的期望，虽然用户不一定记得全部的承诺，但是，可能会在一些程序员认为小问题上，用户会觉得是关注点 。

 

好了， 既然要实现第1，2点都是很高的要求，那项目经理就不可以把全部的希望寄托在设计员和程序员的自律上。

 

那么有没有什么好方法解决这个问题呢？

 

首先，我的考虑，既然是高要求的事情，你就不能依靠操作者的自律，这个是大前提。不是说操作者肯定做不来，我只是说不能依赖。必须采用另外的辅助手段帮助解决。

 

理想的想法是，由测试组去保证实现。测试组要解决这个问题，因为这个也是测试组成立的一种主要原因。

那么如何做呢？

首先，测试组必须参与系统设计，或者说系统设计员要参加测试组。这个是很重要的一点。

只有测试人员知道要测试的内容，测试的目的，才有可能测试成功。

 

其次，要能实现重复（递归）测试 ，因为，有可能这些功能在一开始就实现了，但在后面的开发中又丢失了。所以，如果没有递归测试的保证的话，对于测试组来说，要完整测试系统，也是一个无法实现的任务。

 

然后，要有变动管理。因为项目的变化是必然存在的，如何管理变化呢？ 这个也是项目管理中一直很头疼的问题。

我的理解，项目变化，不管是从上往下通知，还是从下往上通知，必须最终都集中管理， 并必须让整个团队的相关人员都知道这个变化。

所以，

1。项目统一的变化文档必须要有。

2。团队必须在发生变动前/后，开会以统一信息。其中也要包括了测试组成员。

 

总结一下上面的想法：

要保证落实系统设计的功能全部实现，必须要做到：

1。要有测试组负责项目的全面测试（功能测试、质量测试）

2。测试组成员必须参与系统设计

3。项目的每个变动必须让全部相关人员知道（包括测试组），并有统一文档登记。

4。测试时必须要有递归测试工具辅助循环测试。

5。测试组应超越项目经理，向项目经理的上级负责。