- 读《50 Models for Strategic Thinking》系列分享之二
这本小册子是在去年6月份达拉斯机场转机时购买的，内容本不多，是由50个简要介绍的小方法构成，中间偶尔翻了翻，综是未完成，直到上个月，在连续几次的出差途中，利用飞机上的闲暇时光阅读完毕。颇有些收获，想着还是要总结一下的。
这些从各处搜集来的50个小方法被作者分成四大类别：怎样提升自己、怎样更好地理解自己、怎样帮助他人改进、怎样更好地理解他人。
读书就是这样，同一本书，不同的人阅读、甚而不同的时间阅读，感悟和启发总是不同的。我就通过一个系列的短文分享自己在当下感悟比较多的点吧。由于内容比较多，一次只分享一个点。
今天分享的方法是：TheJohn Whitmore Model
往期分享：（1）项目组合矩阵（The Project Portfolio Matrix）。
方法介绍
如果您不确定当前追求的目标是否正确，可以借鉴下JohnWhitmore Model。
一个好的目标是SMART、PURE、CLEAR的！如果您的目标是unattainable的，那么实现的期望就不大，应该及时修正目标；如果您的目标不是Challenging的，那么就缺乏实现的动力。。。
当然，如果觉得这14条太繁琐，完全可以简化地使用，当制定目标时只要记住一条最基本的：KISS- Keep It Simple, Stupid!
Everything should be made as simple as possible. But no simpler.
- Albert Einstein
另外，还要注意的是，目标分为长期目标（the final goal）和短期目标（the performance goal）。比如，长期目标是“我要三个月内减肥10斤”，短期目标可以是“每天慢跑1小时”之类的。
我的启发
The Final Goal和The Performance Goal给我不小的启发。
我最近辅导的一个测试团队，当我询问基层的tester们，他们的测试目标是什么？他们都不清楚。只知道在给定的时间内，做完他们凭经验能够想到的测试，就OK了，至于说测试还要有个什么目标，却没有考虑过。当然，这并不代表测试目标这个东西就完全不存在，实际上，在具体测试的时候，每个tester的心中都有自己默认设定的、比较模糊的目标，指引着他们的测试行为。比如，他们可能发现了一个可用性方面的bug，但却选择了忽略它，原因可能是“我现在只负责功能性测试，可用性测试暂且不用考虑”，至于什么时候考虑可用性的bug，就是管理者的事情了。
测试目标的缺失也导致一个产品或一个特性的测试缺乏整体的bigpicture。每个人都很忙，反正测试时间有限得很，只要把我眼前能想到的测试尽可能都做了，就算完成任务了，至于从大的方面都要考虑哪些方面的测试、哪些重要的测试还没有做、哪些测试应该是由我们这个团队负责哪些应该是其他测试团队负责、目前产品的质量状况如何、距离我们的质量目标还差多远等等，就无人问津了，基本上也没有人能说的清楚。
最终的测试目标（TheFinal Testing Goal）是与产品的质量目标紧密相连的，不清楚测试目标，也就意味着不清楚所测试产品的整体质量目标（QualityTarget）。管理者应该设定明确的QualityTarget，并且在所有成员中达成共识。在《FiftyQuick Ideas to Improve Your Tests》一书中，作者介绍了一个“质量目标金字塔”的概念。
质量目标金字塔是借鉴自Maslow人的需求层次的模型，从最底层的基本生活必需、到最顶层的人的自我实现，质量目标也可以分为5个层次，自底向上依次是：
软件可以正常运行吧？（Is it functional？）
软件运行得好吧？（性能、安全等方面）
软件好用吧？（可用性）
这是个有用的软件吧？（来自生产的数据确实可以证明软件是有价值的）
软件是成功的吧？（来自业务的数据显示软件的商业成功性）
Quality Target和Final Testing Goal一旦确定好了，机会可以着手制定每个阶段的具体的测试目标。书中也给出了一个可行的建议：每到一个项目的里程碑点，来自Cross-Functionalteam的各个代表（开发、测试、业务、以及各Stakeholders）就聚在一起，试着画一个“质量目标金字塔”，每个人用便签纸写下对这款软件产品各个层次质量方面的期望，贴在金字塔相应的层次上，然后大家展开讨论，细化甚至量化这些期望。比如有的人写了“人们可以快速地创建文档”放到第三个层次上，大家就可以一起讨论“有多快”。注意这个办法是用来帮助设定更明确的质量目标或测试目标的，不是帮助设计测试实例的，所以不要讨论过细。
