如何确保需求文档完善?

0 评论 2307 浏览 24 收藏 8 分钟

在撰写需求文档时,要怎么确保需求文档的完善性,确保交付的需求文档是稳当的?这篇文章里,作者梳理了核心流程与相关步骤,一起来看看,或许会对屏幕前的你有所帮助。

一、核心逻辑

1)围绕主数据展开的系统建设。根据二八法则,我们最重要的是那20%的主数据,主数据也可以理解为我们最重要的业务对象,例如:客户、支付、订单、发货等。

这启发于《华为数字化转型之道》以及我平时常看的saas系统写的说明书,特别是旺店通ERP的说明书,让我受益匪浅。

2)用“强逻辑”去确保我们每一步都走得很踏实,来确保我们整份需求文档交出去的时候是稳当的。

二、梳理业务流程,得到核心逻辑

1)详细地将业务流程刻画下来,建议主要用图表来描述,例如:流程图。这一步主要是让我们加深对业务的理解。

2)开始总结出核心。用图表以及一些的文字言简意赅描绘出整个需求,让人一目了然。需要写出必要的固化后业务流程图、功能流程图、数据流程图等。这一步做完,你对需求已经非常理解,能够简要地表达给别人。

注意:这里尽量需要能够从数据底层理解需求

三、抽象出主数据

主数据也可以理解为我们最重要的业务对象,例如:客户、产品、支付、订单、发货等。对于主数据的认识也依赖我们对于系统的理解深度、广度,全局观和前瞻性。

能够借鉴先进的系统,并立足于自己所在的公司业务,严谨地推敲,大胆建设。

四、分析主数据

按照生命周期去分析,得到相关的操作和字段。

我们梳理主数据的时候,通常是从主数据的生命周期去梳理,从一条数据产生到其被废弃不再使用。

我们以产品为例,简要地做个示范。事实上一个很完善的系统,将会记录下产品创建时的状态、上架时的状态、下架时的状态、修改后的状态。这里真的是很简单示范,事实上信息远不止这些。

从数据的角度来说,这样做才算真正将功能做完整,关键操作后该记录下来的东西都记录下来了。

这也是更接近于我们说的一个概念“数字孪生”,现实世界上的东西更多地记录在了系统上。

这也是风控的一种手段,随时能够排查出哪里出了问题。

我还记得某次业务问起谁改了产品信息,结果我们没有日志记录下这些信息就很尴尬,无法排查问题。我们大多数人做系统,特别是企业内部系统,都没有这种将关键操作记录下来的习惯,不信你看看你旁边的同事。

五、分析原型怎么画

直接开始画原型,一边画原型一边脑补应该有什么页面,页面上有什么?

这很容易让我们的思维是很发散的,一边需要兼顾原型的样式,一边需要想有什么操作,应该展示什么数据。可能你会在脑子里想,应不应该搞个批量操作呢,然后画了一下,然后又觉得还是不要了,初期版本没必要。就是这样的不集中的思考,会消耗你很多的时间,让你花了更多的时间去画原型。

本质上,应该是逻辑先行,先从逻辑上大概构建好你的原型。

这里讲的是大概,我特别指出,因为我曾经尝试过将原型的逻辑先构建得非常详细,发现这很花费时间,其实也没必要,因为有一些页面上的字段你在逻辑里概括一下(还有的业务会直接给你表单的字段,这个时候你更没必要重复在逻辑里写一遍字段),等到画原型时直接写在原型上也省一点事。

工作量与产出要达到一定的平衡,这样才会有高的ROI。

六、梳理出页面

根据业务流程图先梳理出页面,假设你要做的是一个简单的商城管理后台,从业务流程梳理我们可以得到下面的页面。

当页面足够多的时候,我们就需要形成一个菜单,也就是我们说的功能结构。

七、梳理页面上的字段与操作

参考我们上面梳理的核心逻辑与主数据信息,我们可以很快梳理出页面上有什么字段、操作。到这里的时候,我们已经将整个原型基本勾画出来了,接下来就是打开axure开始绘制,这一步自然难不到各位。

八、原型的逻辑怎么写

这个逻辑已经在我的上一篇文章里写过了,按照那样去写,大概率不会有什么问题,这是多年实践下来的。

大家一定还是想要一个武功秘籍一样的东西,那应该就是自检表。

以下是我总结的一套自检表。

九、最后

别忘了写完原型之后,自己按原型走一走核心流程以及各个操作看看有没有哪里有问题,这不比啥都强吗!

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

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!