正如我们做出来的产品都希望受用户欢迎，开发和测试是需求文档的用户，产品经理也应该重视他们的想法和要求才能写得令人满意。

“写需求文档”说专业点是把用户（或运营、客服等）的需求转化成技术部门的话语，因此了解技术术语是产品经理的基本素质。要做到需求文档受欢迎，了解术语是不够的。虽然不可能写得像开发人员写设计文档的一样专业，但产品经理如果能运用技术人员的思维多做些考虑，就能减少评审过程的反复沟通，那必然能收到大量好评。

技术人员的思维同样是被工作环境和内容训练形成的，编程语言、架构设计、测试方法是最主要的因素。其中，开发人员会有这些思维：

组件与模块；流程与联系；条件与时机；类型与精度。

测试也会有独特的思维：

极端；因果；场景：一系列的组合条件。

另外，用户体验思维中的“层次分明、重点突出”，也非常有助于优化需求文档的视觉效果以提高阅读效率。

我们以每种思维作为章节来回答本文的问题。

开发思维：组件与模块

我们写文章都不是从头到尾就一段话的，会分段落、章节，这样能帮助做到条理清晰。代码的本质也是“文章”，组件和模块就像是段落和章节，他们会对应一个功能、界面或规则。

为此，需求本身也应有拆分：产品有结构、功能有细分、界面分区块等。

产品结构图就像文章的目录，在做新项目的时候应该附上。它不仅帮助产品经理自己梳理子需求，也让整个项目组都清晰知道产品的构成，对开发、测试、UI设计师后续的工作都有指导作用。现在多数人会用思维导图来画，原因就是它的最大作用是理顺思路。

功能细分可以用“评论”功能来举例，它可分为：

前置的登录注册等条件；界面上评论区的功能（比如：@他人，回复某楼层，引用回复，表情输入等）；提交前的限制条件校验（比如：字数、特殊字符）；提交评论的过程；评论的内容检验（比如：涉黄、敏感信息）；评论后的展示（比如：引用回复、互相@）；用户信息里的评论信息更新。

如何做需求拆解是没有固定模式的，跟业务有紧密关系，一般的两个思路是流程和规则。

下图是界面分区块的示例（示例的意思是在原型和文档上这样命名，这不是原型图）

分区块并进行命名的好处：

利于文档描述，减少说明字数，加速阅读。利于沟通。大家只要说一个名字，就知道是说哪个部分，不用对着界面说。如果整个产品每个区域的名字是唯一的，那么报bug的时候可能连操作路径和截图都不需要了。一般来说，开发写代码时也会用这些命名的（翻译成英语），他们会很感激产品经理帮他们想好了名字。

开发思维：流程与联系

需求是一个整体，拆分后的各部分必然仍有联系，他们的协作步骤即是流程。产品的交互设计在代码流程上是大致对应的，所以如果产品经理能把流程描述详尽的话，开发的工作差不多等于把这堆“中文”用编程语言翻译一遍而已。

如果流程足够复杂，就需要用图来表达。画图是描述复杂事物的基本技巧，不仅仅是需求文档的写作要求了，这里不展开讲。

那么怎么才算复杂呢？

一般简单的判断是：以最长的步骤路径为基准，如果超过30%的步骤有分支就应该画流程图。例如：如果有7个步骤，有3个步骤是“是非选择”或“循环指向”，那就该画；只有2个步骤有分支就不用画，用文字说明白。延伸地讲，如果分支太多，需求本身可能就有问题了，应该从交互设计上去简化它，不应该给用户这么多可选择的东西而造成困扰。

一个实际的文字描述步骤例子：

进入“我”页面；是否已登录，是则继续，否则进入“登录”流程；点击“评论”区，进入评论页；如果评论数为空，显示占位图，否则显示评论列表；点击评论列表中的一条，进入帖子详情页，并且页面自动滚动到那条评论的位置；用户点右上角的“关闭”，跳回第4步，否则按“帖子详情页”的流程继续。

在上面的例子里，我们也看到，流程之间会产生联系。一个流程中的某些步骤可以关联到另一个流程，这些流程之间的联系，在开发设计中会体现为“模块间的依赖或调用关系”。

作为产品经理无需理解前面双引号内词语的技术意义，但有一个很典型的场景能帮助大家认识它的作用：开发解决了一个bug后导致了别的bug。更经典的是，开发抱怨说这是因为产品的新需求没考虑到对原有功能的影响。

无论最终是否开发的责任，产品经理也应该去梳理各个需求之间的联系，包括界面、交互、功能的相互影响。最好是文档中有独立的章节列出需求间的关联，这不仅是帮助开发测试做好设计，也是为自己检查疏漏。

拿一个普遍的需求“登录”来举例，产品经理应该列一下所有“不登录就不能访问的页面”。以后改动登录功能的时候，自己也可以一下子看清所有的影响范围，这个习惯最能防止“状态多层次级联”（如：A影响B，B影响C）的情况下考虑不周。

开发思维：条件与时机

计算机是不会执行没描述过的操作的，即使是火热的人工智能，也是要经过训练才知道什么条件做什么操作。

所以开发需要在代码中精确描述：

流程的入口场景，即这种“可能性”的触发时机。流程内每个步骤的执行条件。

不同的条件会导致不同的结果，这对用户使用有重大影响，所以一定把所有的条件和可能性都列出来。一般来说，产品经理最大的疏漏是没考虑异常情况。

其实无论过程怎样，最终反映在界面上只有4种结果：

加载中；数据正常，正常显示；无数据，数据为空；出错，包括超时。

产品经理把这4种结果的界面都定义清楚，就能覆盖所有中间过程的情况。当然，最好还是能把中间过程的可能性都考虑周全，并针对不同的状况有更精细化的结果展示。

开发思维：类型与精度

这是编程语言（更确切来说是CPU计算原理）带来的思维，我们不去深究计算机知识，只需知道对我们的影响：要用数据来描述一个事物以便计算机能理解。

这些数据分两大类型：数字与文本。

其中数字还有这些考虑：

整数还是浮点数，即是否带有小数部分；浮点数保留多少位小数部分；是否可能是负数；最大绝对值是多少（数字越大，可能会需要更多内存和计算时间。做适当限制有利于提高性能）。

这个思维（或者说限制）会影响所有需要用户输入交互的地方，如果原型图上不能明显看出以上的信息，产品经理应该有意识地在文档中补充。

测试思维：极端

极端的情况下容易出bug，这是最基本的测试思路。如果界面上有一个输入框，以下几个测试用例肯定会有：

输入非常多的字符，看是否允许、是否合理显示；输入不应该允许的数值，比如超出最大最小值，看能否允许、能否继续下一步；输入不应该允许的文本类型，比如身份证号栏填入中文，看是否允许、能否继续下一步。

下面几种测试手段，都会用到极端的思维：

最低配置的设备上能否流畅运行？在设备资源紧张（例如内存不足）的时候，程序还能否正常工作？在最老旧的系统、浏览器版本上能否正常运行？非常频繁地进行操作，程序还能否正常响应？

依据这个思维，产品经理应该把这些东西都定义清楚：

可交互界面的输入类型与范围；目标运行环境的最低配置；兼容性：系统版本、浏览器品牌与版本；需要支撑多少用户同时在线、多少同时发生的流量；要能应对什么程度的故障。

测试思维：因果

开发思维中“条件与时机”注重的是“前提”，测试还会做反向思考和补充。除了关心“什么条件导致了这个结果”，还要思考“这个条件会导致哪些结果”，这也是开发写代码容易疏忽的。

两个典型的问题是：登录后可以做什么，界面上有哪些变化？

这种思维在所有岗位都是适用的，也很容易理解，对产品经理的意义就不细说了。

测试人员不仅用它来评审需求，找bug时要考虑是什么操作、事项、需求导致了bug以及这些东西的关联关系、影响范围等，从而进一步发现更多问题。

而且作为需求的实现者，技术人员都会有这个问题：为什么要这样做，做成了会有什么结果？

产品经理是有责任回答这个问题的。其中，“为什么要这样做”要心里有数，在需求评审时被问到就要能回答。

不能靠想，要有根据：

用户调研；统计数据分析；市场调查；竞品分析；成功经验。

还有“做成了的结果”应该把它以“目标”为第一章标题写到需求文档的前面。

目标示例：

解决用户购物流程中的不便；给占比有27%的喜欢xxx用户增加一种选择，可以对xxx进行操作；转化率至少有12%；提升月活跃度10%（或到30%）；提高广告月收入至300万。

产品经理做需求时，应该先想好这些目标，需求是围绕这些目标来制定的。大家理解这个目标后，还能帮助产品经理想出更多更好的方案来达成。

测试思维：场景

“场景”在本文中意为多个条件共同作用的情况。下表表示的是两个条件（行为、身份）下的结果（权限）。

设想增加一个情况：已绑定微信的会员可以查看“朋友积分榜”，这就需要一个“行为-身份-微信绑定-权限表”。如果有更多条件，就不是一个表格能说明的了。合格的测试人员会把这些条件的所有交叉情况都测一遍，甚至在需求评审后就要做用例设计，把需求文档没覆盖的情况立刻指出来。

场景的本质是条件的排列组合，可以用数学公式计算出有多少可能性。产品经理不应该把这些情况推托给技术人员去想，因为最极端的情况是可能会发现某些场景无解，以致要推翻整个需求。到评审完才发现这些问题就晚了，耽误了太多人的时间。

当场景过于复杂，除了要说清楚规则外，还应该写出示例来帮助理解。

用户体验思维：层次分明、重点突出

产品经理或设计师做网页设计时通常会有这些原则：

方便从上到下阅读，页面不会产生横向滚动条。描述一个宏观事物的图不会跨越两屏才看完整。层次分明：标题比正文的颜色更深、字号更大、字形更粗。段落内部的重点词句（一般是超链接）要使用更显眼的颜色，字形可以使用粗体、斜体、下划线等。无论需求文档是写Word还是用Axure导出网页给技术同事看，以上原则都是适用的：帮助提升阅读效率。

还有一个问题是表格的运用，表格能让人一下看到哪里有填东西哪里是空白，但并不方便人仔细阅读所有的内容。什么时候用表格或列表，这里总结两个简单规则：

表格除表头外至少有3行3列，否则用列表。如果表格写不出精确的表头来，也就是每行是不同意义的，用列表。

最后就是，写需求用Word还是Axure或两者结合，都无所谓，关键是要把事项描述清楚并且方便查阅。

思维应用

上述思维的运用，最终是为了提高需求的完善程度，避免需求本身有bug。产品经理要去学习技术知识的话，应该是要总结出更多的思维，而不是真的要会写代码。以下按照界面和交互来总结一下技术思维的关注点。

界面组件上的应用：

（1）文本框

过长如何显示：换行、显示省略号；如果换行和省略号都不要，就要确定文案最大字数；数字保留多少位小数，四舍五入还是去尾或进1；数字的显示格式，例如：加逗号或加单位；时间的显示格式，例如：是否显示分秒，日期间用中文还是横线连接。

（2）输入框

默认值；占位符；按下回车的行为；自动补全的规则；可输入类型：纯数字、文本（中文、外文、特殊字符），是否密码；输入限制：文本长度、小数位数、取值范围、最大最小值、是否必填。

（3）选择框

默认状态；单选还是多选。

（3）下拉列表

默认值；实际值与显示值的对应关系：例如界面上显示100+，实际值是135。

（4）按钮：点击后的行为

（5）弹框

位置：屏幕中间或中下；显隐动画：时长、方式。

（6）表格：排序规则。

（7）开关：默认状态。

（8）轮播

是否自动换页，间隔时间；是否显示分页器（“点点”或页码），是否可点击分页器来换页；是否可循环；是否显示进度条；是否增加每页边距，边距是多少。

（9）图片

缩放规则，例如：固定宽度、高度随原比例；层级：谁可以遮盖谁。

交互上的应用：

点击：反馈形式（例如变色）。

手势（例如右滑后退）：

距离；速度；方向。

界面切换：

动效：时长；窗口、屏幕改变大小（横竖屏切换）的布局规则；已输入的数据是否保留；关联关系。例如选中后会立刻改变其它控件的状态。

本文由 @hursing 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议