我换了新公众号，新号还没有“原创”标志，所以最近我拿博客中以前写的文章更新推送，等获得了原创标志之后，我再更新新写的内容。在浏览历史文章的时候发现4年前我挖了一个坑，实在过意不去，今天就来把这个坑填上吧。

4年前的文章问题是“这样的产品流程问题如何解决？”，上面图片就是文章中的核心问题，我在之前的文章中给出了“加时间”的解决方案，同时也提出了“将在外，君命有所不受！”的态度，但是在实际工作中这种解决方法不够完美，而且还有风险，所以今天我再来补坑说一说如何用“沟通”来解决这样的问题。

只有问题出现之时我们才需要沟通解决，所以首个方案我们先要排除这个问题流程的出现。由于产品实现过程中很难避免不出现需求变更和计划调整，并且每一次的变更或调整都会对原计划和工作节奏造成影响，很可能会导致产品仓促完成或者延期完成，所以在工作中产品经理尽量不要把版本计划安排到半年或一年的时间，通常情况每一个版本的迭代周期在一个月左右，最多的也不会超过三个月，这样可以有效的避免在长周期的开发计划中出现不确定的因素，从而影响产品计划和工作节奏。

缩短了产品迭代周期之后，当有新的需求想法的时候，就可以在沟通中说明下一版本考虑，反正迭代周期很短，很快就到下一个版本了。如果需求提出方非要冲撞产品原本计划和节奏，强行插入要求变更需求，那么我们就要用到“需求池”作为沟通依据了。

需求池，顾名思义就是把很多需求放到一起的东西，然后在规划版本的时候，从池子里根据“轻重缓急”和“优先级”来筛选出几个需求，排一排、整一整，弄成一个版本开发计划。需求池工具有很多，比如Project、Execl、MindManager等等都可以作为需求池管理工具。

在产品生命周期管理中，靠谱的、不靠谱的、紧急的、不紧急的，所有的需求都应该放到池子里，每一次安排产品版本计划的时候都要重新审视一遍需求。当我们上图的问题流程出现的时候，我们就可以用“需求池”作为沟通依据，首先安慰需求提出者，他们的需求我们都重视了，已经放到了需求池当中，但是安排开发需要根据池子里的所有需求进行“轻重缓急”和“优先级”的权重比较。

如果产品有很多紧急的需求，那么产品经理可以通过需求池来分拆需求，根据迭代周期来分拆需求的实现计划，将长周期的产品需求分拆成多个短周期的产品版本计划，这样不仅仅可以避免长周期中的不确定因素的影响，还可以为产品计划建立多个小的里程碑，让团队成员经常有一个阶段性的心理缓冲和小里程碑的成就感。

通过缩小产品迭代周期，从而让需求都有一个大家能接受的缓冲期，在这个缓冲期过后，重新规划版本计划的时候再来考量需求，此时大家都过了头脑发热的阶段，更能深思熟虑的权衡所有需求的可行性和必要性，并比较需求的轻重缓急和优先级。

写到这里，大家应该清楚我给的解决方案了吧，这样的产品流程问题如何解决？我的方案就是缩短迭代周期和采用需求池管理产品计划。

最后再告诉大家一个小惊喜，采用需求池作为沟通依据，在和BOSS沟通的时候，会让BOSS觉得你做事认真和有条理，在工作中会大大的给你加分哦。