最近没有太多想要写的内容，又是到了一个思考不足的阶段了。

作为产品经理，平时的文章都是来源于每日的工作，发现问题，然后思考解决问题的方法，或是对某些的问题的理解。如果大量重复性的工作，那么在思考的时候，就会常常停留于表面，因为快速的解决当前问题才是最重要的。

最近发现一个问题，那就是评审结束后，进入开发阶段，会发现很多没有想到的技术问题，统统被抛了出来，而我面临的是要不要去解决这些没有写清楚的问题。所以就是这些细节性的问题，处理起来也是颇有门道，选择处理和选择不处理，都不会是一个完整的解决方案，我们要思考问题产生的原因，不断的提醒自己更优的去解决问题。

一、原因

表层：需求评审、技术确认需求、进入开发、发现不同情况下功能需要多种实现方式。

结果：讨论不同情况的处理方式，补充逻辑。这就会造成需求的蔓延，以及版本的延期，因为讨论需要时间，补充逻辑也需要时间，当这些确认后，还要给整个项目组同步信息，个别情况还要向上汇报，一个问题用这套流程处理下来还能接受。但是如果每天都这样，你会如何呢？

其实，这种情况下，如果能提前让团队成员查看需求文档，那么可以提前减少大部分的逻辑修改；如果能过一遍技术方案，那么产品的落地将能更加切合实际。

延展：内部声音

面对这些细节性的问题，有人说要改，有人建议下期实现，你作为产品经理是如何进行判断的呢？当然表层次，用户用的最多的是必须要改的，但这些细节性的问题大部分情况下都是可有可无的，用户很难会用的这么深，所以处不处理都是可以的。

而实际我们要面对的是如何决策，你必须要考虑别人的感受。

一个团队，有愿意配合你的（A），有无所谓的（B），有抗拒的（C）。如果一个方案，你无法说服C，最终选择了C的提议，你觉得A会开心吗？长此以往的这样，以后还会有人愿意配合你来实现产品吗？

有人和我说过，用户为中心。这我是坚信不疑，可是呵呵，不是每个决策都是围绕用户的，方案落地不靠用户，靠的的团队。而很多情况下，我们都是去探索，去尝试，用户需求不是主要的，这是事实

曾经一个团队成员和我说过，决定了我们就去做。改来改去，一直没有个确定方案。这句话我记忆尤深，正如三国里面一句台词，“决策者错可以改，但是不能说错；因为你错了，你就丧失了主动”，这句话到哪里都是适用的。

二、行动

随时记录问题

当问题出现的时候，我们要在第一时间将问题记录上，看看问题产生的频率，这就能知道自己的方案到底是否完善，然后在下个版本的实现中，参考问题，提出优化改进方案，可以不断的去完善产品的细节问题。

我们每个人都要及时的跟进问题，否则1-2天后，就会忘记这个问题，错过了最佳改正时机。因为别人也在等着你的标准，否则就会出现，技术说“你没有标准，ok，我自己按照理解想一个”，结果事后作为产品又不认技术的方案。

多思考在决策

面对细节性的问题，我建议大家不要及时的去认可某一个解决方案，临时去决策，不经过深思熟虑，那么肯定会被带着跑。不同的开发，有不同的意见，A说了方案，你认可了，当做了一段时间后，B来说A的方案有问题，你又觉得B是对的，so？懵逼了吧。

所以当问题来了后，记下来思考下相关性的功能，是否有同样的问题？是否要上报？然后将自己的思考和大家同步下，提出你的改进意见。

避免问题产生

我要说把细节问题完全不产生，那是不现实的，所以我们只能尽力的去避免。

正如前面说的，如果大家对新的需求能够提前认知一下，多开一会讨论方案，那么很多问题就能提前解决掉。

就比如需求评审，我们只是评需求是否合理，能不能开发。而需求细节，大部分开发都是按照你写的PRD逻辑思维进行的，很多地方他们也没有考虑到。

这时，如果能通过一个周会，解决当前的问题，那岂不是很好，关键在于产品经理如何主动的去避免问题。

核心就是多沟通。

好了今天分享结束了，大家有兴趣的的可以加我，期待你的到来！