完整版项目管理经验分享:产品经理如何做项目管理?

3 评论 25820 浏览 171 收藏 18 分钟

编辑导语:对于产品经理来说,项目管理是一件既头疼又让人很有成就感的一件事。一个项目往往需要很长一段时间才能收尾,其中也有很多的风险存在。本文作者通过回顾自己刚刚完成的一个长达半年的项目,为大家总结了一些经验和教训,希望能够帮助到大家,让新人产品经理们少走弯路。

最近负责的两个长达半年多的项目终于阶段性闭环交付,心里的石头落下了一大半。

回顾这半年多,作为项目负责人的项目管理过程,心中五味杂陈。有因项目风险不确定性的焦虑感,也有因能掌控项目进度和质量的成就感,有为团队成员一起并肩战斗的感动,也有为自己在这个过程中看得见的成长和进步而欣慰。

在项目收尾阶段,总结下在经历项目实战后的项目管理经验和教训,算是个人一个小小的项目结项报告。

本文导图框架如下图,主要从经验篇和教训篇两个方面展开:

1. 经验篇:项目管理过程总结

我理解的项目管理的定义:在一定的范围、时间、成本约束条件下,交付满足质量要求的产物,以获得客户满意的过程。

所以这里涉及到的五个要素:范围、质量、成本、进度和客户满意度,这五大要素,也会贯穿项目管理过程的各个阶段。

项目管理一般分为五个阶段:启动、规划、执行、监控、收尾,下面将重点讲述这每个阶段的目标、要做什么、以及如何做。

1.1 启动阶段

启动阶段一般可分为四个过程,对外的商务谈判,以及内部的项目立项、识别相关方,并组织开工会。

目标是为了明确项目启动的背景、前因后果和来龙去脉,确定项目目标,完成项目愿景和目标的同步。

1.1.1 商务谈判

一部分一般由商务主导,内部配合协助评估合同范围等。

在这里值得注意的是:一定要充分评估项目范围、交付时间、交付指标等,具体明确到交付指标的定义,测试方法,避免后期由于模糊的定义而“填坑”。

1.1.2 识别相关方

识别相关方的目的是为了提前了解项目对各相关方的影响,以及相关方对项目的需求和期望。

相关方分为外部和内部,外部客户根据不同的利益方,对应进行不同程度的关注与沟通;内部相关方,一般就是项目组的成员,包括:商务、产品经理、项目经理、研发、测试等。

1.1.3 项目立项会

基于成本与风险考虑与管控,一般投入超过一定工作量的项目,必须要进行项目立项,说清楚项目的背景、价值与收益等,特别是对外交付的项目。需要撰写项目立项材料,进行立项评审。

立项的过程,需要思考以下五个维度:

  1. Why:项目来源,价值意义,是否符合公司的战略目标;
  2. What:项目目标需要做什么,项目范围,核心功能;
  3. Who:那些人做,涉及到多少资源,成本;
  4. How long:做多久,项目的起止时间,初步的里程碑计划;
  5. 风险评估:是否存在技术风险、市场风险或其他风险,风险应对措施;

1.1.4 开工会

在项目立项通过后,组织项目相关方参与项目开工会,会议不需要过多讨论项目实现细节,主要与项目组成员同步项目来源和目标,哪些人做哪些事、怎么做等等,并达成共识(以后就是一条船上的蚂蚱啦~)

1.2 规划阶段

在项目启动后,并不是立即投入开发,而是由产品对项目进行规划,目标是梳理需求,确定项目的版本迭代计划、执行方案与排期。

所以这一阶段主要分为三个过程:工作任务分解、任务计划排期以及风险管理。

1.2.1 工作任务分解

工作任务分解:通常又称为WBS(Work Breakdown Structure),不论项目大或小,可以说都是由需求组成,也就是我们常说的需求池,将需求不断的分解,并明确执行路径时,项目的抗风险能力才能更强。

分解方式:一般可按照功能模块进行分解,比如针对于某个平台,按照功能细化开,可以分为会员模块,订单模块,商品模块等等.每个模块又可细分为更细的功能,例如会员模块又分为会员权益,会员信息等。

在需求分解后,确定需求优先级,根据优先级筛选需求形成版本迭代计划。

比如可分为三个版本计划:

  1. 1.0版本的目标就是产品“可用”
  2. 1.1版本的目标是产品“好用”
  3. 1.2版本的目标是满足质量指标

WBS参考图

1.2.2 任务计划排期

1.2.2.1 里程碑计划

在确定需求池,工作任务分解后,根据优先级,确定版本迭代排期,形成里程碑计划.

如下图,比如在什么时间节点分别完成哪些版本需求设计、研发编码、测试验收。

里程碑计划参考图

1.2.2.2 详细进度计划

在完成初步的里程碑计划后,对当前阶段的工作任务进行进一步细化,明确到具体的工作任务、完成目标、责任人,开始时间,结束时间,成果产出等等.

如下图,比如各个功能的需求说明,需求评审、研发详细设计、研发编码、测试用例评审,测试验收等。

详细进度计划参考图

在完成任务计划排期后,建议先线下与各相关方或责任人确认,再开会与所有人同步确认,现场“签字画押”,也就是意味着大家都认同的计划,在执行阶段就严格按照计划执行,原则上不能delay。

1.2.2.3 风险管理

项目管理过程中风险管理贯穿始终,即各个阶段都需要进行风险识别,但尽量将风险前置,避免风险发生时,措手不及。

风险管理的方式,可借鉴PMP里到的风险登记册去管理,一般可分为外部风险和内部风险:

  • 外部风险,比如项目范围和需求不明确,验收指标高,以及外部的依赖性等;
  • 内部风险,比如一些比较难突破的技术风险,人力不足的资源风险等。

及时识别风险,风险应对措施管控,通过风险登记册记录,并以一定的频度比如每周去跟进风险情况,如下图:

风险登记册参考图

1.3 执行与监控阶段

执行与监控阶段的目标,即依据规划阶段的计划,将项目有条不紊执行下去,定期跟踪监控,对项目进行管控,保证项目进度和质量。

1.3.1 各细分过程跟踪

往往在项目管理过程中,是多个项目同时在并行,或者紧急任务的插入,一个人同时负责多个项目,或者遇到功能开发问题等等,各种因素都有可能导致项目的里程碑delay,所以过程跟踪也是项目管理中非常重要的事。

过程跟踪的方法,可通过每日站会、每周周会的方式,监控项目的执行情况,一般是周会并配合周报的方式。

1.3.1.1 周会

尽量控制在15~30分钟,产品经理可在周会前一天与各责任人check各任务事项的进展情况,做到开会前心中有数。

周会的主题:周任务的完成情况,遇到的问题或难题,以及下周计划,明确到工作任务、责任人、时间节点。在会议结束后,在工作群里同步会议结论。

1.3.1.2 周报

与周会配合,文字邮件的形式同步。但周报的内容,根据不同的汇报对象,有不同的侧重点,比如,向上汇报,建议更突出结论性的输出,里程碑完成情况,top风险管理情况等。

若汇报对象为项目组成员,可以更细粒度,本周周计划完成情况,下周计划,风险与问题情况。

周报模板参考图

1.3.2 阶段性产出文档评审

整个项目生命周期中,不同的阶段会产出不同的文档,对于文档输出和评审是非常关键的一环。

一方面文字输出能留存记录,避免口头传达信息的不准确和理解有误等问题;另一方面,文档评审环节,可以提前把关方案可能存在的问题或风险,避免做完之后与预期不符,造成返工,工作量的浪费。

一般的文档包括:

  • 产品需求文档:由产品经理输出,包括功能架构、泳道图、流程图,以及相关的说明等;
  • 研发详细设计文档:由研发输出,包括详细的方案设计、接口文档等;
  • 测试方案、用例与报告:由测试输出,依据产品需求文档与研发设计文档,设计测试方案与用例,经相关人评审后,进行产品测试,并输出测试报告。

文档不是一成不变的,可能在项目执行过程中,会根据实际情况进行调整,所以一般在文档开头部分加上修订记录,即什么人,在什么时间点,修改了什么内容。

1.4 收尾阶段

收尾阶段的目标,即对可交付产品进行验收,包括内部验收与客户验收,并将项目过程中的相关文档进行归档,总结经验教训,撰写项目结项报告。

1.4.1 产品验收

1.4.1.1 内部验收

一般由产品验收,确定jira问题单是否全部关闭,是否有遗留问题,测试报告、测试结论是否满足交付指标等。

1.4.1.2 客户验收

交付件加密后交付,并在交付后,定期跟进客户集成测试情况,以及客户满意度如何等。

1.4.2 经验教训总结

经验教训总结,即项目复盘是对于每个项目都非常重要,对于一些比较成功的经历、方法等,通过复盘总结,形成经验和规律。一方面可以提高团队的项目管理效率,另一方面,也能形成组织过程资产,为公司减少培训成本。

在这个过程中暴露的问题,比较失败的部分,通过复盘知道如何改进,下次不再犯错,也是下一章要总结的部分。

2. 教训篇:踩过的那些坑

项目管理是整合多个部门的资源,协同并进,产出满足需求的产品的过程,这其中不仅仅是对各事项管理,也包括团队成员的协作、沟通等。

这里梳理我在项目管理过程中,暴露的那些问题,踩过的那些坑,以及对应的改进措施。

2.1 “管事”

给项目交付留buffer。

这一点是“血的教训”,在项目执行过程中,我对于研发出的产品质量过于乐观,并且风险识别不够及时,后面只留给测试两周的的时间,临近交付不断的发生各种问题,内部原定的里程碑交付时间不断的延期。

所以,对于交付物,一定要有“风险意识”,并且留一定的缓冲时间进行bug解决,问题修复。内部交付时间较实际交付时间,进行一定时间周期的提拉,给未知风险留应急处理时间。

每一个方案调整,必须及时分析其联动影响,并验证可行性。项目各个功能模块之间往往有很多依赖关系,牵一发而动全身。

在实际过程中,我没有充分全面的评估好某一个功能模块的改动,对其他功能的影响,并且进行验证,导致后期联调时,才发现很多本应该在前期方案调整时就应该验证发现的问题,导致返工。

其实这里产品一个人的认知具有局限性,应该先评估出可能影响的相关方,再组织相关方一起讨论细节,才能更全面的评估和验证。

2.2 “管人”

适度的强势。

前段时间刚被同事“吐槽”说,平时看着挺小女生的,一工作起来就很强势了。

其实在项目前期,在对自己的项目管理能力不太自信的时候,会比较“软弱”,以前研发跟我说,这个做不了或者比较困难,我可能就“妥协”了。

现在会有明确的项目目标和自己的原则,态度上会更强硬,遇到什么困难,程度有多大,有什么数据支撑。当然有问题也不会让项目组成员独自承担,一定是一起想办法,是否有其他方法解决。

修炼内功才更有说服力。在与同事的项目沟通、协作上,刚开始会觉得如果实力不够的话,就用“人格魅力”凑一凑,够一够,即与项目组成员相处愉快一些,“搞好关系”,这样在资源协调上应该会比较顺利一些。

后面到遇到非常有自己主见的同事,他也提出了我在项目过程中的一些问题,虽然是用非常质疑的口吻,但是我现在是很欣赏和感谢那个同学。

他让我内心变得更大强大,同时也意识到,专业能力、解决问题能力强,才能更有信服力,努力修炼内功才是王道。

写在最后:

对于产品经理来说,项目管理能力是非常重要的一个硬技能:

  • 在过程管理上,不断的实战与复盘,内化成自己的能力;
  • 在在心态上,项目管理一定不是一帆风顺的,中间一定有出现各种问题,发生各种风险,但一定要保持一个积极的心态,相信冲锋陷阵的团队成员能力,也相信领导作为军师的后盾力量,方法总比困难多,问题一定是可解的。

以上便是我基于PMP的一些理论知识,并结合两个项目实战后的项目管理经验与教训总结,可结合自己的实际项目加以灵活应用,希望能对你有所帮助。

 

作者:小谭同学;微信公众号:斜杠产品汪

本文由 @小谭同学 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 会用项目管理软件么?自用的那种

    来自北京 回复
  2. 真的是学以致用,给你赞一个

    来自广东 回复
  3. 很棒,小谭同学👍

    来自上海 回复