本文是前一篇推文的延续靠什么来衡量业务的上下限，其实还特别想取一点怂人逗比的标题《那些经常开会被怼的产品狗子们麻烦进来一下》，不过我向来对这种事比较懒，各位读者认准饭大官人就完事了。废话少说，不罗嗦，看干货。
01
接上文。
前面两个阶段，可以看出团队产品岗的专业水平。
而第三个阶段，需求文档拆解会，则是可以初步看出整个项目团队的协作水平。
前文说了，需求文档是产品岗、设计岗、开发岗、测试岗在后续开发过程中的整体协作指南。
需求文档写得好不好，产品部门的专业天花板，会在此处所展示出来。
【拆解会】需求文档拆解会
此阶段是需求在落实前的必备阶段，在一个会议室里面，产品、设计、开发、测试多方协作，共同拆解需求文档，查漏补缺，明确怎么完成的一个过程。
此过程其实对产品岗的压力极大，写的东西，会在这个场景被每个岗位的人所审视。你的每个文字、逻辑、表述，都会在大家面前展示。
需求文档拆解会如果开得好，那么项目大概率顺利执行。
如果开不好，那么就是一个，各部门各种花式吊打产品岗的大型灾难现场。
3.1 拆解会次数
拆解会的次数，是团队协作的重要衡量指标。
顺利状态，一次拆解会即可明确项目需求，各个部门拿到需求文档直接开工。
常见状态，会议上被指出几处问题，要求补充完善，二次提交文档，不需拆解会即可开工。
困难状态，会议上被各个协作方挑出问题，要求重构文档，并明确要求启动二次拆解会评审。
杯具状态，在会议上被告知该需求此种方案不可实现，文档质量低下，无法开工，被开发直接退回。
一般需求被开发退回，二次拆解会还被各个部门DISS，接下来大概率就是开发部门直接投诉到产品的上司那里（这个人怎么招进来的）。
这种情况就是杯具中的杯具。
我的职业生涯最多见过三次拆解会，如果三次还因为文档质量过不去，产品可以下岗了。
3.2 拆解会消耗时长
需求复杂自然讲得时间长，需求简单自然讲得时间短。
但是在同一个需求难度的恒定下，表达能力较好的同学，主持拆解会非常顺利。面对问题，解释起来流畅自然。不会讲的人，往往就会把会议时间拉的非常长。
值得一提的是，拉住别人的注意力，也是一个加分项。
人的注意是有限的，一旦会议持续时间过长，在会议上一部分人讨论问题，一部分人玩手机的情况就会出现，轮到他提问的时候，这个逻辑明明前面都已经解释过了，你又得重新解释一遍。
耗时越长，说明文档差（被提问多）或表达能力弱。拆解会消耗时长可成为一个客观统计指标。
3.3 开发人员在会议上的提问数
此处的开发人员，包含除去文档撰写者的其他任何协作人员，他们是测试、UI、UE、前后端等，甚至是运营，项目管理和需求方，提问数量越多，说明需求文档质量越差。此处直接呼应前面一个阶段【写文档】的诸多考量：
- 2.2 逻辑丢失
- 2.3 逻辑错误
- 2.4 缺乏全局设计
- 2.5 表述不精准，造成歧义
- 2.6 需求设计方向错误
其他团队的面对这个需求文档的疑问，往往都在这个环节被提出。
当然提问数量多，也不单单是前面的原因，可能是因为有些人走神，后续做的提问，亦或者是讲解顺序导致的提问。
必要强调说明的是，好的文档能让看的人秒懂。
好的讲解顺序，也能让听的人秒懂。
尽管你写得非常清楚，但别人不懂，不能怪别人。
提问人的背景知识不同，对词语，状态的理解不同。
每个人立场不同，关心的问题不同，自然就会根据自己的立场提问。
所以优质的文档拆解会，文档是有组织有结构的，表达是有逻辑有顺序的，若提前知晓对方的疑虑，句句讲到别人关心的问题点上，提问数就会变少。
参与拆解会的人员可能包含：老板、项目经理、项目相关方、前后端、UE、UI、测试……
想要问题少，必须照顾好每个人的理解层次，事先做好预判。
这一点非常！非常！非常难！
在这个场景，其他人的提问数，同样也是一个客观的统计指标。
- 3.4 文档逻辑丢失数
- 3.5 文档逻辑错误数
- 3.6 表述不精准，歧义数
这三个标准在前面已经出现过了，问题先由【写文档】的部门主管审核筛掉，然后转到【拆解会】场合二次筛掉。
这三个标准问题暴露的越多，越丢人。
写文档的人，部门内部核对时，在自己部门主管面前丢人。
而在需求文档拆解会这个场合，那么就是在大家面前丢人。
同时审核这个文档的人（往往是产品主管）也在拆解会上跟着一起丢人。
其中3.1，3.2，3.3是可以进行统计的客观事实。
余下的统计则是在复盘会上，由第三方进行统计，做判断的。
在这个场景下，我一般组织的配置是
角色A：专门讲文档需求的（往往是文档撰写人，负责会议主持正常推进）。
角色B：审核文档协助答疑的（往往临场能力比较好，能够帮助讲文档的人）。
角色C：统计外加判断3.4，3.5，3.6问题数量的人，毕竟这里有些是有争议的。
此为第三阶段的，判断产品岗，组织业务协作，拆解会能力强弱的几个标准。
02
有了评价指标，就完了？
灵魂三问。
1、既然是复盘，也建立了指标，如何追求一个比较好看的指标呢？
2、或者换另外一个问法，如何减少自己在公开场合丢人，减少自己的主管或者是自己的小弟在公开场合一起跟着丢人呢？
3、再严重点，如何保证自己的部门口碑，在争取公共开发资源的时候，赢得更多的认可，继而推进项目稳定前进呢？
写需求是自我梳理，以书面形式呈现。
而拆解会则是一个公开表达，比较考验临场沟通能力。
毕竟把需求装进别人的脑袋里面，同步认知，是一件非常不容易的事情。
在这个【拆解会】阶段，追求好看的指标，则需要产品岗的大基本功。
技术理解能力和沟通表达能力
一个个说。
1、技术理解能力
市面上关于产品经理思维理念的语录中，有一句话一直误人子弟：
“不要去关心怎么实现，这是技术的事。”
具备技术思维，才能够写出质量好的文档，不至于造成大的逻辑丢失/错误，思考各种异常情况，才能够在拆解会上从容应对，才能够听得懂对方的语言。
必要说明的是，技术思维和技术实现，根本是2种不同的能力，此处就不做解释了。
推荐我看过的几本书。
《产品经理必懂的技术那点事儿》
《给产品经理讲技术》
《码农翻身》
《漫画算法：小灰的算法之旅》
这些书里面，都是非常优秀的技术思维呈现。看书真不用贪多，认真看两本就绝对够用。
我自己并非是技术出身，但是在过往组织团队协作，项目推进的过程中，从来未曾遭遇过技术的为难，相反一直以来，因为文档质量，非常受技术同学的欢迎。
同样，在我的职业生涯中，有过至少3个，计算机专业毕业，先写了几年代码后转岗产品经理，文档拆解会和日常协作推进中，被其他人怼得不行，直接劝退的例子。
2、沟通表达能力
说实话，这个事情要一点天赋，但是是可以通过后天的学习和训练提升的。
还记得我前面组织拆解会上的配置的3个角色么？
角色A：一个专门讲文档需求的（往往是文档撰写人，负责会议主持正常推进）。
角色B：一个审核文档协助答疑的（往往临场能力比较好，能够补充答疑的人）。
角色C：一个专门统计外加判断3.4/3.5/3.6问题数量的人，毕竟这些里面有些是有争议的。
我的徒弟，往往就是角色A，我自己扮演，角色B和角色C。一般文档拆解会之后，我都在会后进行复盘，告诉他：
- 为什么谁谁谁在这个地方向你提问，是因为如何如何……
- 你刚刚讲这个地方的时候，大家都皱着眉头，我用了另外一种翻译和比喻，他们就懂了
- 某某在意的问题是什么，而某某在意的问题是什么，所以下次你要提前做好准备。
徒弟们哪些东西做得不好，现场针对小弟的错误动作，分析，并做一个现场规范和纠正，印象更牢靠，成长更快。
我部门里面也有人通过复盘，学习其他高手的文档拆解会的录像获得提升。
我也经常鼓励、或者拿钱诱导，甚至强迫团队的人去做一些PPT，在公开场合完成分享会，锻炼他们的临场表达和应变能力。
关于如何提升沟通，我自己写的书《游戏运营：高手进阶之路》章节六里面已经讲得非常透彻了。
此处补充一个书里面没写过的小方法：
我比较喜欢玩桌游，发现桌游吧的老板们讲规则，就特别厉害，能够让人秒懂规则，并很快上手。
而当我买桌游回来的时候，跟大家去讲，发现
（1）不同的人，理解同样规则快慢不一。
（2）同样的人，理解不同规则快慢不一。
面对同一套游戏规则，有的人花5分钟让人弄明白，有些人则需要花掉30分钟，这中间的差距，跟需求文档拆解会的耗时是一样的。
跟理解能力强的人讲明白，不算本事，跟理解能力弱的人讲明白，才是本事！
桌游吧老板的表现触发了我的思考，作为一个喜欢跟自己的专业度较劲的人，一定要达到，乃至超越桌游吧老板的讲解水准。
于是我经常组织一些大家没玩过的桌游。这种面对面讲解的临场感，跟拆解会差不多。
比如《三国杀》《只言片语》《行动代号》《宝石商人》《现金流游戏》等等等等。
有没有人计算，跟没玩过的人，讲解规则需要花多久时间？
饭大呢，在这件事情上更较劲，先跟自己的同龄人讲。然后过年回家的时候，跟自己长辈讲。
我们的长辈，真的是非常好的练习对象，他们满足如下条件：
- 大多数人理解（新东西）能力弱。
- 主观意愿上，不愿意学新东西。
- 注意力容易分散。
用苛刻的标准去对待自己，练习成功，此能力方可算过关。
挑战过“跟长辈讲解桌游规则”这种地狱难度模式后，回头再去面对，需求文档拆解会的那些同学，你会发现，啊，这些人真的是好可爱啊，简直就是简单模式。
面对同一套游戏规则，我至少有2种套路去讲述。这种事组织得多了，就慢慢的锻炼出自己的表达能力了。迅速让不同文化背景，理解能力不同的人秒懂。
顺带一提，这件事带来的另外的好处是，经常跨部门团建的时候，无非就是吃饭和KTV，而很多程序员，测试，甚至是设计师同学们比较羞涩，全程不拿麦克风，甚至是直接坐在KTV打代码，那我就组织玩桌游，照顾了他们无聊的感受，于是一来二往，自己也越来越受他们欢迎。
03
如何追求极限数据表现？
例如：1次拆解会，20分钟内就把需求讲明白，拆解会上，几乎没人提问，然后大家都非常清楚的去完成开发推进。
如果各位同学能够达到上述的境界，那么拆解会这一块的专项能力，你就过关了。
方式讲起来其实挺简单，文档正式提交，发起评审会之前，把自己的东西，给“帮助你去实现这个需求的相关人员（前后端，UI/UE，测试）们”看一下，如果有问题，直接在对方工位上拿反馈，然后马上在文档上查缺补漏，干嘛要留到拆解会上，给人以公开DISS的机会呢。
所以届时自然就出现了比较好的数据表现。
拆解会次数，1次（纯属走个过场）
拆解会时长，20分钟（其实就是讲下需求背景，彼此认识下协作的人，对个进度）
开发人员在会议上的提问数，0次（在对方的工位上，此前的交流中已经完成答疑了）
文档逻辑丢失数，错误数，表述歧义，趋近于0（提前沟通，完善文档，会上便不会提）
上述的情况我成功做到了很多次。
至今印象比较深刻，且回想起让我感觉满意且无比暗爽的一段经历。
会议前，我拉着一个开发去开拆解会。
“woc饭大你这个需求文档这么清楚了，还要拆？直接开工吧”
“不行不行，走个过场，过场”
“我不想去行不行，有这个时间，我直接代码都给你写完了”
“不行不行，要去要去，项管那里过不去”
会议中，测试提问，我的那个急性子开发同事抢答
“这个需求这个地方是这样的，你在测试的时候，注意这里，还有这里”
“后面呢，我会出一个动态配置的接口，方便其他业务模块调用”
“前端同学，这里注意一下，轮询状态的请求频率……”
我在一边默默看程序员帮我拆解需求文档……回答他人提问。
回头完事散会，他反应过来，看着我说
“我擦勒，这个文档我帮你拆的”
我当时抱着后脑勺，仰卧在椅子上，默默在一边，安静得像个美男子。
“你还笑，下次你什么时候再组织桌游，就上次玩得那个”
安静的美男子，缓缓开口道：
“行，你今天晚上完成提测行为，我晚上就组织，哈哈哈”
“靠，我要不是陪你搞什么拆解会，这会我都写完开始自测了”
能做到这一点的前提是：
1、文档的撰写时间较长，经过反复修订，有足够的信心保障，才发起的需求拆解会。
2、我跟整个项目开发团队（UI、UE、前后端、测试）的关系足够好，对方愿意在拆解会之前拿出自己的时间帮助我。而换成一般人，直接一挥手，我现在很忙，拆解会上说吧。
如果那个产品不受欢迎，文档拆解会上，就会被怼得七零八落。
然后，甩出我的文档，“麻烦需求文档写清楚点，拿出这种颗粒度来。”
所以还是那句鸡汤届的名言。
看似毫不费力的背后，其实隐藏着拼命的努力！
只有达到这种境界，拆解会这个模块的专业表现才算是过关。
04
写到这里，顺带提提那些不争气的产品同学们。
我在面试产品经理的时候，经常性会问一个问题：
“因为各种不可控的原因，频繁改需求，这件事责任不在你，但是下达改需求的行为人是你，而这种事情会引发开发团队的不满，你如何处理好自己与开发团队之间的关系？”
（有兴趣的各位读者，可以在文末做一些留言回复）
在一些人的回复之中，极少能够让我回答满意的。
回答虽未婉转，但是这些回答背后无非就是一些丢人的价值观。
日常工作大哥大姐；
经常给对方买奶茶；
陪对方在阳台抽烟；
有事没事请客买单；
甚至强调女生做产品经理更有优势的……
这些观点，真的是把做产品经理们的脸，丢尽了！
越是这样做，开发团队会越看不起你，这样做久了，自己都看不起自己。
而很多产品同学呢，自己也是不争气。
这种关系的相处，完全就是互相消耗。
提升自己的专业度，做出价值来，靠实力赢得大家的认可，才是赢得尊重的正道！
05
篇章小结。
前面2个阶段，重点谈的是产品团队的表现。
而第3个阶段，是团队之间的首次协作表现。
其中有些问题，要么在第2阶段产品内部评审的时候曝出。
能够在第3阶段拆解会上曝出的问题，可以看出很多东西。
有经验，有嗅觉的项目管理者，参与两次拆解会，能够迅速识别出这个团队里面的各个人的专业段位，人际关系，乃至项目文化。
值得提及的是，在保证基本质量的前提下，如果在【写文档】的2.4 全局设计做得足够好，那么就会赢得开发团队的巨大信任。
拆解会如果顺利，项目团队会有信心，后续项目开展也会更顺利。
拆解会如果不顺利，项目进度将会拖延，还会引发团队内部矛盾。
没有人喜欢照着不明确的建筑图纸施工，没有人愿意跟笨蛋配合，一旦跟笨蛋配合，后续就是无尽的返工和加班。
这个阶段走完，就进入了正式的开工阶段了。
后续的3个阶段会以系列文章陆续发表，后续将会一样用清单的方式去检视，整个业务团队的整体成色。
