抛开那些让人头大的理论，我来谈谈以结果为导向的过程管理
雨点向茉莉花微语道：“把我永久地留在你的心里吧。”茉莉花叹息了一声，落在地上了。
这是一个隐喻，有些时候会以为我们因为行色匆匆，后悔忘了享受当下的美景，有些时候因只顾欣赏当下的美景，却迷失了自己的路。大部分时候我们都认为以结果为导向太过于沉重。
我写这篇文的时候心里很是忐忑，仔细想来还是高估了自己的影响力，写篇文站在自己的视角来看一看这个世界还是可以的。自己想要的结果是30天完成写作，从更理性、系统化的角度来看待问题。想想也就释然了。
这两天和群里的人一起探讨关于研发代码质量管理的事情，QA说想引进一组游戏能体现当下，内建质量，让成员在回顾会上玩一下。过程是：周一抽查代码，各种不合规，开发说忙呀，临时有事啦，后续想抽空改忘啦。希望游戏能让他们反思~
那么问题来了，玩游戏让他们反思的结果是什么？为什么开了很多的回顾会现实是问题还没有解决呢？
什么是我们想要的结果？
假设站在QA的角度上，想要的结果是：开发的代码质量高一些，bug少一些，不要把问题都遗留到测试阶段，好的代码也有助于测试工作顺利开展。QA想要的结果会实现吗？
什么是代码质量？高一些是高多少？BUG为何产生，产生的来源是？少一些是少多少？
怎样量化我们想要的结果？
很多情况下我们想要的结果被赋予了很多的含义，就像我们以为看了一本书，尝试了一个新方法就能立即出结果一样，理智的我们认为不可能。
如何量化我们的结果有神器SMART原则
S即specific，代表具体的，指绩效考核要切中特定的工作指标，不能笼统；
M即measurable，代表可度量的，指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或者信息是可以获得的；
A即attainable，代表可实现的，指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标；
R即relevant，代表相关性，指实现此目标与其他目标的关联情况；
T即time－based，代表有时限，注重完成绩效指标的特定期限。
在不设限的情景下，我们如何实现我们的结果？
在设限的场景下我们会认为开发是在找借口，逃避进行代码修改。真的是这样的吗？
我们了解开发行为背后真正的动机吗？
我们了解开发的思维习惯和环境给他们带来的压力吗？
我们了解在压力情况下爬虫脑的应急机制是逃跑而不是勇敢的去面对吗？
开发是否意识到环境已经发生变化了，可以静下心来修炼自己的代码功力了？
此时DISC（行为风格），HBDI（思维优势），OKR开始登上了舞台。
具体内容接下来的28天里详细拆解这些内容。
来看看我们的架构师是如何做的。
最可贵的一点是他能站在客观的角度去看待开发人员的水平和现实因素。
告诉你什么是正例，什么是反例，为什么你掉进了坑，怎样在短时间内爬出来。
他做的是让程序员改变行为习惯，知道如何去修炼，怎样修炼能写出好的代码来。
总结：
这是个不能着急想要结果但是又需要关注结果的过程。给团队一些时间，明确想要的结果，量化结果，不设限的去实现它。
