专栏名称: 人人都是产品经理
产品经理不再是一个单纯的职位,而是一种思维方式,这种思维是所有互联网人必备的,做互联网的人不能不懂产品,关注产品,改变生活。
目录
相关文章推荐
人人都是产品经理  ·  逃离G端,我拿到了涨薪20%的AI产品offer! ·  5 天前  
人人都是产品经理  ·  骑手群体不该成为短视频“佐料” ·  6 天前  
三节课  ·  国庆假期没安排的人,有福了 ·  1 周前  
人人都是产品经理  ·  支付宝「碰一下」微信 ·  1 周前  
51好读  ›  专栏  ›  人人都是产品经理

关于需求评审,网易内部是这么“玩”的

人人都是产品经理  · 公众号  · 产品  · 2017-04-18 19:43

正文

作者:何燕华,网易资深项目经理,PMP,CSM。先后在网易私有云、网易用户中心、网易GACHA、网易LOFTER等项目担任项目管理工作,积累了丰富的项目管理实践经验,并始终致力于项目的成功交付和团队的健康发展。《网易一千零一夜》主要作者之一。

本文由 @网易杭研项目管理(微信公众号:NetEasePM) 原创发布

未经许可,禁止转载



首先,我这里提到的需求包含了:需求,交互,视觉。


当然,在调整到当前状态之前我们的需求评审也存在很多问题,之前我们也有探讨过需求管理的方法。所以,我这次先来介绍一下比较原始的需求评审的方式以及存在的问题。


以前我们的做法是:


  • 需求评审:各角色的负责人(包含策划,交互,视觉,开发,测试,运营等角色负责人)来参与,没问题的需求全部进入交互阶段进行交互设计

  • 交互评审:所有成员(含所有策划,交互,视觉,开发和 QA)参加,所有交互稿均会交付给视觉同学进行设计

  • 视觉评审:基本无


以上这样的状态,给我们带来了几个困扰:


  1. 首先是所有需求都会进入交互设计和视觉设计阶段,但是最终有可能因为开发评估之后做不完而被搁置,形成了设计资源的浪费

  2. 交互评审全员参与,由于人数众多,而且分工还未确认,开发并不知道自己负责哪部分,所以参与度很低,一般就是交互在讲,开发就在下面听,也不一定能提出问题,到了后半程,有些同学就开始玩手机,效率很低

  3. 视觉评审的缺失,视觉评审由于没有约定明确的评审流程,所以有一些视觉没有经过评审就进入了开发阶段,直至需求走查的时候才发现有问题


基于以上问题,我们逐步对相关的评审机制做了一些调整,调整后的情况如下:


需求评审


参与人员:策划,交互,视觉,开发,测试,运营等角色负责人


评审目标:评审需求的优先级和价值,以及初步判断可实现性


评审形式:集中会议。需求评审完成后的一天内,开发对需求的大小进行初步评估。从估算和计划的角度来看,可以认为这是在需求细节还没那么明确的情况下的评估,有可能存在 50%± 的偏差,但是他能将多余 50% 之外的需求砍掉,不必再进入交互阶段。


调整思路:主要增加了开发的初步评估,将大大超出团队容量的需求提前砍掉,减少了交互的工作量,使得交互稿可以提前交付,同时也避免了不必要的交互浪费,因为当前版本未能开发的功能,在下一个版本可能优先级就又不一样了,或者早已不符合市场需求了。


交互评审


参与人员:团队核心成员(交互评审),相关功能的各角色成员(交互说明)


评审目标:评审交互的合理性,以及交互的可行性评估


评审形式:分为交互评审和交互说明


整体交互稿的交互评审,在交互评审后一天内,参与评审的核心开发针对交互做一个基本的评估。反馈:哪些需求肯定做不完,这些需求就不需要全部进入视觉设计了。


在交互和视觉稿基本确认之后,在当前迭代的后期,再分批跟相关功能的开发和测试进行交互说明。此时,开发的基本分工已经确认,大家会更细致来听,并且能够提出比较细节的问题,当然此时交互稿需要修改的问题会比较少,基本不影响整体的安排。


调整思路:


  1. 与需求评审一样,交互评审之后,基本上就能确认工作量,但是只需要核心的开发在交互评审之后的一天内大致评估工作量,定义是否有一些需求已无需进入视觉阶段,减少了浪费。

  2. 缩小参与交互评审的人员范围,让在场的人能够充分参与;节约未来参加评审的同学的时间。

  3. 缩小参与交互评审人员的范围,可能牺牲了一部分其他人的意见,为了补充这部分人的意见,所以在新迭代即将开始的时候再组织一次交互说明,不仅引入了这部分人的意见,同时也可以将交互做更细致的沟通。

  4. 最后的交互说明,不需要所有人同时过来,而是分批进行说明,这样既能让具体的执行人员能够了解交互细节,又不会浪费大家时间。


视觉评审


参与人员:相应的策划,交互,视觉,以及视觉负责人


评审目标:评审视觉稿是否满足需求,以及从策划和交互的角度提出建议


评审形式:当面沟通。视觉设计师会将设计稿邮件发给相应的策划交互,抄送开发,并且邀请策划和交互当面沟通意见。


调整思路:


  1. 视觉稿没有评审,经常出现在后期策划交互走查时发现问题。但是视觉稿的评审又不适合做的太重,本身视觉设计是一种无法明确定义好坏的问题,不是越多人参与就越好,所以只定义策划和交互参与,开发只需看实现上是否有困难即可(一般比较少)

  2. 形式必须定义清楚,否则就会容易执行不到位。


结语


当然,调整之后的模型也有一些限制条件:


  • 交互评审的时候,能够找得到所谓的“核心开发”,他要对产品整体的业务逻辑都非常清晰,能够评估新提出的需求大致的工作量。如果团队中的开发都是独立负责一块,项目之间都不了解情况的,那就比较难采用这种方式。

  • 这样的视觉评审形式其实也是比较依赖大家的主动性。否则就需要一个人,如视觉负责人来监督,是否所有视觉稿都经过评审。



每日一问

▐ 话题:你遇见过最坑爹的需求是什么?

• 运营:我有个需求,提交评审咯,你看下。

• 产品:什么需求?

• 运营:我们还在想

• 产品:???


• 老板:觉得我们要把APP做的更吸引人一点。

• 产品:好的,您的想法可以大致给我讲下吗?

• 老板:我还没想清楚,你帮我想下,月底就要   改一版。OK伐?

• 产品:???


遇到这样坑爹的需求,真是闻者伤心听者流泪,这尼玛咋做?你告诉我,咋做?


你有遇过最坑爹的需求不?


灯光师已就位,场务把话筒准备好了,在评论区说出你的故事!



本期奖品


这次奉上的经典书籍是《设计冲刺—谷歌风投如何5天完成产品迭代》,详述了一套解决棘手难题五天式流程(这套方法已经帮助100余家初创公司成功起步),教你如何从验证创意到产品落地,快速占领市场先机。

好书不容错过哟~快来拿吧~


▐ 符合以下条件的小伙伴们即可获得奖品:

1. 高质量的评论(走心的那种)
2. 评论被赞数名列第一

3. 评论被赞数不少于30


明晚开奖!请留意明天的 头条文章推送哦,不见不散~ 



点击“阅读原文”下载APP