语言扁平化，统一语言
各方专业术语不同，容易造成理解的偏差。例如，PM这个缩写有项目经理和产品经理两个意思，这也说明了这两个职业早晚会合二为一。关于这个问题，我们稍后再讨论。
举个例子：MFC这个缩写，在研发领域可能指的是微软基础类库，在财务领域可能指的是一种投资方式，在工厂领域可能指的是人工频率控制器。因此，在这种复杂的情况下，过度使用专业术语并不是展示专业能力和技术水平的好方法，而是一种致命的错误。
统一语言是一个值得花费时间去做的事情。这样，后续的会议和沟通将更加顺畅，不会出现两个部门开会却互相听不懂对方在说什么的情况。或者是相互理解都偏离了，各自都认为自己理解了对方的意思。
可以将专业术语转换成通俗易懂的语言，越简单越好，因为越简单，越容易理解。对于无法转换的术语，可以统一收集到术语表中，并在会议或邮件中反复强调。一个小技巧是，主动向领导灌输这些术语，每天都提到，这样大领导都会知道，其他人也会逐渐了解。
用户故事，复杂场景
统一语言之后，后续就好办多了，就是学会讲故事。
把一些需求使用用户故事的形式说出来，因为用户故事更容易被接受和吸收。
例如：
设计软件要实现下单功能，客服后台能查到。
这个需求就很虚，可能了解的人知道是怎么回事儿，要是新来的人估计就蒙了。啥是设计软件?下什么单?往哪下单?要是其他行业的人看见这个需求，更一头雾水了。这就不是一个好的需求，容易造成理解偏差。
改造一下：
(1)自如的客户(有意向租房子的人)，可以登录自如官网，并且可以通过“下单”功能交付付定金。
(2)客服人员，可以登录“订单管理软件”查看传输至自如订单系统供客服人员查询详情(姓名/意向/定金)
通过讲故事的方法，让所有人都能一目了然，清晰的清楚要干什么，这样他们才知道如何配合项目。其他配合的部门也可以通过讲故事的方式配合。
例如：
(1)财务人员登录“财务管理软件”，审批客户已经确认过的客户订单。
(2)财务人员订单审批不通过。通过“驳回”功能，将订单打回到“订单管理软件”
这样通过讲故事的方法，两个部门实现了业务闭环，也都能理解对方在干什么。
产品路线图和里程碑
产品路线图在宏观展示了产品的发展方向，以及大概的时间节点。
产品路线图实际上结合用户故事，很容易让所有人理解我们的产品一步一步的发展，以为产品始终是一个可交付的成果物。
这样把产品路线图，稍微做些改动，按路线图的产品周期划分阶段作为“里程碑”，把产品路线图修改为“里程碑路线图”。
首先，是便于所有人理解，并且都能提出自己所在利益方的意见，毕竟这样的里程碑式一个产品，涉及多利益方。
其次，方便高层知道每个阶段他们能看见什么，重点告诉他们“你看，这个重要的，这个时间点工厂要试产啦”，这样他们有一个划重点的过程，也让他们知道相关的资源，在什么时间该用在哪里。
再则，给 PMO 指明方向，我要干这个，这个不是我一个人能干的，需要各方配合。这样就把一个项目的事情，变成多方参与。
PBS 和 WBS
这里就不展开说 OBS，PBS，WBS 关系了，直接抛出观点，用 PBS 对应 WBS 是比较好的办法!
(1)PBS 更能让人统一目标，清晰的知道我们要干什么。
到执行层这里，故事需要进一步细化，因为干活的人关心的都是性能、指标、参数等等，这样上面的故事对于统一各利益方是够了，当想要干活，还不行，我们需要把大的故事分解成多个子故事，即产品分解结构(PBS)。
(2)PBS 最好也能够用故事展示，然后继续细化，直到故事“易读的”、“便于理解的”、“都懂的”为止。很多可量化的指标都要揉进去。
(3)子故事对应 WBS，故事级别的，基本都是很简单的，这样对应上研发的任务进去，方便追踪和监控，质量也可控!
有很多工具可以支持 PBS->WBS 的对应，具体如何应用可以查询 IPMP 中国业务中心——华鼎维赢的 IPMP 认证知识，里面有 WBS 分解的详细介绍。
里程碑演示，脚本很重要
里程碑展示，是很重要的环节，可以在高管面前刷脸啦~~
(1)一是阶段性汇报，方便后续要奖金，奖金，奖金。
(2)二是阶段性统一目标，让各利益方知道咱们都干出了什么，是否干跑偏了，收集下阶段的信息!
(3)三是让 PMO/高管觉得项目在他们的控制之中。
(4)四是给领导一些信息，因为领导也是需要向上汇报的。
(5)也是给各方一个刷脸沟通的机会，因为里程碑是多方配合完成的。
这样在准备里程碑汇报时，需要充分准备，提前撰写一个详细的“脚本”，明确每个环节的内容，确定谁应该进行演示，感谢谁的支持，以及后续需要谁的大力支持。还要考虑邀请哪些人参与演示，以及如果演示环节出现问题时的备用计划。在这个阶段，你需要扮演导演的角色，因为如果演示失败，之前的努力基本上都会付之东流。
