接口文档要写在概要设计里吗_方法论:产品经理写好一份需求的系统化思考模型...

5e6791dfc7e2b20558361da14b3914a1.png

18年,在做年度复盘时,回顾了自己过去一年的产品工作,发现了几个共性的问题,其中有一个就是:需求场景考虑不全面,开发过程中还会有需求变更。很不巧,开发GG们最讨厌的就是需求频繁变更。作为一个有强烈求生欲的产品,这个问题真的不容轻视啊~因此不禁问自己:你真的会写需求吗?换一种问法就是:产品经理,如何更加高效高质量输出需求?

前言:阅读须知

在开始进入正文之前,先对内容做一些概要说明,若未能满足你的阅读需求,可自行绕过,避免造成不必要的时间浪费,引起身心不适哈哈~~

1、适用人群

作为一个2年级产品新生,认知边界肯定有一些局限性,建议阅读人群为:-1~2年的产品经理。产品前辈们可随意,当然欢迎提出宝贵的批判意见。

2、解题思路

针对自己存在的这个问题,进行现状、成因的深入思考,以更好地对症下药,提出一些粗浅的解决办法。

3、内容说明

写该文章的初衷,主要是为了给自己一个答案,在解决写需求中的问题做一些沉淀,分享出来是希望志同之士一起探讨成长。文章涉及面较为广泛,因篇幅和个人时间有限,仅做框架梳理,不做深入展开,内容概要见下图:

c8d0b7f66f9110318f7abb88db85712d.png

一、现状

这一部分解答是什么。还是围绕目标:高效、高质量输出需求。那么不高效、不高质量的需求是什么样子的?

1、写需求不高效

不高效比较好理解,很容易想到一点就是:憋半天没写出几句话哈哈。通过长时间的暗中观察哈哈,身边厉害的产品经理,写需求基本都是信手拈来的。为啥能这么快?得到的回答是:都是套路!在这里,我们不妨拆解下,你就可以发现,可用套路的一些蛛丝马迹。从写需求整体用时来看:包括了需求调研时间长和需求编写时间长。

1.1 需求调研时间

完整的需求调研应该包括:业务诉求调研、竞品调研、系统实现调研。

① 业务诉求调研

需求的来源方很多,比如老板、用户、业务部门,业务调研是为了深入了解业务的诉求,以便更好实现业务目标。比如做电商的,业务目标可以为GMV。

② 竞品调研

是基于产品目标、满足客群去锁定直接竞争对手、潜在竞争对手,然后开展具体的产品调研,可包括:产品功能调研、产品迭代方向、盈利模式等,这部分调研可大可小,视具体需求而定。

③ 系统调研

对系统现有能力的了解,接口字段有哪些、前中后台的数据如何传输、储存怎么样?产品需要关注的原因是:写出的需求能更好地落地,不过不是重点。这部分一般看产品所处阶段,从0到1,可能看得不多。后续迭代优化的,需要多看看。

1.2 需求编写时间

为啥别人写一个需求,蹭蹭蹭三五下就完成了,而你还在吭哧吭哧写半天?其实,前面的需求调研很关键。要是写需求也有二八法则的话,需求编写占20%。需求编写用时可以包括如下3个部分:

① 需求方案设计

用什么样的方案满足用户的需求,以保证业务目标的达成?这个偏向战略层和范围层,比如:抖音:记录美好生活,其实通过短视频解决用户碎片时间消磨问题(仅代表个人见解)

② 需求流程设计

完成一个闭环任务,需要用户走进什么样的流程?比如患者去医院的看病流程:挂号--候诊--问医生--出诊断结果--缴费--取药。

③ 线框图绘制

前端页面交互部分的绘制,这很好理解了。

2、需求质量不高

这个部分,可能相关同学最直观感受就是:需求根本没法看啊:义正言辞、慷慨激昂、长篇大论,却不知所云!需求写得好不好,产品经理应该具备一个敏锐的意识就是:当开发经常来找你了解需求,这个时候,你该反思自己需求编写问题了。个人理解:需求质量高不高,可以分为以下两个部分:场景缺失及文档可读性差,对于是否更好满足用户需求,这里不讨论。

1.1 场景缺失

这个部分可以看出一个产品的内功是否深厚了。我理解这里的场景包括:业务场景和系统场景。

① 业务场景缺失

产品功能经常考虑不完整,导致后面变更需求。比如说:漏了一个未登录用户的展示状态;比如说,漏了用户优惠券过期之后,前端界面的引导

② 系统场景缺失

有些系统实现场景考虑不完全,也是开发经常找的一些点。缺失范围可能为:系统页面交互、数据交互、判断逻辑、异常处理。

1.2 文档可读性差

正如章节所说的,一些常见的现象是:文字太多、逻辑太乱、语义表述不清、没有区分人群针对性得编写。

二、成因

这个部分,解答为什么。其实上面的问题列清楚之后,再进一步思考,很容易知道为什么造成这样。写需求基本可以有三大组成部分:搞懂问题、找到合适的解决办法、将办法写出来。因此下面的点可能是导致问题出现的原因:

1、搞不清楚问题的本质

其实搞懂一个问题的本质,谈何容易,因为这个跟每个人的教育程度、社会阅历、认知水平密切相关,这都是硬伤,除了提升认知水平,真的没有根本的解决办法。不过为啥还值得拿出来一说呢?因为这些套路,可以降低你去快速一个问题的费力度。

所以,在短时间内搞不清楚,其实是缺乏有效的调研办法,对于这个问题,曾经做过一些思考、整理,一会说。(网上其实也一大把,关键你自己去不去找,找到后适不适用)

2、找不到合适的解决办法

了解了问题之后,还需要知道怎么做,否则也只能说纸上谈兵。在这里造成问题的细分原因如下:

2.1 无清晰的目标

写需求的时候,目标不明确,要解决用户的核心痛点是啥,价值主张不清晰,将无从下手。如果这个目标(大饼)没画好,大家伙为啥给你做需求呢?[奸笑]。往大里说:比如阿里巴巴,让天下没有难做的生意。往小里说:这个页面需要提升用户的点击购买率。

2.2 无明确的优先级

想做的太多,很容易决策困难,眉毛胡子一把抓是很容易犯错的。因此市场反馈未知、资源有限情况下,快速迭代试错的敏捷开发流,是一个很好的指导思想。从0到1,考虑mvp。从1到100,考虑当下产品阶段、业务目标最需要解决的问题。

2.3 无合适的载体

知道目标及优先级之后,困扰产品经理的可能还有:满足用户需求的介质选定。微信公众号、小程序、还是app?这个决策也是依赖于对用户、业务的深入思考。

3、场景缺失原因

这个问题导致的原因很简单:就是对业务、用户、系统的不了解以及经验不足导致的。(写得有点偷懒了哈哈)

4、文档可读性差原因

主要分两个点:没有区分阅读人群和信息呈现形式差。

4.1 没有区分阅读人群

产品经理的PRD,将会给到前端开发、后端开发、测试、设计师几类同学阅读。文档本身也是一个产品,每一方的需求点都是不同的,如果没有差异化满足他们,可读性当然就不会好到哪里去。

4.2 信息呈现形式差

为啥需求文档是一些规范的框架,其实是有意识地提升单位行间距输出的观点密度。框架内的内容就得靠产品经理陈述了,基本上是产品经理组织信息并且表达出来的能力不足导致的。

三、解决办法

前面的废话说了很多哈,承蒙不弃,能看到这里。其实主要是为了帮助大家更好理解办法是怎么给出来的。来点实际套路吧:

写需求前

1、项目调研思路

下面展开又是一篇文章[捂脸]

f3f4c9c8a1a8d87349f309d36c214011.png

2、选定解决办法

找解决办法的思路,其实在前面阐述问题原因的时候,已经说过了,适用才是王道。这里可以参考用户体验五要素里面的几个维度去思考。

① 战略层:确定为什么做

② 范围层:确定做什么

③ 结构层:确定整体的业务流程

④ 框架层:确定交互原型图

⑤ 表现层:视觉的呈现,UI

(可能描述得不准确,求轻怕~~)

写需求时

1、场景缺失问题

1.1 业务场景层

首先的要了解用户的痛点及人群(通过调研)、产品的目标。这样在产品设计的时候,更容易去拆分场景去设计功产品功能。可以拆解为:

同一个用户在不同的场景下面,有时间维度、地域维度、登录状态维度等,举个例子:读书app,需要满足用户在白天和晚上的阅读需求;

不同用户群体在同一个场景,在从会员等级、客群区分、任务状态上,产品如何满足群体个性化需求,等等~~找个时间可以归归类。

1.2 系统场景层面

注意考虑如下几个方面:

217646b68152f121efffb0945a057e69.png

2、信息表达形式

2.1 整体思路就是

在信息内容传递上,视频>图片>文字。

2.2 需求规范

有侧重描述:前后端、测试和设计关注重点,对于设计同学,可单建一个文档说明。

① 背景(痛点)、需求实现、需求价值---文字

② 需求管理--表格

③ 需求范围---表格

④ 需求流程---VISO图

⑤ 页面交互及逻辑---Axure或者墨刀,线框图

2.3 需求类型及表达式

① 数据类:报表需求、埋点需求,侧重表字段来源、加工逻辑及更新逻辑;

② 后端类:侧重字段定义、判断逻辑;

③ 前端类:侧重交互逻辑、展示逻辑。

如果你想找笔者深入聊聊,欢迎到知识星球找我吧

f68b06ba776511f4ebfba53d802529f6.png

行走的大雄,微信公众号:大雄背起行囊,人人都是产品经理专栏作家。金融产品经理,有多款千万级产品设计运营经验,喜欢健身、跑步,关注做事的杠杆方法。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录 1. 介绍 5 1.1 项目概述 5 1.2 范围 5 1.3 参考 5 2. 用例视图 6 2.1 WAS - SAP R/3 集成用例 6 2.1.1 车辆列表功能 6 2.1.2 车辆订购申请单的创建功能 7 2.1.3 车辆订购申请单查询功能 7 2.1.4 车辆订购申请单的修改功能 7 2.1.5 索赔单的创建 8 2.1.6 数据交换需求 8 2.2 PORTAL集成的用例 8 2.2.1 经销商 Portal 框架 9 2.2.2 车辆销售系统和Portal的整合 9 2.2.3 Nadcon system 和Portal系统的整合 10 2.2.4 车辆销售系统和Nadcon 的整合 10 3. 逻辑视图 10 3.1 兼容性 10 3.2 系统架构 10 3.2.1 逻辑架构 10 3.2.2 Web 应用的包设计 12 3.3 组件设计 - J2EE WEB APPLICATION 13 3.3.1 MVC 框架 – Struts 13 3.3.2 日志 14 3.3.3 BAPI代理结构 15 3.3.4 销售商用户信息组件和安全组件 16 3.3.5 页面表现框架 17 3.3.6 车辆列表功能 18 3.3.7 车辆订购请求单创建 24 3.3.8 车辆订购申请单查询列表 32 3.3.9 车辆订购申 请单修改 37 3.3.10 索赔单创建 43 3.3.11 数据交换 50 3.3.12 登录 & 退出 53 4. 数据视图 56 4.1 车辆列一表 57 4.2 车辆订购申请单创建 58 4.3 车辆订购申请单列表 59 4.4 车辆订购申请单修改 60 4.5 索赔单创建 61 5. 实现视图 62 5.1 缓存策略 62 5.2 会话管理 62 5.3 连接管理 62 5.4 集成的需要 62 5.4.1 WAS – SAP 集成 63 5.4.2 单点登陆 63 5.4.3 Vehicle Sale 系统 和 Nadcon的集成 63 6. 部署视图 64 6.1 安装需求 64 6.1.1 服务器的安装 64 6.2 服务支持的考虑 64 6.2.1 安全 64 6.2.2 服务器管理 64 7. 实现环境视图 64 7.1 开发环境 64 7.2 测试环境 64 7.3 生产环境 65 7.3.1 网络 65 7.4 域信息 65

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值