庖丁解牛：如何做产品需求分析(2)

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

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

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

对于户型信息，需要有户型图，户型相关的文案展示对于中介信息，可以看到中介人的头像、联系方式，可以使用多种方式在线联系中介代理对于地理信息，我可以在Google Map上查看其地理位置，并能够从我的位置导航过去对于展示的图片和动画，我需要像幻灯片一样，可以在页面上播放……

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

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

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

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

基于80/20法则，选择那些可以拆出低优先级卡片（或者可以被扔掉的卡片）的拆卡法。选择可以把卡片拆的大小差不多的方法，未来在发布计划中更容易做需求置换选择开发团队更容易理解和实现的方式

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

以终为始-故事验收方法

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

Independent：每个用户故事应该是独立的，不会和其他用户故事产生耦合Negotiable：并不会非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议Valuable：每一个用户故事的交付都要能够给用户带来用户价值Estimable：不需要能够准确的估计，但需要能辅助客户排定优先级Small：要小一点，但不是越小越好，要大小合适，可以更容易的圈定故事范围Testable：需要能够进行验收测试，最好能把Test Case提前加进去

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

最后

再介绍几个反模式。

按照技术架构分层进行拆分，常见的会按照持久层、应用层、展示层进行拆分。这种拆分方式拆出来的用户故事，会明显破坏INVEST中的Valuable的原则，而且各个故事卡由于各方面的原因，如开发进度不统一，无法灵活的集成上线。拆分时，把复杂的UI交互算在故事卡片中。大部分情况下，比较fancy的UI交互都不是核心的业务功能，这部分功能可以作为用户体验优化的卡片，独立拆出来。拆分时，过早考虑性能问题。在性能基本达标、不出现大问题的情况下，提升性能很多情况下也属于用户体验的一部分，可以单独拆出来，左右优化卡片。拆出一些管理类的卡片。比如管理产品，实际上可能包含很多产品相关的操作，如导入、编辑、同步信息、改变状态、上架、下架等，所以应该根据具体的功能，拆分成更为准确和大小合适的故事卡片。

欧阳修在《卖油翁》中，提到一个老翁，在倒油时能通过铜钱中心的方孔，却不洒一滴油，大家都很惊叹，他只说了一句话——“无他，但手熟尔”。需求拆分也一样，并没有什么高深的学问，拆的次数多了，也便有了那份手熟。

作者：张久坤，ThoughtWorks 高级咨询师。程序员出身，参与过多个国内外大型项目的交付工作，对敏捷有深入的理解，目前专注于敏捷项目的业务分析和项目管理的工作。

文章作者系 @张久坤 未经许可，禁止转载。

注：相关网站建设技巧阅读请移步到频道。

编辑：未知