舌战群雄|如何高效的进行产品交付会

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

uld-consider-an-in-house-pr-team

产品设计人员有一项重要的工作,就是将自己所设计的东西交付给研发,由研发人员进行后续的工作。最终产品的实现,还是要依靠我们辛劳的研发同志。所以就有了产品交付会。

有些公司叫需求评审会,但是我个人认为交付与评审还两个概念,可是也并非不可并行。在我看来,“交付”,是将确定无误的东西给到研发(还是那句话,确定无误?臣妾做不到啊~),而“评审”,更多在于“评”。由大家集思广益,对产品设计进行优化。

然而如果项目比较紧急,不会有专门的评审会,只能依靠前期的沟通,来完成大部分“评”的工作。

此次我重点说产品交付会。而且前提是大家对要做什么功能已经有了基本了解,但是具体的细则,还是需要小小的“讲&评”一下。

拿我所经历过的交付会和评审会来说,基本流程差不多,而且也挺有意思。所以特特做了一组小漫画,让大家感受一下这种气氛。

(截图+axure排版,视觉效果还请不要挑剔)

1

PS:

本身产品评审就是个枯燥的工作,产品人员不停的讲,研发人员不停的脑补。如果提前不做准备的话,还真不知道产品在BB什么。

所以我通常的做法是:

提前一天将交付的内容发给研发人员,并在邮件中注明,此次要新增什么功能。贴上对应的DEMO地址,方便研发人员查看,这样交付会就会开得比较有针对性。

在之前的文章中我曾经提过,修改了哪些地方要明明白白的标记出来,具体可以查看 WEB端UE设计及管理规范-2

2

PS:

上文也提到了,交付的过程也是PK的过程。研发可能会提出的问题大概有这么几种:

  1. 你刚才说的某个功能,我没怎么听明白,能不能再说一下?
  2. 这个功能做的有意义么?我怎么觉得好像没有必要啊。(其实他们想说,这TM做了谁用啊)
  3. 你有没有考虑到这么整会影响到**、**、**、**地方啊?那些地方你打算怎么处理?
  4. 你这边的逻辑是这样设计的,但我们那边数据库不是这么设计的,可否换种实现方式啊?
  5. 你这个业务规则设定的压根就不符合逻辑啊……

同样见着拆招了

Q:你刚才说的某个功能,我没怎么听明白,能不能再说一下?

A:一般交付其实不用说的太详细,我曾经也细致到单个字段,但是发现效果并不好。既浪费时间,而且也没有人能耐着性子那么长时间都集中注意力听你BB,所以捡主要的讲即可。如果你没听明白,没关系,我再稍微具体点跟你说清楚。如果我说完,你没问题了,就视为你认可了。

Q: 这个功能做的有意义么?我怎么觉得好像没有必要啊。(其实他们想说,这TM做了谁用啊)

A: 此时可以搬出用户的需求、市场的需求、竞品的分析等等来说服研发,最后来一句:我们所做的每一个功能,都是经过深思熟虑的,这你放心好了。但是千万不要说,这是我们定好的,你们执行就行了,不用管他合不合理。如果你真的这么说了,研发人员内心已经把你捅了N多遍了。强压之下给你来个罢工,那你就没辙了。

Q: 你有没有考虑到这么整会影响到**、**、**、**地方啊?那些地方你打算怎么处理?

A: 如果你已经考虑到了,那最好,请直接陈述即可。如果你本身没有考虑到,这时就要赶紧服软。因为当你说这个功能的时候,程序猿同学已经在脑海中遍历一遍了,他们是思维严谨的单线程生物,只要他们提出来的,绝大多数都是会真的产生影响的,你也没必要嘴硬死不承认。此时最好的方式就是赶紧说好话:哇塞,猿哥想的好全面啊,我都没有想好,我回去要好好补上,多跟猿哥你请教请教。那这一块等我补上之后再发出来大家看看,成不?

Q: 你这边的逻辑是这样设计的,但我们那边数据库不是这么设计的,可否换种实现方式啊?

A: 可爱的程序猿不是执行任务的工具,他们很有自己的想法,所以当他们提出这个问题的时候,多半其实已经帮你想好解决方案了。你只需要说:具体要的嘛,就是这么一个功能,猿哥你有什么好的意见,如果实现简单,那当然是按照你的方式来执行了。可是前提要满足我这个功能哦。

Q: 你这个业务规则设定的压根就不符合逻辑啊……

A: 遇到这样的问题,就好比产品人员心理出现了个晴天霹雳。。来,哥我们慢慢说,哪里不符合逻辑了,如果确实是有逻辑漏洞,如果影响比较大,建议会议结束吧,产品人员回去好好反省去吧。如果是小的漏洞,那我们就商量下怎么弥补了吧。

3

PS:

惊险过后,继续开会,下一个功能,又是一次PK的开始。

4

PS:

评估工作量的时候,我个人基本是不会插嘴的,除非是大家需要回顾刚才的功能点,我会再简单帮大家梳理一下。毕竟研发需要多久,研发心里面更清楚,大家都是一个团队的,合作就是建立在互相信任的基础上的,也没有必要特别去压迫别人的时间。

5

PS:

会议结束,此时通常一个半天就过去了,产品赶紧要把会议中承诺要完善的部分完善起来,因为接着就要进入开发了,如果迟迟不调整,等于间接压缩了研发的时间,这样大家心情就不美丽了。

最后:

跟研发人员合作这么多年,我始终认为,研发哥哥们,是一个很可爱的群体,虽然经常会被我给坑到,也会经常背后吐槽(没关系,只要你们开心,尽管吐槽好了),但是真心来说,只要你本身做的够好,研发人员基本不会故意推脱工作。偶尔不开心,哄一哄很快就没事了,所以我个人特别喜欢跟程序猿混。

 

作者:宋娟(个人公众号 UED_ID_Designer),曾在苏宁易购、焦点科技就职过,现在一个创业团队任职UE主管。6年互联网产品设计经验,曾主导苏宁易购以及百卓采购网等多款产品的产品规划和设计工作。个人网站地址:www.so-sweet.cn

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

您的赞赏,是对我创作的最大鼓励。

评论( 2

登录后参与评论
  1. 请问《WEB端UE设计及管理规范-2》这篇文章的链接能给一下么 :oops:

    回复
    1. 回复

      不好意思,没有链接上去。请移步到我的个人网站查看吧。
      http://www.so-sweet.cn/531-2/

加载中