需求研讨质量CLD图

今天想要纯粹从新增需求的角度来分析需求研讨的重要性。事实上，这部分对于整个架构的设计和演进，整个产品的用户价值和可维护性都是极其重要的。可惜，年少轻狂的我们，总习惯把bug多，产品质量差归结于是代码能力不行或测试能力有待提高。事实上，这是一个系统的问题，问题远不止提升编码或测试技能这么简单。
趋势:

从17年开始，团队需求交付后的bug数，一直呈下降的趋势: 需求研讨质量CLD图
结构:
需求研讨质量CLD图

上述CLD图中存在两个增强环路，它们背后的故事:
17年初，需求研讨质量不好，需求实现方案与现有架构的风险识别不够，导致需求进入开发迭代后，依然存在很多不确定性。导致开发过程中还需要不断去研讨方案。需求基本都很难按期交付，经常需要以补丁的形式合入。久而久之，上下游的干系人，对于需求规划进入迭代后的交付承诺失去了信心，所有的需求，即使一开始不紧急，最后也会变成紧急需求合入。
故事二:曾经实现的某需求，开发实现了几周的成果，在最后关头，推倒重来，开发最后花了一晚上时间，重新实现。最后，该需求交付后，故障率极高，变成一个高危场景。由于需求引入故障多，需求交付后，依然需要花更多时间来修复bug，需求整体对外部交付的计划被延期。用户信任度下降，需求计划性变弱，继续陷入恶性循环。
从上述结构来看，需求研讨质量很关键，研讨质量越高，两个增强循环会进入正向循环状态。反之，也会让团队快速陷入泥潭。

需求研讨质量CLD图