乔布斯曾说过一句话：
每个人都应该学习编程，因为它会教你如何思考。
美国一位APP开发员兼作者理查德·瑞斯（Richard Reis），发布了一篇文章《如何像程序员一样思考——解决问题的方法论》，他分析了为何及如何像程序员一样思考，从而成为一个解决问题的高手。
理查德提出，可以用以下5个步骤，帮你建立解决问题的思路框架。
- 理解
- 计划
- 分解
- 卡壳
- 练习
最近一个朋友遇到一个棘手问题，看看他是如何用到了这5个步骤解决的。用一张示意图来描述一下问题。
简单来说，厂家A拥有一款比较有竞争力的产品，客户E是这个产品的Top3 潜在客户。A在N年前通过中间商B公关E，一直没有效果；2年前，再授权中间商C公关，目前看，效果仍然差强人意。朋友（可以看作中间商D）在E端有不错的资源，而且可以确定拿下E的一个（用到A产品）价值不菲的项目。A也倾向于让D去公关。但是，如果处理不当，一方面会引起B、C的群起攻之；另一方面，会让A方难堪。而且，进入E的体系也面临着各种非常苛刻的条件。如何用这5个步骤解决的呢？
第一步：理解问题
理解问题是解决问题的前提，如何确定自己真正的理解一个问题？有效的方法是尝试用自己的语言说出它，看看有没有逻辑漏洞。真正优秀的程序员，总会写下自己遇到的问题，勾画出序列图，这就是在确定自己对问题的理解没有偏差。
针对上面提到的这个问题，清晰描述是——顺理成章的保障多方利益的最大化。顺利成章，是针对中间商B、C的，毕竟人家在E上也是或多或少的花了时间和精力，甚至不少金钱，作为对他们有约束的厂家A，要让别人退出的合情合理；保障多方利益最大化，这里面涉及厂家A，客户E，以及起到中间纽带作用的关键环节D。
第二步：计划
没有明确的计划，不要轻易着手解决问题。制定计划，某种程度上是制定解决问题的战略步骤。当计划不清晰时，暂停一下，让子弹飞一会，切不可凭直觉鲁莽行事。
针对这个问题，朋友的计划框架如下：
step 1：E方需求分析
首先，明确项目的具体需求，如用量、节点等，这是和A谈的初步筹码；
其次，还要明确E的利益诉求，用新的渠道是否能够为他们降低成本？新的渠道能带来服务上的升级？
第三，新渠道会不会因为审核条件严格，给E方负责人带来很大的困扰？
最后，除了这一个项目，其他潜在项目的破局点在哪里？
step 2：A方需求分析
从业绩方面看，在这样关键的节点，A急需拿下E的项目，为未来增长布局，D在E方明确的项目资源，完全满足这个诉求；
从内部管理看，因为B、C的不给力，让A错失了很多进入E的机会，在E这个客户上，有更换他们的诉求；
step 3：D方需求分析
首先，利润诉求，是第一考量因素，在A需要业绩、E需要产品的节点，D是值得双方信赖的桥梁和纽带；
其次，现金流诉求，项目大，对资金的要求就高，是否有这样的实力？现金流就像人的血液，中断了，就没法生存。
最后，机会需求，D有意向在行业深耕，A的产品资源加上E的行业资源，是难得的切入机会。
step 4：B、C方平衡
B、C方虽然处于弱势群体，但作为A方，要有合理的理由；当然，适当的利益补偿可以加分。
第三步：分解
不要尝试一次解决一个复杂问题，而应该把复杂问题分解若干简单问题。对于程序员，分解问题（做架构）远比编程技能更重要。
有了上述计划，就要针对每一方面的计划做分解，比如分解E方的需求，就要和不同部门的人沟通。采购关注价格，生产关注稳定性，而技术则更关心持续开发及服务能力等。这就需要一步步分解、落实。
第四部：卡壳
即便在清晰的理解问题，也做了周密的计划和任务分解，但仍然会卡壳！因为你面临的是从未遇到过的棘手问题。如果都做过，那就不是问题了！这个时候，不应该陷入困境里，而应该站在全局的角度，调试错误、重新评估。多与这个领域内的高手交流、请教，会有意想不到的结果。
在平衡B、C方的利益的时候，朋友说他确实出现过卡壳，毕竟这是影响到他们自身利益的事情。如果硬来，最坏的结果可能是既无法做成项目，还把D和A置于身败名裂的境地。没找到更好的解决方案是，就是卡壳的时候，不能硬来。
第五部：练习
上面四个步骤相当于建立了一套解决问题的思维框架，但具体成为解决问题的高手，还差一步，那就是——练习，练习，再练习。
实践得真知，计划做的再好，任务分解的再清晰，也需要在练习中检验，这是对思维的检验。
D在“练习”的过程中，也确实得到了意想不到的反馈，而这些反馈又促使他不断地调整计划及任务，直至达到比较理想的解决方案和结果。
