1
To B产品经理：我们应该如何正确的处理需求（七）
source link: http://www.chanpin100.com/article/121662
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
To B产品经理：我们应该如何正确的处理需求（七）
上篇文章给大家介绍了需求细化的第一步“To B产品经理：我们应该如何正确的处理需求（六）”，接下来就看看第二步。
上篇文章给大家介绍了需求细化的第一步“To B产品经理：我们应该如何正确的处理需求（六）”，接下来就看看第二步。
了解了需求规划的重点之后，再来看下怎么去拆解并细化一个产品需求。常见的方法是，你先根据客户场景写下User Stories，再去考虑如何拆解成更细粒度的功能点，以点带面。
我之前看过Bill Wake关于需求拆解的文章，里面很多方法都相当普遍，但确实非常有效，不妨试着对号入座下。
1）通过业务流程拆解
这种方式是最普遍的，根据需求涉及到的工作流程来梳理，将需求拆解为各个步骤，每个步骤一般可以用这样的句式来描述：谁，可以做什么，实现什么效果。
比如，顾客在一个外卖平台的下单过程，可以拆解为如下几个步骤：
作为一个顾客，我可以登录到我的账户，不用每次都重复输入个人信息；
作为一个顾客，我可以为我的订单付款，并在家收到外卖；
作为一个顾客，我可以通过微信支付，以此确认订单；
作为一个顾客，我可以查看我的订单，并在支付前修改订单信息；
作为一个顾客，我可以收到订单确认通知，以此获得支付凭据。
照上述方式拆解需求后，我们对需要实现的功能以及需要提供的能力都有了很清晰的理解。对产品经理来说，也更容易制定优先级了。
2）通过业务规则拆解
一个需求往往涉及到多个显式或隐式的业务规则，还是以上面的需求为例，我们可识别出有如下的业务规则：
作为一个顾客，我可以为我的订单付款，以此在家收到外卖；
作为商家，我可以要求订单20元起配送，因为20元以下不盈利；
作为商家，我可以拒绝20公里以外的用户，因为运费太高会导致不盈利；
作为商家，我可以保留15分钟内已下单的待支付订单，以便顾客支付订单；
作为商家，我可以取消15分钟后仍未付款的订单，以便将商品卖给其他顾客。
业务规则通常是隐式的，你也可以通过编写测试用例来细化业务规则。一旦确定了业务规则，我们就能明确规则的优先级，哪些没那么重要，哪些可以简化实施等。
接下来的两步就是按正常/异常流程拆解和按需求涉及的角色拆解，下篇文章给大家详细介绍。
以上就是“To B产品经理：我们应该如何正确的处理需求（七）”的内容了，如果你还想了解其他相关内容，可以来产品壹佰官方网站。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK