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

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

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

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

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

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

• ……

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

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

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

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

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

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

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

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

以终为始-故事验收方法

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

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

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

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

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

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

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

（编辑：西安站长网）

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