关于需求评审,网易踩过的坑...



原本觉得需求评审也就那么回事儿,大家应该都差不多这么做的,没啥好说的。不过前不久有一位同学问起来我们是怎么做需求评审的,然后发现有一些团队的做法可能还不大一样,他们也还踩着我们之前踩过的坑,他们还在探索更好的方式,于是决定将我们的“玩法”写下来,也许能给困境中的小伙伴一些启发。


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

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


以前我们的做法是:

  • 需求评审:

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

  • 交互评审:

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

  • 视觉评审:

基本无


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


首先

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

其次

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

最后

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



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



【需求评审】

  • 参与人员:

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

  • 评审目标:

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

  • 评审形式:

集中会议。

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


  • 调整思路:

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



【交互评审】

  • 参与人员:

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

  • 评审目标:

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

  • 评审形式:

分为交互评审和交互说明。

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

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


  • 调整思路:

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

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

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

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



【视觉评审】

  • 参与人员:

相应的策划,交互,视觉,以及视觉负责人

  • 评审目标:

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

  • 评审形式:

当面沟通。

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


  • 调整思路:

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

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



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

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


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


本文讲的更多还是术的层面,关于评审道层面的讲解在《网易一千零一夜》一书有详细解读,大家可以按需进行阅读。



关注公众号网易杭研项目管理(NeteasePM),网易一线项目管理实战分享,以及那些项目背后你不知道的故事。


近期,我们整理了网易内部4年来项目管理的心得,有需要的同学可以自行前往领取:关注公众号→历史精彩(底部菜单)→电子书。


©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,064评论 5 466
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,606评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,011评论 0 328
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,550评论 1 269
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,465评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 47,919评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,428评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,075评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,208评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,185评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,191评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,914评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,482评论 3 302
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,585评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,825评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,194评论 2 344
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,703评论 2 339

推荐阅读更多精彩内容