需求文档:没有标准、只有沟通

懂后台的产品经理更值钱!3周线上课程,带你掌握电商后台12个子系统模块设计要诀。了解一下>

虽然标准的文档在一定程度上能够在这些内容表述清楚,通过原型具现出来。但是切记,这些还是需要根据当前公司文化来,按需输出。一味追求所谓标准的需求文档,不去思考为什么这样写,写这些的意义是什么,反而落了下层。

这次写这个其实也算是有感而发,起因是一个产品朋友小李向我吐槽,他在一个创业团队,公司正在从探索期向成长期度过。原来的测试工作都是小李和研发相互协同的,也就是他们各自客串下测试。

后面公司慢慢向成长期过度,员工从10个演变成了50多号人,其他城市也有分公司,加起来快100号人,研发人员也就从2人变成了近10人。因为业务发展迅速,要全力负责业务线上的事情,就招了个测试。之后便是他们找我吐槽的原因。

小李给我说,测试来的第一周,给了他第一个任务,就是熟悉业务,了解公司当前的运营模式,以及基本功能。随后便带着他去见了每一个部门相关对接人,甚至带到兄弟部门去认识下部门的领导。希望后面有问题可以直接有效的沟通,不然后面公司在扩展下,这种机会就很少了。

随后也带到了研发那里,一一介绍,给研发表示,这是新来的测试,以后大家就是工作上的一家人我,画外音就是让研发不要刁难测试。

就这样过了2周,小李觉得半个月时间基本的业务和一些功能应该熟悉了,那么就开始对相关功能就行上手测试吧。

这个时候小李他们的公司也在疯狂的扩展,并且还是获得了融资,这使得小李的工作更忙了。但是小李还是和她约好时间,进行相关功能的对接。

对接的时候,小李拿着草图给测试,进行了相关的讲解。想让他根据草图和上面的文字先进行简单的测试。但是测试老说,没有文档测试不了。

小李说当时他很困惑,虽然当初很多功能都是idea,直接在会议室假设出来,但是之后去探索验证之后,很多都完善到草图上了。他就直接给他说那些草图就是就可以直接完成测试。

后面测试就直接怼了小李,说你这是草图,根本就不是需求文档。小李就直接说,原来公司处于探索业务,变换的很快,都是根据草图来进行研发的,这个草图上都有,为什么不能作为测试依据?

那时,两人争得不可开交,争到最后,测试就说她来自己写一份,说小李根本不是产品。

小李说到这里我也是吃惊了,毕竟都说出这样的话了,连忙问小李草图上有哪些东西,小李表示上面很多是手绘的原型和注释,以及后续方向,并且上面也简单的写了公司的业务方向以及后期如何做这些内容。

还因为怕看不懂,专门还整理了,整理之后还给研发他们看,他们都说没问题,他也不知道问题出在哪里。

后面我也想了想这个问题,真的是没有需求文档而引起的吗?写个需求文档他的标准是什么?

需求文档的作用

工作中,对于产品写需求文档还有个很常见的事情就是,我们花了大量的时间,将产品所有细节都推敲的完毕,都仔仔细细的写在了需求文档上面,甚至写完后还反复和研发、业务部门核对了,确保没有问题之后,交付给了相关干系人。结果他们因为工作安排,时间紧凑要么就没看,要么就简单的看了几眼就放在了一边。这个无疑是打击我们。

但是这个好处是十分的明显:

  • 后期研发中出现了什么问题,这个锅产品肯定不背。为什么?研发自己不看文档,文档里面写的清清楚楚,这个地方要这样处理,是你们自己不根据文档来研发。
  • 如果出现了人员的离职或者是新增,那他可以通过需求文档快速的了解项目。减少他的熟悉时间。

换个角度,不写需求文档。那就是我们可以从作出决定,快速的推进至研发阶段。等于开完会就直接开工,而不需要将所有细节都写的清清楚楚。

有种说法,人无完人,事无巨细。但是这个对研发团队要求很高,首先团队必须具备作出决定的能力,其次大家要有相同的行为准则和职业素养,这个就体现在相关代码规范、设计规范、原型规范上。

因为如果配合出现了失误,包括功能和功能之间的不协调,ui配色和尺寸的不统一。那么就直接凉了。

写需求文档的作用是什么

需求文档的作用主要就是为了保证目标一致性,让研发或是其他配合人员能够清晰的了解我们在做什么,了解当下我们需要解决的问题、面对的场景是什么,对于成功的定义是什么。

总结起来就是只要写出的东西,弄够帮助团队成员,作出正确的结果的东西,那就是需求文档,需求文档没有标准,只有沟通。

我不希望约束的说,需求文档这样写才对,你那样写不对。我认为需求文档对于个人来说,想这么写就这么想,想那样写就那样写。但是对于工作,还是根据公司要求来,毕竟吃饭嘛。

但是,不管是写需求文档还是说需求文档,我还是认为包含下面这些信息,对于团队,还是个人都还是有很大的好处。

  1. 问题和方案;
  2. 证明问题和方案;
  3. 成功的定义;
  4. 场景;
  5. 功能描述。

第一:问题和方案

人与人之间有着明显的差异性和共同性,更别说不同职位了。前端、后端、测试、UI、产品、运营等职位,对于相同的事物和问题都会有着自己的见解和解决方案,并且因为职业壁垒原因,常会鸡同鸭讲,这是最常见的。

(工作中例子太多了,产品要增加个功能,直接给研发说,结果研发说没必要。这就是很典型的研发不知道说在什么样子的背景下,遇见的这个问题。)

我们首先要明确这个新增加的功能要解决了什么问题。其中包括了简要的背景,这个背景可以说一句话,例如:支付成功人数很低。也可以说相关的用户调研、市场反馈、数据趋势等,用于证实这个功能或产品是我们团队要做的。

第二:证明问题和方案

我们需要证实两个东西:一个是问题,一个是方案。

要给其他人说明这个问题是真实存在的,而不是我想当然的。因为职业问题,很多研发或者是其他的部门的人都会认为(不绝对哈,但确实有这样现象),产品是技术部门的“门面”,“吹拉弹唱”样样都会。让人误以为产品经理是个只会“吹牛”的“交际花”。

但确实行业内,包括当初我自己出现过随随便便写个我认为的问题,而没去证实他,之后草草丢给研发。

方案,也是同样的问题,不去穷举,不去关注相关竞品的解决方案,也就推进到研发阶段。我想这也大家都会经历的一个过程。

同样我能够想象到出,当我们经历多了之后,简简单单说一个方案之后,这个方案真的可能是最优方案,毕竟天才和蠢材说出相关的解决方案,前者是经历过很多失败的方案之后说的,后者可能是运气好,正好说中罢了。叫他说出其中缘由,那就漏底了。

第三:成功的定义

我们要清晰的告诉其他人,这个功能对于成功的定义是什么。

这里的成功有两个意思:成功的研发出来;这个功能推出后取得的效果。

成功的研发出来这个很好理解,就是还原度,百分之一百的还原出功能。只有保证这个功能能够百分之一百的还原,我们才能通过市场、通过用户去验证这个功能或说这个方案是否成功。不然对于团队和我们来说就是,资源浪费。

我们要将成功进行定义,只有这样才能得到有效的反馈。不然我们无法确认得到的结果,到底是成没成功。

第四:场景

场景说产品工作中最重要的东西,自始至终贯穿整个产品的一生。我这里不在过多阐述,文末我会发个我使用的场景还原方式。

第五:功能描述

功能描述包含的了很多东西,如:业务、流程、反馈、架构等,如果是文档的还会包括原型、状态、迭代记录等问题。

我们需要让其他人了解业务的流程,让每一个人清晰的知道,我们的业务环节。就像我们说的,如果你们团队很强大,几乎人人都是业务方面的小能手,那么你觉得还需要相关图吗?

反之,我们为了能够清晰的表述业务,不一定要去画精美的图来表示,只要能够理解,写个1234都可以。

我们需要让其他人了解当前产品的架构,不管是信息还是功能,这样能够尽可能的复用,减少开发成本。不然研发不清楚,瓜兮兮的跑去写代码,结果要写完了发现,这尼玛其他模块有,可以直接调用或者是改一下就能用。

现在写出来了还不能用(开发:代码耦合度高)只能去改原来的,那么确实是很尴尬。

所以可以告知用户,这个功能在原产品上是存在的或是已经实现过了,因为代码真的不像我们说的,这个功能很简单,随便加一个字段就行。

最后

其实小李那些草图里面的内容确实是包含所有需求文档有的东西,只是相对于所谓的需求文档,没成体系罢了。也不是说那个测试的问题,我只是觉得太过去追求所谓的需求文档,反而不知道需求文档的真实目的。

虽然标准的文档在一定程度上能够在这些内容表述清楚,通过原型具现出来。但是切记,这些还是需要根据当前公司文化来,按需输出。一味追求所谓标准的需求文档,不去思考为什么这样写,写这些的意义是什么。反而落了下层。

补充一点的就是,大部分研发都不喜欢开会,特别是那种你在这三四十页的需求文档,一开就开几个小时那种。先不说他们记不记得住,这个开会的成本是真的高。

所以我推荐产品在开会前计算下每次开会的成本是多少(计算方法是,每一个参会人的小时工资之和),开会不要随意的开,每一次开会都是耐心的挑战、资源的挑战。

 

作者:wcof,在努力做产品不做产品经理的人;微信公众号:wcof(ID:wcofPM)

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

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 呵呵,我就是个傻白甜

    回复
    1. 什么是傻白甜

      回复
  2. 需求还是有标准的, 但是这个标准在大的方面,可能大家都一样。
    但是在细节方面,还是根据公司具体实践来的,产品和研发相互磨合得出来的。

    回复
  3. 重点在于你的想法和认知与开发人员达成一致,所要追求的模板只不过是需要一种方式/流程来清楚的表达自己的想法。一份完善的需求文档是产品开发以及测试共同深度详细的讨论之后的结果,毕竟有些需求会被砍掉,先写个大纲讨论之后再来完善文档也没什么问题,而不是纠结于一份文档浪费太多的时间。

    回复
    1. 毕竟对于大多数公司来说,时间,真的是金钱。

      回复
  4. 小李的问题我遇到过类似情况。在需求说明较为标准和完善的情况下,给新来的测试同事做了讲解,但是测试结果还是很令人不满意。但是站在开发、测试等其它职位的角度来看,他们对业务不了解,对需求不清晰是很正常的,因为只有产品经理是深度钻研业务和背景的,其它职位只要了解到能够完成工作的程度就足够了。所以产品经理的职责就是在不同的时段下通过各类沟通方式,反复确保开发和测试对需求理解不出现偏差,最终达到可交付的成果。至于沟通的形式,可以是完善标准的需求说明,可以是频繁的问答,只要达到目的就可以。
    我一直认为,产品经理是最应该能够换位思考的角色。你不能默认别人的认知程度都跟你一样,而是应该从对方的角色去辨别他的预期认识程度和实际认知程度,然后有针对性的沟通。
    至于文章中的案例,各打一大板吧。小李同志在自身工作不完善的情况下,还不去反思,是有问题的。反之,测试同志在需求不完善的情况下,还是可以利用专业技能去测试一些基本问题的,而且不要怀着不懈或者甩锅的情绪,去直接否认对方的工作成果,要良性、有效的沟通。不针对、不吵架是社会人的基本素养。

    回复
    1. 对的,我就是让他去想一想,产品的能力要求中,就有一个有效沟通的要求。我说,如果你让其他人看不懂,那就是你自身的问题,不能怪别人。

      回复
    2. 如果产品当时不反驳,而是去改进呢,还各打一大板吗

      回复
    3. 改进当然是好的,主要目的不是要判断谁对谁错,对于公司来讲,目的是如何高效的推进工作,对于个人来讲(不论是产品或是测试,或是其他角色),是努力提升自己,让自己变得更优秀,您说是吧

      回复
  5. 产品不把文档写规范,有些锅还得你背。

    回复
    1. 没错,但确实在工作还是会出现理想状态和现实状态。理想状态是我想把这些细节都写清楚。现实状态是,老板:你咋个还在写哦,快点开发哦,这个很急。之后3小时内催了5词。:(

      回复
  6. 不能过于追求标准,但至少要能让大多数人理解。如果那个草稿的模式只有你们一些熟悉的老员工能看懂,那就还是无效沟通。文档的除了沟通还有能够留底的作用。

    回复
    1. 那个草稿对于他们老员工应该是有效沟通,但是在对外的情况下,确确实实是无效。这个也算是因地(公司)而异吧。

      回复
  7. 一个说明的东西需要写标准?开发那么忙,哪有心情和时间看这个?重点需要写出就行,那些不相关的不要写

    回复
  8. 没写过

    回复
  9. 确实有的时候过分追求标准化可能本末倒置了

    回复
  10. 需求文档只是沟通的工具,只要能达到预期结果,那就不用论太多……

    回复