大厂方法论 + 案例：从 0 到 1 轻松拆解产品需求，对程序员的质疑说不 ...

福特婚车队长

产品需求是如何落地到原型设计的？本文将结合案例和大厂产品经理常用的方法论，通俗化讲解如何系统拆解产品需求，希望对你有所收获。
1 _3 \; T* }  [1 U6 a& D

" _7 D& `6 Q, v" \7 `
一、产品经理设计思路是什么样
& d1 r$ P7 z, ~9 M. I( P面临新业务线拓展或者产品升级的时候，在收集到一大堆乱七八糟的需求后，你可能会想，我要怎么着手呢？答案是，搭框架找思路。
这是一个产品经理通用的设计思路框架，遵循由粗到细、自上而下的流程，具体如下：
战略层—–业务目标是什么，即定方向，含用户、使用终端、市场竞争力和解决方案、项目计划；想清楚做什么，即把具备价值的需求进行梳理优先级排序包括形成产品初步架构
2 y. q5 k2 I3 t% N5 n3 d搭框架—–（功能和 DFX 非功能框架）难点在于梳理功能的全面和思路；dfx 需求：保证用户使用产品的安全、性能、可拓展等需求注：DFX 其实很重要但大部分都会被忽视，此文不做拓展、后续会通过一篇文章进行详细说明，（产品经理千万不能只盯住功能做产品）
' ^5 ?* A  S2 _4 r0 h0 g拆细节—–业务流程（重点梳理异常分支和外围数据交互）、业务操作、信息结构）
8 U" ]) S" }* z& W画界面—–交互设计、信息设计
以上的思路大家可以按需参考，本文着重讲解拆解 2 步骤的方法，即搭建初步功能框架，并可落地到原型指导设计。
二、如何搭建功能框架呢？
8 O8 g, M) N; m+ D7 X9 ]2 x1 e注：搭功能框架也是从宽度上定义业务范围，而不是要深挖细节、要注意避免陷入思路混乱、把握好分寸、见好就收。
1. 用例驱动设计法（UDD）
0 W  h; W; M( H9 Q1 u$ Q用例驱动设计是一种基于用户行为和需求来设计软件开发的方法，有步骤有层次梳理出系统功能的方法，可粗浅理解为用户故事，是一个通用的搭框架方法；如类似网购下单、酒店预定、银行贷款等场景；
整体思路遵循：识别参与者使用场景及问题—–定义描述用例（目标层用例—步骤层用例— - 实现层用例）并简化
（1）识别使用场景及问题
首先，我们通过华为 IPD 需求管理思路那篇，知道产品需求 = 基于场景的解决方案，因此拿到一个产品需求，我们需要想清楚对应的场景，即 5w1h1e。
* ?" W; k9 s9 zwho（面向对象）、why、when+where（场景）、what（干什么）、以及 how（怎么实现）、else（限前置和后置）
比如要做一个访客预约系统，按照上面的描述方法，我们明白了系统的使用场景是这样：
一个基于外来访客，由于园区为了保障安全管理，在临时进入园区前，需要进行线上登记个人资料、并实名认证的产品，并且园区审核通过，验证身份才可以进入和离园。
（2）拆分：目标层 - 步骤层 - 实现层
结合上面的例子：
; _- o3 D; y3 G  F- P访客进入园区就是目标层用例，为了实现这个整体目标，我们需要步骤层用例进行支撑，这时候就可以拆分为第一个大框架
7 v* v* m% s9 F- }/ l% z具体为：
步骤 1：访客在系统上提前登记—–线上预约
步骤 2：访客填写登记资料—–填写表单
步骤 3：园区通过系统审核资料并通知访客结果—–审核管理
7 @: A/ k3 N! H. R: Z步骤 4：访客接收通知— - 消息提醒
$ O  n% I+ f) C8 W2 I: w4 t步骤 5：访客查看提交记录—–预约记录
$ t8 D; \1 Z8 U8 K6 P. w步骤 6：访客获得许可进入园区—身份验证
步骤 7：访客离园确认—身份验证
$ e9 m4 }$ [6 `. w7 N5 n8 A9 g0 r- u1 A那针对每一个步骤层、具体如何实现呢？按照这个思路，通过拆分形成实现层用例（也就是用什么方案实现）
最终这个功能框架会形成这样、（注意把不同用户端分开保证用例全面）如图：
$ k4 X4 ]- @$ a; Q, z) |

% }$ j$ I4 z3 x' |5 z4 l& w
当然这是初步框架，仅作部分举例说明，你们可以自行拓展，只要保证覆盖全部的用例就行。
8 O- @5 b* l2 l: d, Y( m在这里，我们要注意几点：
6 _2 A% \! u0 {在多种实现方案并存的情况下，如何权衡呢？
3 ^: q0 V( L& P# s0 Y0 S; u1、结合功能实现成本、第三方对接周期、客户需要、技术实现能力、外围的交互模块等多方面因素进行决策，选择一个较为合理的实现方案：
  A$ X; N: l- ^  ?7 X2、如上面的进出身份验证，给了 4 种方案，有通行扫码、临时卡、人脸识别、指纹、语音，包括我们常见的支付也可以多种路径实现，如现金支付、信用卡支付、微信支付等
3 P( k% `, k/ v2 h# _. {# G) F小结：
6 u2 b9 i* H4 r2 @, }, h1、工具：建议用思维导图、或者用例图进行梳理
  s8 f0 l$ |& v4 X4 i2、目标：是形成产品功能结构（含一级特性、二级特性、甚至三级特性）
3、适用项目：比较独立、小型或需要快速迭代和更新的项目，注重从用户的角度出发来描述系统的功能需求
2 G9 r( g0 Q: J; K4、特点：方便快捷、拓展性较差、易于理解协作，但难以适用复杂业务
8 Z; j) J% @/ C+ C' z1 R 2. 流程驱动设计法（PDD）
适用于业务协作方较多，具备较复杂的业务层级及审核，更注重流程标准化管理的产品，如 CRM、ERP 系统、工单管理系统、采购系统、数据精细管理等。
* q! \5 _% `' T3 |整体思路遵循：识别关键业务流程—–拆分目标层用例—–业务操作
比如 CRM 系统的流程是有明显前后顺序的，且为了精准做好客户关系管理，标准化的流程非常重要。通常按照以下步骤进行操作：
9 [5 Y  k, ]. l- w. c  d3 ?1、客户档案创建和维护—–客户管理流程
  `* t/ W$ \# j+ I2、销售机会（Lead）创建和跟进——销售管理流程
3、市场活动的策划、执行和跟进—— - 市场活动管理流程
6 h6 i. }- [4 _  M, g  D结合以上顺序流程，就很适合用 PDD 来搭框架，我们大概拆分出几个目标层，并进一步落地到具体的功能模块中。下面是一些可能包括的模块：
- r) n2 l$ p* U# q客户管理模块：
a. 客户档案：创建、查看、编辑、删除客户资料；
- A1 h% r5 l8 Fb. 客户分类：对客户进行分组和标记，例如根据客户来源、优先级、交易状态等进行分类；
- j( M3 R. I" a. n# Pc. 客户关系历史记录：记录客户与企业之间的活动历史，包括通话、邮件、漏斗进展等。
销售管理模块：
a. 销售机会（Leads）：创建、跟进、评估及关闭销售机会，可以关联相关的客户信息；
b. 产品 / 服务信息：录入、查看、编辑和删除产品或服务信息；
c. 报价单 / 订单：创建、发送、听取意见、确认并完成报价和订单交付等流程；
d. 合同信息：建立一个合同管理库存储合同信息，以追踪合同执行情况和收款计划。
3 |8 F0 l: n: s1 S4 p8 Y! ~1 |市场活动管理：
6 k0 |, {3 M4 v- C" w  ea. 活动策划：创建市场活动，定义主题，摘要、预算、时间表等参数；
" \" n. v% G+ ]$ J* kb. 活动跟踪：批量创建活动推广计划来实现对活动方案的执行，包括在线广告、email、电话营销等；
( e% b7 D% Z" h# J) d( G) i& vc. 活动分析：记录活动成效，比如邮件打开率、转化率等进行绩效统计，以及对活动与销售数据的关系分析。
. b7 Z- F9 I4 L7 I! i- s7 Z在设计过程中，功能模块要尽量紧密贴合上述 CRM 系统的整体流程，具体实现时，也可依据企业的运营或者工作方式进行特定的定制。
: M# D) `% @6 F' a例如，在某些企业中市场活动管理可能更为重要，根据不同的客户属性，社交媒体营销方式有些偏年轻化公司会利用大量互联网和移动设备，而传统行业的企业上门拜访更常见。
. [1 Q4 F7 g' `7 g' Y  o1、适用项目：PDD 适用于更大型、复杂或需要对业务流程进行全面分析和优化的项目。
2、工具：UML 流程图、状态图等
9 l; K; O) a( `3、优点：帮助理清内部系统数据、业务流程，基于过程建模，从整体到局部深度设计，复杂业务简单化
4、缺点：过于关注流程，导致各个子系统业务耦合较高，难以实现拓展
3. 领域驱动设计（DDD）
领域驱动设计（Domain-Driven Design，DDD）是由领域驱动设计之父埃里克 · 埃文斯提出的，涵盖面较广，其核心思想是先梳理领域信息结构和业务规则，再梳理业务的用例、流程和操作等内容。
  ^  Z7 e+ k0 D. w2 j& M整体思路遵循：确定场景领域— - 识别核心领域对象（信息结构）— - 业务规则（定义对象之间的属性关系及行为）—–其他模块的交互
举例：场景领域— - 电子商务平台
- P( \. S0 c0 {# A. t8 e我们识别到的核心对象为：
0 ~: r0 E2 N0 T  [7 Y0 e商品管理：包括商品信息的管理、上架、下架、分类、标签等。
订单管理：包括订单的生成、查询、修改、删除等。
用户管理：包括用户信息的注册、登录、个人信息维护等。
支付管理：包括各种支付方式的接入、支付状态的管理和处理等。
% v* H  u  A$ a: Y9 Q物流管理：包括订单状态的跟踪、配送信息的记录、快递单信息的管理等。
$ ^# t$ }+ S* S0 S5 \7 e! f# t/ s售后服务：包括退换货的处理、客户服务的管理、投诉反馈的处理等
. p4 h! ?- z. h* i这里以订单管理为例，用类图表达信息结构。
, u* r# _% b6 t: c" }/ h信息结构表述了信息内容之间的关系。这种关系可以用类图（Class Diagram）来表达。
' _3 R* k: B! G

5 H: F7 A+ V" A/ f5 @* N" O
该图片来源于图书【" 图解 " 产品：产品经理业务设计与 UML 建模】作者擎苍
当我们使用类图来识别领域模型和实体关系后，需要根据业务需求和限制条件定义对象、属性、操作业务规则和流程，如买家只能在特定时间段内下单，不能重复购买同样的商品；订单满足 3 人立刻成团进入待支付；订单超时未支付自动取消等。
) s9 W# L  n8 s6 O最后，在实现层，我们需要识别系统内的其他部分或与系统交互的部分，并确定他们对业务领域的影响。比如，与支付相关的银行接口、第三方支付接口、物流跟踪动态数据的集成等都是我们必须考虑的。
* ~5 G2 p5 U; a7 ?2 M! H6 g' r适用行业：复杂且灵活多变的行业需求，开发此软件的公司，通常是行业的引领者，如中台等大型团队项目
工具：UML 类图、思维导图
优点：低耦合可扩展、能灵活应对复杂业务变更需求、可增强代码质量
缺点：团队技能要求高、时间成本高、协调难度高、编码量增加（长期来看是值得的）
* a4 F- {! a8 i, p& z* n注：通过选择合适的方法论，我们完成了产品设计第 2 步：搭框架，后续再通过第 3 步拆细节，重点梳理各分支下的异常流程，逐步完善细节，最后一步，再进行页面信息收集填充，剩下的就是画原型了，此处不做展开。
三、面对不同项目，如何选择？
$ X4 p: c6 L2 _1 S综上，通过以上 3 种搭功能框架的方法论，我们知道，产品设计方法论，包含用例驱动设计发（UDD）、流程驱动设计法（PDD ) 、领域驱动设计法（DDD），我们来整体再做个对比总结，通过以下维度进行决策，方便我们在具体的项目设计中，选择较为合适的方法。


4 W% _6 U. [" T+ o. r
当然，他们各自有优缺点，在一个项目里，完全可以结合交叉使用。
四、拆解需求需要具备的能力和思维
+ }4 g$ e! k+ M- z设计思维：清晰的产品设计思路、并形成自己的通用方法论，掌握并应用（如上面的 3 种方法）、包括其他的成熟模型（如 AARRR 模型…）
设计方案：内心要有很多成熟可用的方案思维和评估方案的能力，就需要多练多看、多去关注一些最新的技术，不然没法梳理框架里具体都包含什么，怎么实现
* F' \/ `. B  i; V1 F6 P深度思考能力：多使用结构化思维培养深度思考能力、体现在异常流程、外围数据交互处理上（平时要多观察竞品、多问几个为什么、包括开发阶段潜在的问题、面对开发的质疑才可以真正说不）
$ @/ l  U, m' \2 t  d最佳的 UI 感及交互设计能力（审美、人机交互最佳策略）
* c6 x# V7 L  d# M# d工具使用能力：巧用 UML 建模，事半功倍（重点关注类图、用例图、状态图、流程图）、还有其他思维导图等
& A( [3 w8 O/ O, n$ E 五、其他想说的话
本文的重点是教大家如何通过成熟的方法论，拆解需求指导原型设计，在写的时候，里面其实包含了很多知识点，并没有展开：
% e- b( Y/ \% I( N) k比如最容易被忽视的 DFX 需求：UDD、PDD、DDD3 种方法论如何灵活保证系统的 DFX 需求，这部分产品经理必须有相应地思考和考量，不能老是产品做了用不起来或者代码混乱、后面维护难、迭代难……
, b, A# B$ m+ E. J4 W# kUML 建模能力的学习：高效辅助产品经理工作，梳理需求和团队协作、包括作为评审材料后期可进行系统设计检视，很值得研究运用，但不是都要学；
- c: q: a  \5 ]: A% ?5 O7 s. d" F再比如产品设计由静态到动态，框架的各个模块之间如何进行交互设计关联；页面信息结构怎么收集并合理展示…… ..
后续我也会慢慢整理总结、输出。
" _" T" T7 r5 l3 l1 M最后，我们还可以问自己一个问题，从程序员角度，逆向考虑下，程序员拿到一个需求，都是怎么拆解并实现的？
或许你会知道，你设计的功能是不是相对完美的。
& k+ v- ]0 C, S- d  z# z本文由 @凯拉 Kella 原创发布于人人都是产品经理，未经作者许可，禁止转载。
/ a# d7 ]! H# ~6 _$ ?+ J0 N9 s题图来自 Unsplash，基于 CC0 协议。