当我们在说标准需求文档时，到底在说什么？与网上已有的标准模板不同，其实每一个团队，都有最适合自己的一版，可以说是千团千面，那么如何针对自己的团队通过标准化打磨一份最优文档呢？

下面我将按照背景、问题、方案、价值的顺序，来说明标准化需求文档的方法论，并明确其适用场景，最后试图进一步思考标准化的方法论和边界。

标准化的背景

首先要明确目的，为什么要标准化文档？我们都知道项目管理是典型的标准化方法论，良好的项目管理可以有效地确保质量（一定范围），并增效减本。其中，需求文档作为执行环节中传阅最高频的文件，同样也承载了项目管理的价值。

一般来说，需要标准化的场景，就是原有的文档未形成标准化，这意味着文档可能有错误或有遗漏，甚至可能因为一次疏忽造成蝴蝶效应般的风险导致重做。那么根据墨菲定律，只要有可能，就一定会发生。所以，标准化文档，是从根本上解决效率和质量问题的有效方法。

如何识别问题？

通常来说，文档未标准化的问题会出现在2个方面，首先是过程，比如文档已经足够详细，可同事还是频繁地找PM确认，这属于效率问题；其次是结果，比如在测试阶段，发现效果质量与文档描述差距较大，这属于质量问题，如果要返工就同属于效率问题。

说到这里需要强调的是，问题要根据实际情况来判断，也不是所有情况，都要按照相同的质量和效率完成。

接下来我会通过一个具体案例来进一步阐述：

• 问题背景：团队因与甲方深度合作，需要长期驻扎在异地办公，在此之前没有远程工作的经验，历经几次项目后发现，不是延期就是赶着上线，质量也得不到一定的保障。

不难看出，案例中的主要问题是延期和质量，虽然这2点也与“人”相关，比如团队成员的工作态度和能力各有差异，但本文仅从“物”的角度分析，也就是客观事物来看，将其中的核心“文档”抽离出来，下面先分析延期的问题：

（1）延期原因之一，发布前频繁更改

改需求或是开发出结果再改，前者可能来自甲方的需求变化，或者是PM考虑不周；后者则是文档阅读者的理解与PM不一致，或者是描述中有错误、歧义等，这里总结的原因是：

1. 来自源头，文档有遗漏或有错误，导致需要PM做后续的弥补，不仅浪费时间，也有重做的风险；
2. 来自结果，阅读者与PM理解不一致，导致PM需要做协调，这样也会带来不必要的工作量；
3. 以及，不同PM的流程设计，语义等内容未统一，产生歧义等等，造成了结果有差异。

将这3点综合来看，如果能有这样一份文档：没有遗漏或错误，没有理解不匹配的内容，没有不同的描述方式，PM后续编写时以该文档作为参照物，就能解决问题了。下面再来看质量问题：

（2）开发后的效果质量差距较大

我们都知道运动员的状态有起伏，职场人也一样，对应的产出质量有高低，这就不可避免地会给输出物带来一定的影响，这里总结的原因是：

1. 不同PM的文档质量差距较大，文档中对效果的标准没有明确定义，不得不依赖后续的沟通来确认，因此开发产出的质量会参差不齐。
2. 工时评估的精确性较差，导致砍需求或者压缩时间来交付（这个问题用其它方案解决，本文不作展开）。

综上，我的结论是，当团队的工作方式发生变化时，可以视为一种“新场景”，比如集中变远程，非敏捷变敏捷，旧领域变新领域，在新场景下最有可能出现问题，因为旧标准或旧模式与新场景不匹配，需要团队经过一段时间去磨合迭代出新标准。

立足于核心的方案

方案并不唯一，但核心是不变的，正确的做法是根据具体情况来做选择，解决未标准化文档带来的问题自然是标准化文档，另外作为补充，可以辅以更便捷的沟通方式来解决理解的问题。

• 核心方案：内容标准，质量标准
• 解决方案：标准化需求文档
• 辅助方案：在线协作文档，语音在线办公

那么具体如何落地呢？很简单，分为2步，重新分类和完善规则。规则通常是既定的，只做小修改就行，所以我重点说分类，可以从2个角度来分，一个是人，另一个是物。

先从人的角度来分，是指按不同角色来分类，如程序员、设计师、动画师、测试等等。

举个例子，程序员的需求是逻辑，流程，优先级等信息，所以用表格形式描述更合适；动画师的需求比较抽象难以描述，所以如果有类似的视频或动图辅以文字描述更合适。

再来从物的角度分，是指按相同规律分类，可以不断简化描述，并避免歧义。

善用不同的颜色、数字、符号来给打“标记”，来表示权重高低或是你想强调的重点，或者定义某个新符号来代替篇幅过长的内容，将这部分内容单独放到一个页面，这就好比程序里的“封装”，不必每个人都要清楚文档的全貌，这样做可以使某一类角色迅速聚焦到他需要看的部分，这样就能用最少的内容表达最丰富的信息，使文档达到极简。

最后说规则，就是团队对文档共同约定并遵守的管理方法，包括命名，备份，变更等等，概括一下有两点通用规则，一是关于权责划分，二是关于文件管理。

真正的价值

标准文档一般需要历经1-2个项目来打磨，形成模板后，PM只需以最少的思考撰写，后续将整理完成的需求填写即可，团队成员的理解会逐渐与PM接近一致，质量标准也已设立，后续执行作参考，这样效率和质量就得到了提升和保障。

整体来看，一份标准需求文档发价值是提升开发效率和质量，降低沟通成本，新人学习成本，重做延期的风险。

但是如果想量化价值，是既不可取也不现实的。有2点原因，首先，在本文背景已经提到，另一核心因素关乎于“人”，所以单独抽出文档来证明价值，并不准确；其次，如果要计算，提升的价值应乘以未来文档的数量或工时，这种未知值也很难估量。

最后再回过头看项目管理三角，除去成本，只看效率和质量，其实这二者在本质上是一对矛盾指标，所以标准化文档真正的核心价值在于：在客观事物的层面，平衡效率和质量的最优解。

适用场景

在本文的背景已经提过，适用场景的核心是未形成标准化，同理，不适用的场景就是已形成标准化。

这里需要额外指出，不适用的场景还存在一种陷阱：

如果一个团队，彼此之间非常熟悉，那么这种人与人之间大量的交流也会形成某种标准化的习惯，也就是所谓的“默契”，在这种情况下标准化虽然对当前没有多少价值，但是对新同事而言就不同了，可能他很难融入这种默契，无法通过文档来迅速上手工作。

回到正题，什么是已形成标准化的场景？这里我只举几个例子参考，并不唯一。

• 大公司，因为大公司自有一套成熟的标准化文档体系。
• 中小团队，如果工作场景未发生显著变化，那么原有的标准已接近最优解。
• 敏捷模式，敏捷文档已足够极简，是通用的标准化。

关于标准化的思考

相比需求文档，我们更常见的问题是如何将一个产品标准化，或者制度标准化，所以我想探讨一下标准化方法论和边界。

支撑方法论的底层是思维，标准化属于工程思维的核心，从历史来看是从工业革命开始后广为流传，但如果将时间尺度放大到最远，我们会发现仓颉造字到现代文字，也是一场漫长的文字标准化，其中的甲骨文、象形文字等等已经被淘汰了，而国外则演变出了不同的文字，从这里可以看出2点特征：

1. 没有一劳永逸的标准，标准化是持续的状态，只有阶段性的标准，所以标准具有时间属性。
2. 不同标准是基于不同人的共识而建立的，所以任何标准都有一定的适用范围，比如英语在世界通用，方言则在不同地域通畅，表情包颜文字则广泛适用于不同的社交关系。

标准化的结果是取代旧标准，还伴随着旧标准下系统或产品的逐渐衰落，比如智能手机与诺基亚就是最典型的例子，那么如果标准化涉及到关于人或组织，会发生什么？

来回答制度的问题，我们知道，在某些场景下，远程办公比集中办公效率更高，或者OKR比KPI更好等等，然而问题的关键在于，支撑方法论的是思维，如果推行某个新标准，就意味着持有旧标准的人或者组织会受到挑战，要打破他们思维里的墙，甚至还会遭受利益上的损失。所以，如果想试图改变某个人或组织原有的思维，要格外小心，很可能走不通。

所以，标准化对人来说是反人性的，影响的人越多，角色越多样，阻力也越大，这是标准化的边界。

再来回答产品标准的问题，要先想清楚什么是标准？直接去市场寻找一个标准，看它存在的时间，越久就说明越稳定，比如需要深度研究某一个竞品，就选历史最久的那个。

另外随着时间的推移，市场竞争更加激烈，还会产生标准化的对立面——非标准化，对应产品的特征就是个性化，定制化，价值差异化等等，那么这二者如何选择呢？

答案还是看时间，已形成的标准做复制，在此基础上做非标准化来满足市场需求，以此循环往复，没有终点，对产品来说，标准与非标是永恒的主题。

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

题图来自Unsplash，基于CC0协议