很多产品新人，入门产品时，最想先了解的都是如何画原型，如何写需求文档，这很奇怪。就像在平台上可以搜到很多关于需求文档的文章（截至当前，通过搜索关键词“需求文档”，有610条搜索结果），告诉大家需求文档要怎么写，却很少有说为什么这样写的？
大家把关注点都在放在如何实现，如何呈现，却没有关注为什么这么写？像很多大咖常说的术与道，术重要，道更重要，知其然更要知其所以然。
碰到任何问题，最长见的思维方式即为：问题三要素——是什么、为什么、怎么做。这是几乎所有行业、所有人群面对事情时，最常见的思维方式。
笔者认为基于最经典、高效、实用的思维方式的基础上，可以每个人针对不同的知识体系、思考方式、经验总结等维度，总结出自己的思维方式。
笔者常使用的方式为多年前从社会经济学老师那里学来的，做了补充和优化，分享给大家：
在特定的时间、特定的地点、特定的人群因为特定的原因而做了特定的事件。达成该特定事件前，有哪些预期，实际达成的效果是什么样的，中间有怎么的落差，以后处理该类事件时，如何优化方式。
按照上述思维方式，我们将要写的需求文档当做一个特定的事件，通过剖析该特定事件被触发的前置条件、后置补充内容，来实现对需求文档的分析。
二、什么是需求文档？笔者将需求文档定义为：用于阐述产品，满足协同人员开发的内容文档。该定义中有两个重要点：
1. 阐述
即为说明要开发的产品是什么。此处的“是什么”区别于产品说明文档，产品说明文档类似于商品说明书，用于告知使用者我的产品该怎么使用。
而此处的“是什么”是告知该产品的相关人员，该产品有哪些功能，这个功能要怎么呈现，该怎么实现。具体包含以下几个方面：
（1）为什么要做这个产品？
该产品是来自哪里的需求，是内部版本迭代优化、Bug修复、新增功能点，还是来自业务部门的需求，或者来自用户的反馈需求。
必须交代清楚做该产品的项目背景，一方面有利于开发人员更好的了解整体项目，从而更顺利地制定项目计划、项目进度、项目达成；
另一方面，产品开发完成后存档的文档，有助于后续对该产品的复盘、版本迭代，Bug问题溯源，甚至对出现人员异动时，有助于接盘人员快速了解项目，熟悉产品整体的前因后果。
（2）该产品要解决哪些冲突？
需求来自于用户的冲突，用户在使用中遇到了什么困难、疑惑、焦虑等不可调和的问题等待被解决。
在与用户开展调研、访谈等沟通时，充分了解用户的冲突，及急需解决的痛点，有助于产品经理在产品规划阶段，更精准地把握好方向，做出更符合用户诉求的产品。
同时，在了解冲突的沟通中，除了精准获取到用户的核心诉求，还会得到很多非核心诉求，这些来自于用户潜意识中的需求，为以后产品的发展提供了很好的帮助。
将这些需求罗列出来，整理到需求池，有助于以后与用户、业务进行再次沟通时作对比，从而去伪存真，对需求池中的需求做好优先级排序，并根据实际业务发展阶段和公司整体要求，划分好产品阶段，对需求池中的需求进行实现，从而促使产品朝向更好的方向发展。
（3）该产品实现了哪些目的？
任何产品的实现，不仅仅要满足用户的需求，更要在解决冲突时达成更多的目的。而这个目的分为物质层面和精神层面两个维度。
1）物质层面
产品的上线，解决了公司业务层面的流程，满足了业务需要，满足了用户的使用，这是产品首要，且是最核心的目的。
而在满足最核心目的之后，是否有一些延伸的产品需求——减少了操作步骤、优化了交互流程，为实现公司层面的获客、激活、留存、转化、二次推广等各环节起到促进作用。
2）精神层面
产品的上线，解决了用户的困难、疑惑和焦虑，解决了业务部门无法正常使用过程中的烦躁不安，这是产品最核心的目的在用户心里的反馈。
同时，在解决用户优先级最高的负面情绪的前提下，使得用户对产品的感官，对企业品牌的好感度提升，是产品上线所能达成的最好效果了。
2. 满足协同人员
即该需求文档是给哪些协同人员看的。此处的“协同人员”不仅仅是开发人员，而是产品从交付原型至最终上线，过程中所涉及的所有参与者。
这些协同人员基于各自岗位和职责，对需求文档的要求也是不一样的，这是所有产品经理在编写需求文档时应尤为注意的点。
