项目阶段划分,项目阶段划分包括几部分

发布时间：2022-04-27 17:46:43

导读：痛点一:资源不足讨论背景:任何公司、任何部门永远不可能有充足的资源，管理者不得不适应资源不足的常态。所以内部就以下几个问题进行了讨论:需求太大，所有产品？工期紧，什么时候设立标志卡？人员有限，慧聪招不到人？太依赖，很多情况，各种拖延？

项目阶段划分,项目阶段划分包括几部分

痛点一：资源不足

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

需求太多，产品啥都要？工期紧张，立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 B2.10. 整理上线todoList2.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 B4.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、被领导PUA11.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 平时培养backup2.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 联调阶段，阻塞block3.5 外部依赖风险评估--可参考已接入案例，上期迭代等3.6 大量工单走流程、审批--提前了解，提前申请3.7 永远要有plain B3.8 对项目里每个人能力有准确了解3.9 人员规模过大，沟通成本--项目团队规模控制10人以内闭环。

痛点四：角色固化

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

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

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

交流心得：

一、去中心化1.去中心化1.1 提前全局规划、分配1.2. 所有人对项目全局了解(这期功能点，目前进度，哪天测试，哪天上线)1.3. 提前培养 backup1.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 提前与各方领导申请资源，方便协调上面列举现象中，大部分之前已经给过解决答案，或者问题本来就很简单，不需要展开讨论。综上，希望能对大家在项目管理过程中有所启发。