团队给了一些反馈，对于一个比较复杂的需求，没有梳理好会遇到的问题：
需求的各个细节点都有描述，但点与点的关系不是很明确。需求认为写清楚了，团队也认为理解清楚了，结果实际做的时候才发现哪哪都不是很清楚，需要补充完善。还会出现团队和PO发现互相理解原来不一致，从而出现返工。
复杂的需求有时候看起来不是很复杂，不就是调调界面，改改流程吗。但是一旦做起来，就算改了一点地方也会引发其他地方的问题爆发。做着做着才发现旧系统怎么有这么多潜规则，看起来简单的需求，实现起来到处是坑。导致延期。
需求描述的详细程度不一样，有的地方描述的非常精细，各种的升级场景都考虑到了。有的地方有描述的非常简略，见某某UI。但那一个UI 相当于一个京东的首页。这样就导致团队在划分任务的时候，在任务中随意包含一些需求点，这些任务实现需求的顺序和PO理解的不一致，会发生一些低优先级的需求先实现的问题。有些时候，任务包含的需求点过多，无法及早暴露风险。
所以，无论什么样的需求，如果想早点做完，少踩坑，理解一致，做最有价值的部分，能随时调整后续需求，就务必需要拆分需求，将需求拆分成颗粒度大小类似的多个子需求，才有可能达成。
所以，团队改进的一个重点是如何合理的拆分需求，掌握需求拆分的技巧。
网友评论