1. 首页
  2. 电商

保持需求文档简短的3个步骤

Ruby语言的造出家人Matz说:“代码越少,bug就会越少。”文档也是一样,越简短,含晒的错误就越少,一块儿也更容易阅读,更容易更新,更将会带来简洁的设计,总之,保持简短的好处太少了。对于产品团队来说,简短的文档更容易撰写,要是这个条原则并都有负担。

这段话给产品经理在梳理需求文档时提了就让非常重要的建议:保持需求文档的简短。

同保持文档的简短性一样,在需求变更后,针对需求文档的后期维护也是梳理需求文档时非常重要的一点。将会在产品的开发阶段,会遇到零零散散的提升用户体验或修改功能的需求提出,若不及时记录,到最后产品验收时才发现漏做需求,会让我本人陷入某种非常窘迫的境地。在与研发人员不断沟通和磨合后,我总结了几点需求变更后,何如梳理需求文档的经验分享给大伙儿。

拿到这个需求大伙儿分三步走。

田捷,微信:TJ567765。亚信科技(中国)有限公司一名PO(Product Owner,产品负责人),场景并负责太少个项目,主要有智能终端版CRM、智能终端版ESOP、实名信息收集等项目。擅长电信领域软件服务应用的产品策划。在电信领域的需求梳理以及原型设计方面积累了一点经验。

于是我带着疑问图片和研发沟通,得到的答案是:大伙儿没时间看我写的过于冗长的文档。大伙儿只我太少简单地理解这个功能要花费是做哪些地方的,为甚会么会去实现它即可。文档中的内容又多又复杂,要把文档完全理解非常费时,一点不影响开发的字段完全我太少上放去备注中。从这件事就让,我现在现在开始反观我本人文档的疑问图片。就让总害怕研发看不懂,把就让需求写得非常细。复杂的就让功能将会写到十几行(接近1000多个字)。站在研发人员的深度图来看,在较短的开发时间里想用最快的速率去理解需求,长篇幅的文档着实增加了大伙儿理解上的难度以及阅读的速率。

在刚做产品时,我发现就让奇怪的疑问图片:在大伙儿开完需求会议把产品要花费的需求告诉研发人员后,大伙儿在实际开发过程中很少去看我写的需求文档。通常是遇到疑问图片口头询问。我当时就很奇怪,文档里每一步都写得很细,为哪些地方大伙儿不喜欢读我写的文档?

通过分析具体的需求我太少发现研发人员着实要做的要是就让查询操作。

让文档瘦身不仅仅增加了易读性,着实也增加了它的灵活性。将会大伙儿在开发过程中会发现,最终开发完的产品与就让写的需求文档好难保持完全的一致性。将会接口提供疑问图片、技术等各种意味,开发过程中多几块少会一直出現需求变更的情形,把文档写得简短一点也有益于就让变更时修改。

未经书面授权,禁止转载,违者追究法律责任。

在日常生活中,喜欢逛手机中的各种应用,主动发现最新、最好用的交互设计以及最流行的界面模式,分析手机APP的受众人群和用户需求。善于自我反省和总结,喜欢结交大伙儿,交流思想。

以上3点是关于需求文档一点建议,在实际的文档梳理中非常受用。但偶尔也会遇到研发同志过于忙碌忘记看文档,时间一长有将会会一直出現需求变更忘记开发的情形。于是我专门为变更的需求准备了就让文档。文档中描述有具体需求内容、需求来源、提出时间和上线时间。拿着文档跟踪开发进度,我太少处里变更的需求忘记开发的情形。

第三步:增加枝叶

将会所在公司——亚信科技是一家专注于为电信运营商提供IT处里方案和服务的公司。有某种常见的场景要是:电信运营商的客户经理一直会在一天工作的现在现在开始,查看当天未读的提醒,或是待阅的工作。大伙儿将客户经理的这个需求暂定就让名字叫:待阅功能。待阅功能的大致描述是就让的:客户经理看得人的待阅事项主要有三大类:欠费提醒、账单提醒、生日提醒。每个提醒点击后可查看一点具体内容,比如,生日提醒我太少显示提醒时间、提醒对象、短信内容,等等。

总结分析

时间:2015-11-14 08:04来源:人人都有产品经理作者:网络点击:

在梳理需求文档时,保持文档简短,会增加整个文档的易读性。以下是我总结的保持文档简短的十个步骤。

分析需求:开发我太少实现哪些地方操作。 填写躯干:写出操作流程。 增加枝叶:展示具体内容。

一块儿有点硬要的一点:我会在备注的最后标注需求来源、需求提出时间、需求提出人。将会就让遇到过某种情形:产品开发完成后,将会时间比较久,要是需求的来源都淡忘了,此时也就无法得知当初为哪些地方要留下这个功能,为哪些地方会有这个字段。若不幸遇到项目需求确认人遗弃,一块儿文档中好难留下任何确认过的需求来源的记录。在产品验收时,若甲方对产品需求提出任何异议,就好难予以应对,也无法对应当时的需求责任人。

以上是关于梳理需求文档的一点经验总结。其着实工作中,无论是文档、邮件,还是面对面沟通,“简洁精炼”都有一项非常受用的工作技能。希望我的经验分享会对你有帮助。

第二步:填写躯干

产品需求文档作为某种和研发人员沟通的重要工具,梳理不好,会直接影响后续与研发人员的沟通质量。“保持需求文档的简短”,这点看似简单,但却是我在最初做产品,梳理需求文档时体会最深的一点。

第一步:分析需求

本文选自《产品经理:48位一线互联网产品经理的智慧与实战》

像上文中所提示的那样,把我太少显示的具体内容上放去了备注中。将会哪些地方地方内容无须会影响开发,将会上放去需求描述中,反而会降低阅读的速率和增加理解上的负担。

实践案例

一定要及时把变更的需求写入需求文档中,无须拖到下次再写。 用高亮的颜色标出变更的细节,如我太少显示的字段内容。 对于做了完全的需求要标明意味以及时间。

#作者信息#

为保持简短性,我的需求描述主要写成:作为客户经理,我我太少在待阅功能中可查看3类提醒事项,如欠费提醒、账单提醒、生日提醒。提醒以列表形式展现,点击某条提醒可查看具体内容(具体内容是一点比较完全的字段,如提醒名称、提醒日期等)。

本文来自投稿,不代表赢咖2立场,如若转载,请注明出处:http://www.zfxindai.cn/dianshang/1372.html