在产品开发工作正式开始之前，如能有效合理的对产品工作内容进行很好的分解和规划，那么整个项目就会行云流水，运转良好。而正好文章分享了关于如何拆分产品工作内容的一些心得方法，希望对你有益。

　　作为一个产品经理，对待产品的心情与态度好比是什么呢？做个最形象的比喻就是将产品当做自己的亲身骨肉一样看待。 从产品的创意开始，一直到产品上线实际运营当中的每个细节都要无微不至的照顾到，负责到底。

　　对于一个产品最终出来，会不会有先天缺陷畸形，会不会很难带大成人。其中重要的一环，就是在产品开发之前的策划。工作内容的合理分解与计划。这一步做好了，团队就有了为之奋斗的目标。整体像一台精密的设备一样，按部就班的，运转良好。如果没做好，就会引来团队内部人员的相互扯皮，埋怨。最终导致产品胎死腹中。

　　今天来谈一谈类似携程网这样的工作流产品，产品经理在开发之前需要做到如何的拆解工作，才能发挥团队的最大效益。当我们面对一个复杂的业务需求时，如果不得其构造，不明其法，是不能够很好的拆解的。

　　工作流系统

　　我们平时经常会接触到工作流类的系统。所谓工作流，就是我在完成一件工作的过程中，需要经过多个步骤，可能还会有多个不同的角色参与。对于这种系统，我们一般有两种方式 —— 横切和纵切。

　　1、横切

　　所谓横切，就是先切分出工作流中核心且轻薄的一层，然后再去实现各个步骤中的细节部分。这对于那些核心业务逻辑比较简单、但每个步骤的附属功能多且复杂的工作流系统来说比较适用。

　　（横切示例）

　　举个例子：

　　假如现在我们需要做一个商旅订票系统，其简化的订票流程如下图所示：

　　（携程商旅的工作流案例）

　　在这个流程中，每个步骤都包含了很多个功能。比如“会员查找需要预定的航班”这一步，会员的需求可能会包含：

　　根据起始城市搜索航班

　　根据选择的城市，找出最近的机场所在城市

　　使用GPS定位所在城市

　　翻转起止城市

　　根据航班号选择航班

　　如果采用横切的话，我们仅会选取让本流程可以工作的最小故事集，如：

　　根据起始城市搜索航班。

　　甚至，在本故事中，我们可以设置会员仅能通过精确输入起落地城市名称的方式，来进行航班搜索，在不影响本步骤走通的情况下，来最小化这个步骤的工作量。其它的流程也使用同样的策略，来加速打通整个业务流程。

　　横切的优势在于可以快速实现核心逻辑，并快速上线，验证假设并收集反馈，可以根据反馈的结果来决定每个步骤中的功能应该如何设计、优先级是什么，来避免一些可能出现的浪费。缺点在于整个工作流设计会采用短平快的原则，用户体验较差。

　　2、纵切

　　另一种方式是纵切。纵切就是按照工作流中的每一个步骤进行切分，这样可以使每一个步骤都具有相对完善的功能，这在某些需要关注终端用户交互体验的产品中应用较多。注意，这里有个技巧：如果在整个工作流中，需要跟终端用户进行交互的功能仅出现在某几步中，如第一步和最后一步，而中间的N-2步都是后台流程，在开发中，我们可以先实现第一步和最后一步的功能，而中间的流程处理环节，仍然采用逐步线上化的方式，这样可以使整个工作流系统最快的上线，同时能平衡用户的交互体验。

　　（纵切）

　　比如上面携程商旅订票系统的例子，我们可以把涉及终端用户操作的步骤：

　　会员查找航班

　　会员发起订票申请

　　公司审批人审批订票申请

　　会员收到订票成功通知

　　把这几个步骤拆出来优先实现，及早上线；而中间的跟票务相关的步骤，仍然采用线下的形式。比如工作人员在携程商旅后台，把订单导出到excel表中，人肉打电话给票代，再把票代确定的订票信息填入系统，然后手动通知会员。这种方式对于一些流程复杂但用户量较小的初创公司比较适用，可以在保证用户体验的情况下，大大提升产品上线速度，并降低试错成本。

　　在这里要注意的是，不管是横切还是纵切，工作流中的每一个步骤都会遵循80/20法则，也就是20%的功能决定了这个步骤的核心价值，而80%的功能仅仅是锦上添花的，所以我们需要更深刻地研究客户的真正需求是什么，提炼出这20%的业务价值到底在哪里，从而进行更加合理的拆分。

　　功能模块拆分

　　对于已经拆出的功能模块，仍然可以根据一些方法进行进一步的拆分，这里介绍三个方法。

　　1、按业务规则拆分

　　同样的流程和操作，由于输入的数据业务规则不同，因此进行数据处理时采用的方式也不同。对于这样的情况，我们可以把功能按照业务规则来进行拆分。

　　典型的例子是搜索引擎，比如Google。在Google中，输入框只有一个，但Google会根据你所输入的数据规则的不同，来进行不同的处理操作。看下面几种情况：

　　在Google搜索框中输入一个关键字，得到这个关键字相关的搜索结果；

　　在Google搜索框中输入一个算式，如“ 1+1=”，得到算式的结果；

　　在Google搜索矿中输入“ThoughtWorks site:www.example.com”，得到在http://www.example.com这个站点中出现ThoughtWorks的页面

　　…

　　对于这样的情况，我们可以把每一个业务规则都单独拆分成一个用户故事。当然，虽然这些用户故事看起来很相似，但是大部分情况下，这些规则的优先级是截然不同的。总会有一簇最高优先级的用户故事以及围绕在外围的用户故事。比如在这个例子中，对于Google来说，支持关键字搜索一定是最高优先级的，需要在产品设计的一开始就要实现，而能够计算算式的，可能很多年之后，才开始考虑加这样一个功能。

　　2、1+N模式

　　第二种情况，是对同样一个流程，在终端接不同的网关或渠道。最典型的例子是在线支付。比如，我在京东上买了一盒磁力橡皮泥，提交订单进入支付流程，在支付页面可以选择微信支付、京东支付、银行卡支付等等。

　　第一次实现支付的功能，可能会比较复杂，但后面如果从一种扩充到多种支付方式，就相对比较简单。而且最先需要支持什么样的支付方式，你可能在一开始也拿不定主意。这个时候，我们不妨将支付功能拆成2张卡，形如：

　　会员可以使用微信支付/京东支付/网银支付中的一种进行支付

　　会员可以使用微信支付/京东支付/网银支付三种渠道进行支付

　　使用这种拆分方法，可以延迟决策-我们需要最先支持哪种支付方式，同时合理的评估项目的工作量。

　　3、复杂的业务模型拆分

　　对于有的系统，业务模型可能会非常复杂，比如一个房产交易平台中的房产信息，可能包含户型信息、中介信息、地理位置信息、价格及购买相关的税率信息、展示图、效果动画等等，当我们需要在系统中引入这样一个业务模型时，如果一上来就要考虑清楚这个业务模型的方方面面，是个性价比很低的事情——做了很多功课，但没有给客户带来真正的业务价值。

　　这个时候，我们需要将业务模型，按照我们实际需要提供的功能进行拆分。比如，我们要做一个中介搜索系统，可以仅取出模型中的中介信息，而不需要处理其它部分。即使我们需要整个业务模型去做一些事情，也可以把其拆成一个个子模型，根据子模型的业务价值及优先级去设计相应的功能。

　　比如在这个例子中，我们需要对房产的信息做展示：

　　对于户型信息，需要有户型图，户型相关的文案展示

　　对于中介信息，可以看到中介人的头像、联系方式，可以使用多种方式在线联系中介代理

　　对于地理信息，我可以在Google Map上查看其地理位置，并能够从我的位置导航过去

　　对于展示的图片和动画，我需要像幻灯片一样，可以在页面上播放

　　……

　　那么，如果我们一开始就着手于解析这个房产业务模型，那可能浪费了很多时间，而没有交付对用户有价值的业务功能。这个时候，我们需要区分哪些信息是核心信息，是对用户来说最有价值的，把这些信息从业务模型中提取出来，而后设计相应的更小的业务功能，切忌一蹴而就。

　　需求拆分是否有一套完美的方法？

　　需求拆分是没有银弹的，要根据具体的场景、限制来选择合适的拆分方法。在遇到使用某个拆分方法，不能满足当前业务需求时，看看是不是可以换个思路，换个方法。

　　当然，在选择拆分方法时，也有一些技巧，如：

　　基于80/20法则，选择那些可以拆出低优先级卡片（或者可以被扔掉的卡片）的拆卡法。

　　选择可以把卡片拆的大小差不多的方法，未来在发布计划中更容易做需求置换；

　　选择开发团队更容易理解和实现的方式。

　　当然，这一定不全面，每个人在不同的场景、限制条件下，都会有不同的技巧。相信你自己的拆分方法，多与团队成员沟通才是不变的法门。

　　以终为始-故事验收方法

　　Bill Wake提出了一个好用户故事的验收标准——INVEST模型，它由六个单词的首字母组成，分别是：

　　Independent：每个用户故事应该是独立的，不会和其他用户故事产生耦合

　　Negotiable：并不会非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议

　　Valuable：每一个用户故事的交付都要能够给用户带来用户价值

　　Estimable：不需要能够准确的估计，但需要能辅助客户排定优先级

　　Small：要小一点，但不是越小越好，要大小合适，可以更容易的圈定故事范围

　　Testable：需要能够进行验收测试，最好能把Test Case提前加进去

　　这不仅仅是故事的验收原则，更是在进行需求拆分的时候所需要考虑的拆分原则。当然，凡事有例外。在需求拆分中，有时会拆出一些实在不能满足INVEST原则的故事卡片，也不要太纠结，我们追求完美，但也总要接受现实的不完美。这个时候，跟开发团队多交流，开拓思路，协调一个比较好的拆分方式，比自己一个人憋大招要好的多。

　　最后

　　再介绍几个反模式。

　　按照技术架构分层进行拆分，常见的会按照持久层、应用层、展示层进行拆分。这种拆分方式拆出来的用户故事，会明显破坏INVEST中的Valuable的原则，而且各个故事卡由于各方面的原因，如开发进度不统一，无法灵活的集成上线。

　　拆分时，把复杂的UI交互算在故事卡片中。大部分情况下，比较fancy的UI交互都不是核心的业务功能，这部分功能可以作为用户体验优化的卡片，独立拆出来。

　　拆分时，过早考虑性能问题。在性能基本达标、不出现大问题的情况下，提升性能很多情况下也属于用户体验的一部分，可以单独拆出来，左右优化卡片。

　　拆出一些管理类的卡片。比如管理产品，实际上可能包含很多产品相关的操作，如导入、编辑、同步信息、改变状态、上架、下架等，所以应该根据具体的功能，拆分成更为准确和大小合适的故事卡片。

　　最后，对新手来说，对于如上的方法，看似繁琐复杂。但是当你亲手操作了两个项目之后，有些步骤已经内化成了你的潜意识。上手之后就知道第一步要做什么，第二步要做什么。需求拆分多了，并没有什么高深的学问，拆的次数多了，也便有了那份手熟。