成功的项目小组的运作方式如图3-6所示。PAC给核心小组明确的、可衡量的里程碑式目标，同时充分授权他们对开发资源的使用权。

图3-6　成功项目小组的运作情况

核心小组根据与PAC的项目合同承担管理项目的责任，对产品开发中的具体事务做出决策，并且保证组内充分知情，共同参与，得到自主激励，让决策更加有效。

职能部门则为核心小组的决策提供人员和专业技术上的支持，利用授权的项目资金，完成实质性的产品开发工作，对项目的职能卓越负责。

在核心小组与决策机制的联动下，高管在合适的时机参与，既能了解情况，又能将精力集中在制定战略方向和控制上；核心小组为产品开发制定所有实施决策或战术性决策；职能部门负责开发工作落地，让核心小组运作完整高效。

实战案例2：分层决策，打破“白天开会、晚上工作”的怪圈

一家精密仪器公司刚刚成立不久，项目不算多，然而公司的会议却非常多，工作时间基本被大大小小的会议填满。为了产品交付，工程师们只能通过晚上加班的方式来追赶进度。

不仅工程师如此，公司的高层管理者也是如此。公司总裁每周雷打不动地牵头重点项目的项目例会，做出大大小小的决策。而为了能够在例会上表现好，项目经理和团队会前都需要花更长的时间来准备。项目的推进因此慢了下来，毕竟，在总裁点头之前，谁也不敢拍板决定项目的走向。

一般情况是，高层管理者在产品开发中的参与过少，频频引发产品上市前“救火”的情况。而这家公司则恰恰相反，公司高管参与过多，缺少必要的决策结构，导致了时间延迟和中层、基层管理的低效。当公司的项目越来越多，这种模式将难以为继。(www.daowen.com)

如何让决策更高效？不是要减少决策的内容，而是通过结构化、系统化的会议机制，在不同层级的会议上决定该层级能决策的问题，即所谓的“分层决策”。一方面，通过分层决策，将小问题留在日常解决，大问题才上升至高层，充分调动基层、中层管理者的主人翁意识，节省高层管理者的精力和时间。另一方面，通过分层会议，工程师们需要参加的会议大大减少了，会议议题更聚焦了，再也不用将工作时间花费在开会和去开会的路上了。

经过梳理，我们帮助这家公司将产品会议划分为3个层级：项目例会、技术评审会议和阶段评审会议，并制定不同会议的参与人员。

项目例会由项目核心小组参与，确认项目目标、进行产品构思和方案设计、决定项目计划、跟踪项目进度、解决项目核心小组的协作配合问题。

技术评审会议，顾名思义，是由核心小组中的研发代表汇报、聚集企业的技术专家评审，判断技术方案是否可行，识别潜在技术问题和风险的会议。

阶段性评审则由核心小组组长向PAC汇报，决策产品的关键卖点、评估商业表现，决定公司是否需要继续投入资源，推动项目进展。

根据这家公司的实际情况，我们并没有照搬所有的决策点，而是结合公司已有的高层经营会议，对阶段评审点进行了一定程度的精简。在产品全生命周期的7个阶段中，公司仅在计划阶段和验证阶段结束时保留了决策点，做出通过或不通过的决定。因为在这家公司，这两个阶段决策点对资源投入的影响最大。而其他阶段结束时，项目小组则仅需要在公司高层经营会议上，汇报项目进展和情况。参会的高层管理者扮演指导员的角色，帮助项目小组认识风险，指导他们更好地进行工作。这种安排更加灵活，一方面，对公司原有的运作模式改变较小；另一方面，大大减少了“项目排队”的问题。也就是说，各种项目在每个阶段点结束时，不需要堆积在一起，排队等候大型的评审会议作出决策后，再进入下一阶段。

这样的改变得到了公司上下一致的认可。公司CTO认为，原来各领域专家都分布在各个职能中，没有机制把他们聚集在一起。有时候关键时间错过了，公司才发现风险，造成浪费。通过结构化的技术评审会议，这些专家能够聚集起来，共同讨论技术方案，力量更集中，技术风险的管控也更到位了。

而阶段性评审也获得了许多高层管理者的欢迎，公司的产品总监表示，优化后的阶段性评审对产品的市场、特性、销售分析都更加到位。更重要的是，因不同的项目采用一致的分析方法和口径，高层管理者可以将项目放在同一层面进行比较，投资决策也更全面、更有效。