EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
本帖最后由 I_believe 于 2021-11-29 13:50 编辑 & a. b) g# b0 E9 P' V
# O$ S4 {/ }" e& U3 S概述:. p) o- G1 ^- \8 I1 Q7 P
对需求管理及需求评审的描述,从3个方面进行阐述,分别是需求分类、分类方法、评审过程。另附文档示例。; L! B* h: ^. h! c: h
一、需求分类
7 ?. |8 [7 y6 y3 ]- q9 S分类方式一,按用户类型:* N" A4 o2 q1 o5 U2 E3 b! {
1)B端需求面向企业客户的需求;' [- M0 E! a4 y' A! T% \- N! b
2)C端需求面向个人用户的需求;% h2 L+ a+ I$ b, `4 P
分类方式二,按功能分类:2 i# x% \* l X# z
1)设计类;5 h3 a" G& h$ ^# R6 n
2)体验类;) G. z7 ]6 q) X$ Y
3)功能类;
8 M. x) Q# a% y. b' ]: {4)运营类;' {1 _" {) d, J! ]1 }) f7 L
5)数据类;$ v9 F% t$ f# R
分类方式三,按需求强度分类: q# n; r- T. b! P% x# v# F- f
1)真需求:用户真正想要的需求;
9 L }( S& ]2 R: e3 {; d7 Y2)强需球:用户最渴望满足的需求,必须满足;+ h8 k4 g; Y. F0 F$ a
3)弱需求:用户非必要需求,不满足用户也可以;% A8 p) A2 ]8 T% Q3 P4 d. L6 N0 s/ t
4)伪需求:用户自以为需要,实际不需要(无用);
% `' n& P$ e, t7 `; ?5 Y二、需求分类方法% Y2 g: X! i, O3 B' b' g, G: d
kano模型# c4 J8 S8 e5 ~1 G& n( X
1、背景:KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。
- L1 s7 G7 C5 A5 o0 `2、根据不同类型的质量特性与顾客满意度之间的关系,产品服务的质量特性可分为五类:基本(必备)型需求——Must-beQuality/ Basic Quality
, h' _1 d0 [7 v5 [1 \期望(意愿)型需求——One-dimensional Quality/ PeRFormance Quality
, n6 o, D5 O, z- ~6 r) U兴奋(魅力)型需求—Attractive Quality/ Excitement Quality
" U6 h0 f% a+ a0 L; D无差异型需求——Indifferent Quality/Neutral Quality
0 O& I1 u, ^+ S- b# A5 w反向(逆向)型需求——Reverse Quality2 h$ S( b' L2 U- N* s) \! T
前三种需求根据绩效指标分类就是 基本因素、绩效因素和激励因素。
* i. F! v( o: a! n* @& P备注:关于更多的kano模型了解可以再找一下资料~- i) h, v' U" j7 P
Eg:互联网公司对用户核心需求的理解3 U7 {; _( c# U' p( U8 L
1、腾讯公司理解的用户核心需求:性与暴力(微信 张小龙)
8 y6 g d$ q* q7 E+ v( A2、阿里巴巴理解的用户核心需求:快乐与健康 (马云)
5 t- t/ @2 j6 I5 I3、字节跳动的用户核心需求:延迟满足感,效率工程部,信息创造价值,记录美好生活9 b2 V( P8 z4 V5 D' b
4、百度的用户核心需求:搜索速度快,简单可依赖
3 ]1 ^# u0 J" ^% F( g三、需求评审过程
4 H! u" z# E( g: I/ h需求开始至评审完成过程大致由四部组成(每个公司情况不同):需求整理(整理需求池/to do list + 初步评审(N次)+ 需求确认 + 最终需求输出物)
3 U! M6 f, K& T) ~1、什么是需求池?/ c+ W y* B/ r5 n" t) P
定义:某个软件现在及将来可能提供的所有功能的集合。2 T, d0 y. b1 @' o0 h c- c
8 z3 x% e6 B% }! @5 e9 ]
2、需求生命周期:, \/ a2 y. c; B( A
根据需求的进度与重要紧急程度,需求池中的需求按状态可以被分类为:
2 I. W& h- I- c/ o+ j3 k& ]1)想法阶段(未开始需求)
( w- @. R n0 ?% I `7 k4 k9 L2)设计阶段(待设计需求)- k- ?" |$ j; Z! J. B
3)评审阶段(待评审需求); s9 j& t* t0 s7 M
4)开发阶段(开发中需求)
8 l' m) a: l! N! A* G" v$ K% ^5)测试阶段(测试中需求)& V6 O3 h) J2 T! l
6)修复阶段(修复中需求)
, d% W* B! a | H8 W: S6 a7)上线阶段(已上线需求)% Y" x5 j3 {9 `8 v% ]! p
# A7 r8 R+ d9 J3 x9 `! o
3、需求池记录格式与描述维度(标准不唯一)+ m" n9 t' J: p$ V
1)需求标题:简述需求内容,区别于其他需求;
+ b7 t, ]0 V7 x+ S) i2)需求价值:为什么要有这个功能?如果没有这个需求会导致哪些不利因素?如果有这个功能会带来哪些有利因素?受益相关方都有哪些?- }# U& X& z) v
3)需求描述:详细描述需求的位置、场景、角色、功能、交互、文案等等细节内容。+ o( e# g' L3 `, n
4)产品线:标准文字记录该需求属于那条产品线,eg:app、微信小程序、web端等等; ~* b$ q- r) G! V- S1 j! @1 _
5)功能模块:文字说明该需求属于哪个产品线的哪个页面功能模块。Eg:app → 个人中心 → 我的订单。
1 Z d8 u$ V, t2 V V) X6)需求来源:需求的初始来源,eg:业务、运营、零售、技术、BOSS等
, K3 C/ u8 u; k J7)提交人:记录需求的具体提交人,eg:产品经理张XX,李XX
1 e. A$ z3 M% C! d( H8)优先级:初步判断该需求的研发优先级,eg:高中低、紧急、非紧急。
- l! {$ D& J/ e$ z7 g& m9)需求状态:未开始、待设计、待评审、待开发、开发中、测试中、已上线等。* `* D8 a& O0 A7 [+ i# e
: h1 a* N& s) Q1 ]
4、需求评审环节
6 h* P) P7 v; R6 H
1)需求评审核心讨论维度:
) k' ~8 P/ w1 o I l- S需求评审一般会围绕需求的以下多个维度进行讨论与博弈:
* ^0 L8 h# y9 O+ x. a风险大小、成本把控、技术难度、技术资源、版本周期、紧急程度、预期效益、运营资源、其他配合资源。9 c. T5 B" K/ W* h3 u
2) 核心维度举例:6 r- i4 c3 T1 ]$ M
(1)风险大小:高、中、低;& Z# k- L# y2 J3 x6 E# ~( s. }
(2)成本把控:金额预算、人力预算、时间预算;
; Z* d" `, c: X/ }: z2 h5 P(3)技术难度:难、中、易;3 g( U, x; g8 f4 T9 c0 Y, w
(4)技术资源:前端可用人数、后端可用人数、iOS/Android可用人数;
! j+ A5 \7 n, B(5)版本周期:第几个版本
, n: F* k7 T! E1 X6 t(6)紧急程度:高、中、低
* x9 w! i- ^8 w4 J7 N f(7)预期效益:满足多少个用户需求,eg:优化某个高频场景,可以带来多少销售额提升。/ r) s" U* [- h; B. `
(8)运营资源:广告运营预计投入资金,投入人工工作量3 I- a3 X" t& }2 }$ l# W9 U' i8 c
(9)其他配合资源:是否涉及其他内/外部资源的配合,预计投入工作量,如涉及外部资源,是否涉及资金投入。
. Z& `) g) n' j+ u* L6 H四、文档示例, B* v6 g" r7 d3 J8 G1 M
1、需求to do list
1 q0 V: O1 W/ b+ V+ J6 l1)2 D1 ?! s$ M7 B7 z- A
2) O0 `" {4 P6 L2 |, K- a
7 G& A" W7 P6 G; @* G9 n
2、需求列表
+ F8 C4 y# x2 ~ [; r2 F1)
6 U" y- e+ A0 M7 O 2)
& O% i" ]( D% c% S
, _' B! V7 ^# N7 f) Q
& c% ~! ^# m% ?+ M( e- t% p: M5 q: d' {* ? j* R
7 b# T2 @. G: Z& W
|