解决问题的思路
该译文对应原文: How I think about solving problems (该文出自 JS 高级程序设计作者 Nicholas C. Zakas)
5 个疑问帮助我决定，排序和解决问题
在我软件开发的早期生涯中，我认为自己的主要贡献是编写代码。毕竟软件工程师被支付薪水的主要部分就是创造软件和编写代码。我花了好几年的时间才意识到有大量其他的贡献在创造软件时(如果不是，为什么会有主管，设计师，产品经理，销售人员等)。我自己逐渐从一个编码人员转为一个问题解决者。有些时候问题可以通过编码解决， 而其他时候解答并不总是和代码相关。
一旦我理解到自己是一个问题解决者，我决定采取一种高效的方式处理发生的问题。 当作为技术主管后，我每天都身处持续的问题之中。这迫使我不得不思考一种对策在尽可能解决更多问题的前提下，使决定更加果断，问题的排序更加高效。
最终，我定义了一个问题清单，当每个问题出现时，我发现按顺序回答这个清单的问题可以帮助我尽可能做出最佳的决定。
- 这真的是一个问题么？
- 该问题需要被解决么？
- 该问题需要现在被解决么？
- 该问题需要被你解决么？
- 有更简单的问题我可以解决来取代此问题么?
每一个问题都被设计用来揭露问题的一个方面，这可以帮助你进入下一个步骤，
如果足够幸运，尽可能避免回答所有问题。(笔者注:此处的含义是减少问题到第五步的数量)。这些问题有细微的差别，我将会详细讲解。
这真的是一个问题么？
处理任何问题的第一阶段是识别它是否是一个真正的问题，这需要一个明确的定义。 基于这篇文章的目的， 我将定义问题是如果不处理会导致客观条件下坏结果的任何事情。这意味着假设下雨时你让窗户一整晚开着它就是一个问题，因为房间内部会变得潮湿，这可能损坏你的地板，家具或其他财产。避免这种坏结果的一个解决方案是在你上床之前关上窗户，这将避免你的财产遭受损害。
当作为一个领导者，收到一些听起来像是问题的抱怨，但只是一个建议的现象非常普遍。举个例子， 我同很多刚开始工作或加入一个新团队的工程师谈过，他们感觉团队做的很多事都是错误的:使用的框架很糟糕，代码风格差劲，文件组织方式错误，他们会怎样解决这些问题?这是一个巨大的工作量!
我会问软件工程师这个问题:它是一个问题么或有哪些区别? 很多时候错误只是意味着不是我曾经的习惯或偏好。如果你能够识别哪些报告问题并非真正的问题，你将不在花费资源在解答上。团队成员对做事的方式不满意并不是一个客观上的坏结果。团队的分歧本质上没有问题。如果你可以决定一个问题并非真正的问题你就可以处理其他的任务。
该问题需要被解决么?
当你确定这是一个问题后，下一步就是确定这个问题是否需要解决。一个问题可以不被解决只要坏结果可以容忍或者影响缓慢。举个例子，如果 web 应用的一部分只有系统管理员(典型的是只有 5 个人或者更少)用，它的加载慢于应用的其他部分， 你可以认为这一部分是可以接受的。这个问题范围过于狭隘而且只影响了几个人在不经常使用的情况下。当然能够解决这个问题也很好，虽然这不是必须的，因为他的负面影响足够小，即使不解决也不会导致更大的潜在问题。另一种提问方式是:如果不解决这个问题会发生什么?，如果答案是不多，可以考虑不解决这个问题。
该问题需要现在被解决么?
如果你有一个待解决的问题，下一个问题就是它需要现在被解决或者暂缓。有一些问题明显很急迫需要被立即处理: 网站被关闭，每当有人使用时应用发生崩溃， 等等。这些问题需要被解决是因为坏结果是直接的，连续，且持续增长的。网站关闭时间越长公司损失越多。应用崩溃次数越多，用户会更有可能选择竞品。
同等重要的问题是确定问题解决是否可以被推迟。有一系列意想不到的不紧急的问题会暴露给主管层。这些问题需要最终解决但不是立即解决。软件开发中符合此类的最常见问题就是技术栈。技术栈是你应用(或基础设施)中任何表现不如预期的部分。据我所知，技术栈很少被处理直到它变为一个紧急事件(这时已经晚了)。然而，技术栈并不是需要放下其他所有事情开始着手处理。它属于中间区域，现在不需完成，但必须被解决!
一个问题不需要现在解决，推迟它是一个不错的注意。推迟它， 意味着计划在未来处理， 而不是什么都不做。如果现在不是处理这个问题的最佳时机那么决定什么时候处理它: 在这一周，这个月，六个月?把它放入你的日历或任务管理系统以防你忘记追踪它。另一种询问此问题的方式是，这个问题紧急么?
该问题需要我解决么?
该问题非常适合管理层或者有许多任务需要完成的人。这个问题的某些方面是否需要特殊技能而只有你才能处理，或者其他人也可完成这个任务。
这个问题改编自我的导师给我的建议。我曾今抱怨自己一直在收集任务而不能持续跟进。他告诉我我必须问自己:这是 Nicholas 的问题么? 这里有一些事是只有我知道如何做， 而其他事情是我需要关注的。这些事我需要安排给其他人。导师给我的另一个重要的建议: 你可以比别人更快的完成某些事并不意味着必须自己来。对于一些不紧急的任务，用一天或两天完成并无区别。
所以如果有些问题别人可以解决，如果你是一个管理者或已经有很多工作了，那就分配出去。
有更简单的问题我可以解决来取代此问题么?
最后一个步骤一旦你决定这个迫切的问题需要你亲自解决，就该判断是否有更简单的问题可以被解决。关键在于更简单的问题相对原始问题必须给你相同或相似的结果并且可以节约你的时间(或其他资源)。
当我在新版我的雅虎页面工作时，一个产品经理表示一些测试用户需要页面添加尺寸可变的列。这是一个相当复杂的问题因为在 2006 年 web 浏览器并不像如今这么强大。这个任务几乎不可能， 当时页面已经充满了 JavaScript，添加更多逻辑去管理复杂的鼠标移动而且需要保存着这些信息到后端是一个艰难并且极易出错的任务。
我要求来自用户反馈的原始数据， 试图弄清尺寸可变的列是用来解决什么问题。实时证明没有用户要求尺寸可变的列(产品经理从客户的抱怨中推导出了这个需求)。相反，他们抱怨无法使新版雅虎页面看起来和老版本一样。我们创建了和老版本几乎完全不匹配的新布局，但是事实显示用户更喜欢老版本布局。这允许我们关注一个跟简单的问题:重新创建老版本布局。
因此，我们花费了少量时间在新页面上重新创建老版本布局，并重新收集用户对话。 人们很乐意看到新页面和老版本基本相似。通过解决简化的问题，我们节约了大量的开发时间同时用户也感到开心。
并不总是有简单的问题可以解决，但是每当问题看起来特别巨大或者困难时值得花费时间去检查。
总结
这五个问题已经成为我解决问题的基本方法，不仅仅是在我的工作中也包括我的日常生活。无论问题何时出现，通过这些问题都使我成为更有效的问题解决者，并且对结果总体感觉满意。无法为你的服务员计算 15% 的小费?我以 20% 替代(或者 10% 如果我不满意他的服务)。我的高中校友机构总是向我发送通知说我并非验证的校友？这些并不是我需要解决的问题。我需要一个新的驾照如果我想要在美国旅游？这是我今年需要解决的问题，但不是现在。
有很多的方式解决问题，我并不确定我的方法对所有人都适用。但我确定有解决问题的方案强于没有任何方法。人生充满了问题，有大有小，你每天都会面对。有一个清晰定义和可重复的策略是解决问题更易接受的最简单方法。
笔者总结。上述方法提炼为如下的检查清单
- [ ] 这是一个问题么？问题定义阶段
如果这个事情不解决会出现坏的结果,则考虑是一个问题，注意这里关注的是结果,这意味着一件事情即使中途产生了损失但只要不影响结果都是可以接受的!!!
- [ ] 这个问题需要被解决么？问题的价值评估
- [ ] 问题的影响点是否足够小？ 从结果评估
- [ ] 问题解决是否需要大量资源？ 从成本评估
从经济学角度对高成本低回报的事情不要投入太多精力
- [ ] 这个问题需要现在被解决么？问题的优先级评估
- [ ] 采用 时间“四象限”法 评估问题优先级
- [ ] 采用 ToDo List 管理问题
- [ ] 这个问题需要你解决么？问题的领域划分
善于利用外在环境合理优化资源调度
- [ ] 问题是否可简化为其他问题? 问题的解决策略
类似 分治法