原腾讯产品经理如何管理好项目进度(干货收藏)

经过产品需求评审,UI、研发、测试同事都已经评估了工作量,确定了产品功能提测时间和上线时间,那么对于产品经理来讲是不是就可以去分析下个版本的需求,坐等产品上线了呢?

首先,谈一谈项目,大家对这个字眼应该熟悉吧,不管是具体实操还是面试过程中,都会有项目这个词汇出现。

那什么是项目呢?

其实很简单,项目是为了创造独特(或符合公司/市场需求)的产品、服务或成果,而进行的临时性工作。项目有清晰明确的开始和结束时间,在目标时间内,启动→计划→执行→控制——收尾,就是一个项目的生命周期。

你是否有这样的经历?

安身于一家中高型企业,毕竟不是大型或职能岗位建设很齐全的企业,职能并没有那么细化,作为一个小小的PM,担着分配到自己的业务线,涉及具体项目领导找你对接询问。

但是碰上项目屡屡预期的话,那种对上无奈,对下的无语且愤懑,中间对自己的小委屈, 真是闻者呵呵,听者心累——明明是开发过程中或测试过程中bug多或者各种非PM原因问题导致项目延期,但还是免不了领导一顿bb。

不过也难免,毕竟在这样的环境下,PM是项目的发起同时也是领头人,以结果为导向看待问题。

那…我们该如何高效地交付项目呢?

  1. 明确协同职责
  2. 统一迭代节奏
  3. 过程有效透明
  4. 站会三讲:完结的内容,存在的问题,怎么解决或需要哪些帮助
  5. 过程高效决策

回归文章主题,该如何有效防止项目延期,首先需要明确可能造成项目延期的原因:

01 UI图未经过评审或成品界面不达标,造成返工导致延期

实际生产中存在这些问题,UI图输出后没有经过评审直接转到技术进行开发,过程中或成品后发觉此时再做调整修改,难免延误时间导致延期。

这类操作一般出现于首次带队的产品小白,前期别埋坑,UI评审的意义不容小觑,助于团队成员加深需求理解,沟通交流,同时也能给设计提供更多不同思维的灵感源泉。

当然,也可根据产品或公司领导对于项目流程的看法,不把UI出图及评审调整的时间算在项目内,单独计算时间,正常流程是设计图完成后是进行UI评审,没问题后转接产品及开发测试团队,因UI图的问题导致延期,解决方案如下:

1. 提高设计团队的专业度,UI图产出后即时进行评审

注:上图的项目初期、中期、后期可译为”第一感觉、相对来说、细节挑刺儿”

2. 明确设计图可交付的时间

产品需要跟每个需要合作的部门或同事沟通好,如果项目包含UI设计出图的流程,明确开始及最后的完成时间(即评审后调整完毕可交付的时间)

3. UI评审时明确重点,不必太过纠结细节

标题概述很明了,如果单单因为页面留白或者按钮大小圆角与否之类相对无关紧要的问题争辩不休迟迟敲定不下,此为因小失大,小问题后期优化迭代,不占用团队时间;

4. 项目开发过程中按时间节点查阅UI效果,如有问题及时跟进调整,避免成品不达标导致最后返工

02 实际开发过程中前松后紧,没hold住导致延期

工作中这个点比较常复现,例如公司待久的一些技术员工难免轻视公司制度,尤其是在制度并不完善或者自认为早已对公司业务轻车熟路的情况下,实际开发过程中如遇跨项目联调受阻…临近预计完结时间,加班加点熟悉其他项目组代码寻求解决方案,或团队整体氛围松散,导致项目延期。

况且前期轻松后期加班换调休 or money的类似行为,久而久之这种行为形成习惯,这也是很多企业定期换血,老员工数量占比较大的原因之一吧。

那么怎么解决呢:

1. 使用燃尽图节点设置,关注成员每个人的进度

燃尽图的纵轴可以是整个项目的剩余的任务,也可以是个人剩余的全部任务,用来观察项目过程中完成的实际工作量与剩余时间的关系,关注节点进度,如有异常及时沟通解决。

2. 需求优先级划分

需求优先级一经确定,将贯穿项目需求的整个生命周期,所有的资源将根据优先级被安排。分享几个划分需求优先级的方法如下:

(1)核心价值需求,影响主流程的需求,优化需求

例如本期项目核心就是优化下单流程,那么即买即付这个功能就是核心,登录注册即为主流程需求,如果添加oauth,则属于优化需求,评审项目时间,如果优化需求占用时间较多,即可迭代下一版。

(2)从开发及效果角度分析划分

(3)从使用频次和用户量分析划分

(4)根据业务或市场情况划分

(5)根据KANO模型划分

  • 必备型:如电商类App,购物车、下单及订单管理流程则是必备型需求,最高优先;
  • 希望型:如oauth,便捷登录注册的方式,符合大众用户简易使用操作的心理,属二级优先;
  • 兴奋型:如百度地图语音功能,能触发用户感叹的点即为兴奋型需求;当然,创新的需求点需投入大量的构思、试验、研发成本,不鸣则已一鸣惊人,属三级需求(视具体情景而定);
  • 无差异型:不论提供与否,对用户体验无影响。针对这类需求,要避免投入,转战其他更有价值的需求。

3. 晨会

也称为早会、站会等,说法不一罢了,及时汇报项目进度,如有问题(产品逻辑or技术开发)及时抛出调整解决。

03 需求下发后只关注自己的模块,协接故障导致延期

如果仅仅关注自身的业务,那对自己来说不管是技术能力或项目全局的把控能力都不会有太大的提升,只有成长了才会有更大更好的平台发光发热。

再者,毕竟是大家一个团队,在同一家公司共事,共同努力做好一件事不香嘛~,期间的过程酸甜苦辣不都是一份经历一份成长嘛~,同时作为带队者:

1. 需求拆解

PM前期开需求评审会议的时候,就做好需求的拆分,按具体模块、功能划分,每一部分事无巨细讲述,逻辑清晰易懂、循序渐进贯穿本期需求/项目,如有与别的项目耦合关系或逻辑判断,着重讲述,让团队成员明白整体流程,以及最后需实现的成果,而后技术负责人按模块/功能安排具体开发人员。

2. 各自评估,集中讨论

开发人员拿到自己所需模块后,进行集中讨论(类似头脑风暴),毕竟业务/功能相互之间难免存在耦合,规定时间内理清业务,寻找与之前后是否存在相关联性,避免后期埋雷。

当然,需要开发人员熟练业务、自身能力及表达顺畅,相互之间较快得出估期结论。

3. 促进组内成员相互之间多交流沟通

大家一起讨论需求难点时,适当回应、多聆听、不打断、不做任何个人感情色彩评价,全程采取开放性的提问,让成员去思考,讲出自己的想法。

遇到逻辑问题或理解不通畅时不要争论,尽量把说话和表现的机会让给对方,聆听中抓取问题,设身处地站在开发或测试的角度去想他们提出来的问题,善于运用肯定式问句,引导对方思考,让对方不断认同。

如“你把这个逻辑想的有些复杂了,其实很简单,XXXX,你看这样是不是好理解一些或者更顺一些了呢?倒是你之前想的很不错,可以作为下期的优化点迭代一版”,如有好的想法加以肯定,每个人都需要被肯定。

04 估期时间偏差,导致延期

这是最重点的一个问题,百分之六十以上的项目延期就是因为预估时间出现问题,从而造成项目延期。

需求评审往往只预估了理想状态下的开发时间、联调时间、测试时间,忽略了一些开发上可能存在的一些难点,攻克、联调,再到测试或者测试出bug,修复半天找不到原因所在或修复所需的时间。

如涉及到B端产品,B端一般涉及到的数据流转非常复杂,有时候还需要与其他项目进行对接或接口的联调。

针对这种问题比较好的解决方法:

1. 采用Excel甘特图表

可采用Excel甘特图表记录时间节点以及具体每人按时间段需完成的需求点。

清晰展现估期时间段,一但发现某个需求在既定时间内延期,及时找出问题解决并判断后面的需求是否可能遇到类似的问题;

2. 需熟悉业务流程及逻辑

项目完结后,每人提交一份输出报告(类型可以是文档、版本代码、原型等),目的是让团队成员明确每个部分/需求/项目之间的关联,对现有逻辑有较清楚的认识。

3. 不可忽略联调及测试改bug时间

技术难点不可控,so 适当预留时间,便于及时调整解决。

4. 适当”留一些余地”,或可替代性方案

适当的预留一些时间,如上所说遇到一时难以攻克的问题,需要时间或及时寻求一些帮助去解决。

对PM来说也是如此,作为带队者,应准备可替代性方案,防止因技术难点或其他原因可能造成的逾期及风险预警。

05 深入后发现对现有业务耦合或造成改动过大,开发时间不够导致延期

这个问题跟上一个问题差不太多,前期尽量做好相应的一些准备,埋头吭哧吭哧开发了半天,才发现和现有XX模块对接不上!这个接口/方法导致现有H5页面出问题等等情况!于是乎,又得重新搞,此时延期的警报即将吹响……

1. 用鱼骨图分析潜在问题

项目前期可用鱼骨图分析一波,对项目正常完成可能产生威胁的因素进行评估,以便逐个击破解决问题。

2. PM需要足够熟悉项目

PM对项目的熟悉程度,一定程度上决定项目是否能够顺利进行,不了解的状态盲目规划制定需求,不是事倍功半就是夭折,延期还算轻的…

如果是新接手的项目,查阅PRD文档及原型,或跟测试人员沟通,尽快熟悉项目内容。

需求评审时应及时提出相关的逻辑关联辅助开发进行判断。

3. 做好需求拆分规划,根据公司或市场情况,及时调整稳步迭代

可根据上文需求优先级划分的方式进行后续版本迭代规划。

针对每期需求,拟可替代性方案,如一个连环相扣的判断逻辑略复杂,实现较为繁琐,占用时间较多,此时有一个简化的方案可替代,既满足使用,又不会导致延期,记录当前问题后期迭代调整也不失为一种解决方案。

06 需求变更或新增,导致延期

需求临时变更或者新增应该是最常见的情况了吧。

案例情景:

项目1期的整个周期为1个月,有3轮环境及功能测试。

当第3轮测试结束时,即将进入灰度发版阶段,领导此时给出大客户反馈并要求按客户的反馈意见修改。

技术了解后给出改动的地方涉及App端、H5及后端校验逻辑等方面,调整的话3个端均得做相应改动,再投入时间及测试成本……

首先需PM进行一波尽量带动领导思维的冷静分析,明确解决该问题所需要的成本及时间,是否属于重要且紧急的bug,是否必须解决。

如果仅仅是一个优化并不影响大面积使用不会造成系统崩溃,可否延后到下版迭代。

一波苦口婆心的劝说无果,那就转身深呼吸,低喃一句佛曰:“阿米豆腐”,再来一波面向开发大佬们的演说~

1. 冷静判断需求优先级(上文第2点有具体阐述)

  • 核心价值需求,影响主流程的需求,优化需求
  • 从开发及效果角度分析划分
  • 从使用频次和用户量分析划分
  • 根据业务或市场情况划分
  • 根据KANO模型划分

2. 主要跟开发做好沟通

主动找开发沟通,产品岗在项目或团队中起的带头作用,做事态度积极,处好人际关系利于工作,当然对自身做事也有益处。

与开发沟通心态平和,站在对方的角度给予一定程度的理解,但如果是紧急且必须修复的问题需合并上线,商讨解决方案,尽量将延期时间压到最低。

07 开发/测试对需求理解有偏差,返工导致延期

可能你的成员是有不同小组或项目组临时抽调出来组建的团队,团队成员之间也不熟悉,同样,新同事进入团队也需要一个熟悉的过程,此时,沟通显得尤为重要!

沟通在任何团队任何项目中都是重大问题,自认为一个小的逻辑上的理解偏差可能就会造成实现的成果截然不同——开发记得是这样的,测试记得好像是那样的,造成项目在成品的时候出现偏差。

情况好的是测试理解不准确,不好的话那就得返工重新投入开发、测试时间成本。

同时也会造成团队成员之间相处的矛盾障碍,对之后的交流沟通埋雷。so~

1. 仔细讲明需求,保证团队对需求认知一致

需求讲述清晰明了,目的明确,评审时带动团队成员,从核心出发,按模块,逻辑,细节逐步讲述。

只有团队所有成员对需求认知一致时,才能保证工作高效的完成,达到事半功倍的效果,同时也有助于团队协作氛围提升。

PRD文档整理详细,逻辑清晰易懂,流程/结构图准确无误,应包含的内容:项目名称、版本历史、目录、文档介绍、需求目的、需求模块概述、需求明细、相关结构图、逻辑说明、全局功能说明、详细功能说明、影响范围说明、非功能性需求、注意事项、上线流程等。

2. 沟通

沟通 —— 沟通能增进团队彼此的感情,消除误解,增进团队彼此之间的了解,同时也让我们学会换位思考。

人与人的交往,就是一个反复沟通的过程——

沟通好了,就容易建立起良好的团队氛围,积极上进;沟通不好,闹点笑话倒没什么,但因此得罪人,导致工作处处受阻,就得不偿失了。

沟通的几种方式如下:

  • 项目组成员位置就近,降低沟通成本;
  • 项目管理工具:如Jira、企业微信TAPD等,便于及时查阅文档、问题,沟通及处理;
  • 邮件的方式通知到项目每个成员及领导,也是一个查证依据;
  • 站会及周会,汇报成果及问题,问题及时抛出及时处理;
  • 建群,便于每天通报进度。

总结

个人感悟,只要做好项目管理、需求排期、对应功能时间节点、功能开发状态、进度达到多少时要开始预警、警报解除 、评估风险、延期影响评估、是否存在可替代性方案,一波操作下来,大程度不会出现延期的情况。

前辈大大们曾说过产品要有节奏感,这句话我十分认同。现在业内比较推崇的方式是敏捷开发,小步快跑,快速迭代的模式,把项目分成足够细的粒度并设置时间截点可以有效避免项目受到大的影响或经常性延期。

在实际版本开发的过程中,可能会出现这样的问题,运营同学反馈有一个影响用户的产品功能马上需要优化,领导增加了新的需求,已经评审的需求出现了需求变更。技术由于处理线上问题原来的需求计划有所延迟,研发处理各种线上BUG影响了开发正常工作。本文主要分析项目开发中的影响因素及其对应的解决方法。

1. 项目排期表

项目排期表是进行项目进度管理的重要手段,通过项目排期表可以非常直观地看到该项目有哪些开发任务要做,这些任务是由谁来做,开始时间和完成时间,完成的前置条件是有哪些。项目排期表确定了该版本要开发的产品功能的范围,每个功能中需要的开发工作量,也就是本次版本迭代的迭代周期。

由于产品功能的开发一般需要UI设计师,前端开发工程师,后台开发工程,共同完成,前端开发可能又会分为web、APP-Android、APP-iOS,小程序,h5,那么项目排期表中除了承载任务安排的关系,还代表了一个产品功能下面需要的不同类型研发工程师的关系。

项目排期表也是一个沟通的工具,前端工程师根据排期表和UI设计师进行UI问题的沟通,和后台工程师进行产品功能的联调,测试工程师可以针对测试过程中出现的BUG直接指定对应的研发工程师。

在时间安排上,可以很直观地通过项目排期表看到各个研发人员的时间安排,各个产品功能开发时间端,产品功能开发的先后关系。同时呢,也会从整个版本迭代过程中发现关键任务(重点关注进度的产品功能)和关键人员(重点关注进度的研发人员),关键任务在整个项目排期中至关重要,不允许有延期的情况。

同时也会调整研发人员的排期,对于有空闲时间的研发人员可以安排其他项目或者进行其他产品功能的开发。一份完善的排期表会大大减少开发过程的沟通和需求问题。

在项目启动开发之后,除了项目排期表之外,可以同步输出版本范围列表,产品功能路径图会有助于项目团队中各个人员对本次产品迭代范围及注意事项的整体理解。

2. 项目进度跟进

在输出项目排期表和版本需求范围,确定了关键任务和关键人员,还需要定期跟进项目进度。在敏捷项目管理中会采用每天站会的方式同步开发进度和需要解决的问题,每天站会显得比较繁琐而且至少会占用30分钟的时间。

采用在线文档的方式进行项目进度的跟进成了一种不错的选择。在原来项目排期表中增加【进度】和【备注】两列,其中进度用于同步每条任务的完成情况,备注用于增加对该条任务以外情况的描述,比如后台未提供接口,第三方未提供接口等等。

通过对项目排期表中进度的描述,项目管理人员可以很清楚和直观地了解到目前项目进行的状态,正常进行,延期还是提前完成,并且可以了解研发人员的反馈,及时处理开发过程中出现的意外情况。

可以利用project中的报表工具对项目进行的状态和开发进度进行评估,直观的了解项目状态。项目经理每周将需求开发情况,出现的问题及解决情况同步至项目组成员和领导,以便大家及时了解项目最新进展。

3. 需求变更

在理想情况下项目进度会按照项目排期表有条不紊地进行,完成一个个产品功能的提测,完成一个个产品功能的测试,验收和上线。但是实际情况中,往往会出现各种情况影响正常的开发迭代,其中最常见的就是产品需求变更和技术因素。

俗话说,计划就是用来改变的,在互联网产品开发过程中,产品需求变更往往也是避免不了的。虽然说需求变更备受UI、研发和测试同事的吐槽,但是需求变更来了的时候,还不得不进行需求变更。针对产品功能的变更首先是要了解变更的来源在哪里,是否有必要变更,开发的工作量有多少,是不是一定要在这个版本上线,放在下个版本开发是否可行。

3.1 产品功能补充/小改动

在开发的过程中,产品经理突然发现遗漏了某种场景或特殊情况,对产品需求进行的补充和修订。客户需求发生变化,需要产品功能进行对应的更改。这个时候需要产品经理根据最新的需求补充产品文档,并同步至研发、测试和项目经理,项目经理根据产品需求变更带来的工作量对项目排期表进行调整。

调整的原则为保证关键任务和关键人员的进度,对新增需求开发工作量进行评估并增加到项目排期表中,同时根据变更后的项目排期表调整部分需求的提测时间。这部分需求变更的管理有一个前提就是不影响关键任务和关键人员的安排,或者是对该部分影响较小。

3.2 产品功能的增加

有时候出现大的产品功能的增加,这往往可能来自于业务方面迫切的需求或是领导对整体规划的调整。这里所说的产品功能的增加指的是增加一个完整的功能,并且会需要较大的工作量,直接加上该功能会对原有项目排期产生重大的影响。

在这种情况下,一般是要确定产品需求,确定产品需求文档,避免出现后期需求变更的问题,评估整体的工作量,查看新增工作量对于整体迭代周期的影响。然后对版本范围中为开发的,优先级相对来说比较低的需求安排在下个版本上线。如果时间还是比较紧张,可以向领导说明情况并根据实际情况进行适当延迟。

3.3 产品需求变更流程

在需求变更过程中非常重要的环节就是注意变更流程和变更规范,以保证整体的上线质量和上线效果。首先由需求方(运营/产品)填写《需求变更申请表》提出需求变更的原因和内容,由产品更改产品PRD,再进行需求评审,如果是小更改可以直接在群聊中解决的就不用再进行需求评审会。

最后项目经理作为统一的归口同步更新《版本范围列表》和《项目排期表》,项目组的各项成员统一以最新的产品PRD,《版本范围列表》,《项目排期表》进行产品功能的开发,测试及验收。

需求变更的规则还有:

  1. 尽量在开发早期提出需求变更;
  2. 提测之后不接受需求变更;
  3. 变更后的需求一定在产品PRD中标注,并在微信群中@相关人员;
  4. 产品上线统一由项目经理做为归口,以《版本范围列表》为准;
  5. 采用在线文档或是公司网盘的方式同步文档,以确保所有人获得的是最新版本的文档;
  6. 所有文档如有变更,必须进行记录。

最后项目经理要对每次项目迭代过程需求变更进行记录和总结,反应在项目总结当中。如果是在需求理解或是需求设计中出现的问题要吸取教训,在以后的产品设计中进行改进。

4. 技术因素

随着产品功能的增加,用户数量的增加,在实际开发的过程中,技术研发人员往往会在开发新需求的同时修复线上BUG的问题。对于线上BUG的及时响应,及时修复,在占用研发时间中很大一部分用在和运营/产品的沟通中。

那么此时需要对BUG的处理进行优先级和处理时间的分类。对于影响用户量很大,非常影响用户体验的BUG,问题提出当天进行反馈,尽量在当天或第二天上线。

同时BUG处理流程会按照下图严格实施,以减少技术沟通时间,提高研发效率。对于不太紧急的BUG,在开发任务比较紧张的情况下,会在版本上线之后的一周内上线,在开发任务比较宽松的情况下,会在一周之内统一解决,统一验收,统一上线。

在项目进度管理的过程中做好来自以上几个方面风险的应对基本能够控制项目整体进度,保证产品功能上线。在项目进度管理中最核心的内容就是让项目成员了解项目概况,了解自己的工作内容和上下游关系。当出现不可避免的需求变更时,积极应对,拥抱变化,随和和团队同步最新需求和最新进展。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/3803.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息