产品开发:项目管理的在实际工作中的应用

0 评论 2516 浏览 7 收藏 16 分钟

编辑导语:在上一篇文章《超硬干货:如何把需求变成产品方案?》中,作者从前期准备、方案设计、需求评审三个层面,为我们分享了如何把需求变成产品方案。本篇文章中,作者和我们聊一聊在评审会之后,进入到产品开发过程有哪些关注点。

上一篇文章,我给大家介绍了把需求变成产品方案过程,以及为了通过需求评审,要注意的几个点。

那通过评审会之后,我们产品要做的工作,就是推进项目、关注进度、并按时上线。所以,这篇文章,我会在“实用”的层面,从项目排期—>需求开发—>上线前体验—>产品上线,这四个步骤,给大家从介绍下,在产品开发过程中要关注点。

一、项目排期

通过评审会的需求,需要根据需求的优先级,进行资源分配,排期开发。

如果大厂的话,一般都会有项目经理来支撑这块工作;如果是中小公司的话,通常是由研发负责人来承担分配任务的角色的。此时,我们产品需要做的工作就是,关注自己需求的排期情况。

如果是较紧急的需求,或领导比较关注的需求,要尽可能需求提高优先级,为自己的争取开发资源。

在这个场景下,沟通技巧就很重要了。如果是优先级较高的需求,我的方法是:先跟对方陈述需求背景,然后强调需求尽快实现重要性,辅以领导关注的背景,将压力传递过去,提高需求优先级。

其次,在沟通时,最好是线上沟通,否则资源紧张排不上期,后面领导问起来,也有文字留档。

二、需求开发

需求排期之后,一般项目经理会通过既定渠道告诉你,你的项目已经分配到对应的开发了,那次是,我们就可以跟进需求开发的情况了。

根据经验,在开发阶段,是最容易导致需求延期的。所以,我们要利用项目管理的方法,尽可能避免出现延期的风险。总的来说,需求开发跟进过程要保证分工具体、工作量化、风险可控这三个点。

1. 分工具体:方案同步,拆解工作

首先,在开始之前,我们首先要根据需求文档,跟对应的开发阐述需求。

力求对方和自己要实现的需求预期是一致的,如果是多端合作的大需求,工作分配要具体到人的话,每项工作,每个功能模块都必须拆解出来,并以会议形式同步。

关注明确需求的负责人,将负责人落到会议纪要,并最终在项目群群里同步。

2. 量化工作:明确开发周期

在同步好方案后,就需要明确开发的开发时间。即:我们要关注谁,在什么时候开始,预期什么时候能完成。

我们团队的开发流程,一般是需要开发根据需求文档,出技术方案,然后提交到技术团队,进行内部技术方案评审,评审通过之后才能知道具体的开发工作量。

所以,在前期沟通方案时,我也会先跟对方明确技术文档完成时间和上会时间。在明确技术方案之后,再和相关同事对齐具体的开发排期,并在群里同步。

这里我有个小技巧,就是我一般会在开发评估的时间上,多加上1-2天,然后再同步出来。因为人都是会高估自己工作能力的,所以在开发过程中,很可能会超出既定预期的。

我们团队的项目经理会通过“甘特图”来明确项目的进度和落地进展。

所以,工作量如果确定下来,我们可以用上面甘特图的方式,将拆解出来的任务、预计进度、实际进度,统统进到表中。我们一般是在“腾讯文档”上,通过建立共享文档的方式,来给团队各成员同步项目进展的。

3. 风险可控:设置反馈节点,按时回收反馈

在确定好项目安排之后,就可以正式进入开发阶段了。在开发阶段,最容易出现的风险的,就是因为开发未按照预定时间开发,导致延期。

所以,我将从向下和向上的两个角度,来介绍如何让风险可控:

1)向下管理:负责的项目,及时了解项目进展

在开发过程中,我们项目根据甘特图排好期之后,还需要另外设置反馈节点,然后定期回收反馈信息,才能知道我们手里需求的开发的进度。

我如果手里有多个需求在并行的话,我每天早上和下午都分别会花1-2小时,分别跟进开发的开发进度,并且叮嘱对方,如果有发现困难需要我支持的,要及时跟我同步。

因为,在实际工作中,并不是所有开发都是很主动的,所以我们自己要主动去了解开发进展,看是否有方案上的调整,开发延期的情况。

如果有方案上的调整,尤其是涉及产品功能的调整,我们要及时用文字方式,在群里跟项目成员同步调整的原因和调整后的结果。

而后,尽快抽时间更新需求文档,明确调整时间。如果是大项目的话,可以定个一周/次的项目同步例会,以便定期和各方同步项目进展,以及遇到的困难。

2)向上管理:跟领导及时汇报进展,同步困难

在了解项目进展之后,我们也要及时和领导同步自己手中的需求进展情况,有困难要及时暴露出来。我见过一些刚入行的新同学,可能是碍于情面,不敢或不好意思跟领导说明困难,最终导致项目延期的。

其实,这是一个非常不好的“学生气”。我们遇到问题时,能够适当寻求领导支持,对工作来说,也是很重要的。

但注意,我这里说的要“适当”,是我们要注意把握“度”,遇到困难我们要先尝试自己解决,不能说每个需求都让领导支持,否则领导也会怀疑我们的工作能力。

我的习惯是会在每周的周三下午,在有领导的项目群里,@下领导和对应开发,同步开发进展、完成时间和项目困难。

我选周中是因为我预留了调整的时间,如果真有问题,周四周五可以及时调整,时间上才不会太紧。如果有人对进展或需求有问题的话,也可以及时在群里讨论解决。

这样做,除了同步进展和预留时间之外,还有一个好处:在群里通过文字留档,起到保护自己的效果。

三、上线前体验

在需求开发完成后,需求离正式上线只有最后两步之遥——产品测试和产品走查。

1. 产品测试

在需求开发完成后,首先进入测试环节。测试环节,我们首先需要在测试环境,体验产品核心流程是否符合开发预期。

然后,根据需求文档,给测试介绍整个需求的背景和需求预期,以便测试输出测试用例,这里主要是针对异常流程的测试。这里的重点是,必须让测试对产品的理解和你是一致的,否则容易出现部分异常流程没有测到的情况。

最后,就是让测试同学的工作,也要遵循在开发阶段,需求推进的三步走策略——明确分工、量化工作、风险可控这三点。

2. 产品体验走查

在这个环节,主要是针对有前端页面的需求,在产品的使用流程和前端的页面设计的走查。这部分的工作,通常需要交互和设计同学支持,看这里的体验是否符合产品设计的预期。

而在这个阶段,产品也需要和交互设计一起,体验产品的细节。这是一个非常磨炼产品人,可是却不能偷懒的工作。我见过所有优秀的产品经理,都对产品细节有极致的追求。

我一开始其实也做的不好,主要是沉不下心来做这个事,所以也经常因为粗心出过错。

但后来,我看过一本叫《清单革命》的书:书中主旨是:因为粗心出错的情况,在各行各业都比比皆是。但所有的复杂流程,都可以通过建立清单的方式,减少出错的情况。

即:把工作中所有的必做项,都列成清单,在具体实施的时候,一项项勾兑完成。这样就能极大地减少出错的情况,做到不重不漏。后来我也建立了属于自己的《上线走查清单》,从页面中从上到下要关注的细节,流程中从入口到出口的页面,逐一体验通过。

所以,我建议大家如果没有建立走查表清单的同学,也开始建立一套属于自己的清单,可以极大地减少,由于粗心导致的问题。而且,如果有问题但当前版本已经来不及调整的话,我们也可以把这个优化点放到需求池中,下个版本的规划中,再放进去。

四、需求上线

在完成上线前的测试和走查之后,需求就可以根据原定的时间安排上线了。而在上线前,可能还需要准备一些资料。

如app上线的话,需要准备一些应用商店的文件、描述、图片;或是产品内帮助中心的文档、智能客服的描述;但如果是B端产品,可能需要准备新功能的客服或销售的培训文档等。

因为产品的不同,需要准备的东西可能也不一样,这里大家要根据自己的产品或行业准备即可。当然,如果比较复杂的,也可以用上面说的清单的方式,来建立走查表。

除此之外,我还想讲两个,个人认为非常重要的点:

1. 关注数据变化:是产品优化的方向

我之前有很多需求完成之后,没有及时关注数据变化的。当时我的领导在会上有“提醒”过我,他说:有些同学工作习惯还是要加强下,产品上线后不看数据的,你根本就不知道你这个产品功能有没有用户用。你不看数据和没做需求有什么区别?

后来,我领导为了专门培养我这个习惯,隔三差五就会问我某个功能的数据情况。而后,我为了减少被领导问到的窘况,我每天早上都会花一个小时的时间,看产品数据,并尝试分析数据抖动的原因。

2. 项目复盘:不复盘=白忙活

产品的工作,失败的需求要远多于成功的需求。我们团队的产品,为了实现破圈,去年一年在产品上新增的功能,无一不是失败的。

为了增加产品留存,我们增加过游戏模块,上过签到返现能力,也弄过积分体系、会员体系,可无一被用户接受。可失败之后,我们一直在复盘,因为复盘,是我们唯一能从失败中获取的最有价值的东西。

我觉得对产品人来说,最好,也是成长最快的捷径,就是复盘。具体复盘的话,可以从整体的产品流程入手。

从前期调研—>需求分析—>方案设计—>需求开发—>产品测试—>产品运营入手,对整个项目流程进行复盘。结合当时背景、遇到问题、当时处理方式等,进行反思和总结,最终得出优化的复盘方案。

我们也可以从目标入手。对比目标预期和实际实践环节,对比差别,看到不足之处,以及如果重新做的话,我该如何优化实施环节。并且,我们还要结合产品数据表现,进行更全面的思考分析,输出优化的结论。

这样,我们的项目,才形成了一个优化迭代闭环,在下一个需求或项目时,才不会重蹈覆辙。

五、写在最后

产品需求落地的过程,就是项目管理实操的过程。

  • 首先,我们要先明确项目排期,可以用背景+领导关注的阐述方式,提高需求优先级;
  • 其次,需求开发和测试过程中,要遵循分工明确、工作量化、风险可控这三个原则;
  • 然后,在上线前体验过程中,可以通过自建走查表的方式,减少出错的可能性;
  • 最后,需求上线之后,需关注数据变化,并及时复盘,记录优化点,输出改进结论。

这样,我们才构建了一套完整的需求闭环。

 

本文由 @豆奶 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!