场景，是业务方案转化成系统方案的根本。场景，是需求方案是否合理，是否具有拓展性的评判基准。场景，是产品经理和开发，测试澄清需求最有利的法器。
产品经理几年，做的都是仓储系统的需求，对接的开发和测试都是相对熟悉业务场景的人，所以，过往的需求文档中总是很少介绍与本次方案相关的业务场景。同时，因为在实际写需求文档前，都会跟开发沟通具体的实现方案，所以，养成了一个不好的习惯，即需求文档中会定义比较细的逻辑。
举个例子：某个接口包含了箱号，sku，送货单号，数量，这几个字段，但接口同步时，哪些字段该放在主明细，哪些该放在子明细，可能都会定义。虽然是大家一起讨论的方案，但开发实现时也就不会再考虑这种设计是否合理，直到测试过程中发现问题再提出来，项目组紧急响应。或者更糟糕的是，测试也没有发现，到了生产环境，才发现这个问题，又得紧急处理。
今天项目组内评审一个变更需求时，涉及到接口数据结构的变更，开发负责人提了一个问题，在前期设计接口时，开发是否清楚具体的业务场景，是否清楚接口可能存在的数据变化。诚然，开发没有弄清楚这些就设计了接口，存在一定的不合理。但也让我看到了，产品在讲解需求过程中也没有过多地把业务场景描述给开发和测试，导致系统方案过度依赖产品经理，因为产品经理了解到的信息最全面，最彻底，最深入。
场景描述是否全面，是否清晰，都影响着开发和测试对需求的理解和认识，也都影响着项目后期的风险。
场景，永远都是产品方案的重中之重，做产品经理时间越久，越容易忽略掉需求设计和需求文档的本质和核心。回归自我，或许能够帮我们更上一层楼，加油！
图片发自简书App
