产品设计人员有一项重要的工作，就是将自己所设计的东西交付给研发，由研发人员进行后续的工作。最终产品的实现，还是要依靠我们辛劳的研发同志。所以就有了产品交付会。
有些公司叫需求评审会，但是我个人认为交付与评审还两个概念，可是也并非不可并行。在我看来，“交付”，是将确定无误的东西给到研发（还是那句话，确定无误？臣妾做不到啊~），而“评审”，更多在于“评”。由大家集思广益，对产品设计进行优化。
然而如果项目比较紧急，不会有专门的评审会，只能依靠前期的沟通，来完成大部分“评”的工作。
此次我重点说产品交付会。而且前提是大家对要做什么功能已经有了基本了解，但是具体的细则，还是需要小小的“讲&评”一下。
拿我所经历过的交付会和评审会来说，基本流程差不多，而且也挺有意思。所以特地做了一组小漫画，让大家感受一下这种气氛。
PS：
本身产品评审就是个枯燥的工作，产品人员不停的讲，研发人员不停的脑补。如果提前不做准备的话，还真不知道产品在BB什么。
所以我通常的做法是：
提前一天将交付的内容发给研发人员，并在邮件中注明，此次要新增什么功能。贴上对应的DEMO地址，方便研发人员查看，这样交付会就会开得比较有针对性。
在之前的文章中我曾经提过，修改了哪些地方要明明白白的标记出来，具体可以查看 WEB端UE设计及管理规范-2
PS：
上文也提到了，交付的过程也是PK的过程。研发可能会提出的问题大概有这么几种：
Q：你刚才说的某个功能，我没怎么听明白，能不能再说一下？
A：一般交付其实不用说的太详细，我曾经也细致到单个字段，但是发现效果并不好。既浪费时间，而且也没有人能耐着性子那么长时间都集中注意力听你BB，所以捡主要的讲即可。如果你没听明白，没关系，我再稍微具体点跟你说清楚。如果我说完，你没问题了，就视为你认可了。
Q： 这个功能做的有意义么？我怎么觉得好像没有必要啊。（其实他们想说，这TM做了谁用啊）
A： 此时可以搬出用户的需求、市场的需求、竞品的分析等等来说服研发，最后来一句：我们所做的每一个功能，都是经过深思熟虑的，这你放心好了。但是千万不要说，这是我们定好的，你们执行就行了，不用管他合不合理。如果你真的这么说了，研发人员内心已经把你捅了N多遍了。强压之下给你来个罢工，那你就没辙了。
Q： 你有没有考虑到这么整会影响到**、**、**、**地方啊？那些地方你打算怎么处理？
A： 如果你已经考虑到了，那最好，请直接陈述即可。如果你本身没有考虑到，这时就要赶紧服软。因为当你说这个功能的时候，程序猿同学已经在脑海中遍历一遍了，他们是思维严谨的单线程生物，只要他们提出来的，绝大多数都是会真的产生影响的，你也没必要嘴硬死不承认。此时最好的方式就是赶紧说好话：哇塞，猿哥想的好全面啊，我都没有想好，我回去要好好补上，多跟猿哥你请教请教。那这一块等我补上之后再发出来大家看看，成不？
Q： 你这边的逻辑是这样设计的，但我们那边数据库不是这么设计的，可否换种实现方式啊？
A： 可爱的程序猿不是执行任务的工具，他们很有自己的想法，所以当他们提出这个问题的时候，多半其实已经帮你想好解决方案了。你只需要说：具体要的嘛，就是这么一个功能，猿哥你有什么好的意见，如果实现简单，那当然是按照你的方式来执行了。可是前提要满足我这个功能哦。
Q： 你这个业务规则设定的压根就不符合逻辑啊……
A： 遇到这样的问题，就好比产品人员心理出现了个晴天霹雳。。来，哥我们慢慢说，哪里不符合逻辑了，如果确实是有逻辑漏洞，如果影响比较大，建议会议结束吧，产品人员回去好好反省去吧。如果是小的漏洞，那我们就商量下怎么弥补了吧。
PS：
惊险过后，继续开会，下一个功能，又是一次PK的开始。
PS：
评估工作量的时候，我个人基本是不会插嘴的，除非是大家需要回顾刚才的功能点，我会再简单帮大家梳理一下。毕竟研发需要多久，研发心里面更清楚，大家都是一个团队的，合作就是建立在互相信任的基础上的，也没有必要特别去压迫别人的时间。
PS:
会议结束，此时通常一个半天就过去了，产品赶紧要把会议中承诺要完善的部分完善起来，因为接着就要进入开发了，如果迟迟不调整，等于间接压缩了研发的时间，这样大家心情就不美丽了。
最后：
跟研发人员合作这么多年，我始终认为，研发哥哥们，是一个很可爱的群体，虽然经常会被我给坑到，也会经常背后吐槽（没关系，只要你们开心，尽管吐槽好了），但是真心来说，只要你本身做的够好，研发人员基本不会故意推脱工作。偶尔不开心，哄一哄很快就没事了，所以我个人特别喜欢跟程序猿混。
U962240960
U575789758
