作为产品经理，你是否遇到过在评审会议上各相关方，包括老板、业务、UI、技术等，对设计的原型都有不同意见。评审会一度很尴尬，会后也不知从何下手。
刚从事产品经理的时候，我就遇到过这种情况，随着自己的经历越来越丰富，对评审中的流程和沟通进行了升级。从踩过的坑总结成长。
一、评审的分类
在互联网行业，评审有很多类型。比如需求评审、UI评审、技术评审、TC评审等。其中需求评审是产品经理需要组织进行的工作。UI评审、技术评审、TC评审分别是由UI人员、开发人员、测试人员组织进行的。
需求评审：是PRD、原型评审的统称。根据公司规模和文化不同，进行的评审内容也不同。一般情况下大厂是需要写PRD的而且逻辑要清晰完整；小厂一般只进行原型评审，把逻辑或规则写到原型页面就可以。
UI评审：在原型评审之后，产品经理把解决方案交由UI人员出设计图。很有责任心的UI会针对解决方案提出交互设计、视觉设计方面的优化或建议，不过这也看个人能力。有的UI经验少，设计图完全按照产品经理的原型来，没有融入自己对业务、需求的理解来设计。
TC评审：对于大型软件或者大厂是需要测试人员写测试用例的，小厂一般都是由测试人员点点点。
技术评审：由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细地检查，以找出和消除其中的缺陷。
二、当年评审的坑
当初刚做产品经理的时候，是不是满怀一腔热血要改变世界。根据客户或者公司内部人员提供的需求设计出的原型自认为很完美，满足需求。于是满怀信心的召集了老板、业务、UI、技术等一屋子的人进行评审。一心想赶紧评审自己牛逼的设计。可是评审进行10分钟时，突然发现情况不对，讨论已经达到炸锅的程度。老板、业务、UI、技术从不同角度表达了自己的见解。现对当时踩过的坑总结如下：
坑1:没有进行需求再确认：收集上来需求之后，没有进行需求的再确认，就认为我理解的就是客户所表达的。
坑2:没有进行解决方案的逐步确认：设计出原型，没有分步找相关方进行确认。
坑3:没有把会议标准化：会议的召开很生猛，直接群里@相关人员说要某时某地进行需求评审。
三、升级打怪后的流程和沟通
经过了几次这种尴尬的情况之后，感觉到这种方式急需改进。寻找同行、朋友、看书等方式找寻解决办法。再和自己的实际工作结合改变如下。
需求再确认：分两层去理解。第一层：需求描述的再确认。把从客户、业务、老板等人员得到的需求理解，用自己的话表述出来，与他们进行确认；第二层：原型的再确认。设计出原型，第一步找客户、业务、老板分别沟通下，看看是否符合需求；第二步与技术沟通下，看看技术实现是否有障碍；第三部召集所有人进行集体评审。
会议的标准化：要想把会开成功，是很多注意事项的，比如会前要提前把开会资料和内容介绍通过邮件邀请相关人员并群里@相关人员查收邮件，让他们提前了解，同时可以提前收集问题，让大家的理解内容在同一频道；会中针对解决方案进行讲解，过程中针对收集的问题进行重点讲解，让大家更好地参与；会后把开会的决议以邮件方式发送给相关人员并群里@相关人员查收邮件。
网友评论