标签：style get strong 文件 com cti
这个题目很难写的。 每个人的思考问题的方式都不一样，即使同一个人对待不同问题或者同一个问题不同场景也会有不同的策略。 但是有没有通用的解决方案？
问题本来是抽象的， 一般的, 其答案也是一般的，不会对待特定问题直接给出答案，但是对于问题有指导作用， 废话一大篇。
Polya 在书中给出了一个解题框架。
1. 理解题目
理解什么是未知量，什么是已知量，什么是条件。未知量代表什么？ 能用符号或者图表示出来吗？
是否可以用自己的描述清楚？ 从而理解问题是什么，对问题有一个总体的认识。
2. 制定计划
对于如何解这道题目，给出一个思路或者规划，这是最有挑战的一部分。
对于题目，可以找出已知与未知之间的联系？ 如何找,这是一个技术活。 Polya在书中给出了自己的一些间接，简单直观有用。 从自己已有熟悉的题目入手，熟悉的定量入手，或者曾经做过的某些类似的方面入手。
如果还找不到联系，尝试从另外的角度复述这个题目？ 试着从定义入手？这道题目的更普遍化的题目是什么？ 更特殊的题目是什么？ 能转换一道熟悉的题目？ 题目已知条件可以 改改吗？ 未知条件可以改改吗？ 需要引入其他辅助的元素？ 你用到所有的条件吗？ 用到所有的数据吗？
3. 执行计划。
执行方案，保证每一步都正确。你能证明每一步是正确的吗？如果不一样，可以是计划出错还是执行问题？
4. 检查和反思。
检查题目的正确性。 题目的每一步解答是否正确？ 结果是否容易验证？ 特殊情况（特殊值）是否也成立？ 一般情况是什么样子？
反思就是经验教训总结。题目是不是还有别的思路，别的解法，尝试看看。比较之间异同？ 哪一个更好一些？更直观简单不出错？
这个题目有什么结论，可以为以后利用上？ 这个题目的解答，分析，思路，有什么可以借鉴的？ 这个题目的解答是否还可以优化？ 是否可以替换掉冗余或者复杂的部分？ （这就是举一反三， 如果读书的时候可以做到这一点，或许就接近学霸啦:) ）
感觉Polya这个方案很容易推广到一般问题的解决框架。
1. 理解问题。
什么是问题？
问题就是实际和期望之间的差距。
了解什么是期望， 目标，需求？能具体吗？ 什么是现实情况？ 中间的差距是什么？ 有多大？
Beyond what you see。 了解问题的深层次原因。
问题不是凭空开的出来的。 问题是从哪里来的？为什么会有这个问题？ 问题对应的场景是什么？ 它的上下文是怎样？ 定性是什么？定量又有什么？
利益分析, 问题从谁哪里来的？ 问题没有解决谁会受益？ 或者受害？ 如果没有解决，谁会受害或者受益？
如果没有理解问题，就直接执行或者关注细节，如同没有看病没有诊断，直接开药。但是这一步往往会被不经意的忽略掉。
2. 制定计划。
寻找思路，制定规划。这个都是最关键的一部分，一个挑战。不同问题，其解不一样，很难有一个统一的思路。当然对于丰富多彩的世界，千奇百怪的问题，不可能有一个one-to-all 的银弹。对于这个时间点的自己，很难系统的给出一个方法了，或许是孜孜不倦的追求了。
总结自己常用的方法：
比如： 穷举与启发。 计算机中常用到的。穷举问题域所有可能肯定可以，但是耗时耗力成本高。启发可以快速解决，但是难度大。 比如家里东西不见，可以大扫除，一定容易找到；也可以根据判断再那里丢的，什么时候丢的？期间自己呆过那些地方？ 一般很大概率可以找到。
比如： 对比。 对于修理东西，不管软件硬件这个方法都可以尝试。 一个好的，一个坏的。 二者之间一个一个比对，局部替换，总归可以可以找到问题。 比如修机器，比如配置文件出错了。
比如： 类比。 对于类似的问题，类似的问题自己是如何解决的？ 某些属性是相似的，其他方面是不是也可以借鉴呢？
比如： 自治。 对于大问题，打碎。各个击破。 比如搭建一个环境。分块，分层解决。
比如： 抽象和特化。 对于问题的一般描述是什么？这个问题一般有什么思路? 对于这个问题的特殊情况，有什么借鉴的思路？
尝试，反证法，没有任何头绪，可以反问是什么阻滞，妨碍了问题的解决。
尝试，迭代。 每次做一部分，增量完成。
其他模式：
模式1： 散弹聚焦。迭代
模式2： 黑盒白盒灰盒子（对比，类比）
模式3： GIAF（Google is a Friend）
模式4： RTFM (Read the f*nk manual)
模式5： 咨询他人。 身边有经验的或这方面专家，或者社区寻找帮助。
对于一般那的技术问题，google is your friend 或者 read the f*uk manual，get info from community。 可以解决大多数的问题，或者得到思路。
3. 解决问题。
按照计划去执行。往往会有同计划不一样的地方？ 实际情况和期望的不一样？ 那么就应对这些变化？ 或者有风险，应对风险。 （怎么和PMP一样呢？）
读万卷书，行万里路。 没有实践压根不知道计划的好坏？ 就是在牛逼的理论没有检验，只是停留在口头。遗憾白搭。
4. 检查，经验教训总结。
对于问题本身是否解决了？ 么有解决，从新迭代一次。
解决了，经验总结，那些做的好？ 可以保留借鉴。 那些做的不好的？ 值得提高。
对于问题本身解决了，有哪些可以值得发扬广大，乘胜追击，扩大战果？ 那些可以优化？ 那些可以更好？ 二度定律（见到的规律都是另外一个定律的一种特殊情况）
对于解决问题的思路， 有什么可以借鉴的？ 有什么可以学习的？ 有什么和以前的不一样？
其实如同生活里面的走路。 去哪里？ 怎么走？ 走过去？ 如果走歪了走偏了，如何发现和纠正？
走完后，给下一次走路经验教训总结。
解决问题依赖的因素。
1. 态度和动力。
问题不能回避，否者同样的问题会出现。 根据自己的生活经验，这个我坚信。
2. 知识储备
巧妇不能无米之炊。比如没有计算机知识，去fix 一个bug？ 没有医学知识，去看病？
3. 心智
逻辑推理，如何提问，独立思考。
4. 个性
自信与坚韧。
对应无其不有的世界，这个方法对于不同的领域有着不同的变种，但是感觉有着某种类似：
比如1： 如何fix bug？
1. 重现问题。
2. 定位问题。
3. Fix bug。
4. 回归测试。
前两点就是理解问题，第三点就是制定计划，解决问题。 第四点就是经验教训总结。
比如2：如何PMP中的一般项目管理。
项目启动章程，计划（计划说明说3个基准），执行，监控（计划与实际比较，采取措施纠正），结束（经验教训总结）。
一切皆项目，这个也可以看做解决问题的一个一般框架。
项目章程对于理解问题； 项目的计划对应于解决问题的计划，这个同样也是难点； 执行与监控，这个与问题执行也一样的，PMP更将强调变化。 结束与反思，经验教训总结。
按照对于问题的定义，项目也是一个大问题。但是和问题解决思路是一样的。
比如3： IT中敏捷，scrum
Planing meeting1 ---需求的定义--->对应于理解问题----》对应于项目管理的章程
Planing meeting2---任务分解，估算时间，分配给具体的人-----》对于项目管理的计划阶段-----》解决问题
daily Meeting-------执行任务报告状态和风险管理---->项目管理的执行和监控
review meeting----- 对于执行的结果，是否满足需要----》项目产品的经验教训
retrospective meeting----对于执行的过程中的反思---》经验教训
迭代iterate -------对应于增量开发。
比如4：戴明环。
计划，执行，测量，处理
也就是定义问题、制定计划、执行、反馈处理==》再次迭代
比如5：胡适的“ 大胆假设，小心求证” ==》 对应计划和执行，迭代。
比如6： 自己最近自己解决的一个问题安装R环境：
比如7：最近公司软件质量问题。 开会说是bug比较多，但是么有 任何对于此问题的深刻理解，就直接给处方。忽略掉第一步。
应该怎么做？
软件质量有问题？ 具体是什么样的情况啊？
是用户不会使用？ 还是可用性比较差？ 还是实施没有实施好？ 还是用户业务有变化？ 是bug数量太多，support的速度跟不上？还是新feature，support 的知识没更新？
是测试覆盖率跟不上？ 还是测试时间不够？还是测试技能不够？ 还是测试对于用户如何使用软件不清楚？还是测试对于领域知识不够？ 还是build‘不稳定？
是开发的质量不好？历史原因，代码维护不太好？ team 之间沟通不够？ 还是技能不够？还是第三方依赖或者外部依赖不对？ 还是开发节奏太快，开发赶时间？ 还是开发流程太复杂？还是设计太难？
还是解决方案太差，没有抓住用户问题？
还是发布速度太快，其他方面没有跟的上而导致的？
还是大家的态度问题？是因为协作，沟通问题？还是对于产品不看好？激励不到位？
这些bug分类吗，2/8原则找到最主要的？
对于问题没有理解，期望找出好的办法，有针对性的办法？ 如果生病不去诊断，蒙着眼睛抓药。这样企图康复的概率有多大？
对于人生，也一样，如果没有目标？ 那一切也无从谈起.
标签：style get strong 文件 com cti
原文地址：http://www.cnblogs.com/zhyg6516/p/3710674.html
