困在家里，每天起床 - 开早会 - 开项目会议 - 刷牙洗脸 - 看文档邮件 - 开项目会议 - 循环往复直至睡觉，不胖都难...
每天干的最多的就是沟通、看文档，最经常遇到的也是在沟通过程中对文档的各种“Diss”。今天抽点时间，总结下写文档的思路，希望对大家有点启发。
在写文档之前
大家很容易在网上看见各种眼花缭乱，格式规整，精美无比的文档，显得很专业。不可否认，这种文档但凡谁第一眼看见，都会觉得很专业。但是，文档的矛盾往往是在细节review和沟通中才会爆发的。
所以，文档主要是搞定看的人。
给研发看的文档
从日常沟通频率来看，产品和研发之间关于文档的矛盾最多，先来盘它。
一. 先讲故事
我是从研发转做产品的，搞研发的，多半逻辑思维比较强，喜欢剖析事物的本质（这个事情本质上...）、引经据典（我见过的产品没这么做的...）、列举可能性（当xx情况下，万一...）等等等。
产品经理如果直接搭话，后果就是在逻辑的灵魂拷问中败下阵来。
那么面对这种情况，我总结的原因有几种：
- 直接写产品功能。这种就是变相的告诉研发，别BB，按我说的做。
- 文档描述的文字不严谨，前后概念定义不相同，需求范围边界不清晰，约束条件不讲明。任何一个细节的点被抓住，整个文档的严肃性就没了，开始迎接各种挑战。
- 过多用技术化的语言来写文档，以为研发能看懂。这种仅适用于技术功底较深的产品经理，否则进入对方的绝对领域就是找虐。
写给研发看的文档，最重要是说明为什么要做和做什么。多讲讲故事。
在任何大小沟通之前，先准备好一两个典型故事，最好出自典型客户需求或者经典案例，开门见山的和研发聊一下我们的实际需求和业内情况。一个好的产品经理，自己就是个故事大王，应该储备大量的案例、行业见解和解决方案。这些故事不会引起别人反感的原因在于：故事都是第三方的，不是自己的；而沟通中最怕上来就讲自己的观点，“我”和“你”是对立面，“他”不是。
二. 再说策略
明确了需求和要解决的问题，不要一上来就直接给出解决方案。原因很简单：
- 你给的方案技术不可行。研发直接给你打上一个“外行指导内行”的标签。
- 你给的方案在目前市场或者产品中没有竞争力。这个最可怕，直接关系到大家对你能力的判断。
- 你给的方案太初级，是个人就能想到。敷衍了事，无解。
讲故事获得共情后，要进一步获取信任，把业界情况、自身目的和限制、初步决策的原则说清楚。
很多时候，排到计划里的解决方案往往是修改了若干次之后的结果，这和网上设计师的作品被甲方来回修改并没有太大区别。首先，我们要认识到，解决方案的修改是无法避免的，但是为了让方案尽可能落地，产品经理需要比任何人都思考的更多：
- 业界经验如何解决这个问题，有哪些不同的做法。
- 我们目前的条件如何，包括但不限于：时间、人力资源、已规划已执行的产品计划是什么样子的。
- 和研发、市场等同学沟通完之后初步的可行性分析。
- （非常重要）如果不做会有什么不能接受的后果。这一点是为了进一步搞清楚这个需求的核心问题是什么。
最后的最后，给出的不是方案，而是拟定方案的选择策略。没有这个策略为大前提，后面细节的讨论会经常漫无边际的展开，3个小时的会不是梦。
三. 做好细节
前面两点如果能很好的落实下去，影响文档质量的就是各种细节。这个问题没有捷径，就是花时间仔细做，反复推敲。我把经常会遇见的问题列举出来，引以为戒：
- 一个人写的文档，基本没有统一的格式，每次都是随性发挥。
- 产品概念随便定义：前后名称不统一，用非业界常规的命名，用冗长晦涩的文字去解释。
- 在正规文档里画一些自创的图例。
- 流程图或交互图不完整，用另外的文字去做“补充说明”。
- 细节规则没有，以为大家都知道。
- 文档不检查不推敲，留了一堆逻辑漏洞和错别字。
- 文档存储的位置飘忽不定，网盘、wiki、本地文件、三方应用到处都有它的身影。
如果上述问题你都没中招，那么你写的文档应该堪称典范；但如果想都做好，你唯一无法缺失的就是时间。
文档需要时间，不要压缩时间来提前交付文档，这样后续扯皮的时间会更多。
四. 定稿前多沟通
在产品经理编写的各种文档里，基本上都需要其他角色的意见作为输入，如果一个文档发布前都是出自自己的经验和理解，那会是什么天都不知道。
输出一份任何一份正式的文档，都可以划分为两个阶段：草稿阶段和打磨阶段。
- 草稿阶段的文档，形式不限媒介不限，以最快速度最有效的和相关人沟通讨论。没必要约正式的会议，避免大家过于扣细节。
- 打磨阶段的文档，需要你把之前草稿阶段的成果进一步揉碎了消化了满满撰写，反反复复推敲。
文档类型的选择和精力分配
从我个人经验以及产品经理圈子的实际情况来看，目前尚未发现能从头到尾输出完美文档的人，这是资源限制和能力限制的必然结果。
如何选择合适的文档，分配多少精力，主要看你的团队情况：
微型集中型团队
如果团队很小，一起办公，大家技能树比较均衡，那么文档最好的形式就是产品本身。每天输出一个版本的产品，最直接能反应出你的产品文档应有的结果。
中小型集中型团队
如果团队规模较大，有明确的职责分工，那么就要根据实际情况来选择：
- 如果团队缺少行业经验，那么把用户需求、竞品分析、成熟的领域模型编写的细致点。
- 如果缺少明确的需求来源或者复刻某个竞品，那么把功能需求和交互文档写的细致点。
- 如果团队磨合比较好，产品有固定的输出套路，那么把功能需求和数据模型定义好就可以开工了。
- ...
这也是为什么并没有什么统一的的文档规范的原因。企业为了生存下去，活法不一样，纠结形式本身首先就慢人一步了。当然，这和注重细节并不冲突。
产品经理的日常功课型文档
除了在产品研发过程中常用的用户需求文档、功能需求文档、交互文档、产品Roadmap及计划、产品验收文档等，还有一些文档需要输出，也可以视作对产品能力的锻炼。
- 产品运营（运行）情况：验证产品是否达到预期目标，PMF有没有问题，接下来的改进目标是什么。
- 产品市场及客户反馈：产品市场是否有变化，客户的反馈渠道建立及问题分析，产品和竞品的跟踪比较。
- 产品定义的重新思考：未来五年、十年，目前的产品会有什么样的趋势变化，有没有实验性质的功能需要尝试。
- 产品的包装：当把产品输出给客户、经销商、老板、亲人朋友时，它是什么样子。
——
说真的，写出无懈可击的文档产品经理缺的只是时间，你说呢？
祝疫情期间，大家每天都能多输出5份文档，god bless U.
