作为一枚优秀的产品经理您知道在项目管理中的八个要素吗?-09大数据

正好前段时间做了一个虚拟项目:通过项目管理的形式组织一次吃火锅的活动。这次活动通过完整的项目管理的形式进行,对日常产品经理工作中涉及的项目管理也有启发。今天我们就一起来走一遍这个项目吧~

step1:启动/规划——项目前期准备,kickoff

当领到这个目标,并被任命为项目PM之后,我们首先要进行项目的背景及目标了解。这里也简单介绍一下:我们之前参加了一个项目经理的培训,这次主要将学员们组织起来,通过吃火锅的形式来实操项目管理方法,同时增进感情。目标很简单:在活动当天(X号X点至X点),负责活动小组7人,经费400元,活动方提供场地,自带餐具,使用活动组经费完成采购,烹饪,聚餐以及餐后清理工作;组员吃好喝好。

启辰菌说:在领到项目之后,不要马上进行项目推进,而是要先就项目合理性,项目目标,项目预期,项目时间,项目预算等与资源方达成一致,这样可以更准确的安排项目节奏,管理起来更加游刃有余。

项目交付物(一)项目内容拆解图:

在PM确认并认可项目目标之后,PM会简单进行项目内容拆解,具体如图(初稿,勿喷O(∩_∩)O):

作为一枚优秀的产品经理您知道在项目管理中的八个要素吗?-09大数据

项目内容拆解不包括排期,主要是工作内容的分解。

有了项目拆解稿之后,我们简单开了项目沟通会议,和项目成员同步了我们的项目背景及目标;确定了几个关键时间点及交付物;同时简单过了下项目内容拆解图,进行头脑风暴,进一步细化项目内容拆解图。

启辰菌说:有关项目拆解:确认项目目标之后,PM需要进行的是与项目成员同步项目目标,背景,以及进行项目内容的拆解。合理的项目内容拆解,能让项目成员明确项目的边界,明确看到项目的进度。但由于PM毕竟是人不是神,有很多时候都需要整个项目组进行头脑风暴,来进一步完善拆解图,同时细化的过程也会增加项目成员的参与感。

项目交付物(二)类型总结:

交付物一般包括几种类型:

  1. 计划型交付物:如项目内容拆解图,行动计划表,成本预算表,一页纸项目计划表等;
  2. 进度型交付物:项目日报,周报等;
  3. 里程碑型交付物:立项报告,结项报告,项目阶段文档等。

安利Xmind,拆解项目,脑暴神器。

会后,我们组建了项目IM群,邮件群,微信群在群里统计了大家的空闲时间,以及饮食喜好,对项目内容中是否有在行,愿意主动帮忙的地方。很快我们也达成了一致。PM依据大家的时间及专业能力做了简单的项目排期。

启辰菌说:

保持沟通:保持流程的沟通是PM的重要职责。项目开始之际,应通过多种通讯方式的选择,尽量保证可以随时联系上项目成员,方便后续跟进;

了解项目成员:项目中的每个人都是独立的个体,大家围绕着一个共同的目标一起努力。这时应该充分发挥成员的主观能动性,专业的人做专业的事,这样才能更高效完成项目。PM的重要一点是有效统筹项目中的人,物,资金。

上面一切准备就绪之后,我们简单开了kickoff会,重申了以上达成共识的一点,重点强调了目标,项目分解,项目资源,项目排期。在大家达成一致后,PM产出了立项报告,成本预算表以及行动计划表,并邮件抄送了邮件组,并将关键节点在IM群中设为公告,方便大家查阅。这样项目就算正式开始啦!

启辰菌说:

kickoff会的目的:明确项目背景,目标,资源,排期等关键需求。作为项目的里程碑节点,该环节交付物为立项报告,成本预算表以及行动计划表。

项目交付物(三)立项报告,成本预算表,行动计划表:

  1. 立项报告:一份较为完整的立项报告包括项目名称,项目背景,项目目标,项目人员,项目时间,项目PM,项目交付物,项目成本,涉及团队等因素。
  2. 成本预算表:成本预算表每个团队格式不同,简单格式由支出项,数量,价格组成。
  3. 行动计划表:以甘特图形式标记团队各个成员工作内容及时间,便于跟踪。其中有报警项,如果进度delay严重,可以及时发现,具体如下:

作为一枚优秀的产品经理您知道在项目管理中的八个要素吗?-09大数据
有关项目管理工具:

这里分享几种常用的项目管理工具:

  1. Omniplan:用于管理项目(比excel专业,但是excel更加普遍)
  2. 一页纸项目管理工具:可以视为是行动计划表+成本预算表的合体,适合快速统筹项目资源,网上下一个马上就可以用,具体如下:

作为一枚优秀的产品经理您知道在项目管理中的八个要素吗?-09大数据

step2:执行/监控——项目推进,关键节点检查

kickoff会之后,项目就正式开始了。虽然项目时间比较短,但我们还是定了好几个关键时间点。现在PM的角色主要就变为进度跟进者,资源协调者,风险解决者。需要做的主要是走查,确保进度(比如采购,食具,会场检查等子项目进展);人,时间,资金不被其他项目或需求挪走(比如临时会议导致没空参与采购);如果被挪走后,怎么灵活应变。还有就是组织项目站会,以及写项目日报啦。

启辰菌说:

当项目正式推进时,关键点就成了风险管理了。项目会面临各种风险,主要有目标变动,人员变动,时间变动,资金变动。这些风险都可以通过灵活调拨资源,砍功能点,项目节奏调整来应对,但最严重的风险是业务变动,有可能整个项目对被砍掉。大部分情况下,这种风险一旦发生,PM铁定要背锅的,这说明在第一步项目背景和目标了解的时候,没有做好本职工作而直接执行了(如果整个BU被砍掉。。。那就真的没办法了┑( ̄Д  ̄)┍)。

对于PM来说,无论事前想的再详细,项目总会有风险发生的。项目风险管理是很重要的!所以每天都要更新行动计划表,日报等,都是为了有效监控进度和风险!

常用项目跟踪的方法:主要可以从以下三个方面进行考虑:

1、事项管理——站会

组织站会。每日站立可以在同样的时间和同样的地点召开,会议准时开始,最好不要超过15分钟,每一个开发团队的成员都必须发言,会议中不进行讨论,发言内容需提供以下信息:

  • 昨天完成了什么
  • 今天即将做什么
  • 遇到了什么困

一方面可以避免有些同事在项目过程中沉浸在自己的世界里,方向走偏了自己没有发现。另外一方面是能帮助大家克服人性上的懒惰因素,在每天汇报工作进度中给大家形成适度的压力。

2、人员管理——保持沟通

PM需要多沟通,了解项目组每个成员的表现,对表现突出的给予赞赏和肯定,对表现不好的则应提出相应的提醒。

另外一点,产品经理要去多和项目组的成员进行沟通,这种沟通不仅仅是工作上的沟通,还可以聊聊生活方面的东西,这样不仅可以促进你和项目成员之间的关系,还能及时知晓他们的生活状态,也是有利于项目管理的。

3、预算管理——了解开支

运营活动相关的项目管理,就经常会涉及到项目开支的问题,这里的监控其实主要是记录下所有的开支流水,看下与项目计划初始阶段的预算相比是否有超出的情况。这个时候可以好好和运营的相关同事进行沟通,找出具体的费用超出项,分析原因找到相应的解决方案。

step3:收尾——项目验收,复盘

在小伙伴的共同努力下,有惊无险的进行了整个活动,包括采购,会场踩点,会场资源检查,吃饭,清洗收拾等环节之后,活动发起方和PM验收了这个项目。验收完成后,我们现场进行了一个简短的项目review。PM带头说了项目中的问题点,总结了好的地方,也检讨了做的不好的地方;项目组成员也都进行了发言。结束后,大家各自回家,而PM则默默敲完结项报告,项目总结文档,邮件抄送项目组全员及活动发起方,项目相关文档进行归档。项目圆满结束!撒花~下午茶走起~

启辰菌说:

项目验收环节,包括关键节点的验收,交付物的验收,项目目标的验收,风险管理效果的验收等几大块。
另外项目review是非常关键的环节,有利于项目成员沉淀好的项目管理经验,扬弃影响项目效率或者风险管理不当的做法。review可以单出会议纪要,也可以与结项报告一起整理。

项目交付物(四)结项报告:

结项报告:结项报告主要包括几个部分:对项目背景,目的,分解后的项目目标,参与人员,责任部分,考核标准,交付物checklist,项目成果及效果,复盘及风险报告,沉淀及总结等。

以上就是一个简单项目的项目管理方式。吃火锅项目,麻雀虽小,五脏俱全,其中总结出来的项目管理方法,在复杂项目的管理中,亲测实用!项目管理其实方法论比较简单,但是魔鬼在细节,魔鬼在执行。希望对大家的日常项目管理有所启发。

  • 耗费时间和精力:最初大家还是愿意接受线下手工的方式写字操作各自任务记录,后面每人每日都要花费大量时间手写任务列表,进行卡片粘贴。到最后整个团队都觉得这样写起来很麻烦,逐渐放弃了手动写的过程,转而进入线上工具的管理。
  • 更新删除麻烦:团队每个人每天都需要对今天完成的任务进行更新,多数时候当大家拿起笔去更新时重写内容时就开始愁苦。写了一天代码要下班了还得重新写字更新今日任务,尤其碰到需要删除重新的需求任务更是崩溃。
  • 历史记录找不到:每天只能看到当天完成了什么,昨天完成了什么。当整张墙贴的密密麻麻时,想找一个人任务时,眼睛都要瞅半天。此时大家真想有个“搜索”功能。尤其在每期迭代结束后,统计每个人任务进度时,简直要崩溃。此时多希望有个工具能帮我做这件事。
  • 子任务拆分不方便:产品需求永远都会拆分子任务,研发在开发时也需要拆分更细的子任务。此时自己用人工的方法来做就显得特别麻烦,尤其拆好的子任务要做拆分修改时,更是麻烦。
  • 人员管理麻烦:我们当初整个看板名字是固定的,随着后续有新同事进来,旧同事离开,整个看板都需要更新。这时就需要把看板上的所有任务全部清除后再重新布局。

后面尝试转移到线上工具管理后,整个研发团队的迭代节奏明显加快许多,原先将近两周才完成的迭代、现在相同任务量缩短到一周。每日晨会、站会时间也由半小时缩短到15分钟。研发团队每日下班的时由原先花费将近10分钟更新今日任务的时间,缩短至1-2分钟搞定下班回家。从这个现象可以看出一个有效的工具能帮助研发团队提高效率。

在产品迭代流程方面,我们采用周期的研发节奏,整个产品研发的迭代顺序大致是 需求收集 – 需求分析 – 功能策划 – 原型设计 – 需求评审排期 – 开发阶段  – 测试阶段 – 上线阶段,这里实现一个完整的迭代。

作为一枚优秀的产品经理您知道在项目管理中的八个要素吗?-09大数据

对项目时间管理,本来采取的是线下excel表格管理,后面也逐渐转移线上工具化管理。

下面就详细讲解下 在产品迭代项目的每个阶段我们都做了什么。

需求收集阶段

产品部门有自己的需求收集和分析方法,我们会在建立一个“需求池 ”,产品会将收集来的各方面需求收录到池子里。需求池的需求主要来源于市场、用户、竞品、老板、产品经理。我们会用线上工具将需求进行分类管理,比如APP端需求、运营需求、网页端需求等等。并定期对需求池中的需求进行合并删减。

在需求收集阶段,产品部会和运营、市场、商务等同事进行详细沟通,确保了解每一个需求的目的和意义。

需求分析阶段

对建立的“需求池”,产品对定期进行评估,评估也是基于产品内部的讨论,在讨论前一定要确保了解每一个需求背景和意义,不要一个人拍脑袋把需求拍出来。我们崇尚以产品为公司核心导向,所以产品经历的决定权很重要,直接影响公司战略走向。所以对于需求池的需求进行详细分析时,一定多基于用户、市场和公司角度出发。

对需求池的需求分析主要做两件事:

  1. 整理需求池内容,从优先级和重要性两个纬度进行产品功能筛选。
  2. 确定需求池优先级和重要性后,进行需求标记,创建新迭代并关联需求。

确定要做的需求后,就需要开始细化需求。这时候就考验产品经理的功底了。

功能策划阶段

在确定要做的需求后,为了保证需求在研发阶段的完整性和可分工。需要在功能策划阶段就要对产品需求进行模块拆分和任务拆分。确保需求的颗粒度与研发时间评审的模块一致,如果不知道怎么拆分,需要提前与研发同学沟通。

在任务拆分后,为了保证及时同步给研发同事,需要将子任务先在线上工具关联到迭代,目的主要有两个:

  1. 可以让研发同时知道下一期功能范围和模块,提前进行技术框架搭建或技术预研。
  2. 方便产品同事(多人负责一个模块)的协作设计。

在线上工具上,可以对需求进行关联,比如父子关系,方便连续查找,树形结构更容易一目了然。

原型设计阶段

原型设计阶段最难管理的是版本问题,这里包括两类文件的版本管理。

  1. 产品经理的原型稿件
  2. 设计师的高保真设计稿

首先,原型稿修改的次数远远会大于设计稿,主要因为一些需求会在评审后或者开发中才会发现问题。修改或者补充的。再者,我们的创业公司原型稿上大都有交互说明一起的,一般修改/补充文字说明比较多。而且原型稿的使用对象更多是研发和测试同学,所以每一次版本记录和修改后同步都是巨大的工作量。做好的方法是建立统一的svn或线上管理工具,如果有修改可以实时同步。

设计稿也是类似,一般设计稿改动的频率较小,但我们当时为了保持同步也会统一以版本命名,上传到在线管理工具上,统一管理。确保信息同步及时,研发过程中不至于使用版本不同而导致提测是几个端的功能效果不同。

需求评审排期

需求评审我们一般会有3次评审,之前有过两次,但发现在开发时存在很多重复沟通,很多需求研发同事都没有搞明白。分析原因主要是需求评审会上时间短,很难短时间就搞懂所有逻辑。所以后面换成了3次,添加了一次“预评审会”。

在第一次“预评审会”上,不讨论需求细节,只讨论框架和流程。让大家知道下个迭代要做什么,先在脑海中有概念。一般预评审会的时间会在上个迭代的测试阶段,这样在距离这个迭代结束的下次评审会前,大家有时间提前带着框架和流程去熟悉下需求细节,这样就可以带着问题进行第二次需求评审会评审了。同时也可以在这个评审会上遇到一些技术改动比较大的问题,或者技术难点提前周知产品,评估看是否要对需求进行调整。

第二次评审会上,属于正式评审,会把产品需求从每个细节进行一次评审。每个人都带着问题来听,没问题的地方快速过,有问题的地方着重讨论确定的方案,这样就节省大量时间。因为都是线上需求管理,遇到问题直接当场标记,会议后针对标记的地方进行修改。有记录,而且还不会遗漏。

第三次评审会,主要对第二次需要修改的地方过一遍,顺便加深研发同学对需求的理解程度。一般第三次评审会会在第二次评审会的第二天。我们一般选择第二次在前一天下午,第三次在第二天上午。利用晚上的时间修改需求,这样就可以节省项目时间。

紧接着就是第二天下午的项目排期了,会直接在线上工具已经拆分好的子任务上进行人员分配,包括开发人员、测试人员,之后进行开发周期的安排。在线上管理的目的是 分配好人员后,大家就能自己登录后看到负责的任务,同时系统也会自动计算出开发周期。

开发阶段

开发人员按照每个子任务的排期时间,在每个需求的时间节点前完成开发即可。在开发周期内会安排几种会议:

  • 每日晨会:每天早上全员参加,围绕 昨天进度,今日安排,遇到问题 三个话题展开。每人大约几十秒时间,不讨论详细解决方案。遇到问题的同事或者需要跟xx对其的人在晨会后 以小组的形式单独详细讨论。晨会的目的是做到明确每个人的安排,同步及知道要解决的问题。
  • 每周例会:每周的例会一般安排在周五下午。1个小时左右,主要同步项目整体进度,集中解决规则及制度性的问题。
  • 临时会议:一般遇到开发过程中的重大问题,需要即可解决的,才会组织临时会议。一般是问题的干系人及老大们参加。
  • 分享会议:每周会安排一次项目成员的分享会,由一个人准备,分享自己的所闻所感。建立团队间乐于分享的友好氛围。

开发阶段,会项目的管理主要是线上工具,同步及沟通的工具一般都是线上管理平台及在线聊天工具。因为我们都在一起办公,遇到问题吼一声,人就过去了。

测试阶段

测试同事会提前根据需求编写测试用例,测试用例也会在开发前进行评审。测试用例会更新到线上工具,让每个人都能看到。测试时也会根据评审的用例进行,防止带入主观判断。碰到的测试问题也会自动提交到bug池,关联给对应的开发人员,确保不遗漏bug修改。

因为创业公司测试人力少,我们一般都是全员找bug,可以设置一些有奖活动。比如谁找的bug多,谁就可以获得奖励。

上线阶段

当所有任务测试 完成后,即可上线。上线前产品、运营都需要列出对应的负责内容。建立checklist,逐一检查是否有遗漏问题。一般版本是否上线会由测试邮件发布测试质量报告,并提出是否可以上线的建议。产品会根据邮件反馈进行判断是否可以上线。这样既有了双保险,由能一封邮件就完成上线同步工作,提高上线效率。

除了研发团队外,公司还将运营和商务也划归到项目中统一管理。为了让各部门信息互相同步,让技术同学了解业务帮助他们更好基于业务层面进行开发,让业务同学更了解技术难处,能提出更加合理的需求,用开发的语言跟开发同事沟通。

以上是从创业经历的实战项目总结出来的创业公司项目管理流程,并不一定适用于每一家创业公司,但其中一些方法不论是大公司还是小公司都可以尝试使用。

来源:pm28