真正伟大的人还会继续向前，直至找到问题的关键和深层次原因，然后再拿出一个优雅的、堪称完美的有效方案。
————史蒂夫· 乔布斯
之所以将乔神的话作为引言，是想告诉大家，产品经理真的没那么好做，除了需要拥有专业技能、产品设计能力、产品管理能力、团队管理能力和自我管理能力外，支撑这些能力的前提是认知层面的深度和广度，你还需要掌握行业动向、国家政策、产业链发展、心理学、社会学、行为学、用户体验、技术、运营、市场营销、美学等方面的知识，并有一定建树。
所以，目前涌现出来的产品经理大部分充当的角色是项目经理、画图经理或功能经理等，并且连最基本的专业技能都不是很完善。行业发展之快导致背后问题滋生，越是在这种浮躁的环境下生存，最基础的最专业的能力越会被人们忽视，比如说需求分析文档的撰写能力以及它背后的思想。下面，我将根据自己工作经验，和大家分析下如何写出一篇优雅、堪称完美、众人满意的需求分析文档。
一、开始写需求分析文档前，你需要做足准备
大部分人会问，需求分析文档到底该在什么时候写。我的答案是：当你有一个产品的想法时，最初的需求分析文档也就有了雏形，此时的文档，我们暂且叫它产品前期分析文档。
当然，这个文档是你的过程性文件，没有格式和形式的要求，你可以用Axure、word，甚至excel来进行梳理。这是你在战略层、范围层和结构层的分析思路呈现，里面可能有文字、表格、规划图、信息架构图、产品结构图、业务流程图、用户路径图等等。
做这些，你可能用到的工具有word、excel、MindManager、visio、Axure、纸、笔等。记住，工具永远是你的辅助，重要的是最大化利用它传达你背后的思想。
1、Word文档
我一般用它来串起我对产品的整体规划思路，是必备也是核心工具之一，后期的诸多文档都由此生成，尤其是PRD文档。以下是某个产品的初步思路word文档
以上的分类还只停留在很初期的分析阶段，最后形成的需求分析文档和这个目录差别会很大。
而上述word文档里面的内容可能是如下示例的样子
从文字内容中可以看出，是分析的很初级阶段，还是一些零散的信息元素堆积，还存在很多的不确定性。
2、Excel表格
我一般会用excel表格梳理内容信息，这是一件很繁琐的事情，这个过程你可能还需要借助思维导图等分析工具。
以下只是截取了excel表中的一小部分内容，这是分析的过程文件，所以我会用一些标记来标明，协助我做分析。
3、思维导图
这里不得不提思维导图，产品经理必备神器，我一般用他来梳理产品结构、信息架构或用户路径。
4、Visio
Visio的功能其实已经很强大，能完成好多工作，我一般会用它绘制流程图，当然Axure绘制流程图也是很不错的，取决于个人习惯吧。
下图是用Visio绘制出来的跨职能流程图
下图是用Axure绘制出来的业务流程图
5、Axure
大部分人用Axure还是在原型绘制阶段，但其实它的方便性和功能强大性，足以支撑你将整个产品的生命周期产物都搬到这里来完成。当然，我在这个阶段对于Axure的使用一般都是绘制产品的分析规划图。如下：
上面这个规划图看起来清晰规整一点，是因为后期准备放到PPT方案里。
下面这幅图的内容讲的是借助互联网社群的思维解读教育类产品的社群思维。
当然，在此阶段，你应该已经用Axure形成了产品的一些低保真原型图。
6、纸、笔
纸、笔是在你设计分析和头脑风暴时不可或缺的元素，简单粗暴够直接，最大化挖掘大家的思想。
在上面的分析过程中，工具、格式、形式、美观等都不是关键因素，最关键的还是你的思想深度、广度和高度。
二、我是如何撰写需求分析文档的
上述分析过程的产物是零散的，不成体系的，无法形成最终产物。你需要将他们整合，输出满足技术人员和其他相关人员心里预期，并能清晰明了诠释你分析成果的产物—需求分析文档。
再次强调一遍，文档形式不重要，重要的是你传达的思想。下面，我将具体描述下在完成前面整个分析过程后，我是如何撰写产品需求分析文档的。我的文档是word形式，技术人员会结合原型图一起来开发。
1、第一步当然是打开你自己的需求分析文档模板，这是结合众多模板和范文以及自己撰写多个产品需求文档的经验基础上总结的。
无外乎包含以下一些内容
一、简介
文档目的
范围
参考资料
术语定义
二、产品目标
用户角色描述
产品目标（产品结构图、产品规划图等）
总体流程（产品结构图、用例图、流程图、状态图等）
功能摘要（简要功能规格说明表）
约束和假定
三、功能介绍
四、其他需求
数据需求
软硬件需求
环境需求
网络
兼容性需求
安全性需求
性能需求
监控需求
用户操作界面需求（用户体验）
……
2、简介和产品目标部分基本上就是把上文介绍的一系列分析过程产物整合到相应目录下，考验的是你的结构化思维。在我的文章《如何速度写出一篇有深度、高度和广度的文章》有介绍这种思维方式。
3、功能介绍部分的写法，要类似结构树的思想，从外向内写，先写外层即1级部分，再写内层即2级部分，以此类推。
4、写的过程你可能会联想到关于其他模块目录下的一些关键信息，将他们在文首空白处记下，便于写到后面快速复制使用。
5、关于文档中的关键部分—功能介绍，需要写的内容大致分为三项：页面路径、用户和内容。
前两项主要是让研发人员有全局观认识，避免直接陷入到具体实现的内容中而导致可能遗漏关键性信息。
1）页面路径：页面名称、页面简介、页面用户、页面来源、页面去向。页面来源和去向一般会用页面路径图来完成，如下
2）用户： 主要描述不同用户身份下，该功能页面的不同逻辑呈现说明，示例如下
3）内容：
内容的描述遵循的原则就是分块。如下：
内容分块后，UX（UI）人员和技术人员会很清晰的看出来该页面的内容是怎样组织起来的。此外，同一页面，不同用户的权限不一，我一般都用明显的红色文字标识；涉及到跳转页面，我会将跳转页用明显的蓝色标识，技术人员通过页面路径图和蓝色文字标识可以很清晰的了解到该页面的入口和出口。
6、此部分很主要：先设计出某一个角色的一系列页面，然后撰写这个角色这些页面的需求描述，再对着刚才的角色页面写另外一个角色的需求描述。前提这两个角色对于这个页面的可复用性很大。这部分就考验了产品经理对整个产品结构和流程的把控能力，也就是本文第一部分的分析能力，做出最合适、最符合用户心里预期的产品路径和最合理的产品结构层规划。
再次想说明一下：
以上的分析仁者见仁，智者见智。做产品以来，也见过很多他人的文档，各有优缺点，真正考验产品经理的，是总结出适合自己做产品的一套方法论。
三、总结
产品经理，不是什么都能用情商来解决的，技术不愿意看你的文档，一定有他的道理和你的问题，你不会表达，说不清楚，写不明白，就要承认，不会讲故事的产品经理从来都不是好产品经理。
最后请记住，产品经理的文档绝对不是从头至尾一气呵成写下来的，这背后借助了众多的工具、方法和思想，然后经过产品经理的整合（讲故事能力）完成的大作。
作者：@夏若，喜欢文字，喜欢冥想，喜欢设计，天马行空，总结癖，整理控，产品汪。
