当我们有了一个好办法解决问题的时候，就会想着把它推广给更多的人使用。
“推行方案” 看起来像是一件 推己及人 的好事，但经常会遇到很大的阻力。
这是为什么呢？
“文无第一，武无第二”，讨论方案的双方更像是在 “文斗”，
一个问题经常会有多种解法，并且我们很难确定哪个是最好的解法。
在推行方案的时候，大家经常讨论的是 “你这个办法好不好”，
却不是 “我有没有遇到你说的这个问题”。
我们拿着 方案 到处找 问题，相当于拿着 “锤子” 到处找 “钉子”，
这是推行方案时遇到阻力的最重要的一个原因。
那么如何扭转这种局势呢？本文就讨论一下我常用的做法。
去解决问题
首先，我们的目的不应该是为了推行方案，而是为了解决问题。
既然是为了解决问题，那么方案就是可以调整的。
所以，与他人讨论的关键在于，识别 “问题” 是什么，而不是 “方案” 是否优雅。
比如当我们用了一种配置方案生成表单，我想拿出来给别人使用时，
就会想，其他人有没有这样的需求？我的方案在他的场景中是否合理？
如果对方有其他方面的诉求，我能不能改方案？
对自己而言，我们已经实现了从 问题识别 到 方案设计 的全过程。
但向外推广时，状态就又回到了 问题识别 阶段，
我们需要重新讨论 问题是什么，并考虑 旧方案 是否还适用。
我们考虑更多场景的时候，原有的解决方案很可能就行不通了。
要么部分问题解决不了，要么无法满足 扩展性 或 易用性 方面的诉求。
总之，在推行方案时，要抱着 “解决新问题” 调整 “旧方案” 的心态去做。
要事第一
有时候会想，为什么我们辛辛苦苦的去 “推” 一件事情，还费力不讨好呢。
比如我们想推行 React 中的最佳实践，别人为什么就不领情呢？
难道说我的这种方案不够好吗？难道他们没有这种需求吗？
“方案” 是合理的，“问题” 也是存在的，为什么还是有阻力呢？
原因在于，我们要做的事情 对别人来说可能并不 紧急。
可能对方在加班解决大量需求做不完的问题，哪有时间关心写的好不好。
因此，我经常借 “拉力” 而非 “推力”，用 “问题驱动” 的方式 考察这件事。
先搜集需求，列出优先级，为紧急重要的需求找方案，
这样方案一旦得手，大家都很高兴，阻力自然就不存在了。
这需要我们坚持 “谦逊” 的品格，
不是为了推行自己的方案，而是为了解决 用户的 “燃眉之急”。
消除假想敌
在进行工具开发的时候，我们很容易对问题的难度进行过多假设，
而实际上，大多数方案只要解决一些足够具体的问题就够了。
比如，我们想要设计一个函数用来处理向量，
很容易在设计的时候，就考虑 N 维向量的 一般性 处理方法。
而忽视实际问题场景中，到底会出现哪几种可能。
不合理的假设，会增加问题的复杂度，也会增加解决方案的抽象程度。
如果真实场景中只会处理 二维 和 三维 向量，
我们对于 N 维向量的假设，会导致很多工作白费，用起来也很不接地气。
尤其是对于快速迭代的业务领域，能快速解决问题的办法就是好办法，
方案是不是优雅，适用性是不是更广，未来好不好维护，甚至都不是最重要的。
也许过了半年之后，连项目本身都不存在了。
消除假想敌，会让我们的方案更 “务实”，用最小的成本获得最大的价值。
调整工作重心
除了考虑 “推行方案” 为什么会遇到阻力之外，
我们还应考虑 为什么我们会遇到 “推行方案受阻” 的问题。
为什么我们没能解决紧急的问题，为什么需要我们自己去兜售方案呢？
我想这可能在于 团队上下 没有针对 “解决正确的问题” 达成统一。
这是沟通的问题，也是管理的问题。
作为 开发 我们应该反思，有没有抓住外部环境中的核心问题。
作为 管理者 应该反思，有没有识别关键问题并向团队输入。
如果团队的大部分精力都在解决一个 “错误” 的问题，
那么团队整体的 绩效 就不会太好。
整个团队应当反思，是不是大家都在闭门造车，是不是对外部事件充耳不闻。
我们该如何让外部反馈更加具体？如何在更大的环境中创造双赢？
因此，经常出现 “推” 方案的团队，需要反思自己在大环境中的定位。
结语
不论是在业务部门还是工具开发部门，“推” 方案的例子比比皆是，
在业务部门开发的好好的，就遇到工具部门过来 “推” 方案，
在工具部门做了一个新东西，就想着 “推” 到各个业务团队去落地。
这种事情频繁发生，就说明组织内部的需求流动是反向的。
工具部门没有把精力用在 紧急重要 的问题上面。
极少数情况下，会出现工具部门具备前瞻性，想要做出一些变革。
但历史上的成功变革，没有一个不是 “以民为本” 的。
本文从四个角度分析了 “推” 方案产生的原因：
不是为了解决问题，而是为了推行我的方案
我要解决的问题，对别人来说并不紧急
假想了很多真实情况下并不存在的问题，导致方案过于抽象
团队没有识别正确的问题，导致工作重心走偏
我更喜欢用 “问题驱动” 的方式 “拉动” 方案产生，构成一个反馈闭环，
（1）找到自己的用户，了解需求，发现和定义问题
（2）根据具体的问题确定务实的方案
（3）在真实环境中进行验证，不断的改进方案
以上反馈闭环，会促使 问题与方案 “越卷越大”。
我们不断的解决更多的问题，促使方案中的技术含量越来越高。
而不是反之。
不是一番寒彻骨，怎得梅花扑鼻香。