您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 角色 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
什么是敏捷又不被技术嫌弃的需求文档
 
作者:乌木 来源:人人都是产品经理专栏作家 发布于: 2016-5-6
1000 次浏览     评价:      
 

先问几个问题,大家觉得写文档是一件必要的事吗?你喜欢写文档吗?你写的文档程序猿和测试会看吗?

假如你自己能独立设计和开发一个产品,你甚至根本就不需要写文档。文档的存在很大程度是因为团队协作需要进行信息传递。但负责传递信息的文档会存在几个问题。

1.信息传递会有损失。

2.存在写文档的成本。

3.存在阅读理解成本。

而在一个变化万千的互联网行业里,大家应该知道有一种绝望叫做,当你还在写文档的时候,别人已经在收集用户反馈了。

关于信息传递在知乎我找到一个图表,大概表达的是“沟通成效和沟通渠道的关系”。

我们可以发现右上角面对面交流的效率是最高的,左下角用纸来交流效率最低。

当今的世界是敏捷开发的天下。传统开发过程中,人们通过交付文档来获得价值。但这样做的结果仅仅是撰写了产品的附加件而已,对于产品本身的交付没有太大的帮助。在经典的敏捷软件开发宣言中。

我们会发现很有名的一句话:工作的软件高于详尽的文档。

你写再多的文档也不如用一个哪怕简陋却可运行的软件来阐述明白你的问题。

当然文档也有它存在的必要,比如说它的“记录”功能,若干个月后,项目换了负责人,他就可以通过这份文档了解项目的来龙去脉,从而更好的传承设计思路。文档也有益于解决纷争,当传递过程中信息流失太多,事后追究过错,看一看文档就能找到问题所在。

因此在互联网行业,无论是大企业还是创业公司,文档有其存在的必要,但这个文档应该是一份轻量且高质量的文档。那么一份敏捷有效的文档应该遵循怎样的原则呢??

最最基本的有两条:

1. 敏捷性

2. 可读性

什么叫敏捷的文档,我的理解就是“精简易迭代”。

所谓精简,就是指你的文档只讲重点,什么标题目录复杂的专业术语统统都先抛掉,只写当前任务的核心要点。有些需求文档会先讲行业和业务背景,还会有名词解释的类别,专门有一块来解释后文难懂的专业术语。

而对于一份敏捷的文档来说,这些细节应该在MRD或者BRD里说明,不应该在PRD里废话。如果程序猿需要了解业务背景知识,当面讲给他听。

所谓易迭代,就是这份文档要有一个易于迭代的形式。

一是编写人员不应该花费过多的时间去注意排版和规范,思考的重心在需求内容。

二是要有迭代记录的区域,需求变更频繁,变动的原因、时间、提出人、处理情况还是有必要记录下来的。

当然大家可以将这部分统一进PRD的文章开头,也可以另外用专门的软件或文档来管理。

关于“敏捷性”还有一个要点要提一提,就是编写文档的时机。我们要知道,不是先写文档,才做产品。合理的顺序应该是先有产品,需要的时候才写文档,当然这一点比较难把握,实际操作中大家需要综合考虑。

接着说可读性,我的理解也是两个要点:

1. 形式易读

2. 考虑阅读对象

关于形式易读,其实它会增加编写人员的写作成本,但还是有一些很基本的技巧和方法可以快速的达到目标。最起码,我们要用上设计四原则的前两个,亲密性和对齐。

再用简单的色块区分开文档的不同要点,就能很大的提高阅读人员的理解速度,同时不会增加太多的编写成本。

接着就到了本文浮夸标题的内容了T.T,也就是写一份考虑阅读对象尤其是程序猿的文档。写文档的人其实最怕写完文档却没人看,所有的努力仿佛都被浪费了,而产品需求文档最主要的阅读人员就是开发工程师和测试工程师。那究竟怎样的文档才是他们喜闻乐见的呢??

我的想法是写一份符合程序猿思维模式和工作方法的文档。

比如说测试最常见的工作方式是什么,就是撰写测试用例。测试用例如果简化一点,我们可以用写“用户故事”(user story)的方法来写

用用户故事的方法来编写需求文档,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。 ??这里我上网搜了一下资料,规划业务需求,可以采用“3W模板”,也就是:

- 谁(Who)

- 是什么(What)

- 为什么(Why)

上面的3W实际上就是描述了相关利益者是谁,他们想要什么,他们为什么有这种需求。下面举一例子进行说明:

- 谁(Who):用户

- 是什么(What):希望借助一个应用程序在不同服务器间传输文件

- 为什么(Why):为了存储项目数据

为了更加接近“用户故事”,我们可以改写为:

- 谁(Who):消费者/用户

- 是什么(What):想将归档过程数字化

- 为什么(Why):为了增强沟通,提高分享效率

敏捷项目中编写用户故事有一个常用模板:作为一名“用户类型”,我想要“需求”,以便于“原因”。

应用到这个例子,就是:作为一名用户,我想要将归档程序数字化,以便于增强沟通、提高分享效率。 ??多数情况下,需求内容需要更加充实和详细,这一步要放到后面做,开始不要这样。

用户故事的方法有时会因过于简短、不断重复而受到批评。这里我们必须明白:需求文档不是散文或诗歌,应该清晰、简明地描述用户需求;需求文档的重点也在于此,不要管形式多变或内容是否重复这样的问题。

然后作为一个不太懂技术的产品,我了解到开发中最常用的一个软件设计框架叫做MVC框架。

它的运作规则我还在学习,但它给我编写需求文档提供了一个重要的指导意义,就是在开发的思维里,用户的输入行为、后端规则和前端交互是独立出来的,我们在撰写文档时是不是也可以按照这种思维方法来区分内容。对此我设计了一个需求文档的模板,欢迎大家提出参考意见啊。

   
1000 次浏览  评价: 差  订阅 捐助
 
相关文章

锻造软件需求人员的六大要素
开发需求路线图:重要的是规划
需求用例模板
如何做好需求变更管理?流程规范
 
相关文档

需求分析方法
需求分析与建模(两个周期)
如何将客户需求转化为技术需求
产品生命周期管理
 
相关课程

面向产品的需求分析与管理
面向产品的需求分析与管理
非功能需求分析与管理
用户体验 & 界面设计
软件需求分析与管理
 
相关文章
需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   
相关培训课程
软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践

相关咨询服务
软件需求分析与管理
成功案例
北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号