深度剖析项目管理五大痛点及其解决方案（深度剖析项目管理五大痛点及其解决方案）

痛点一：资源不足

讨论背景：
任何一家公司、任何一个部门永远不可能资源充足，管理人员要适应资源不足的常态，故而针对以下问题进行了内部讨论：

需求太多，产品啥都要？
工期紧张，立flag卡时间？
人员有限，有hc招不到人？
依赖太多，状况百出，各种延期？

交流心得：

一、需求太多–排优先级

1.1. 产品
1.1.1. 确保主流程优先
1.1.2. C端用户体验优先
1.1.3. 探讨方案替代(看透需求本质，产品要的是过河，不一定是船/桥)
1.1.4. 产品妥协、降级(先上线，再迭代)
1.1.5. prd需求质量(同频共振，产研理解一致）

1.2. 技术
1.2.1. 复用已有组件/服务
1.2.2. 代码规范性，风格可适当共存
1.2.3. 扩展性(预留2期,3期)
1.2.4. 架构不过度设计
1.2.5. 合二为一(技术类优化可和产品需求合并，一次性开发、测试、上线)
1.2.6. 拔插式(部分服务没改造之前，替代服务先使用，后局部升级)

二、工期紧张–提升效率
2.1. 架构方案折中(没有完美架构，先实现需求，再迭代优化)
2.2. 人员分工(经验丰富更熟练人员做最快)
2.3. 前紧后松(工期往前赶，余留buffer)
2.4. 集中封闭
2.5. 分模块并行提测
2.6. 任务拆解详细(粒度越细，把控更精准)
2.7. 外部依赖协调(高优解决外部，明确需要对方做什么，时间点)
2.8. 同步做(服务、权限、数据库，开发和线上一起申请)
2.9. 做预案 plan B
2.10. 整理上线todoList
2.11. 人员借调支援
2.12. 定时check（站会，晨会，周会）
2.13. 求教高人(技术难点，多问多沟通)
2.14. 当面求教(不限于IM沟通，电话，当面)

三、招不到人–注重平时积累
3.1. 靠介绍(主动找朋友、同事、前同事)
3.2. 自己去平台找(BOSS，拉勾、脉脉)
3.3. 广告(朋友圈、社交平台宣传)
3.4. 外部影响力(公众号、社区、技术答疑引流)
3.5. 推荐奖励
3.6. 提升现有人员能力
3.7. 提升研发效率
3.8. 岗位核心竞争力、岗位亮点
3.9. 适当放宽门槛
3.10. 适当提升福利待遇
3.11. 人脉积累

四、依赖太多–学会适应别人
4.1. 提前节点沟通(立项、开发、联调、测试、上线)
4.2. 主动沟通(必要可升级沟通方式：电话，当面)
4.3. 做预案 plan B
4.4. 风险预警，问题向上升级
4.5. 维护人际关系
4.6. 站在别人角度想(解决他的困扰，eg：陪加班可开车送回家等)
4.7. 上线后感谢信
4.8. 请老板站台
4.9. 自己人(不同部门都有处的好的朋友，通过朋友再推动)
4.10. 先看文档，带着问题结论寻求帮助(服务入参、出参等)
综上，核心三要素：MVP迭代，提升效率/能力，注重平时积累。

痛点二：情绪牵制

关键词：沟通不畅，领导不满意、员工闹情绪

项目经理一个很重要的职能就是沟通协调，多数项目管理人员缺少风险预判能力，当出现面临风险和出现问题时又不能很好地向项目各方反馈，更提不出好的解决方案。比如多数技术转型项目管理人员面对不合理需求时，不敢也不会向客户反馈、更不会向公司领导表述，任务强压给团队成员后，又不能安抚好员工情绪，结果可想而知。对于不懂技术项目管理人员的问题是分析问题（尤其是技术问题）不深入，往往口头禅是这块儿不太懂、这块儿没想到或没想明白，由XXX来说，开个会恨不得能拉上整个团队。回头分配任务，要不就是发号施令，要不就是传声筒，从而逐渐丧失威信。

项目经理作为一线基础管理人员，对外有客户、甲方、用户、监理，对上有领导，对内项目团队成员，需要合理规划、统筹安排、有效沟通才能真正把项目做好。

交流心得：

一、领导不满意

1、信息传递失真
1.1、多讨论
1.2、反讲确认
1.3、快速反馈

2、团队效率不高

3、风险识别不够
3.1、传授方法论
3.2、亲自带着做
3.3、了解上下游
3.4、了解每个人困扰
3.5、多深入一线

4、主动向上汇报

5、主动性热情不够
5.1、权利不够
5.2、价值没说清楚
5.3、引导赞美鼓励
5.4、提升视野、认知
5.5、关键先生
5.6、关系维护

6、下属问题麻烦制造者
6.1、润物细无声，不是针对他，所有人都一样
6.2、配备back up，弥补他
6.3、规范流程、明确制度要求
6.4、能力差—提升技术能力
6.5、粗心大意—责令改进
6.6、陪他一起习惯培养
6.7、准备工作做充分

7、军令状flag变来变去
7.1、调研不充分，信息决策不够
7.2、团队达成不统一
7.3、沟通不够
7.4、粒度粗，不够细致
7.5、转危为机，找更优解

8、描绘很好，结果没执行到位—不切实际给老板吹

9、老板基本工作要求未达成—定期周知老板，及时矫正

10、有担当，不找借口

二、员工闹情绪

1、工作分配不合理
1.1、了解每个人职业诉求，尽量满足
1.2、是否愿意
1.3、工作量太多
1.4、长期固定

2、公众场合被批评—私底下沟通

3、被甩锅、委屈
3.1、帮他澄清
3.2、边界划清楚
3.3、适当安抚
3.4、风险提前周知(事实)
3.5、对结果保证(先于别人之前发现问题)

4、边缘业务，没价值没成长
4.1、轮换制度
4.2、提高要求
4.3、技术赋能
4.4、关停下线(说服大家)
4.5、真诚沟通
4.6、放任务池，等主动认领

5、做得越多、错越多

6、队友不给力
6.1、摆正心态
6.2、互助提高
6.3、宽容、别较真

7、待遇被倒挂
7.1、所做事情要证明价值
7.2、成长性，放权给他
7.3、主动给予

8、荣誉奖励不公
8.1、尽量公平
8.2、考核标准要明确
8.3、透明、公信力
8.4、其它方面补偿
8.5、给最需要的人

9、性格孤僻、与团队不和

10、被领导画大饼

10.1、不要期待太多
10.2、领导尽量言行一致

11、被领导PUA
11.1、量力而行
11.2、容忍性
11.3、听一听就行

12、情绪低落
12.1、团队关怀
12.2、自我调节
12.3、情绪宣泄
12.4、团队荣誉感
综上，面对项目团队负面情绪，作为项目经理要及时感知并调整。最重要的是：把事情做正确。

痛点三：全局迷失

关键词：没有全局规划能力，资源调配失衡，目标不清晰

比较典型是水来土掩兵来将挡型，一事一议，全然没有计划型，结果导致资源调配失衡，不是资源浪费就是资源短缺。往往需求来了，不加以深入分析和设计，就急急忙忙向公司申请一大批开发人员介入，后期又过早把人员释放，导致测试阶段和上线后问题不断，没有人员及时修复系统缺陷。

项目管理人员从接触需求开始，就要全面分析需求、任务拆解、阶段划分、人员配置等一系列工作，建立项目整体计划并按计划推进和资源调配。

交流心得：

一、为什么要分期

1.为什么分期
1.1 项目定位
1.1.1 创新试点类型–最小MVP，敏捷迭代
1.1.2 稳定正常类型–固定跟版制、班车制
1.1.3 专项聚焦类型–集中资源，快速完结

1.2 资源短缺被迫拆解
1.3 外部依赖不可控
1.4 迭代开发，目标清晰
1.5 阶段性验证结果
1.6 规模小，可控制
1.7 最快看到收益
1.8 缓解大项目压力

二、没有规划

2.1 紧急需求插入，节奏被打乱
2.1.1 尽量减少需求插入–提前预知，未来2个版本要做啥
2.1.2 留buffer–积少成多，会导致大时间轴被拉长
2.1.3 政策不可控–长期关注行业政策，提前准备
2.1.4 线上业务逻辑不合理
2.1.5 体验优化类
2.1.6 老板需求–敢于挑战老板(虽然最后还是乖乖做)

2.2 人员变动
2.2.1 留出熟系/交接时间
2.2.2 平时培养backup
2.2.3 文档沉淀–前人栽树后人乘凉，衡量文档写得好不好，看第二个人能不能比第一个人时间更短，更快。
2.2.4 局部模块明确–把业务需求翻译为技术需求，直接开发

2.3 需求不明确
2.3.1 目标不够明确
2.3.2 战略决策调整
2.3.3 逻辑不明确–不同产品顾此失彼，缺乏全盘熟悉，整个项目团队都梳理维护，技术补位
2.3.4 测试用例，分支不够全
2.3.5 边界不清晰
2.3.6 理解不一致，没达成共识
2.3.7 对上下游了解不够

三、资源调配
3.1 项目拆解粒度不够细
3.2 需求理解不一致，不透彻–没考虑问题根本，而是表象
3.3 调研不够充分
3.4 联调阶段，阻塞block
3.5 外部依赖风险评估–可参考已接入案例，上期迭代等
3.6 大量工单走流程、审批–提前了解，提前申请
3.7 永远要有plain B
3.8 对项目里每个人能力有准确了解
3.9 人员规模过大，沟通成本–项目团队规模控制10人以内闭环。

痛点四：角色固化

关键词：忙于细节，忽视角色变化：从拉马车到赶马车

从技术岗转型到管理岗的项目经理人员通病，多数就是因为技术和业务能力比较强，被领导重视和认可，逐渐过渡到带团队，进而转型到项目管理工作。可是角色没有及时调整和转换，更多精力在于技术和业务细节上，忽视了整个项目的协调工作。项目成员不能放手去做，依赖性强，项目经理本身还有一堆文档要写、协调事儿要处理示，结果就是项目经理四处救火，忙得要死，且团队成员也很难独撑一面。

项目经理的作用：正确定义目标、制定项目计划、推动执行、进行团队建设及跨部门协调、保证质量、保证沟通、控制成本、密切监控过程并纠偏等，这样才能保证项目最终的成功。

交流心得：

一、去中心化
1.去中心化
1.1 提前全局规划、分配
1.2. 所有人对项目全局了解(这期功能点，目前进度，哪天测试，哪天上线)
1.3. 提前培养 backup
1.4. 文档沉淀，“错题本”积累
1.5. 责任边界，所有人清晰谁负责哪些模块
1.6. 敢于充分授权，只负责跟进
1.7. 同角色内部多分享，所有人都快速接手
1.8. 项目组内部信息广播，传递(开大会，全员周知，不限于微信群，邮件)

二、流程规范
2.1. 之前做得好的，列出来借鉴
2.2. 兼职pmo，不能只关注自己开发任务
2.3. 整理项目管理清单，每日一问
2.4. 随时把控关键角色
2.5. 关键节点check，有明确各方配合方案
2.6. 达成共识，不同阶段该做什么
2.7. 至少组织3次全员会，需求评审，排期，联调提测

三、到处救火
3.1. 提前评估难度、风险，并做准备
3.2. 子模块业务可以独当一面
3.3. 正确的行动计划(重要&紧急)
3.4. 留出buffer时间
3.5. 做好复盘
3.6. 通过之前案例找到解决方案
3.7. 做事方法论的沉淀
3.8. 提升大家解决问题思路和能力
3.9. 做些通用demo可参考，只负责难点攻坚

痛点五：利益分配

关键词：部门不同，目标不同，利益不同，利益分配的合理性　

　
人们奋斗所争取的一切，都同他们的利益有关，这是马克思的至理名言。人们为团队工作，总要获得利益，或物质的，或精神的。利益的分配，代表着一个人的贡献和成就。必须公平合理，同工同酬，论功行赏，这样才可以调动职工的积极性，提高团队士气；反之，就会引起职工的不满，挫伤职工的积极性，降低团队的士气。

交流心得：

一、多劳多得
(前提是要让所有人认可规则，否则依然不公平)
1.1 项目角色(核心参与者)
1.2 简单配合支持方要感谢(上线邮件、复盘会、当他领导面感谢)
1.3 目标把控者
1.4 过程中表现(平时收集细节)
1.5 项目攻关人物

二、核心价值
2.1 满足用户核心需求(成就感)
2.2 增进不同部门协作
2.3 项目实际收益
2.4 独有性(为什么是我们做)
2.5 关键先生，较大突破

三、平衡未来
3.1 动态看不同角色权重
3.2 提前考虑未来依赖部门
3.3 平时注重挖掘潜力人员

四、分配不合理(负面)
4.1 不愿意配合(外部门)
4.2 消极、应付(项目内成员)
4.3 onwer威望值下降
4.4 得不到认同感，人才流失
4.5 提前与各方领导申请资源，方便协调
上面列举现象中，大部分之前已经给过解决答案，或者问题本来就很简单，不需要展开讨论。综上，希望能对大家在项目管理过程中有所启发。

（来源： 一叶而不知秋 作者：李跃红）