因为集成Azure注册慢,登录页面,而且极不友好。 这导致用户放弃注册。
官网没有展示客服咨询电话,只有一个用户建议表单。无法实时联系客服。
这个案例,很典型。从市场到技术,我们做了很多工作,但是最终效果不理想。最大的愿意就是产品不闭环。用户想学习课程,但是登录和注册体验太差,这就已经挡住了大部分的用户。
写作套路
前面我们讲了很多坑和避坑策略,那要如何才能写好需求文档呢?
铺垫
根据百度百科-铺垫法。戏剧情节结构的一种手法。在戏剧的进展中，对于某些将要出现的关键性情节和起关键作用的人物，必须在事前有所准备、暗示;为情节的展开，为高潮的到来，酝酿气氛，作好准备，铺平道路。这种手法叫埋伏或伏笔。
其实可以简单理解为背景说明。在需求文档中,增加一定的背景表述,可以增强事物间的因果联系和完整性,不显突兀。
一般可以在你的需求前增加一个背景交代，
这样的好处是,其一,让之前没有参与的人有个背景认识;其二,为自己后续的观点(或者设计思路)提供可信依据,至少不知自己拍脑袋想出来的。
下定义
对于不同的业务,有时候会有一些专有名词,或者是你自己了说明某个事物而定义的名词。如果不做一些定义的解释,很难理解。比如,在设计IM聊天时候,可能会有一些定义,可以给出定义。
逻辑清晰
需求文档,不是日记,切记流水账。排版工整,重难点突出。逻辑清晰,富有层次感。
利用图表配合文字,有条不紊的表达出合理地逻辑。这样大家阅读起来,一目了然。
说人话
针对不同的人群一定要设计不同的话术
这里的人是指不同的受众。考虑到需求文档面向的对象较多,有技术,业务,测试等,需要抛弃过于专业的技术语言，比如不要出现技术设计的细节,尽量要用自然语言表达。
说句题外话,其实严格意义上,需求文档可能是要写两份,一类是给技术同学看的,一类是给非技术同学看的。对于前者,你当然可以用类似抽象的uml图或者直接给出伪代码来说明。
视角
子非鱼,安知鱼之乐
你以为的就是你以为的吗?很多时候,需求的来源并不单一,比如公司要做一个工单系统,这个工单系统的使用者几乎涵盖了公司的各个部门。按照”用户第一”的要求,我们需要考虑到不同业务方的诉求和用户习惯。
我们在做需求的时候,就要提前想到。否则,后面的设计一定会违背使用者的意图。前面,讲过的换位思考,或者多角色思考该排上用场了。
在文档中,如何体现呢?通常,可以按照不通视角来描述。这就是类似程序的switch…case…
切记站在上帝视角看待问题。
版本延续性
需求文档很少一次性就让各方满意的,或多或少都会有补充和调整。比较好的习惯是使用修订版本来记录。
修订历史是一个版本的可追溯源，对需求变更历程有一个清晰的认识。
新建默认为相应模块的首次使用，对于文档的修改以及增加的地方可加入超链接，同时在增加与修改的具体地方进行颜色标示或者其他标志来进行区分，方便其他人员进行查询。
结语
写好一个需求文档,让人觉得很专业有很多东西需要学习。这里笔者只根据个人多年的工作经验,抛砖引玉,欢迎大家怕批评和斧正。