摘要： 参与了一下某个项目，这个项目是这样做的：第一天，产品人员写了一份几十页长的需求文档，然后召集开发人员开始做需求评审，然后需求文档被截掉了若干页，并且确定7天后上线（含量天周末休息和一天公众假期）。第二天，开发人员开始照着一整份需求分档开始做技术设计，写了一份能够覆盖全部需求文档功能点的技术方案。第三天，早晨刚上班，技术人员与产品人员就开始进行技术方案评审，做了分工。技术人员说：这个时间太紧；测试人员说：我们没有多少时间可以测试了；研发经理说：那就把时间往后延一天。想想：我们能做的更好吗？1、让开发人员多关注需求（客户与诉求）并且让解决方案（要实现的功能）可商量可以尝试吗？2、需求拆分可以尝试吗 阅读全文

摘要： 在开发过程中，难免会有人问，我们的需求改拆分到多细才算合适我与火星人陈勇在聊天时，我们有过这样一种共识：按团交付更合理那么什么叫按团交付呢？简单来说，就是每次交付刚好可以且仅可以交付一个完整的客户价值——达成一项客户诉求。（注意区分客户与用户——奶瓶的客户是家长，用户是儿童，客户价值是家长以此来简化喂奶，这种价值以家长购买奶瓶的价格来体现）怎么才能防止拆的过粗？需要明确定义一项需求的客户是谁、这个功能对客户有什么样的价值，直到每一项仅满足一个完整的客户价值。怎么才能防止拆的过细？拆分到技术、部署上可以独立发布版本——确保是个潜在可部署的增量 好的需求拆分可以带来好的优先级排序，而好的优先级排. 阅读全文