在我心里，写文档不只是创作一个作品，更多的是时候，是将我心里的想法，组织成文字，写下来，让我可以看得见，也让别人看得见。协作中，让对方看见文档，便有了更多的「共同语言」去讨论同一件事情。而这，在解决复杂问题的时候尤其有用。
这篇文章来自我在公司内部的一次分享，关于我自己是如何用「写文档」这个方法，去提高解决问题的效率。
作为一名产品经理，我们天生的嗅觉就是发现各种问题，并且解决它。你可能听说过产品经理要写各种需求文档，可以说需求文档本身就是用「写文档」提高效率的手段。但解决一个问题的过程往往从收集问题就开始了，我聚焦说明在一个问题从产生到最终落地解决方案的过程之间，我们还能做好哪些工作。而这些工作，我观察到，很多产品经理之前都是忽略的。文章聚焦于方法的共享，因此很多思路不仅仅是关于如何写，其实更多地是关于如何用更加有效率的方法去做事情。在一个问题从诞生到解决的过程中，我们此刻已经在用一些方式去完成每一个环节了，但每一个环节，其实都有潜在的效率损失。
我相信这里有几个大家常见的痛点：
1、收集到的问题不一定是真问题。这里的「真」包括两个意思：要么，这不是提问者想要解决的问题，被曲解了；要么，这个问题没什么意义。
2、想要找一个人明确问题，但他们可能总是不在位置上
3、开会、开会、开完会也没有解决问题，会议效率太低了。
4、跟老板做阶段性汇报，却发现效果并不好，每次都不如预期。
5、解决方案总是变，工期一拖再拖。
三
所以，怎么办。或者说，在每一个解决问题的要命的点，我们还能怎么提高效率呢。
来，我们看看那几个痛点。
问题不是真问题怎么办？
那就在收集的时候，回到本质去梳理这个问题。
找一个人，TA总是没有在？
那就用异步沟通，准备好一切，让TA在方便的时候处理。不要让等待成为影响你解决这件事的效率瓶颈。
会议效率太低了？
那就先做好会议准备工作。
我在飞书组织进化论的听友群，看到过一篇文章，关于如何组织一场高效的会议，我的理解是，你在会议前的准备工作越完善，会议效率就会越高。（点击最下方的阅读原文可以看到这篇文章）
解决方案总是一变再变？
首先把为什么要变，当作一个问题处理，走一遍这个流程，然后真的要变了，就做好记录和同步吧。
千万不要一部分人以为变了，另一部分人以为没有变，这种扯皮对于组织的效率是极大的内耗。
汇报质量不高？
那就更要往下看，如何做好一场工作的阶段性同步了。
总的来说，提高效率的方法如下：
| | | |
| | | 通过结构化的表格，在问题的整理阶段就完成部分理解工作 |
| | | |
| | | |
| | | |
而我呢，一般会用「写文档」的方式，去将每一步的提高方法落地。
| | |
| 通过结构化的表格，在问题的整理阶段就完成部分理解工作 | |
| | |
| | |
| | |
四
先讲讲，问题汇总文档怎么写。
我会总结为如下几个步骤：
第二，这个问题的最小结构是怎么样的。所谓最小结构，就是讲清楚了这几个点，这个问题是不是一个真问题，就基本能判断出来了。第三，将最小结构变成收集问题的表格。为什么一定要用表格，这是为了让提出问题的人，也能按照表格规定的结构去将问题描述清楚。如果不做任何限制，相信我，大家对于问题的描述要么很简短，要么废话一堆，总之，后续的理解成本非常高。
对于绝大多数问题来说，基本都是这三个要素：
最后你会发现，收集的每个问题，不一定都是有最小结构的，比如why和how，在收集的时候没有答案，那表格里空缺的，就是待讨论的问题。但价值在于，我们知道了对于这个问题来说，还需要讨论的地方是什么，很精准。
那问题汇总的文档该怎么写？我以自己的实践来做个说明。
但为了篇幅考虑，后续的其他文档我都只说方法，实操经验如果你有兴趣，可以添加我的微信跟我交流。
1、说明
我强烈建议为解决问题而产生的文档最好有说明，让看这个文档的人，在最短时间内知道这个文档的作用是什么。
2、找谁收集
退款3.0版本的需求，一方面来自产研在2.0版本中遗留下来的问题，尤其是测试过程中发现的缺陷，我们放在3.0版本解决。一方面来自客服在实践中提出的新需求。
3、已收集问题
注意，如果某个模块你需要用很大的一段篇幅去写，那我建议单独成一篇文档，再去引用就好。上图中，第一个问题其实我已经调研好了解决方案，所以我就用一篇文档单独描述并引用了。
4、不确定信息
第2个需求，是什么和为什么，目前产研侧不太理解，需要组会讨论，在需求消化阶段解决。
问题说明是认领这件事的负责人，对收集来的问题做的二次加工，目的是为下一步的开会讨论做准备。如果想要对已收集问题中信息缺失的部分做补充。有两种方式：2、专门开一次会做讨论，也可以跟之后的推动问题的会议一起讨论。问题说明文档的判定标准，是针对每个问题，最后都有一个完整的，且能够直接拿来讨论的结构，而不需要对问题本身再做重定义。
七
如何用「写文档」去准备一场会议？
不知道会议目标是什么，不知道我去了该干嘛，不知道自己应该说些什么，不知道开完之后要做些什么。那如果你是会议的组织者，你该如何用「写文档」的方式，给会议提效呢？
目标是这个项目的大目标，期望输出是这次会议应该有的作用。比如我们的目标，可能是实现大促100万收入，但这次会议的期望输出，是整理出3个能落地的方案供下一次讨论。如果讨论的是新问题，那就要说明一些背景知识，确保大家都知道；如果要讨论的是老问题，最好写一下现阶段的情况，以及之前讨论的核心结论。什么是新问题，什么是老问题，是会议组织者要去评估的。怎么评估？看参加的人，你得去想对这些人来说，即将要讨论的是新问题还是老问题。
所以，了解每个人对于这件事的了解程度，是非常重要的。切忌完全以自我为中心去组织一场会议，不要把参与者当成纯粹的工具人。
发散类型的问题，最好设计一个框架表格，做结构化的限制。参考问题收集文档。
想清楚谁要来参加，不要一下子邀请整个部门或者整个群。
明白谁需要提前看文档，不管别人看不看，你都要先准备好。尽量不要依赖别人，去养成你自己的好习惯。最后的最后，千万不要忘记了，提前沟通好，谁来做会议纪要。
关于会议纪要的写法，其实飞书文档里已经给了非常清楚的结构，所以我在这里只是做一下简单的说明。
但有一点是很重要的，一定要先确认好，谁来记。哪怕不是按照模版来，哪怕你之后自己去整理，也总比没人记下任何内容要好。
一定要实际参加的，而不是call到的人，没有来就是没有来。参会代表了你对会议中发生了什么是了解的，如果没有异议，那对会议纪要中的共识就是认可的。更重要的，准确记录下参会人，对于他们来说是一种尊重和督促。那些没有来的人，有什么资格共享会议的成果呢。
我一般会在议程部分加上会议准备文档，说明为这个会议提前准备的内容是什么。当然除这个之外，常规的议程该怎么写就怎么写。结论就是共识。包括两种：确认的和不确定的。注意，「我们在这件事上有分歧」以及「什么事情不确定，下来要确认下」这两个结论本身也是共识，这是之后要去解决的。很多人都会有意识去写todo，但很多人也会发现，todo写了，后面到底怎么样了，不知道。我对todo的建议是：1）最好是一周内要去做的事情，太久了就不好追踪了；2）有明确的责任人和时间，这就是一项任务，大家严肃一些，也是对会议本身和各自时间的尊重。关于会议纪要，我最大的体会是：如果你不记，往往就会出问题。在这方面，墨菲定律是很准的（墨菲定律：你担心的事情往往更容易发生）
九
会开完了，事情也有了进展，那么如何把阶段性汇报做得更好呢？
根据汇报对象组织你的汇报内容，我们公司CEO的这个建议应该更清楚。在这里我对于如何组织why what how这三部分的内容谈谈自己的理解：1）不理解why：那就通过数据、行业、用户反馈、以及向上进一步沟通解决。在文档里把你可以想到的，可以查到的所有资料，组织起来，最后用一两句在开头写出来，到底是什么问题在困扰你。2）不知道该做什么：重点是把你认为可以解决问题的what，都列举出来，有没有想清楚都可以，但一定要写在文档里。（落地1个方案，需要先想10个方案）3）不知道该如何落地：实操，不断地实操和总结。但这个问题对产品经理来说一般不是问题。那是不是，根据不同的对象，只需要准备对应的部分就可以了呢？并不是，你还是要把这三个问题都想一遍，都写一遍，只是你可以挑重点说而已。
结尾
你可能会觉得，这么麻烦呀，我能写好么？
我一直认为这是个意识和习惯的问题：
你得首先认可这件事的价值。如果你意识不到低效率的工作方式对你的损耗，可能你就看不见高效率工作带来的甜头。更多关于职场进阶的思考，欢迎扫码了解大力哥的知识星球
