某天，一段对话，给我的触动很大。
W先生：据说在互联网行业，项目经理这个职位已经消失了，转而被产品经理所取代，项目经理都转型了，不知道算不算是坏消息？
X先生：以后的项目管理都是类似于SM这样的人加上自组织去干了。
良子：项目经理这个角色或者职位叫什么不重要，关键是看组织对这个角色的价值定位和职责边界与个人能力是否匹配，如果一个人什么都精通，那么他干哪个角色的活都可以，站在公司或者老板的视角，简直太棒了，肯定在哪儿偷着乐呢。
但这只能说是太完美主义了，毕竟每个人的精力、知识技能、性格等是有限且不同的，大多数情况下：术业有专攻，每个专业有每个专业的价值，但尽可能的拓展多维度知识和实践经验，会对本职工作起到加分的助力作用。
假设，项目经理工作中，那些例行化的工作，团队能自组织且胜任了，那么项目经理就太舒服了，可以多去识别和挖掘更大的组织痛点，例如组织赋能、组织转型、战略型PMO等维度~~~
那么，今天一起聊聊项目经理的价值与生存之道：为团队或组织解决过程痛点并满足职能定位。
感谢C朋友贡献的案例及素材：
公司环境
所属行业：互联网
所在部门：重组后的业务部门
历史情况：项目发起与启动由产品经理说了算，产品经理担当项目经理的角色在管理项目，项目经理后进入公司
项目经理-产品经理-研发团队 三者的工作关系：发起项目时，产品会告知项目经理，团队遇到跨部门协作问题主动找项目经理，项目经理跟产品收集项目信息
人员配置：专职项目经理一名
上级情况：有些许项目管理意识，接触过IPD体系，期望项目经理能输出整个业务的项目进展状况、成本、人员投入、项目优先级排序等信息以供团队管理与决策
组织结构：业务型-职能矩阵
项目经理眼中的问题及做了哪些工作？
场景1-项目管理过程混乱
产品经理对接需求来源，来一个客户需求就做一个项目，项目随时由产品经理发起，直接交付给研发团队开发实现，产品无长期整体规划，无立项流程，项目更没有明确的量化目标，做的好坏没有评价标准，另外，目前没有所有项目的优先级排序、执行团队-人员分配总览。
场景2-研发先行及技术债
基于标准化产品，根据比较宽泛的产品场景，提前做了架构&配置相关的开发，但开发完又经常颠覆式的改，因为与产品后来出的需求偏差较大，一边做新项目一边填坑，跟领导反馈过，这样不合理，但是无反应。
场景3-项目经理的处境
项目的排期、进展、问题、风险及紧急事件等，只对接产品经理，关键节点信息不流经到项目经理这里，一般产品经理自己处理，不习惯CC项目经理，领导层也没有统一说哪些信息同步到项目经理这里；即使个别情况有反馈，信息偏差也比较大：例如某基础产品给客户的版本1.0.2，但实际给到客户的版本是1.0.6了。
场景4-作坊式管理，过程留痕不足
职能Leader层对下属工作任务拆解与把关薄弱，进度等过程信息，只口头沟通。
场景5-帮团队尝试过哪些改变
用Jira给不同的职能，搭建产品需求看板、研发看板，但需求&任务录入太少，几乎用不起来。
当前工作重点及遇到的困难
工作：把整个业务部门的项目信息汇总上报给老板
困难：一手的信息拿不到，过程信息产品经理不CC，拿到的信息不及时
已施办法：用jira来操作，但团队接受度与使用度不高，项目经理只能亲自去问才能得到具体事件（每周或半周，跟产品经理对一下进程）
案例整体诊断与建议：
【表象】
领导层-项目经理-产研团队 对项目经理的【价值定位的期望】 与 【实践操作】之间有偏差，过程信息不流经项目经理
【本质】
项目经理与团队的协作机制不清晰，项目经理需要获取的上层支持未落地，导致 项目经理上下受困
【价值】
1）向下：帮助团队解决，项目执行过程中的跨部门协作问题
2）向上：支持领导了解，业务团队所有项目状况、问题、风险、组织人效与项目优先级统筹等情况
【突破点】
项目信息获取：引入每日站会协作机制，简单可操作，认知学习成本低，收效却快；站会可分层开，项目执行团队以项目为单元，这一层一起开，产品经理主导，项目经理找重点项目团队辅助支持；产品经理这一层一起开，项目经理主导，偶尔邀请老板参与旁听；
人效信息获取：职能总监或者职能部门负责人在管理着职员，信息他们提供最直接，项目经理需要做的准备是：给出标准工具或模板，以及反馈时间。
项目优先级统筹：不改变现状的情况下：直接问产品经理是什么等级即可，所有的项目信息，项目经理可以整合起来，整体看一下各个启动的项目优先级是否有问题，把信息、问题及解决方案反映给老板征求意见，老板认可自然会有改变。改变现状的情况下：在业务部门建立起立项机制，把项目立项标准和准入这关把好，具体方法参考往期文章。
授权问题：以上离不开清晰的职责边界以及领导授权，这需要领导站台。
上层领导其实是愿意帮助员工站台的，但领导一般不站没必要的台，如何获得领导的认同是争取领导支持的关键；获得领导认同的根本决定因素是：能不能给团队及领导带来价值、利益平衡、是否是当前待解决的痛点（而不是问题）。
案例延展：
实施jira-Kanban落地效果不佳，是因为公司的项目管理认知及文化没建立起来，团队成熟度又低，贸然上了这样的工具，团队看不到价值，不认同，一是给大家带来了工作负担，二来，工具实施的真正目的及效果不理想、回收周期太长，且不是最佳选择。
做任何一件非自己独立能完成的工作时，需要思考：
这么做的意义是什么、能给他人带来什么收益、尽量不要触动既得利益者的蛋糕，如果必须动请尽量控制在最小、尽量不要改变大多数人的个人行为习惯，如果必须改变请尽量控制在最小。
项目管理工作，请不要为了做管理而管理，而要为了解决痛点而做，痛是大家的痛，痛是高层关心的痛，解决起来才会稍微顺畅且更有价值。
