携程网类产品，开发之前该如分解产品工作？

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

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

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

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

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

• ……

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

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

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

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

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

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

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

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

以终为始-故事验收方法

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

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

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

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

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

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

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

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

最后

再介绍几个反模式。

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

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

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

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

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

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!