结构化和定义在开发过程中的必要性

admin

    由于多数公司没有把新产品开发视为一个过程，他们从不按照开发新产品的需要给要做的工作下定义，甚至连基本术语也没定义，例如，每个项目包括一份职责说明书。说明书的定义对参与项目的每一个人来说都应该很清楚，而不应该被某个工程师认为是一份10页纸的小结，被另一个工程师看作一份60页的文件，更不应该被第三个工程师看作一份400页的文件。

    缺乏统一的术语导致大量的时间和精力被浪费掉了，因为使用这些晦涩难懂过程的人极力想把它搞明白。比较常见的是，会议可能开了不少，但没有什么效果，开会的目的只是了解目前进行的工作。诸如此类的时间浪费，完全是由于缺乏结构所致。（澄清和达成一致的成本很高）

    例如，一家数据通信公司，由于缺乏结构化过程，不得不为进行中的开发工作多花一倍的资源。根据调查，我们发现人们有30％的时间实际花在了产品设计上，而另外70％的时间全浪费在澄清关于正在做什么和由谁做的事情上。另外，由于术语不一致，使产品的技术规范有四个不同的名称和两套定义。

    我们在跨行业的许多公司中调查了好几百个从事产品开发的人，询问他们是如何从结构化开发过程中有所获益，得到的结果非常有趣：

    1．小组间的交接常常出现误解和混乱：

    * 在所有的交接任务中有30％引起了混淆和困惑，既浪费力气，又误导工作，不一而足。换句话说，如果一个项目有三件这种交接任务的话，至少有一件肯定会是一团糟。

    * 有趣的是，22％的工作是在明知混淆和困惑的情况下放行的。原因很多，比如计划不周、执行仓促和纪律松弛等。

    这已经够烦了，但还没完，接到手的工作中还有39％是混乱的。在交接过程中，混乱的工作怎么会从22％增加到39％（相差17％，几乎是原来22％的两倍）呢？这是因为开发过程中不同小组之间关系从根本上说被相互误解了。换句话说，下游部门的需求未能被上游部门理解或欣赏。例如，CAD（计算机辅助设计）部或许不了解生产部的物料清单上需要什么具体的信息和规格，于是就在把任务交接给搞糟了。

    2．由于上游部门出现变化，例如反馈顾客要求太晚、技术规格有错或一些问题被忽略等，造成42％的工作得重做。于是，每五个工作日中有两个被浪费了！ 如果消灭了重复性的工作，开发机构的生产率将会增加72％（有效工作从 58％增加到100％）而不必增加任何人手。

    3．至少有48％的开发工作是“救火”，即解决那些出其不意地冒出的必须立刻加以解决的、无计划的工作。“救火”式的解决办法往往是“贴药膏”，因为时间压力大，资源有限，备选方案有限，而且许多设计已经不能更改了。“救火”式的工作方式是仓促完成的，常常有很多差错。（导致更多的“救火”）

    4．在开发人员个人制定的计划当中，有48％受到经理们或同级部门的质询、怀疑、忽视或被经理们或同级部门否定掉。由于产品开发本身是一个复杂的、涉及多个部门的过程，整个项目的总体进度表是需大量低级进度表的综合而成的。然而，每两个进度表中就有一个被否决。为什么会这样呢？很可能是因为早期的进度表只有45％是准确的！既然早期的进度表常常不准确，因此根本没有人相信它们。还有，管理人员常提出不合理的要求，开发小组就只好扩充进度表。

    5．令人惊讶的是，只有28％的开发工作是全新的，也就是说，72％的工作是熟悉的。如果是这样，为什么上述的问题还出现呢？因为没有结构化过程，没能汲取教训。把开发过程结构化是指把以前所做的72％ 的工作结构化，因为工作流程不畅，阻碍重重，使项目难以进行下去。一旦把这些工作条理化，开发小组就能把精力集中到28％真正新的有创造性的工作上，这才是最具增值的部分。    这些调查结果表明，把开发过程结构化将会带来巨大的机会。