在需求管理中，新增的需求还容易处理，但如果是在原有的基础上进行优化迭代，情况就会比较麻烦：需要兼顾旧需求，又要理清新功能，这种情况，如何处理？

在众多的产品需求中，大概分为两种，一种是从无到有的，行话叫从0到1；另一种是迭代优化的。

从无到有的需求，需求逻辑肯定是要从头开始梳理，但是迭代优化的需求，就要在已有产品的基础上，来进行需求的增删改，这就要求在做迭代优化的需求时，既要理清新需求，又要兼顾旧需求，一旦哪里衔接的不好，可能就会产生问题。

以下是本次复盘的迭代需求。

一、需求背景

平台有一个审批单，是之前的产品经理做好的已有功能，可以进行两种模型的更新申请，咱们暂且称其为模型A和模型B。

现在根据业务的要求，需要将模型C的更新申请，也加入到这个审批单中，一个看似很简单的需求就这样诞生了。

二、遇到的问题

在这个需求中，所谓的问题，其实也不叫问题，主要是在写方案的时候，对于一些关联模块和一些历史需求考虑的不到位。

在我们的平台中，模型申请更新之后，会自动触发模型的上线流程，而上线流程会先后同步到平台的多处位置。但是对于后端开发来说，前端所谓的同步是需要在后端先通过代码实现的，所以在方案中，哪里需要同步更改，就得说明清楚，不然后端在开发时，就会出现遗漏的情况。

好在第一版方案出来后，我们内部对齐了下，及时做了补充，避免了需求开发的二次返工。

另外还存在历史需求改动的问题，因为是在原有功能上做优化迭代，不可避免的对于原有功能的一些逻辑做了调整，但是因为之前的功能太过常用，一些细节的地方被忽视了。比如在之前的注意点文案中，说明了该申请单只支持模型A和B的更新申请，在模型C加入进来之后，这部分文案并没有同步更新，虽然对于整体流程没有影响，但如果恰好有人看到了之前的文案，可能就会产生疑问，进而产生相应的咨询沟通成本。

三、如何避免

可以发现，上面提到的两种问题，其实都是细节的疏漏，要想解决细节的问题，那必然是需要细心才行。

产品经理做产品需求，其实就是在解决问题，要解决问题，首先要了解现状，了解背景，了解问题点。

不管是从无到有的需求，还是迭代优化的需求，深入了解业务和系统现有逻辑至关重要，否则就会出现头痛医头，脚痛医脚，遗漏业务场景的情况，而且可能会造成场景或不同系统模块间的冲突，解决了一个问题，却出现了两个新的问题。