起点学院课程

如何标准化需求文档提升团队效率和质量?

1 评论 1680 浏览 5 收藏 13 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

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

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

标准化的背景

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

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

如何识别问题?

通常来说,文档未标准化的问题会出现在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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 干货

    回复