|
说起评审，真是让人又爱又恨。 一个重要的文档，如果有专家给出专业的建议，那么不仅文档的质量能有保证，相应的决策也不会有失偏颇。 可是，评审却不是那么好组织的。有时候一次高层评审，需要各个部门的领导参加，可要找齐这些领导却不是那么容易的。领导凑不齐，评审没法进行，只能一拖再拖，给项目的策划和监控都带来一系列的麻烦。这样的事情如果一而再，再而三地发生，项目就会失控，乱成一锅粥。 此类难题，特别是传统的层级管理的组织中，项目团队构成来自不同的部门，一个评审往往要从多个部门找评委的情况，尤为常见。 如何破解这种难题呢？俗语说：大事化小，小事化了。换句话说，就是把复杂的事情简单化。只要把评审的内容按照不同的领域/层级进行拆分，评委相对集中且人员可控，这样分而治之，难题即可迎刃而解。 比如开发计划的评审。项目开发计划是一个综合的计划，包括了软件过程定义、可重用分析、资源计划、进度计划、风险计划、测量计划、评审计划、利益相关方计划……等等。有的计划还集成了质量保证计划、配置管理计划。计划的内容较多，涉及PP、PMC、MA、RskM、IPM、OT、PPQA、CM等多个过程域，特别是利益相关方计划，更是涉及到多个部门的配合，因此开发计划的评审涉及到的人员众多，可以想象这样的评审组织起来有多困难，如果再考虑到计划的变更评审，这个难度还要增加数倍。 但是，如果从分级控制的角度来看，进度计划中的里程碑节点、成本以及资源的投入等内容，才是高层管理者所关注的；其他的很多内容都是为它服务的。这些处于下层的计划内容就不需要由高层来审批，只要项目经理审批就已经足够了。 基于这种观点，要降低计划评审的难度，不妨把项目计划拆分成两个层次的计划：一个是主体计划，不妨把它称为“项目计划”，主要包括那些需要由高层决策的内容。它必须由高层管理者审批（由高层管理者决定采用会签评审还是会议评审）；另一个是下属计划，包括各种为主体计划服务的内容，它由项目经理负责审批。 具体来说，主体计划的内容包括：过程定义、资源计划、成本计划、进度计划。而下属计划则囊括了风险计划、测量计划、质量保证计划、配置管理计划、测试计划等等。 这样分解之后，主体计划的内容相对集中，是高层管理者关注的内容，高层也较容易做出决策，审批的难度下降。另一方面，下属计划虽然种类、数目较多，但都在项目层级，评审也较容易进行。这就是分而治之带来的好处。 这种思想同样适用于其他大而复杂的问题。 引申一下 曾经有单位鉴于评审难的问题，提出了这样一个解决方案：把跨阶段的多个评审打包进行，这样就可以“毕其功于一役”，减少高层评审的次数，也就降低了组织评审的难度。 但是，这种方案是不可取的，且不论把前后不同阶段的工作产品强行打包在一起评审是否合适，仅就这种“打包”的思想就和“大事化小，分而治之”的思想相违背。即使组织的次数少了，但是评审的效果肯定也会下降。在有限的评审时间内完成多个工作产品的评审，而且评委人数众多，一个工作产品可能每个评委一句话的时间都没有，这种评审只能流于形式而已。 参考书目：《软件工程与项目管理解析》 微信赞赏专用通道
|
|
|
