项目管理痛点
Posted Impl_Sunny
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了项目管理痛点相关的知识,希望对你有一定的参考价值。
一、资源不足
讨论背景:
任何一家公司、任何一个部门永远不可能资源充足,管理人员要适应资源不足的常态,故而针对以下问题进行了讨论:
- 需求太多,产品啥都要?
- 工期紧张,立flag卡时间?
- 人员有限,有hc招不到人?
- 依赖太多,状况百出,各种延期?
1.1 需求太多--排优先级
产品方面 | 确保主流程优先 |
C端用户体验优先 | |
探讨方案替代(看透需求本质,产品要的是过河,不一定是船/桥) | |
产品妥协、降级(先上线,再迭代) | |
prd需求质量(同频共振,产研理解一致) | |
技术方面 | 复用已有组件/服务 |
代码规范性,风格可适当共存 | |
扩展性(预留2期,3期) | |
架构不过度设计 | |
合二为一(技术类优化可和产品需求合并,一次性开发、测试、上线) | |
拔插式(部分服务没改造之前,替代服务先使用,后局部升级) |
1.2 工期紧张--提升效率
- 架构方案折中(没有完美架构,先实现需求,再迭代优化)
- 人员分工(经验丰富更熟练人员做最快)
- 前紧后松(工期往前赶,余留buffer)
- 集中封闭
- 分模块并行提测
- 任务拆解详细(粒度越细,把控更精准)
- 外部依赖协调(高优解决外部,明确需要对方做什么,时间点)
- 同步做(服务、权限、数据库,开发和线上一起申请)
- 做预案 plan B
- 整理上线todoList
- 人员借调支援
- 定时check(站会,晨会,周会)
- 求教高人(技术难点,多问多沟通)
- 当面求教(不限于IM沟通,电话,当面)
1.3 招不到人--注重平时积累
- 靠介绍(主动找朋友、同事、前同事)
- 自己去平台找(BOSS,拉勾、脉脉)
- 广告(朋友圈、社交平台宣传)
- 外部影响力(公众号、社区、技术答疑引流)
- 推荐奖励
- 提升现有人员能力
- 提升研发效率
- 岗位核心竞争力、岗位亮点
- 适当放宽门槛
- 适当提升福利待遇
- 人脉积累
1.4 依赖太多--学会适应别人
- 提前节点沟通(立项、开发、联调、测试、上线)
- 主动沟通(必要可升级沟通方式:电话,当面)
- 做预案 plan B
- 风险预警,问题向上升级
- 维护人际关系
- 站在别人角度想(解决他的困扰,eg:陪加班可开车送回家等)
- 上线后感谢信
- 请老板站台
- 自己人(不同部门都有处的好的朋友,通过朋友再推动)
- 先看文档,带着问题结论寻求帮助(服务入参、出参等)
以上是交流心得,综上核心三要素:MVP(最简可行化分析)迭代,提升效率/能力,注重平时积累。
二、情绪牵制
关键词:沟通不畅,领导不满意、员工闹情绪
项目经理一个很重要的职能就是沟通协调,多数项目管理人员缺少风险预判能力,当出现面临风险和出现问题时又不能很好地向项目各方反馈,更提不出好的解决方案。
比如多数技术转型项目管理人员面对不合理需求时,不敢也不会向客户反馈、更不会向公司领导表述,任务强压给团队成员后,又不能安抚好员工情绪,结果可想而知。对于不懂技术项目管理人员的问题是分析问题(尤其是技术问题)不深入,往往口头禅是这块儿不太懂、这块儿没想到或没想明白,由XXX来说,开个会恨不得能拉上整个团队。回头分配任务,要不就是发号施令,要不就是传声筒,从而逐渐丧失威信。
项目经理作为一线基础管理人员,对外有客户、甲方、用户、监理,对上有领导,对内项目团队成员,需要合理规划、统筹安排、有效沟通才能真正把项目做好。
2.1 领导不满意
问题 | 分析&解决 |
信息传递失真 | 多讨论 |
反讲确认 | |
快速反馈 | |
风险识别不够 | 传授方法论 |
亲自带着做 | |
了解上下游 | |
了解每个人困扰 | |
多深入一线 | |
主动性热情不够 | 权利不够 |
价值没说清楚 | |
引导赞美鼓励 | |
提升视野、认知 | |
关键先生 | |
关系维护 | |
下属问题麻烦制造者 | 润物细无声,不是针对他,所有人都一样 |
配备back up,弥补他 | |
规范流程、明确制度要求 | |
能力差—提升技术能力 | |
粗心大意—责令改进 | |
陪他一起习惯培养 | |
准备工作做充分 | |
军令状flag变来变去 | 调研不充分,信息决策不够 |
团队达成不统一 | |
沟通不够 | |
粒度粗,不够细致 | |
转危为机,找更优解 |
2.2 员工闹情绪
问题 | 分析&解决 |
工作分配不合理 | 了解每个人职业诉求,尽量满足 |
是否愿意 | |
工作量太多 | |
长期固定 | |
公众场合被批评 | 私底下沟通 |
被甩锅、委屈 | 帮他澄清 |
边界划清楚 | |
适当安抚 | |
风险提前周知(事实) | |
对结果保证(先于别人之前发现问题) | |
边缘业务,没价值没成长 | 轮换制度 |
提高要求 | |
技术赋能 | |
关停下线(说服大家) | |
真诚沟通 | |
放任务池,等主动认领 | |
做得越多、错越多 | |
队友不给力 | 摆正心态 |
互助提高 | |
宽容、别较真 | |
待遇被倒挂 | 所做事情要证明价值 |
成长性,放权给他 | |
主动给予 | |
荣誉奖励不公 | 尽量公平 |
考核标准要明确 | |
透明、公信力 | |
其它方面补偿 | |
给最需要的人 | |
性格孤僻、与团队不和 | |
被领导画大饼 | 不要期待太多 |
领导尽量言行一致 | |
被领导PUA | 量力而行 |
容忍性 | |
听一听就行 | |
情绪低落 | 团队关怀 |
自我调节 | |
情绪宣泄 | |
团队荣誉感 |
以上是交流心得,综上面对项目团队负面情绪,作为项目经理要及时感知并调整。最重要的是:把事情做正确。
三、全局迷失
关键词:没有全局规划能力,资源调配失衡,目标不清晰
比较典型是水来土掩兵来将挡型,一事一议,全然没有计划型,结果导致资源调配失衡,不是资源浪费就是资源短缺。往往需求来了,不加以深入分析和设计,就急急忙忙向公司申请一大批开发人员介入,后期又过早把人员释放,导致测试阶段和上线后问题不断,没有人员及时修复系统缺陷。
项目管理人员从接触需求开始,就要全面分析需求、任务拆解、阶段划分、人员配置等一系列工作,建立项目整体计划并按计划推进和资源调配。
3.1 为什么要分期
为什么要分期 | 项目定位 |
创新试点类型--最小MVP,敏捷迭代 | |
稳定正常类型--固定跟版制、班车制 | |
专项聚焦类型--集中资源,快速完结 | |
资源短缺被迫拆解 | 外部依赖不可控 |
迭代开发,目标清晰 | |
阶段性验证结果 | |
规模小,可控制 | |
最快看到收益 | |
缓解大项目压力 |
3.2 没有规划
问题 | 分析&解决 |
紧急需求插入,节奏被打乱 | 尽量减少需求插入--提前预知,未来2个版本要做啥 |
留buffer--积少成多,会导致大时间轴被拉长 | |
政策不可控--长期关注行业政策,提前准备 | |
线上业务逻辑不合理 | |
体验优化类 | |
老板需求--敢于挑战老板(虽然最后还是乖乖做) | |
人员变动 | 留出熟悉/交接时间 |
平时培养backup | |
文档沉淀--前人栽树后人乘凉,衡量文档写得好不好,看第二个人能不能比第一个人时间更短,更快。 | |
局部模块明确--把业务需求翻译为技术需求,直接开发 | |
需求不明确 | 目标不够明确 |
战略决策调整 | |
逻辑不明确--不同产品顾此失彼,缺乏全盘熟悉,整个项目团队都梳理维护,技术补位 | |
测试用例,分支不够全 | |
边界不清晰 | |
理解不一致,没达成共识 | |
对上下游了解不够 |
3.3 资源调配
- 项目拆解粒度不够细
- 需求理解不一致,不透彻--没考虑问题根本,而是表象
- 调研不够充分
- 联调阶段,阻塞block
- 外部依赖风险评估--可参考已接入案例,上期迭代等
- 大量工单走流程、审批--提前了解,提前申请
- 永远要有plain B
- 对项目里每个人能力有准确了解
- 人员规模过大,沟通成本--项目团队规模控制10人以内闭环。
四、角色固化
关键词:忙于细节,忽视角色变化:从拉马车到赶马车
从技术岗转型到管理岗的项目经理人员通病,多数就是因为技术和业务能力比较强,被领导重视和认可,逐渐过渡到带团队,进而转型到项目管理工作。可是角色没有及时调整和转换,更多精力在于技术和业务细节上,忽视了整个项目的协调工作。项目成员不能放手去做,依赖性强,项目经理本身还有一堆文档要写、协调事儿要处理示,结果就是项目经理四处救火,忙得要死,且团队成员也很难独撑一面。
项目经理的作用:正确定义目标、制定项目计划、推动执行、进行团队建设及跨部门协调、保证质量、保证沟通、控制成本、密切监控过程并纠偏等,这样才能保证项目最终的成功。
交流心得:
目标 | 分析&解决 |
去中心化 | 提前全局规划、分配 |
所有人对项目全局了解(这期功能点,目前进度,哪天测试,哪天上线) | |
提前培养 backup | |
文档沉淀,“错题本”积累 | |
责任边界,所有人清晰谁负责哪些模块 | |
敢于充分授权,只负责跟进 | |
同角色内部多分享,所有人都快速接手 | |
项目组内部信息广播,传递(开大会,全员周知,不限于微信群,邮件) | |
流程规范 | 之前做得好的,列出来借鉴 |
兼职pmo,不能只关注自己开发任务 | |
整理项目管理清单,每日一问 | |
随时把控关键角色 | |
关键节点check,有明确各方配合方案 | |
达成共识,不同阶段该做什么 | |
至少组织3次全员会,需求评审,排期,联调提测 | |
到处救火 | 提前评估难度、风险,并做准备 |
子模块业务可以独当一面 | |
正确的行动计划(重要&紧急) | |
留出buffer时间 | |
做好复盘 | |
通过之前案例找到解决方案 | |
做事方法论的沉淀 | |
提升大家解决问题思路和能力 | |
做些通用demo可参考,只负责难点攻坚 |
五、利益分配
关键词:部门不同,目标不同,利益不同,利益分配的合理性
人们奋斗所争取的一切,都同他们的利益有关,这是马克思的至理名言。人们为团队工作,总要获得利益,或物质的,或精神的。利益的分配,代表着一个人的贡献和成就。必须公平合理,同工同酬,论功行赏,这样才可以调动职工的积极性,提高团队士气;反之,就会引起职工的不满,挫伤职工的积极性,降低团队的士气。
交流心得:
状况 | 分析&解决 |
多劳多得 (前提是要让所有人认可规则,否则依然不公平) | 项目角色(核心参与者) |
简单配合支持方要感谢(上线邮件、复盘会、当他领导面感谢) | |
目标把控者 | |
过程中表现(平时收集细节) | |
项目攻关人物 | |
核心价值 | 满足用户核心需求(成就感) |
增进不同部门协作 | |
项目实际收益 | |
独有性(为什么是我们做) | |
关键先生,较大突破 | |
平衡未来 | 动态看不同角色权重 |
提前考虑未来依赖部门 | |
平时注重挖掘潜力人员 | |
分配不合理(负面) | 不愿意配合(外部门) |
消极、应付(项目内成员) | |
onwer威望值下降 | |
得不到认同感,人才流失 | |
提前与各方领导申请资源,方便协调 |
以上是关于项目管理痛点的主要内容,如果未能解决你的问题,请参考以下文章