|
痛点⼀：资源不⾜ 讨论背景： 任何⼀家公司、任何⼀个部门永远不可能资源充⾜，管理⼈员要适应资源不⾜的常态，故⽽针对以下问题进⾏了内部讨论： 需求太多，产品啥都要？ ⼯期紧张，⽴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.做预案planB 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.2主动沟通(必要可升级沟通⽅式：电话，当⾯) 4.3做预案planB 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、配备backup，弥补他 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.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.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永远要有plainB 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.3onwer威望值下降 4.4得不到认同感，⼈才流失 4.5提前与各⽅领导申请资源，⽅便协调 上⾯列举现象中，⼤部分之前已经给过解决答案，或者问题本来就很简单，不需要展开讨论。综上，希望能对⼤家在项⽬管理过程中有所启发。 |
|
|
