项目管理实践常见困境（四）

1. 我们在项目管理中，如何解决项目瓶颈的问题？如果要做项目的“断舍离”，有哪些好的方法做项目的优先级排序？
2. 我们在项目管理过程中，怎样能更好的做到产品任务拆解和项目工作分解相结合？

3. 项目的阶段管理实践中，有哪些提醒关注的问题？
   

01

—

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

项目场景：

我们在做项目管理的过程中，很多时候都会遇到瓶颈，比如我们做项目的时间不足和资源不够。时间希望延长，延长也许会带来更多的不确定性。资源希望有更多，资源多了也许会造成对项目更高的期望。

问题：

我们在项目管理中，如何解决项目瓶颈的问题？如果要做项目的“断舍离”，有哪些好的方法做项目的优先级排序？

反馈：

不同视角可能关注点不同，举例从产品需求梳理的视角思考项目内的优先。

大块分两级：（可看作是结合了MoSCoW和KANO模型。）

1、第一级：高优先需求。

将面向合规的、核心功能/价值体现的、差异性市场/价值的，归为此类。当然还可以再细分。

这部分从产品视角来看基本处于MoSCoW中的Must级。

2、第二级：一般优先需求。

这也占用主要的优先级评估工作量。

即对满意度提升效果好的。这部分可能与前面提到的差异性市场/价值体现的需求没有明确的分界，需要人为设置一些评估标准区分开。例如细分到KANO模型基本型和兴奋型需求曲线中导数大的部分。这里可以再通过权重的设置，综合考虑收益（含负收益）、成本、风险（含时间）的因素，通过综合评分来确定细分的优先级。

备注：‍‍‍‍‍

这个讨论中，一位老师提出了一个很好的问题：场景问题中是问项目间的优先级还是项目内的优先级？

这个问题提醒我们视野的宽窄对我们应对场景时的关注点的区别。

项目场景：

我们在做项目管理的过程中，会有很多需求需要梳理，也会有很多的任务要交付，项目经理的项目团队成员每天都是非常忙碌。这种场景下，有明确的产品任务分解和明确的活动匹配就显得格外重要。

问题：

我们在项目管理过程中，怎样能更好的做到产品任务拆解和项目工作分解相结合？

反馈：

常见的貌似是先PBS再WBS。（这点待探讨，大家怎么看？）

另外说到PBS还想到一点：要关注拆解后的联系。

可以从两个层面看：

（1）无论是实物组件还是服务模块，通常都是通过最终的整合提供某种能力支撑，为用户的收益达成而服务的，所以模块间的配合机制和接口就需要关注。

（2）模块间的整合不仅仅是简单的拼凑，有时在提供的服务中甚至可能是制约关系，这就更需要从产品用户角度去看，从提供的整体服务带来的整体用户价值/收益来看。

这里要提醒注意区分这几个问题的区别：为什么要做？做什么？怎么做?‍‍‍

PBS和WBS虽然都是分解，但本质差别很大。硬要把PBS和WBS比较，也可以先从为什么做来区分：

PBS是为了用户能获得某个价值而提供的服务产品拆分；

WBS是为了确定谁做什么任务而拆分。

拓展其他老师视角的回复内容：‍‍

【某位老师的反馈】（暂未来得及联系这位老师确认是否可署名）‍‍‍

PBS往下，会与需求管理对应上；WBS往下会与进度计划对应上。一个研究做什么，一个确定如何做，谁来做，什么时候做等方面的问题。

【潘继平老师的反馈】

目的不同：PBS用于明确项目或产品的最终产出物，而WBS用于划分和组织项目的工作任务。

焦点不同：PBS关注于产出物，而WBS关注于工作任务。

结构不同：PBS采用层次结构，将产出物按层次关系分解；而WBS也采用层次结构，将工作任务按层次关系分解。