复杂项目中的管理方法

说一下产品思维对我个人在项目上的一些触动。

　　做过一个很大型的复杂项目，还是国企性质的，涉及政府、工厂、母公司、分公司、供应链等多利益方，协调起来很是头疼。

　　因为他们的小目标并不一致，说简单点就是“你的目标管我啥事儿，我只做配合!”类似的想法，麻烦也就接踵而来了。

　　后续采取的方法是：借助高管的力量，强行统一目标，并且借助PMO的力量，行政手段进行阶段性目标统一。

　　在此感叹一下，不同类似的企业，不同的人，采取的办法各不相同。这类国企类型的公司，因为是战略项目，我的办法就是简单粗暴，找到最高领导，强行压目标!

　　但是呢，每个利益方的“语言”都不相同，运营的、销售、供应链、工厂、政府、法务等等。。。这样如果跟人家每天沟通谈战略，就显得假大空了。

　　所以在这个项目中，引入了产品的思维进来。

　　1、语言扁平化，统一语言

　　各方专业术语不同，容易造成理解的偏差，例如PM这个缩写，就有项目经理和产品经理两个意思，也从说明了这俩职业早晚会合二为一的，关于这个后面再说。

　　比如说：MFC这个缩写，研发理解可能是微软基础类库，财务理解可能是一种投资方式，工厂可能理解是人工频率控制器。所以说，在这种复杂的情况下，飚名词儿不是彰显如何专业，如何NB的，而是很致命的一件事情。

　　就统一语言这个事儿，值得耗费时间去做，这样后续的会议，沟通就会顺畅很多，不至于出现两个部门开会，谁也听不懂对方说什么。或者是相互理解都跑偏了， 各自都觉得理解了对方的意思。关于开会的话题，放在后面说吧，这里就不展开了。

　　可以把术语转换成大白话，越low越好，因为越low，越容易理解。实在转换不了的术语就统一汇总成术语表，在会议/邮件中反复强调，小方法是，主动给领导洗脑，天天说，大领导都知道了，其他人也就知道了。

　　2、用户故事，复杂场景

　　统一语言之后，后续就好办多了，就是学会讲故事，怎么写个好故事就不说了，相关知识自行恶补吧~。

　　把一些需求使用用户故事的形式说出来，因为用户故事更容易被接受和吸收。

　　例如：

　　设计软件要实现下单功能，客服后台能查到。

　　这个需求就很虚，可能了解的人知道是怎么回事儿，要是新来的人估计就蒙了。啥是设计软件?下什么单?往哪下单?要是其他行业的人看见这个需求，跟一头雾水了。这就不是一个好的需求，容易造成理解偏差。

　　改造一下：

　　(1)自如的客户(有意向租房子的人)，可以登录自如官网，并且可以通过“下单”功能交付付定金。

　　(2)客服人元，可以登录“订单管理软件”查看传输至自如订单系统供客服人员查询详情(姓名/意向/定金/)

　　通过讲故事的方法，让所有人都能一目了然，清晰的清楚要干什么，这样他们才知道如何配合项目。其他配合的部门也可以通过讲故事的方式配合，例如：

　　(1)财务人员登录“财务管理软件”，审批客户已经确认过的客户订单。

　　(2)财务人员订单审批不通过。通过“驳回”功能，降订单打回到“订单管理软件”

这样通过讲故事的方法，两个部门实现了业务闭环，也都能理解对方在干什么。

　　3、产品路线图和里程碑

　　产品路线图在宏观展示了产品的发展方向，以及大概的时间节点。

　　产品路线图实际上结合用户故事，很容易让所有人理解我们的产品一步一步的发展，以为产品始终是一个可交付 的成果物。

　　这样把产品路线图，稍微做些改动，按路线图的产品周期划分阶段作为“里程碑”，把产品路线图修改为“里程碑路线图”。

　　首先，是便于所有人理解，并且都能提出自己所在利益方的意见，毕竟这样的里程碑式一个产品，涉及多利益方。

　　其次呢，方便高层知道每个阶段他们能看见什么，重点告诉他们“你看，这个重要的，这个时间点工厂要试产啦”，这样他们有一个划重点的过程，也让他们知道相关的资源，在什么时间该用在哪里。

　　再则，给PMO指明方向，我要干这个，这个不是我一个人能干的，需要各方配合。这样就把一个项目的事情，变成多方参与。

　　4、PBS和WBS

　　这里就不展开说OBS，PBS，WBS关系了，直接抛出观点，用PBS对应WBS是比较好的办法!

　　(1)PBS更能让人统一目标，清晰的知道我们要干什么。

　　到执行层这里，故事需要进一步细化，因为干活的人关心的都是性能，指标，参数等等，这样上面的故事对于统一各利益方是够了，当想要干活，还不行，我们需要把大的故事分解成多个子故事，即产品分解结构(PBS)。

　　(2)PBS最好也能够用故事展示，然后继续细化，直到故事“易读的”、“便于理解的”、“都懂的”为止。很多可量化的指标都要揉进去。

　　(3)子故事对应WBS，故事级别的，基本都是很简单的，这样对应上研发的任务进去，方便追踪和监控。质量也可控!

　　有很多工具可以支持PBS->WBS的对应，自行搜索，避免广告!

　　5、里程碑演示，脚本很重要

　　里程碑展示，是很重要的环节，可以在高管面前刷脸啦~~哈哈~额，低调。。

　　(1)一是阶段性汇报，方便后续要奖金，奖金，奖金。

　　(2)二是阶段性统一目标，让各利益方知道咱们都干出了什么，是否干跑偏了，收集下阶段的信息!

　　(3)三是让PMO/高管觉得项目在他们的控制之中。

　　(4)四是给领导一些信息，因为领导也是需要向上汇报的。

　　(5)也是给各方一个刷脸沟通的机会，因为里程碑是多方配合完成的。

　　这样在准备里程碑汇报的时候，要做足功课，提前写一个“脚本”，把各环节盘清楚，谁该演示什么，要感谢谁，后续需要谁大力支持，邀请谁参与演示，演示环节掉链子怎么办，有没有B计划，这些都是要考虑的。这个时候要化身为导演了。演砸了，前面的努力基本都没了!

　6、额外风险：自主可控需求

再次强调自主可控的重要性，避免客户忽然要支持自主可控，这样的工作量会翻倍，建议在项目概述或建议书中，加入如下话术：

确保国家信息安全与核心技术自立自强，我司将对基于XXX系统的自主可控能力投入建设，具体体现在以下几个方面：

1. 核心技术自主创新，知识产权清晰
2.  本系统为我司原始创新成果，从架构设计、算法模型到核心代码实现，均由我司技术团队独立完成，不涉及任何未授权的第三方代码，核心代码自主率极高，权属清晰，无任何知识产权纠纷，从根本上保证了软件的技术自主性和不可控风险的可规避性。
3. 全面构建安全体系，通过权威测评
4. 系统安全性是自主可控的核心。本系统在设计与开发阶段即内置安全特性，遵循安全开发生命周期（SDL）规范。
5. 深度适配国产生态，保障供应链安全
6. 在硬件与基础软件层面，系统支持与主流国产技术路线的深度适配与优化认证。可稳定高效地部署于国产CPU、国产操作系统、国产数据库及国产中间件之上。

在项目进程中，发生过要替换国产中间件的情况，造成了很大的麻烦，建议把上面的话术粘贴到客户的文档中，让客户明白工作量以及风险，这样会更好的让客户明白工作如何顺利开展。

可以采用类比法或者推测法。

总之，自主可控吃过亏。各位谨记。

-----------------------------------------------------------

20250921更新，现在工作这么卷嘛？项目经理也得画原型了