你们现在的团队都有什么痛点?
当我问一个团队这样的问题的时候,经常会得到各种不同的回答,这些回答中,出现频率居高不下的就是:
需求定义不清楚
这种情况下,我通常都会去看一看他们最近的需求文档,然后去找研发团队聊一聊,请他们对每个需求文档说说他们的看法。
先来说说我看到的需求定义的常见问题。要说明这个问题,要从什么样的需求定义是好的定义说起。
1如何判断一个需求文档写的怎么样?
以我的经验,判断一个需求文档写得怎么样,大概可以看三个维度,完整性,清晰度,和效率。
1. 完整性
完整性指的是软件解决方案是否定义完整。
完整性没做好的例子有:
只定义了正常业务流程软件的行为,没有定义分支流程的软件行为;
缺少交互的定义;
接口缺乏定义;
缺乏异常处理定义,等等。
2. 清晰度
清晰度指的是软件解决方案的描述是否清楚。
3. 效率
效率指的是软件解决方案的描述是否简洁明了。
以上这三个类别是有排序的,
完整性最重要,其次是清晰度,再次是效率。
这就引出了:
2需求定义的常见问题是什么?
大部分需求定义不清楚的问题,其实是定义不完整。
我看到的需求文档存在的首当其冲的问题,就是把上面的这个优先级顺序给弄颠倒了。
这些文档通常都是“效率”优先。
我见过的最“高效”的一个文档,打开来看只贴了一张UI设计图。研发团队用“一脸懵逼“来描述他们看到这个文档的感受。
还有一种观点更加夸张,认为敏捷就是不写文档,或者写一个故事卡片就可以了。
这种情况我通常会给对方看一个简单的需求模型:
这个需求模型,不论你是采用传统的瀑布开发方法,还是采用敏捷,都能用到的。
这个模型的本质,就是PMP倡导的“渐进式规划”。
在初始阶段,我们的定义可以概括一些,但是当要进入开发的时候,需求应该是定义清晰的。
清晰的标准是:团队沟通顺畅,和团队对交付件有一致共识。
如果产品和研发团队有长期的顺畅合作的关系,需求文档才会考虑到效率维度。
而在很多的团队当中,以当前产品和研发团队之间的合作顺畅程度,需求文档根本谈不上拼效率。
所以对于这类团队,我的建议是:先把解决方案定义完整,写清楚,再来说是否花太多时间写文档了。
毕竟写需求文档的本质,不是写文档,而是产品定义。产品定义是一份严肃的全职工作。
你不能说一个开发人员是否花太多时间开发了,同样的,你也不能说一个产品人员,是否花太多时间定义产品了。
在我们开始正式介绍如何写好需求文档(定义需求)之前,我们先来看看:
3需求分析的目的是什么?
有人说需求分析的目的,就是把用户的需求分析一下,拆解一下。
不对。
还记得我在需求总变怎么办?一文中讲的故事吗?
用户提的需求“要做一个手机订餐系统”其实并不是用户的需求,用户的真正需求是“外出办公,中午回到公司还有午饭吃”。
所以,
需求分析的目的是把握用户的真正需求。
要做到这一点,就要把用户的真正需求,和用户为了满足他的需求而提出的解决方案区分开来。
4需求文档包含什么内容?
包含两部分的内容:需求分析和软件设计。
需求分析是弄清楚用户需求是什么,软件设计是设计一个解决方案,来满足用户需求。
举个例子,大热天,用户既不想不出门,也不想动手,但是想要吃饭。这个是用户的需求。
为了满足用户的这个需求,可以有百度外卖,也可以有美团外卖,后面两个就是为了满足同一个需求做出的两个不同的解决方案。
5需求文档的撰写角度
有一种常见的撰写角度就是以产品经理或者开发团队的角度来写。
这样的角度也不是一定不可以,但是这个角度有一个问题,就是很容易把方案写成一个自嗨(自我感觉良好)的方案。
我的建议是:
从用户的角度来写需求文档,这样可以确保不会丢失用户角度。
具体怎么从用户角度来写,请往下看,这个角度会影响到需求文档的各个方面。