【giszz笔记】产品设计标准流程【6】
目录
六、组织评审
1.评审的类型
2.评审的人员——谁参加评审
3.评审的核心——怎么提问 & 答案谁说了算
4.评审的流程——前中后三部曲
5.评审的标的——漂亮的靶子
6.避免被“烤”问的一些技巧
7.搞几次评审比较好
这个产品设计系列，陆陆续续写了6篇了，虽然标题加了“标准”2个字，但仍然是漫谈，把这些年产研一体化过程中的心得，整理和分享出来。不是把一部电影的剧情，非要写成连续剧来卖钱，确实是写着写着，每一章都超出预期的字数。争取以后每天写上个一两千字，好好学习，从心出发。
今天重点来说说评审。
想参考之前文章的，我把链接给到这里。
【giszz笔记】产品设计标准流程【5】-CSDN博客
【giszz笔记】产品设计标准流程【4】-CSDN博客
【giszz笔记】产品设计标准流程【3】-CSDN博客
【giszz笔记】产品设计标准流程【2】-CSDN博客
【giszz笔记】产品设计标准流程【1】-CSDN博客
六、组织评审
评审是产品设计流程中，非常重要的一环。也是很容易被忽视的一个环节。
很多人说，这都是大厂必须的流程，搞评审，报OA，最后出问题了，更有利于找到合适的“背锅侠”呀！艾玛，虽然离谱，但是这个说法，我还真的不能随意抨击。曾经我就吃过这个“哑巴亏”。工期过于紧张，核心干系人口头同意，在没有评审会、没有OA、没有邮件确认的情况下，推动了进一步的项目流程。最终导致忽略了某个资源部门的协同，消耗多个人天去重新补足相关的环节。
所以说，真正的老司机，是特别喜欢有人评审自己的。新手才天天想要更大的权利和自由度。
这不是说讨论油腻的职场生存法则，而是评审的过程，让各个部门、各个干系人的信息、思想进一步的对齐，暴露问题，发现亮点，增进团结，提高效率。
1.评审的类型
一般分为内部评审，外部评审。
2.评审的人员——谁参加评审
内部评审，一般是由万能的产品经理来组织，因为这时主要被评审的成果物，是产品经理产出的。也可以是PMO来组织，也可以是项目经理按照项目进度来召集。参与的人员，包括产品团队，技术团队的核心人员，项目管理成员，产品/技术总监（vp），CTO等。高级leader也建议follow 内部评审会议，如果是小型的团队，或者一号项目，建议CEO要主动或者由适当的人员邀请CEO参会。避免CEO做出不符合实际的决策，成功邀请CEO参加重要的评审会议，这可以作为对上管理能力的一部分。
很多互联网和SaaS服务公司都取消了PMO这个部门或者相关岗位。没领悟要义的PMO，除了设置条条框框之外，有时确实无法提供更有价值的帮助。而且一线的战士，很多时候无法去指挥这个部门。当然，在交付类型的公司里，PMO这个项目管理的中枢，还是有重要的作用。对该岗位人员的协调能力和项目管理经验和执行力上，是比较大的考验。
外部评审，一般内部的人员出场就是产品线的关键人。我的建议是多让骨干人员倾听客户（用户）的声音，如果有可能，带更多的人参加评审，客户也觉得你们重视。你在那个“场”，就能理解更多信息，项目成员会更加的积极，甚至拉上技术、美工一起被客户骂，都是有积极作用的。客户方人员，注意要力争邀请到说话算的核心人员，如果关键人不参加，不要组织外部评审。避免更多不必要的麻烦，这个不展开。
3.评审的核心——怎么提问 & 答案谁说了算
评审会上必然有争论，有提问，有回答。那么谁是裁判，如何决定谁说的对呢？
有人说西方是冲突的文化，我们是和谐的文化，但是暗地里使劲。其实也不然，西方也有很虚伪的一面，比如这种夸奖，“XX，你真的是独一无二的！”特别是对中国人，老外知道中国人会把这种话术，认为是一种表扬，而对于他们来说，每个人自然是独一无二的，我只是说句善良的废话而已，并不违背自己的良心。
在一些技术和产品关系紧张的团队，产品经理，特别是新手产品经理，会把需求评审会，当做一次人生的低潮，一次劫难，想到要开评审会，就焦虑的胃疼那种。后面，我会对这种情况，写点自己的心得。
在大厂某团，有四大名著，《学会提问》，就是其中之一。
我的理解，学会提问成为四大名著，这里不光是开放的环境，批判性的思维，除了思考，还有语言的艺术。
评审会上，最常见的就是技术怼产品了。有的技术人员，设计能力甚至超过某些产品。所以，剑拔弩张，在内部评审会上，是经常见到的情况。说这说着，就上头了。激烈的语言当然很痛快，效率很高，可是信息密度未必大，翻来覆去，就是在表达情绪，这样常常会对团队带来不可逆转的伤害。
个人有一个可操作性比较强的方法，就是要求所有人减少使用反问句。比如很多人爱用这样的语法来说话：
“这个事你不能做吗？”
“这句话你听不懂吗？”
“你这里能用黄色吗？”
“这里不应该设置埋点吗？”
“你不应该先看我更新的文档再提问吗？”
……
这些话，其实都有其他的说法，就是改为陈述句。
“这个事从分工上，你来做合适。”
“我表达的清晰么，有听不懂的地方，告诉我。”
“这个地方不能用黄色。”
“这里应该设置埋点，这关系到后续ABTest的结论获取。”
“你没有更新文档，看的还是旧版，新版本中，我已经解决了这个问题。”
……
坚定，清晰，不带无谓的情绪。
大家可能觉得好累，好烦，我们就要直白，就要直怼的快感。实际上，我发现是人都喜欢听好的呀！屡试不爽呀！
立足于大家共同的利益，彼此相信我是尊重你的，敢于面对冲突，抱着开放谦虚的心态，发挥团队每个人最极致的专业能力，评审会才能真的开好。
哦，谁说了算，这其实是个很难的问题。有客户的，当然是客户说了算，除非客户的意见将带来巨大的灾难，或者客户的代表不是关键人。内部立项，面对内部客户的，如果大家的意见不能一致，那就是CEO或者最高产品leader说了算。
这不是官僚，尽管这是大部分团队实际就在发生的情况，但这其实并没什么问题。
你想，你们公司要上个产品，不相信CEO的洞察和嗅觉，那相信谁呢？即使CEO一叶障目，参加了评审会，依旧做出某个决定，那也要执行，不要有什么可纠结的。这是你们公司的宿命，干就完了。因为你想的未必对，事情是在发展的，有些问题在发展中，答案自然就出来了。
4.评审的流程——前中后三部曲
| 评审前 | 评审中 | 评审后 |
|
|
|
其中，问题可能会有多种类型：
- 一致认同的问题。
- 不能落实的问题。
- 形成结论的问题。
分别去讨论和处理，如上表的流程。
不要怕问题，也不要隐藏问题，也不要政治化问题，即使你的公司再大。一个组织的灾难，往往是从大部分人不愿意讲话开始的。
结论的形成，是让人开心的。要有会议纪要，有必要的评审会议记录流程，会后要抄报所有的干系人。
5.评审的标的——漂亮的靶子
就是评审什么东西。PRD当然是最常见的，这里，最好有PRD，有PPT，还有PLAN等辅助物料。
PRD包括了prototype，是评审的核心。
PPT我认为不是必须的，有的公司需要这个，有的不需要，比如字节这样的公司就不需要，因此飞书的在线PPT功能是用的WPS的，因为字节的文化就是，能一句话说明白的事，就不要写两句。更不能忍受给那么多人开着高薪，而他们却在漂亮的工位上，排版对齐一句正确的废话。话又说回来，PPT这么流行，当然有他优秀的作用，可以关键的地方，做上几页，如果想学习AI生成PPT，可以参考我的文章：【AIGC】如何让AI一键生成PPT-CSDN博客
特别是外部评审的时候，99%的客户，是爱看PPT的，这是你的道具，敲门砖。
PLAN包括产品的进度，预算等。
评审的结果，就是一个会议纪要，或者一个《XXX项目评审报告》。
评审后，要通过邮件、OA或者其他公司使用的方式，把评审的结果、TODO、更新后的时间表，同步给所有的内外部干系人。
6.避免被“烤”问的一些技巧
评审会上，谁汇报，肯定谁就被炙烤了。
这里有一个重要的技巧，就是要自由恋爱再步入婚礼的殿堂，千万不要搞大姑娘上轿，洞房时才见头一回。那就真得拼颜值和你娘家的实力了。
也就是说：整个设计过程，要多和客户沟通，多和各种角色的人等沟通，让你的设计包含了大部分专家组成员的意见。一是保证质量，二是保证顺利通过。你要把人给尊重一下。
7.搞几次评审比较好
这个主要看团队的大小，项目的复杂度。
个人经验，一般至少在3个环节要做评审，也不是天天开会就是沟通。
这三个必要的环节：一是评审产品设计PRD，二是评审技术接口和数据库设计，三是上线验收。
分别有评审的目标、物料、原则和结论，后续会专门说说这3次评审，在实践中摸索出来的，比较合理的组织方式。
（未完待续，下一次讨论交互和视觉设计的要点）