精华内容
下载资源
问答
  • OKR与CFR管理模式(一)-什么是OKR?

    千次阅读 2019-05-19 11:43:22
    读前预 无论任何管理书籍,都是围绕着人性,如果激发员工的人性中... “好主意”再加上”卓越的执行”,就一定可以创造奇迹,而这正是OKR(目标与关键结果,Objectives and Key Results)管理模式的奥妙所在,它可...

    前言

           无论任何管理书籍,都是围绕着人性,如何激发员工的人性中的自尊和自我价值观、自我成就感,作为一名领导者,在管理面前,必须要是冷静,安静的对待他人

           “好主意”再加上”卓越的执行”,就一定可以创造奇迹,而这正是OKR(目标与关键结果,Objectives and Key Results)管理模式的奥妙所在,它可以让好的想法得以实现。

           我们会把所期望达到的关键结果描绘成清晰的蓝图,然后分解成可以逐步实施的计划。

           OKR可以让企业内部的很多事情变得可视化,OKR也可以作为逆向思考问题的有效方法,例如:为什么用户留存率不断的在降低?还有比这个问题更重要的吗?

           OKR让谷歌公司实现10倍速的增长,OKR让谷歌公司总是能够把时间和经理聚焦在最重要的任务之上。

     

    为什么要管理?

           看很多管理的书籍,看了很多内容,但是我们似乎在书中无法看到为什么要管理?

           企业为什么要管理?项目为什么要管理?产品为什么要管理?......骤然之间无数的为什么会涌现在脑海。

           一件事的最终执行者始终是人,管理自然是对人进行管理,为什么要对人进行管理呢?

           首先要明确一个思想就是,员工怕的不是管理者本人,而是企业的治理框架中的制度,和其中授予管理者的权利,可以理解为绩效评分权利。

           既然有制度了,也让员工知道要怎么做了,为什么还要进行管理呢?

           问题在于趋利避害的天性,即人性。所以管理就是管理人性,人性是趋利避害的,如在分配任务时,员工自然希望任务的完成时间越长越好,这就意味着企业的成本增加了......

           管理者就是要对人的人性进行引导,让其按照管理者的意愿作出预期期望的行为。

           建阅:https://blog.csdn.net/Su_Levi_Wei/article/details/103546984

     

    什么是管理?

           在英特尔,你知道什么几乎完全不重要,如何对待你知道的,能学到的及已有业绩才是英特尔所看重的(态度决定得到的知识)。- 安迪格鲁夫

     

           管理这件工作必然是由管理者来做的,而无论这个管理者在组织所处的位置是高还是低,是无关的,毕竟都面临着同一个问题,就是拍对上面的马屁,讨好下面的团队成员,这就对管理者的情商要求比较高。

           管理就是平衡,平衡好领导的需求,协调好团队成员的行为一致性,同时还需要扮演多种角色。在事的面前要扮演管理者,按照企业制度流程办事;在人的面前要扮演好领导者,支持、培养人员,突破挑战;在投资的面前要扮演好整合者,突出自身的大局观和平衡力。

           并且留住员工和提升员工敬业度是作为企业领导者第二关心的问题,其重要性仅次于如何迎接构建全球领导力的挑战。

     

    企业指导框架

    企业指导方向

    管理层面

    实施

    生活例子

    愿景

    方向层面

    为什么去做?

    净化地球,降低污染

    使命

    思想层面

    做什么来实现愿景

    降低PMI

    战略和目标

    指导层面

    指定目标,目标为导向,表明企业存在的意义

    制造性价比高的无污染汽车

    【战略:制造无污染汽车(方向),性价比高(目标)】

    战术

    执行-指导层面

    实现目标,收益为导向

    研发电池技术,获得专利,进而寻找汽车品牌建立战略联营关系

    策略

    交付-指导层面

    产生收益的工具,即可交付成果

    寻求母校科研所的帮助,招募应届研究生。

    业务管理

    项目管理

    执行-交付层面

    具体执行者

    运营、销售管理         

    技术、建厂项目

     

     

    什么是OKR?

           如果你不知道目的地在哪里,你可能永远无法到达。 - 尤吉贝拉

     

           OKR是目标与关键结果法(Objectives And Key Results - OKR),是由企业、团队和个人协同制定目标的方法。

           OKR是确保将整个组织的力量都即将于完成对所有人都同样重要的事项的一套管理方法、套路。

    OKR并不是万能的,它不能替代正确的判断、强有力的领导和创造性的企业文化,是确保将整个组织的力量都即将于完成对所有人都同样重要的事项的一套管理方法。体现的是企业最主要的目标,能引导员工共同努力和协作,将不同的业务联系在一起,为整个组织提供明确的目标和凝聚力。

           目标就是你想要实现的东西,不要将其夸大或缩小,目标应该是重要、具体,具有行动导向并且是鼓舞人心的,如果设计合理并实施得当,能够有效的防止思维和执行过程中出现的模糊不清的情况。

           关键结果是检查和监控如何达到目标的标准,有效的关键结果应该是具体有时限,具有挑战性的,必须是可衡量的、可验证的、可实现的。

           如果没有具体数字可以衡量这些结果,那么它就不能算是一个关键结果,在随着工作的进展而对关键结果进行相应调整,一旦关键结果全部完成了,目标实现就是水到渠成,如果目标没有实现,那说明最初OKR的设计可能存在问题。

           OKR是一种弹性的、数据驱动的方法,适用于自由的、崇尚数据的企业,OKR系统将目标与团队更宏大的使命结合在一起,目标能够激励员工并提高业绩,只有目标明确才能实现目标,而且目标和关键结果会推动目标的清晰化、责任制化及卓越的不懈追求。

     

    设定目标

           如果你不知道目的地在哪里,你可能永远无法到达。 - 尤吉贝拉

    过度的追求目标的破坏性,福特平托汽车油箱的爆炸,西尔斯中心汽车维修的漫天要价,安然公司疯狂膨胀的销售目标……  《哈佛商学院 - 疯狂的目标》

     

           组织在设定目标时,要格外的小心,目标就像是一种需要谨慎使用和严密监管的处方药,由于聚焦过度、出现不道德的行为、冒险行为增多,以及合作意愿和工作积极性下降等原因,目标会在组织内部引发系统性问题,目标设计的坏处可能会抵消其所带来的好处。

           困难的目标往往比简单目标更能有效的提升绩效,其次具体、困难的目标往往比含糊其辞的目标带来更高的产出。

    如有人评价某些德国企业的效率低下,但其效率低下的专注及清晰的沟通抵消了其效率。

           OKR的实施效果可能很好,也可能很差,初创企业通常在业务增长和目标达成之间挣扎,进而想法很容易,执行最重要,明确的、具有挑战性的目标,确实能够提升生成效率的。

           目标设定并不是万无一失的,如果目标的优先级有冲突,不明确、毫无意义或被随意改变,那么员工就会变得沮丧、愤世嫉俗,并失去动力(回想一些类似的经历的过事)。

           没有哪一个因素比明确定义的、被记录下来的,且能够自由分享的目标更重要了,目标可以确保一致性、清晰性、并提升工作满意度。

           OKR是鼓励有益的失败的,OKR的关键成功要素是信念和高层以身作则的支持,谷歌创始人拉里和谢尔盖最初使用OKR时,也会固执己见,甚至有所抵触

           采用OKR的企业:美国在线、领英、甲骨文、推特、谷歌、宝马、三星、迪士尼、埃克森等…

           初创企业,结构化的目标可以给投资人提供一个衡量成功的标准,如在计划生产某款产品,并通过跟25位客户沟通进一步明确了目标市场,同时也调研了他们愿意支付的价格。

           中等规模和快速扩展的组织,OKR明确了预期,需要(尽快)做什么,以及具体谁来执行,OKR让员工垂直目标和水平目标能够保持一致。

           大型企业,OKR能够在不同部门的员工之间建立联系,赋予一线员工特定的自主权,让他们能够提出新的解决方案。

           OKR的实践需要严谨、投入、清晰的思维和积极的沟通,我们不止是做一些列表,然后检查两遍,而是在锻炼能力和设定目标。

     

    当谷歌遇见了OKR

           我把今年的失败看做明年再次尝试的机会。 - 戈登摩根

     

           在成立不到一年的时间里,谷歌就明确了它的使命:”整合全球信息,使人人皆可以访问并从中获益”。

           谷歌早期谢盖尔打造基于技术的商业模式,拉里则努力研发产品,作为市场的第十八个搜索引擎,放弃了先发制人的优势通常是致命的,尤其是在技术竞争领域。

           由于谷歌公司的高风险偏好,创始人必须要学会做出艰难的选择,他们要放弃对失败者的投入,需要及时、相关的数据,一遍追踪项目进展,衡量真正重要的结果,快速结束那些失败的项目。

           在谷歌内部,员工能够浏览和了解其他团队是如何衡量OKR的成败的,也可以追踪自己的工作是如何与他人工作联系在一起,即如何融入企业的整体战略

           每年各个团队和产品部门都会制定未来一年的计划,并将其凝练成OKR,并对上一年的OKR进行评分,进而找到那些没有达标的部分。

     

    OKR的四大利器

    对优先事项的聚焦和承诺

           高效的组织应该聚焦重要的工作,同时清楚什么是不重要的,领导层面临艰难抉择时,,OKR可推动其作出选择,对于部门、团队,和个人来说,OKR是一种精准的沟通的工具,能够消除疑惑,让我们进一步明确目标,聚焦到关键的成功要素上。

     

    团队工作的协同和联系

           OKR具有透明性,上自首席执行官,下至一般员工,每个人的目标都是公开的。每个员工都将个人目标和公司目标计划紧密的联系起来,进而明确两者之间的依赖关系,并与其他团队展开通力协作,这种自上而下的协同,将个人贡献和组织成功联系起来,为工作赋予了特定的意义,自上而下的OKR,则通过加深员工的主人翁意识,促进了个人的参与和创新。

     

    责任追踪

           OKR是由数据驱动的,定期检查、目标评分和持续的重新评估可以让OKR充满生机,所以这一切都是基于客观、负责的精神。危险的关键结果会引发某些行动,应使其回到正轨,或者在必要时,对其进行修正或替换。

     

    充分延展进而调整不可能

           OKR激励我们不断超越之前设定的各种可能,甚至超出我们的想象力。通过调整极限和允许失败,OKR能够促使我们释放出最具创造力和雄心的自我。

     

    小结

           OKR是对人性枷锁的引导,让鲨鱼带领你前进。KPI是一对人性的枷锁,如同一头鲨鱼在背后追着你。

           OKR是系统化的,可失败的、可调整的。OKR是单一的,不可失败的。

     

    OKR之父

           尽管很多人都很努力的工作,但他们却没有取得什么成就。 - 安迪格鲁夫

           结果是明确的、分层次的。有让发出命令,有让则接收和执行命令。 - 安迪格鲁夫

     

           安迪格鲁夫是匈利亚难民,而且听力还严重受损过,个子不高,凭借顽强的毅力和过人的智慧,充分发挥个人能力和责任感的管理原则,同时树立共同的愿景和努力方向,建立团队合作精神,协调个人和共同目标的和谐一致,一举成功硅谷顶级公司的最高领导层。

           安迪·格鲁夫从来都毫不掩饰对德鲁克的崇拜之情。彼得·德鲁克是我心中的英雄。他的著作和思想如此清晰有力,在那些狂热追求时髦思想的管理学术人群中独树一帜

    彼得德鲁克发现了人性的一个基本特点,即当人们为行动路线的选择做出贡献时,就更希望看到它顺利的实现。(人性的自尊和自我成就感)

           当企业将注意力专注在少数几件优先事项上,取得的结果相当令人震撼。有效的实施目标管理可以将生产率提高56%,反之则只能提高6%。

           在许多企业的内部,目标是通过顶层规划后,在层层缓慢的传达下来的,而在一些企业,由于缺少经常性的更新,目标长期不变,而在一些企业中,由于退化为关键绩效目标(KPI),最终成为没有灵魂或意义上的数字。

    最可怕的是,目标管理经常会同员工的工资和奖金挂钩,如果冒险可能受到处罚,员工为什么还要冒险呢?(人性都是趋利避害),目标管理不过是另一个工具而已,而并非治理效率低下的良方。

    公司应该建立在对员工的信任和尊重的基础上,而不仅仅是振作获得利润的机器,要促使员工做到督促公司针对目标征询员工的意见。 - 彼得德鲁克

     

    量化产出

           产出的提高是生产力提高的关键,而努力增加生产活动的结果可能会适得其反,甚至会步入流动性陷阱。

     

    MBO(Management by objectives,即目标管理法)和OKR的比较

    MBO

    OKR

    目标是什么

    目标是什么及如何实现

    年度

    季度和月度

    不公开和透明

    公开和透明

    自上而下

    自下而上或团队协商

    与薪酬福利挂钩

    大部分与薪酬福利无关

    规避风险

    进取精神

     

           如果我们连首席执行官的目标也可以看到,这种方式很具有启发性,就像聚焦的灯塔,本身也在发挥着作用,让人们和首席执行官一起在一条线上跑。

           优先事项在OKR上列的清清楚楚,团队成员一眼看到,OKR总是在提醒团队需要做些什么,明白无误的告诉我们做到什么,没做到什么。

           安迪格鲁夫认为解决管理问题最好的办法就是,以创造性的思维去面对问题,坦诚、直接、不带歉意的去面对他人。

           其中要想得到格鲁夫的尊重,就得提出自己的见解,坚持自己的立场,然后努力的去执行。

     

    营造健康的OKR文化

           健康的OKR文化的本质是绝对诚实,摒弃个人利益和忠于团队,这也是格鲁夫思想的核心,不过,整个OKR系统成功的前提,是格鲁夫对基本要素的关注。

     

    少即是多

           格鲁夫写道,这些精心选定的目标传递出一个明确的信号,它告诉我们要做什么和不做说明,每个周期最多只需要制定3到5个OKR,就能够版主公司、团队和个人明确什么是最重要的,一般而言,每个目标都应该与5个或更少的关键结果相对应,即对优先事项的聚焦。

     

    自下而上的设定目标

    为了促进员工的参与,应该鼓励团队和个人与管理人员进行协商,通过这种方式指定的OKR,应该都占到各自OKR的一半左右,如果所有目标都是自上而下制定的,那么员工的工作动机就会受挫,因此团队的协同和联系就非常的重要了。

     

    共同参与

    OKR皆在通过协作确定优先事项,并规定如何衡量进展情况,即使在公司目标已经确定下,关键结果依然还是可以商讨和调整的,集体达成一致,对最大限度实现目标来讲是至关重要,所以团队的沟通是非常重要。

     

    保持灵活

           如果大环境发生了变化,既定目标看起来不切实际或难以实现,则可以在执行期间修改甚至放弃某些关键结果,对于对应关键结果的责任的追踪就很重要了,不然他人还在为这个关键结果而努力,这可不是什么好事。

     

    敢于失败

           格里夫写道,如果每个人都把目标定得比自己轻而易举就能完成的目标高一些,那么结果往往会更好,如果你想要自己和下属都有最佳的表现,那么这样的目标制定方式是非常重要的,某些操作性的目标必须要全部实现,但激励性OKR会让人倍感压力,甚至会让人觉得可能无法实现,格里夫将这种目标称为挑战性目标,它能够将组织推向新的高度。

     

    OKR是工具,并非武器

           OKR系统就好比给你一块秒表,让你随时诊断自己的表现,它不是一份基于绩效评估的法律文本,为了鼓励员工承担风险,防止消极参与,最好将OKR和奖金激励分离开来,而OKR结合CFR(对话(Conversation)、反馈(Feedback)、认可(Recognation))则是可以评估员工的绩效。

     

    耐心、坚定

           每个过程需要反复试验,格里夫曾经说,英特尔在采用OKR之后犯了很多错误,我们并没有完全的理解OKR的主要目的,但随着时间的推移,我们将它运用的越来越好。

           一个组织可能需要4到5个季度才能完全适应这个系统,而往往构建成熟的目标则需要更长的时间。

     

    小结

           OKR并非是与金钱挂钩的,是以人性的自尊、成就感、自我价值的体现为基础而构建,以此触发人的行动。

     

    英特尔的粉碎行动

           我们终将实现目标,而目标的实现可以由关键结果来衡量。 - 比尔达维多

          

           英特尔采用OKR的方法,规定具体的时间期限,而且把做什么,如何做都描述得十分清楚,总是把需要特别强调的事情写下来,并铭记于心。

           OKR使英特尔公司能够以更清晰、精准且闪电般的速度执行其作战计划,在这场战役中英特尔改进了营销策略,发挥了英特尔公司的优势,他们引导客户明白,相较于短期的实用性而言,长效的系统和服务更具有价值,他们不再向程序员推销产品,而是开始将目标转为客户企业的首席执行官。

           当处在高层管理职位的时候,更多的是在教学,在这场战役中英特尔部门经理,将公司所有关键结果作为其目标。

           目标是一种建立紧迫感,并启动关键决策和行动计划,以应对威胁生命的竞争挑战。

     

    英特尔公司的目标

    使8086成为性能最好的16位微处理器系统,衡量方法如下。

    关键结果(1980年第二季度)

    1.开发并发布5个基准,显示8086系列的性能(应用开发部)。

    2.重新包装整个8086系列产品(市场营销部)。

    3.将8MHz部件投入生产(工程部、制造部)。

    4.最迟6月15日,对数学协处理器进行采样(工程部)。

     

    工程部门的目标(1980年第二季度)

    5月30日前,向CGW公司交付500个8MHz8086部件。

    关键结果

    1.4月5日前完成成像照片。

    2.4月9日前向芯片制造厂交付2.3版本。

    3.5月15日前完成磁带测试。

    4.最迟5月1日芯片制造厂开始制造产品样品

     

           可以看到,英特尔公司的企业目标和部门目标紧紧相连,并且各个部门之间知道各自的关联性,也知道别人什么时候需要什么资源。部门之间不再甩锅,而是去找企业高层索取资源以支持他人。

    安迪告诉其他人必须要做的事情,以及要这样做的原因。直到这些事项完成之前,其他人都该视为优先事项。

     

    转瞬之间

           在面临危机时,企业需要一个可以快速推动的系统。很多内容都必须自下而上的汇集,你可以去告诉人们清理一个烂摊子,但你是否需要告诉他们应该使用哪把扫把呢?

           在英特尔高层强调,我们必须要压制住摩托罗拉时,基层员工可能会说,我们的基准程序很糟糕,我想我会写一些更好的基准程序。OKR是找到原因更好的完成,因此是允许失败的,但失败是要有意义的失败。

     

    更高的目标

           安迪格鲁夫希望员工可以让管理层关注可能存在的问题,这时企业的透明性是特别的重要,员工可以表达自己的观点,而不担心被受处罚,如果没有这种文化,粉碎行动也就不会成功了吧。

     

    小结

           开放性的企业文化,是自下而上的,信息更真实,而且对企业的战略调整具有重大的意义。在失去优势时,就寻找别的途径,他人需要的是什么,怎么样才能让他人的这种需要是一种更好的满足。

     

    对优先事件的聚焦和承诺

           是我们自己选择而不是能力,展示了我们是谁。 - J.K 罗琳

     

           成功的组织聚焦于少数能够产生实际性差异的举措,并推迟那些不怎么紧迫的事项,而高层管理则在言行中对这些选择做出承诺,坚定不移的维护最高层的OKR,并给团队提供方向和评价基准。

    非决定性或草率放弃的决策,对企业毫无价值,企业在未来一段时间的优先事项是什么?人们应该在哪些方面集中精力?

           一套有效的目标设定系统始于组织高层的严谨思考,领导者需要投入时间和精力去选择重要的事情。

    通过选择一套OKR,可以突出强调一些事情,这些重要的事情必须按照计划和时间来完成。

     

    开始的时候

           企业发展的动力来自于创始人和其执行团队,所以企业层面的OKR,责任在于高层领导者,他们必须亲自对这一过程做出承诺,通过OKR明确了自己的聚焦点和承诺。

           最强大和最活跃的OKR往往源于一线员工,当公司把员工的工作上升到公司层面的OKR时,就意味着员工在工作成为了公司的优先事项,并使得他人获得成就感。

    OKR需要领导者在言行上做出公开承诺才能实现,如果领导者不以身作则,就没有人真正在意这一目标。

     

    清晰沟通

    员工不仅需要通过里程碑式的成功来获得动力,他们还渴望理解辛勤工作的意义,同时了解自己的目标和公司使命之间的关联。

    领导者必须要说清楚为什么做某件事,以及怎样做。当你不厌其烦的多次强调时,团队成员可能才真正听你讲话。

     

    关键结果:关心和支持

           目标和关键结果是目标设定的阴阳两面,即原则和实践、愿景和执行,目标往往是鼓舞人心且与长远计划是有关系的,而关键结果往往是更接地气且是可衡量的,是拉动目标实现的杠杆和实现目标过程中的一个个节点。

           如果目标太多,往往会淡化焦点,对预期的进展形成障碍,如果有足够的信心能够做好这件事,那么你设立的目标很可能还不够宏大(谷歌的10倍速增长就是不断的突破自我)。

     

    做什么、如何做和何时做

           短期的OKR来支持年度OKR的实现,也有长期的战略规划,而年度OKR是依据实际情况制定的,并确保这一计划是可以实施的。

    明确时间框架可以进一步突出工作的焦点和承诺,没有任何东西能够像截止日那样推动人们前进。

    因此使用OKR系统应该在相对较短的时间内设定目标,例如,我们每年做一次计划,相应的OKR设置应该以季度或月度为时间单位,要使反馈有效就必须在评估活动发生后立即给予反馈。

           OKR的时间设定是没有统一标准的,例如工程团队可能倾向于6个星期为一个OKR周期,以便于保存产品的开发进度同步。

           相对而言,一个月的周期则可能适合于,那些新创立的,正在寻找市场定位的企业,最好的OKR节奏,往往是与企业所处的行业及企业的文化节奏相适应。

     

    匹配关键结果

           致命的缺陷:尽管特定的,具有挑战性的目标可以得到满足(市场进入的速度、成本),但却以牺牲其他重要功能(如汽车的安全性)为代价。

           OKR越野心勃勃,其忽视的重要标准的风险也就越大,为了保证质量并推动量化的可交付结果,则是将关键结果进行匹配,用以衡量效应与反效应,当关键结果聚焦于产出时,相匹配的关键结果应该强调工作质量。

     

    数量和质量匹配的关键结果:

    数量目标

    质量目标

    结果

    3个新功能

    在质量保证测试中每个功能必须少于5个缺陷

    开发者要编写更为清晰的代码

    第一季度销售额达到5000万美元

    第一季度维护合同额度达到1000万美元

    专业销售人员持续不断的关注,会增加销售量及顾客满意度

    10笔订单

    2笔新订单

    为了满足新订单的阈值要求,提升前期质量

     

    完美与优秀

    OKR就是正在进行的工作,它不是一成不变的,在OKR周期中的任何时间点,都可以修改甚至完全抛弃之前的设定,不要让完美成为敌人。

           目标设定也有一些基本的规则,关键结果应该是明确的,具体的,可衡量的,产出和投入的组合(匹配)对其有所帮助的,最后完成所有关键结果的关键和前提是实现目标,如果目标都没有实现那就不是OKR了(目标的实现,是指完成度)。

     

    OKR质量评估表:

    较差

    中等

    较好

    目标:赢得Indy 500赛车比赛。

    关键结果:提高圈速

    关键结果:停站时间缩短

    目标:赢得Indy 500赛车比赛。

    关键结果:平均圈速增长2%

    关键结果:停站时间缩短1秒

    目标:赢得Indy 500赛车比赛。

    关键结果:平均圈速增长2%

    关键结果:在风洞测试10次

    关键结果:停站时间缩短1秒

    关键结果:停站错误减少50%

    关键结果:每天练习停站1小时

    模糊不清

    稍微清晰

    具体执行方案

     

    少即是多

           季度OKR的理想数量往往介于3到5个之间,设立很多目标,可能会很诱人,但这通常是错误的。

    在设置太多的OKR时,试图完成的事情太多了,而且事情的优先级也不够明确,所以我们要减少OKR,以确保这些都是我们需要的。

    管理的艺术在于能够从看似同样重要中选择一个,两个或三个能充分发挥杠杆作用并能让你专注于此的活动。每次做出承诺时,就失去了投身其他事项的机会,关注所有事项和一件都不关注的结果是一样的。

           最大化的利用现有资源,集中精力去打造顶级产品的组织。

     

    小结

           一线人员为什么要按照这个去执行呢?凭什么?

    做什么?如何做、何时做?

           目标,过程清晰、过程的时间点。

     

    Remind的故事

           Remind创始人对技术一无所知,也不了解产品的开发或运营,创始人戴维把自己关在屋里自学编程,布雷特在推特采访200名教师,实际回复有250名,老师想要的更少的工作量,而不是更多潜在的麻烦。

           Remind用更多的数据来支持决策,以小窥大、言简意赅、把握重点,辨别无关紧要的东西。Remind教育通信是使教师、学生和家长能够在安全、可靠的环境中进行沟通,对于选择正确的目标来说,聚焦是至关重要的,这对区分OKR的优劣也是至关重要的。

     

    成长目标

           你一生只能做好一件大事,所以你最好知道那件大事到底是什么。

     

    目标

    支持公司招聘

    关键结果

    1.招聘1名财务和运营总监(与至少3名候选人交谈)

     2.招聘1名产品营销经理(本季度与5位候选人会面)。

    3.招聘1名产品经理(本季度与5位候选人会面)。

     

           把所有事项记录下来,知道团队内的其他人正在做什么,毕竟员工需要了解首席执行官首要目标是什么,自己如何才能与之共同努力以达到最好效果,如果没有新的目标设定纪律和聚焦点,我们可能无法坚持我们的立场。

           创始人可以公开的表达自己的进步和失败,他们想要知道,犯错误、纠正错误并继续前进是公司所允许的,不能够害怕犯错,否则会抑制创新。

     

    小结

           目标是量力而行的,可以设定认为可以实现的目标的10倍,但不要设定100倍。

           机会是人创造的,一心二用会失去机会,聚焦于重要的事情。

     

    Nuna医疗科技的故事

           Nuna的第一年是连一笔订单都没有拿到,Nuna创始人的总结是对客户了解并不充分。Nuna是经历了两年多的被拒、挫败,以及数不胜数的应酬。

           为了让结构化的目标设定盛行起来,首先需要管理层全身心的投入,让管理层以身作则,可能需要花上1到2个季度的时间客服来自管理层的阻力,并让他们适应OKR,而不再是将其当成魔鬼,避之唯恐不及或敷衍了事,而是将其作为完成公司优先事项的使用工具。

           除了聚焦,承诺也是OKR第一个力气中的核心元素,在实施OKR时,管理则必须公开对其目标作出承诺,并一以贯之。持续的向整个公司或团队阐明工作的优先事项,需要对各自的OKR表现出持续不变的承诺。

           在扩大Nuna医疗科技公司的规模时,Nuna管理层比以往任何时候都更加的需要聚焦和做出承诺。

           OKR还属于某种激励的时候,仍不能指望员工会直接跟进,目标越具有挑战,就越有可能给抛弃。毕竟人们习惯了公司老板制定目标,然后跟着目标走,如果船长在暴风雨中弃船了,就不能指望水手们会将船开进港湾。

           为了激发出真正的承诺,领导者必须身体力行,为他人做出示范。员工可以批评领导者的OKR,告诉领导者如何提升和改进,这一点意义非凡。

     

    目标

    打造世界级的团队

    关键结果

    1.招聘10工程师[ 0.8 评分 ]。

     2.招聘销售主管 [ 1.0评分]。

    3.即使Nuna没有给其发放录用通知,也要让所有应聘者感受到Nuna的组织有方和专业性[ 0.5评分]。

           Nuna对OKR的承诺是公开透明的,整个团队都需要更为清晰的聚焦点及更为明确的优先事项,这是深化承诺的先决条件。

           你不会在第一次推行OKR时就把这件事做好,第二次、第三次也不会做到十分完美,但是不要气馁,继续坚持下去,不要改变、适应,知道找到属于自己的方式,承诺是自我强化的。

     

    小结

           员工是渴望与高层站在同一条线去做同一件事的,进而获得成就感与自我价值的体现,这也是公开透明高层承诺的重要性。

     

    团队工作的协同和联系

           不要雇佣聪明人,然后告诉他们去做什么,而是要让他们告诉我们,应该做什么。 - 史蒂夫乔布斯

     

           在互联网企业,透明性已经成为组织日常运营的默认设置,然后对于大部分企业而言,这个默认设置却是变得默认忽略这个设置,其企业目标仍然属于不可公开的秘密,与隐秘性相比,组织中公开的目标往往更容易实现。

           如果同事能够看到他们的进度,他们会更有达成目标的动力。最快升职的人,是集中精力做公司最重要的事情的人。

    假如销售人员不喜欢最新的营销计划,他们不用私下抱怨,可以直接将自己的看法公之于众,OKR让目标变得更加客观,而不是非黑即白。

           其他人可以在这名名员工需要帮助的时候介入,发表评论并提供支持,从而大大提高他的工作效率,与此同时,员工之间的关系也进一步加深,甚至会发生微妙的积极转化。

           通过清除每个人的目标之间不可见的障碍,OKR系统将重复多余的任务暴露出来,从而为组织节省大量的时间和金钱。

     

    保持协同

           最高目标一旦成功设定,真正的工作就开始了,目标从计划转为执行时,管理者和员工都必须将自己每天的工作与组织的愿景联系起来,这种联系的专业术语就是协同。

           目前协同在组织中是稀缺,有研究表明,只有7%的人完全理解公司的经营战略,以及企业为了实现共同目标期待他们做什么。

           缺乏协同是战略制定与执行之间的头号障碍,协同的答案在于聚焦、透明的OKR。OKR将每个人的工作与团队工作、部门项目及整体的组织使命联系起来。

           人类天然的充满好奇,也人类渴望彼此之间建立起联系,我们对领导者在做什么及我们的工作如何与之相融,天然的充满 好奇,OKR则是实现纵向协同的首选工具。

     

    伟大的层级与关联

    总经理的OKR:

    目标

    为股东赚钱

    关键结果

    1.赢得超级碗(美国职业橄榄球大联盟年度冠军赛)的胜利。

     2.主场上座率达到90%。

    作为总经理,将自己的目标与直接下属的目标进行关联,总经理的关键结果成为了他们的目标。

     

    教练的OKR(总经理的直接下属)

    目标

    赢得超级碗的胜利

    关键结果

    1.每场比赛传球进攻300码以上。

     2.每场比赛防守丢分少于17分。

    3.特勤组弃踢回攻补位排名前三。

     

    进攻教练的OKR(教练的直接下属)

    目标

    每场产生300码以上传球进攻

    关键结果

    1.达到65%的传球完成率。

     2.将每场比赛拦截次数减少到1次以内。

    3.聘请一位新的四分卫教练。

     

    防守教练的OKR(教练的直接下属)

    目标

    每场丢分少于17分

    关键结果

    1.每场比赛少于100码冲球。

     2.每次比赛禽杀次数增加到3次以上。

    3.培养一个职业赛角位。

     

    特勤教练的OKR(教练的直接下属)

    目标

    弃踢补位团队晋升前三

    关键结果

    1.每次弃踢回攻少于10码。

     2.整个赛季阻止弃球4次。

     

    高级营销副总裁的OKR(总经理的直接下属)

    目标

    主场上座率达到90%

    关键结果(不清晰的关键结果,进而影响到他人)

    1.提升团队品牌形象。(慈善方式还是什么方式?,没有明确的方向)

    2.提高媒体曝光率。(电视、互联网、杂志、报纸?)

    3.重启场内推广计划。

     

    市场总监(高级营销副总裁的直接下属)

    目标

    提升团队品牌形象。

    关键结果

    1.为新的营销活动瞄定两个优秀选手。

    2.创建一个更有说服力的团队口号。

     

    公共人员(高级营销副总裁的直接下属)

    目标

    提高媒体的曝光率

    关键结果

    1.安排每个球员每赛季参加两次慈善活动。

    2.邀请20位体育记者见面并问候。

    3.在社交媒体上分享赛事照片。

     

    商品经理(高级营销副总裁的直接下属)

    目标

    重启场内推广计划

    关键结果

    1.联系10家纪念品公司。

    2.给出5个待优选品的定价。

    3.在8月1日前提出3个关于场内赠品的想法。

     

           我们可以看到营销副总裁的关键结果是无法衡量,不具体、也没有时间限制。对于总结来说缺乏内在的激励价值,对于团队中在东海岸的童子军或复印机上埋头苦干的公关实习生而言,就更是这样了。

     

           适度的层级和关联性往往可以使得组织运营更加协同一致,但但所有目标都沿着组织层次过度关联时,这一过程就有可能退化成一个机械、纯粹由数字粉饰的活动,会带来4个方面的不利影响:

           丧失敏捷性:即使是中等规模的企业,也可以存在6~7个汇报层级,当基层员工等待上级下达指令时,层层会议就像丛生的杂草,每个目标周期都有可能达到几周甚至几个月的时间,紧密关联的组织往往拒绝快速而频繁的目标制定,实施过程太过繁琐会导致季度OKR变得不切实际。

           缺乏灵活度:由于需要花费如此多的精力来制定各个层次的关联目标,人们很可能不太愿意在周期内做出修改,即使是微小的修改,也可能给下级带来很大的负担,因为他们正在努力保持目标的协同,这样随着时间的推移,系统就会变得难以维护。

           员工被边缘化:严格的层级系统往往会对一线员工的投入和努力视而不见,在一个自上而下的生态系统中,员工在分享与目标相关的问题或有希望的想法时会犹豫不决。

           单一纬度的联系:当层次和关联都集中在垂直纵向的时候,组织中水平横向联系的效果就会大大的降低。

     

    激活基层

           OKR是高度透明的,毕竟OKR系统最强大的力量往往来自核心管理层之外的洞察力。

    如果一个目标服务于更大的目标,那么他是可以跳过许多级别的。例如:一个目标可能从首席执行官层直接跳到经理层,或者从一个主管层直接跳到某员工层,而不是从首席执行官层到副总裁层,再到经理层(然后再到经理的下级)。

           由于顶层的OKR是众所周知的而且团队中,每个人的OKR也是公开可见的,因此随着时间的推移,目标也会自然的协同一致。

    在现实中,过度的目标协同也可能会在组织中产生强迫性,进而给组织成员带来精神上的伤害。健康的组织往往是鼓励某些目标自下而上的涌现的。与组织中心相比,创新通常更容易发生在组织的边缘。

           安迪格鲁夫:在一线作战的人通常会提前感知即将发生的变化,销售人员往往比管理者更先理解顾客需求的变化,金融分析师是最早知道商业变化的人。

           安迪格鲁夫对管理干预持悲观的看法:下属可能会对上司给予的期望持保留态度,进而解决自己的问题时,表现的不那么主动,转而把这些问题推到他的上司那里,该组织的产出因此而大大的减少。

           理想的OKR系统往往允许员工自主设置部分目标及大部分或全部的关键结果。知道要去哪里的人,往往会更加清楚如何到达目的地。那么目标对我们的驱动作用可能是相当有限的。

    例如:医生要求你降低血压,以便于参加马拉松比赛,可能你会心不甘情不愿的接受他的意见,但是如果是处于自己的意愿参加马拉松比赛,那么结果又不一样了。

    高绩效团队会在自上而下和自下而上两条目标设定路径之间保持创造性张力。在遇到执行层面的紧急状况时,如果只是需要落实简单的事情,那么组织的指导更多的是指令性的。当数字变得强劲而让公司变得过于严谨和保守时,发挥基层员工的创造性和主动性就可能事半功倍。领导者对自上而下和自下而上这两种目标设定的选择往往是各占一半。

     

    跨职能协调

           对于具有创新性和相对复杂的问题,孤立的个体与相互联系的群体解决问题的能力是不可相提并论的。

           领导者和员工需都需要横向联系并打破障碍,只要目标对于所有人而言是公开可见的,团队中的每一个小分队都可以解决他们遇到的问题,透明为每一个人创造并提供了非常清晰的信号,增强了有效完成工作的能力,而且管理税是零。

     

    小结

           打破信息孤岛,人性的动力源泉来源于对自己的危机。

           在自上而下和自下而上的目标要区分清晰,何时采用哪种方式。

     

    协同减肥宝的故事

           8年来,迈克和阿尔伯特两兄弟用自己的积蓄和个人信用卡维持这款应用程序的运营。减肥宝是一个包含1400万种食品的数据库,使得追踪具体用户的饮食和锻炼效果变得比以往任何时候都更加容易。

           这款应用程序还有社交的功能,用户可以在上面拥有自己的朋友圈,一群每天为自己加油的人。

           OKR并非信息孤岛,OKR创建了相互联系的网络,在垂直、水平、对角线等各个方向全方位的联系着组织中最重要的工作。当员工的目标与公司的最高目标保持协同时,OKR的影响力就会被放大。

           目前很多公司拥有年度财务计划、年度营收目标、以及广泛但缺乏结构化或连续性的战略,它们都有一个共同的弱点,明显缺乏协同性,员工不知道其他团队在做什么,也不知道应该如何为共同的目标而努力。

           我们一次只要处理一个目标,一直到目标完成,然后我们在移到清淡上的下一个项目,这中间很少有重叠,不需要复杂的工作程序,但要确保它是高度聚焦,可以衡量的,OKR将主目标简单化,在组织中提炼、延展并层层分解目标。

     

    跨团队融合

           在高层次、战略性思维和更细致化的指令沟通之间取得平衡,是很有挑战性的,在减肥宝实施OKR时,远比预期要困难得多。

           当减肥宝从10人增加到30人时,当时会认为生产效率会提升200%,但是低谷了规模扩张减慢效率提升的程度。

           因此需要新的流程来避免互相冲突或重复作业,其实就是帮助人们理解你想要别人做什么,即协同。

           他们对自己应该做什么感到困惑,而这些可能会在不经意间发生变化。由于工程师团队每周都要在不同的项目之间进行轮换,这大大的降低了他们的工作效率,在每次中端之后再回到特定的产品时,他们会不得不问自己,如何重新开始?从公司的经营收入来看,升级软件版本的工作尤为紧迫,但开发工作却不得不时断时续。

           在市场营销部门中没有人想到需要通知工程部门,而工程师也设定了自己当季的优先事项,没有工程师的支持,这个OKR在开始之前就已经注定是失败的。

    团队之间想要更多的协同,我们的OKR系统设计的很好,但在执行方面却出现了短板,但各个部门想要互相依赖以获得重要支持时,我们却没能明确各个部门之间的这种依赖关系。

           协同并不意味着冗余,共有的OKR在很多程序上削弱了问责制,如果一个OKR体系的实施失败了,我不希望两个人互相指责,即使两个或两个以上的团队有同样的目标,但他们的关键结果也应该不同的。

           目标更加精确,关键结果更具有可衡量性,成功的概率就更高。在发布某个产品时,会先准确的评估它的影响和潜在的价值,这样,在设定下一个OKR时就可以更实际的对产出进行预测和延伸。

    目标越是宏大,人们就越趋于保守,这是典型的无意思结果。在减肥宝,在适当的时候会选择增量,但也会告诉团队,只需要尽自己的所能去构建最好的产品特性,我们希望员工能够跨越藩篱。

     

    未确认的依赖和增强

           随着组织规模的扩大,协同的复杂性会呈现指数级增长,我们如何向几百个人的展示公司想要达到的目标,并帮助彼此进步与相互协同?我们怎么才能让每一个人都朝着同一个方向前进呢?

           一开始是很难做到的,我们几乎无法想象亚马逊公司或苹果公司是如何进行管理的。必须要澄清自己的核心优势,让其他部门意思到你们部门的局限,因为这是一种单向公开,透明的方式,但它奏效了,通过寻找符合跨部门目标的项目来与它们保持协同。

    我们不能把所有事情都做完,我们必须做出选择。首要目标高于一切目标,嚼多不烂。当所有人的目标都是一直时,我们就站在同一个立场,这给了我们拒绝其他事情的自由。

     

    对准北极星

           坚持透明和问责式的OKR价值观。

           协同除了使公司内部目标更加一致,协同还包含着更深层次的含义,那就是始终保持你的目标相对于北极星(公司最重要的核心价值)的真实性和正确性。

    你的目标必须对公司的核心价值做出实质性的贡献。我们所做的每个决定,都需要和我们的企业愿景保持一致,当我们在用户和业务目标进行权衡时,我们或选择和客户保持一致,假如一个目标看起来与我们说的不一致,我们则给予其额外的关注,确保对准公司的北极星。

     

    小结

           公开、透明,使得目标自上而下。

           自下而上的清晰的、一致的。

     

    连接:财捷集群的股市

           通过在技术标准上保持领先一步的优势,在一次又一次的竞争威胁中生存了下来。人们无法与看不见的东西产生连接,网络也不可能在封闭的环境中兴旺发达,OKR对组织内所有的部门中的所有层级都是开放的、可视的。

           自上而下的推行OKR系统,会使得基层人员不会对此系统做出官僚式的服从,而是会慢慢的出现热爱式的服从,人们是发自内心的遵从的。

     

           通过OKR系统,员工能够把自己的日常工作和其他同事的优先任务、团队的季度目标及公司的使命更加清洗的联系起来。

           设定相互关联的目标是至关重要的,因为这种方式可以帮助员工将自己的工作做到最好。(潜意识的竞争)

           如果我们每天忙于灭火,解决现有的技术问题,便很难有时间和经理开发下一代的计费技术。

           在传统的谷仓式的组织中,部门之间的信息是被隔断的,人们的活动往往是不透明的。

           现代信息技术部仅仅是用来检查和处理票据或更改请求,它还赋予了更多的商业价值,比如帮助企业寻找未来的解决方案。

    领导者不能只关注团队成员日常的工作,更应该把更多的精力集中在更有价值、更长远的计划上。意识清晰且目的明确,以让主管和下属定期进行交流。

           OKR系统之所以强大,正式因为它是如此简单,又如此透明。OKR系统让公司里的每个人都知道我们在做什么,怎么做,以及为什么要这样做,如果人们了解你的优先目标和约束条件,在有些事情发生偏离时,他们更倾向于相信你。

           部门领导的个人目标就是团队的目标,这个是错误的。高层以下的团队和员工都会随着环境的变化修改他们自己的OKR,并不断取得进步。

    OKR系统结束了猜谜游戏,员工们的目标是透明的,让公司更有凝聚力,紧紧的连接在一起。

     

    来自云端的实时数据

           在企公司不同的团队将他们的目标实时的联系起来,而不是事后联系。

     

    目标

    使每一位财捷的员工都可以基于实时数据做出决策

    关键结果

    1.为人力资源和销售部门提供功能性数据集市。

    2.迁移到为实时访问而建立的新企业数据库。

    3.创建单独的团队,操作所有数据可视化工具,驱动财捷的统一策略。

    4.创建数据模块,帮助其他团队的人员使用数据可视化工具。

    作为一家基于云计算的企业想要知道现在正在发生什么。公开的数据,联系各个需要协同的点。

     

    全球协作工具

           解决全球化协作的问题需要进一步提升连接能力。为此指定了要用哪种工具协同,员工而不必浪费时间弄清楚应该使用哪种工具,他们可以专注于他们的工作了。

    制定目标是一种艺术,而不是仅仅的主观判断,大家聚焦在一个最高的目标时,当它不需再需要额外的关注时,我们就会让他作为一个普通的关键结果,这是一个动态的过程,领导者要随时根据实际情况和需要来进行调整。

    当一线员工能够看到他们的工作如何与公司总体目标保持一致时,他们就会发挥能动性。结构化、可视化的目标制定系统,它让企业内的员工边界消失殆尽。

     

    横向连接

           在公司里想要取得成功依靠的是最好的创意和想法,而不是最大的官阶。高层管理者需要非常尊重基层员工,并愿意倾听他们的想法。

    OKR横向的向上打开了部门之间的边界,实现了跨团队的开放和协同,刚开始员工可能会不适应,高层需要作出表率。

     

    小结

           协同、透明,让一线员工与公司战略上,及和直属领导的目标上保持一致,使得他们获得了自我价值体现的曙光,并且会不由自主的捍卫个人的自尊,而不再是互相推诿,而是变得互相监督。

     

    责任追踪

           我们信仰了上帝,除了上帝,其他人都必须用数据说话。 - 爱德华戴明

     

           OKR系统是具有可追踪性的,使得我们可以根据实际情况堆OKR系统不断的修改和调整。统的目标管理体系,是管理者设定了目标,但是这些目标是不容易调整,还容易遗忘。

     

    生命周期之启动

           这些目标是公开,但是谁会有耐心去寻找目标之间的联系或一致性?如果你攻陷的目标根本没有人看到那么这个系统还能算透明吗?

           如果公司的最高层目标和各个业务部门之间的目标是用电子表格来呈现的,并用这些表格进行层层传递,那么这些目标从来没有一个统一的平台,就像人没有家,目标无法和每天的日常工作联系在一起,同时,这些目标是没有及时更新的,使得这些目标没有很强的关联性,这也是导致计划与现实之间的差距日益扩大,这样的OKR是纯粹的纸上谈兵,毫无实际意义。

           OKR系统要是一个持续可追踪、更新、提醒的系统,更能够让员工体悟到工作本身的内在价值。一流的OKR软件包括移动应用、自动更新、分析报告、实时报警的系统,并还可以和Salessforce、JIRA和Zendesk等软件产品的整合。

           OKR系统的价值,主要体现在以下的几个方面:

           1.OKR系统让每个人的目标更加清晰,用户可以直接访问OKR系统中的老板、直接主管、和整个组织的目标。

           2.OKR系统有利于驱动团队的积极性,当员工知道自己在做正确的事情时,保持积极性和斗志就更容易了。

           3.OKR系统有利于提升内部网络效率,透明化的平台可以引导个体与共同职业兴趣的同事一起工作。

           4.OKR系统有利于节省时间、金钱,同时减少挫折,传统的目标设置方法都在会议记录、电子邮件、电子文档和幻灯片等事情上浪费了大量时间,有了OKR管理平台,所有相关信息都可以在需要的时候准备就绪。

     

           公司的目标之间毫无联系,上下级的目标也没有关联起来,年度目标和员工日常工作也似乎没有联系时,就可以考虑使用OKR管理方式,使得目标实时、紧密的联系在一起,有力的促进公司协调运营。

     

    OKR导师

           要使OKR系统有效的发挥作用,整个组织,包括高管团队,都需要使用这套系统,没有例外,也不能随意退出。

     

    生命周期之时时追踪

           对于个人来说,最大的激励因素是在工作中取得进步,人们取得进步的时候,是他们感到最积极、最投入的时候。 - 丹尼尔平克《驱动力》

     

           人们渴望知道自己每天是如何取得进步的,取得可量化的进步和公众的认可,相比于金钱刺激或实现目标的本身,对人更有驱动力。

           OKR系统不需要每天都要追踪,但是需要定期检查,最好每周一次,这是防止绩效下降的必要措施。

           如果没有行动计划,经理人就会成为业务实现的俘虏,随着业务的发展,如果不设置检查点,对计划进行检查,经理人就无从知道哪些业务是真正重要的,哪些事项是分散精力的干预事项。

           写下目标,这一简单行为可以增加你达成目标的可能性,如果你在与同事共享目标的同事,还能够监视目标的进程,你的胜算就会提高。

           适应性是OKR系统的核心特征,它们是OKR系统的护栏,而不是限制目标达成的锁链,或者使人看不到目标的眼罩,当我们跟踪和审核目标与关键结果时,我们在任何一个时刻都有以下四个选择

           继续:如果目标处在绿色区域,这就表示目标在正常追踪之中,而不需要去调整它。

           更新:如果目标处在黄色区域,它提醒我们需要对目标进行特别注意了,需要对关键结果或目标进行调整以适应或外部环境的变化。

           开始:只要有需要,随时可以重新启动一个新的中期OKR。

           停止:如果目标处在红色区域里,这就提示达成目标已经有很多风险了,当前的目标已经没有用了,最好的解决方案就是放弃。

           人们可以从失败中学习,继续前进,挫折中也孕育着未来成功的机遇。当在目标实现过程中,目标没有清晰的解决你设立这个目标的初衷(让人们积极的在平台交流),可以选择立刻改变开发目标。

           当一个关键结果或目标变得过时或不切实际时,就要当机立断的结束它。目标是为目的服务的,而不是为了其他事项服务的。

           当一个目标在OKR评估周期结束前被删除时,需要通知每个和它有关系的人是很重要的。反思:有什么是我没有预见到的?我能够得到什么教训以指导未来?在谷歌如果一个承诺的OKR失败了,团队会制订一个补救计划。

     

    生命周期之总结(清零与重复)

           事后的评估和分析都可以挖掘出巨大的价值。总结包括:客观评估、主观自我评估、评估与反思。

           客观评估:如果OKR得分低,则需要评估,目标是否仍然值得追求?如果答案是肯定的,需要做出说明来改变它?

           谷歌使用0~1.0分作为计量标准:

    0.7~1.0 = 绿色(目标完成)

                  0.4 ~ 0.6 = 黄色(目标取得了进展,但是没有完成)

                  0 ~ 0.3 = 红色(目标失败)

           通常情况下,我们都知道我们不能实现是有的目标,如果一个部门100%完成了目标,董事会就会认为这个部门的目标定得太低了,这样反而会有麻烦。

     

    自我评估

           有时候,数据不太理想并不代表团队一定不努力,漂亮的数据背后也可能存在认为造价。

    评分和评估的变量:

    目标与关键结果

    进度

    得分

    自我评估

    获得10个新客户

    70%

    0.9

    市场不景气,OKR比我想象的要困难的多,签下7个新客户代表我非常努力并取得非常好的结果。

    获得10个新客户

    100%

    0.7

    当我仅用8周就完成了本季目标时,我意识到我的目标与关键结果定得太低了。

    获得10个新客户

    80%

    0.7

    尽管我签下了8个新客户,但与其说因为努力,不如说是运气,其中一个客户带来了另外5个客户。

    获得10个新客户

    90%

    0.5

    尽管我成功的获取了9个客户,但是我发现其中7个新客户只能产生很少的营收。

     

    通过这种评估,让我们看到他们所做的一切如何与公司的总体目标相联系,毕竟,目标和关键结果是为了让每个人都做正确事情。自我评估可以更好的驱动指定下一季度的目标,在这里,没有批评,只有学习。

     

    反思

           OKR是以行动为导向的,但是如果只是不懈努力而没有偶尔停下来反思,这跟永不停止的仓鼠轮没有区别。

           要有意识的去总结、提炼和阐明关键的经验教训。我们并不是从经验中学习,而是通过反思经验来学习。

    我们是否完成了所有的目标,如果是,是我们促成我的成功?如果没有我遇到什么障碍?如果我要重新写一个完整的目标,需要作出说明改变?我学到哪些经验,可以帮助我更有效的制定下一个周期的OKR?

    对工作进行彻底的评估,找到自己的不足之后,尽情的享受自己的进步。

     

    小结

           失败与出错是自身寻找的,但过程中的质量与目标一致性打成是否成正比。

           自我反思是为了更好的下一次,也是责任的过程追踪。

     

    跟踪:盖茨基金会的故事

           项目的投入越高,追踪过程的重要性就越凸显,识别并记录隐患、及时止损、在经营中不断调整目标。

           在解决问题时,不需要墨守成规,要考虑在没有资源限制的情况下,你怎么做。在对优先事项做艰难的选择时,问一下自己,你最擅长什么?通过关键结果不断对其进行加强和巩固,OKR让目标和结果更加清晰。

     

    使目标具体化

           OKR管理方法也可以称为,绿黄红管理办法。

           确认目标是非常重要的,如果目标不够明确,则无法在过程中做出选择。前提是目标是能够有效掌控的,当制定的目标过于宏大时,它实际是不可信的。

           使命是具有方向性的,目标是包含一系列的具体步骤,需要个体参与其中,并为之不懈奋斗。

           有一个宏伟的目标是必要的,但你必须知道如何控制它的规模,以及如何对它进行衡量。

           有一个好的使命是还不够的,你还需要一个具体的名表,并且需要知道如何实现这个目标。当可衡量的结果提示我们无法取得进展或者目标无法实现时,我们需要重新思考或调整目标。

    需要利用关键结果来调整你的日常行动计划,随着时间的推移,你会不断的将它们向前推进并进行调整,从而实现更大的目标。

           比如:你有一颗种子,可以使得白薯的产量增加2倍,你将注意力聚焦在产量上,最终你发现,没有人愿意使用这种种子,因为用这种种子种出来的白薯需要花费平常的4倍时间进行烹煮。

           设定宏大的目标相对容易,但是达到目标不容易,我们需要时时刻刻追问,需要客服哪些困难才能实现目标?

     

    小结

           为什么?目标的初衷

           怎么样做?关键结果

           做什么?与目标保持一致,根据实际环境可调整做的内容

     

    挑战不可能

           最大的风险是什么也不做。 - 米乐迪霍布森

     

           如果一家公司做不到持续创新,这家公司必将走向灭亡,创新并非重复。调整目标的选择恰当而明智时,所获得的回报是和风险对等的,甚至远远超过其所需承担的风险。

    要敢于设定胆大包天的目标,要相信星星之火可以燎原,善于利用杠杆的原理。目标越具有挑战性,所产生的结果越佳,虽然高难度的目标与其产出的结果之间的差距,通常大于低难度目标与其产出结果之间的差距,但是前者达到的最终结果仍然比后者要好。

    设定明确而有挑战性的目标,不仅可以提高工作的趣味性,同时要可以帮助人们体会到工作的愉悦感。

           创业者不仅仅制定挑战性的目标,还要思考各种可能性,而且要将各种可能性都付诸实践。挑战性的目标都有利于塑造创业文化,它迫使人们打破原有的思维局限,让企业经营更加出色。

           实现宏大的OKR目标时,专注和承诺是打成目标并实现真正差异化的必要条件。只有透明、协作、目标一致且内在联结度高的组织才能让其他常规组织走的更远、更久。但是如果缺乏有效追踪,你将如何得知自己何时达成挑战性的目标呢?

           谷歌将OKR分为两类,一类称为承诺型OKR,另一类称为愿景型OKR。

    承诺型目标是与日常考核有关的,这些目标是要100%在规定的时间内完成的。

           愿景型反映的是更宏伟的蓝图,更高的风险,以及更侧重于未来导向,他们可以来自任何层面,皆在调动整个组织的积极性与活力,它们是极难实现的(失败率40%),但仍然是构成谷歌OKR的一部分。

           领导者必须思考:未来一年、两年、三年我们要成为什么类型的公司?

     

    我们需要挑战

           按照马斯洛的理论,人们的需求共分为5个等级(生理需求、安全需求、爱/归属感、尊重、自我实现),只有当我们的低级需求得到满足后,我们才会转向更高层次的需求。

           格鲁夫发现:对于一些人而言,即便没有外部激励,他们仍然能够不断的进行自我激励,调整自己的能力边界并努力实现,自我超越,他们从不会止步于自我满足。

           挑战性的目标有助于实现最大产出:如果领导者新闻自己和下属都能取得最佳绩效,那么设定挑战性目标是非常必要的。

     

           拉里佩奇:大多数人倾向于认为某件事是不可能的,而不是回归于显示时间的本源去寻找可能实现它的机会。

    10%改进,意味着你和其他人一样,你们在做着同样的事情,你可能不会失败,但你也绝不会太成功。

     

    挑战性目标的调整

           挑战性目标就不能一成不变,你也不能好高骛远,不考虑实际情况而强行设定高目标,过分追求数独和进度返回会导致拔苗助长。

           例如:这周要每天看30页书。

                    而你把这个目标调为80页。

                    但是你发现,你已经有2年没看书了,最终你是每天看完60页。

                    虽然目标没有达成,但是我们随后的能力提升速度会更快。

                    如果你把这个目标调整为500页每天,那么是不切实际的。

          

           领导者必须要给员工传递,结果的重要性和结果能够被实现的坚定信念。每个组织都有承担一定风险的能力,这可能随着时间的推移发生变化,承担风险的边际越大,公司就越有能力扩展其业务规模。

           OKR有40%的失败率可能看起来太冒险了,太令人沮丧了,对于高成就者而言,任何不完美都会有损士气。

           所有OKR都死一个必须承诺完成的目标。领导者更好的做法是把目标设定在一个适度的范围,随着时间的推移,当团队和个人实现OKR的经验不断丰富后,他们设定的关键结果自然会变得更加精确,更有挑战性。

           你的团队是如何创造最大价值的?令人不可思议的目标是什么样的?如果你追求卓越,那么这样一个令人不可思议的挑战性目标就是一个好的起点。

           目标的奖励之一便是,你能够不断获得晋级的机会。

     

    小结

           专注度是实现过程的指标

           承诺是实现的门槛

           透明是激发自我驱动的方式

           协同是透明与联系的的前提,是伟大目标实现的门槛。

           一致是目标朝着正确方向的前提。

           挑战是自我超越的基础

     

    延展:谷歌浏览器的故事

           拉里佩奇:当你设定的是一个疯狂而富有挑战性的目标时,即使没有实现它,你也仍然会取得一些不少的成就。

           假如你的目标是去一颗恒星,也许你永远无法达到,但在此过程中你可能飞到了月球。

     

    升级目标

           作为领导者,你一定不希望在季度末,站在醒目的展示着红色方格(表示OKR未完成)的大屏幕前,向整个公司解释你是为什么失败的,以及是哪些因素导致此次的失败。那种经历所带来的压力和不适感会激发我们的胆识,让我们敢于去做很多具有突破性的事情来避免失败,但在一些情况下,即使你给你的团队设定了正确的目标,失败是在所难免的。

           作为团队的领导者,你的作用之一就是激励团队,让他们觉得目标是可以实现的,尽可能把我们的能力推到极限,甚至超越极限是非常重要的。

           OKR给了团队前进的方向,并成为衡量我们工作进度的晴雨表,如此一来,我们就不至于取得一点成绩就沾沾自喜。它也可以时刻提醒我们要对我们工作所遵循框架的的合理性进行反思,所有这些都比在某个特定日期打成某种特定目标要有意义的多。

           有时候挑战性的目标并不想它看起来的那么疯狂,有时候往往我们是会低低估自己的能力。找到问题,弄明白为什么,解决它。

    当你设定了一个可量化的年度目标,并将其按照季度逐个分解时,你就会发现登月计划好像变得可行了。

           OKR给我们提供了实现从量化到质变的清晰可量化的任务清单。在一个团队中,每个人都不能独舞,你无法仅靠自己取得成功。

     

    小结

           没有不可能,只是在于你的决心与驱动力,最后就是执行力。

           在谷歌产品中可以看到,简单。

           一切的问题解决开头都是从为什么开始,成长也是从为什么提升。

     

    延展:YouTube的故事

           必须要弄清楚,只有抓住问题的症结,才是实施一切方案的基础。这是一个目标,也是一个要实现的关键结果。

           特别在创业伊始,资源匮乏的时期,清洗的方向是至关重要的,这就如同教育小孩一样,小时候不立规矩,等到他们长大后再告诉他们,这就是规矩,你必须要遵守规矩,他们是不会听的。

           目标与关键结果越清晰,成功可能性就越高。

     

    巨石理论

           一堆鹅卵石和一些沙子,你的任务是尽可能的把所有东西都装进一个一加仑的广口瓶中,如果你先放沙子,再放入鹅卵石,那么再想放石头时,你会发现瓶子已经没有空间给他们了。

           然而,当你先放石头,再放鹅卵石,最后放沙子,你会发现一切如你所愿,沙子把石头之间的缝隙填满了。

           我们要善于抓住主要的矛盾,重要的事情要先做,否则有可能永远都没有机会去做了,要使每个人都明确知晓什么任务才是符合公司最高利益的,应当被优先执行。

     

    更好的衡量标准

           在一个计算能力几乎无限的世界里,真正稀缺的商品才会越来越受到人们的关注。这也是为什么YouTube的收益是来源不是来源于观看率和点击率,而是观看时长。

     

    设置挑战目标的规则

           如果人们不相信挑战性目标是可以实现的,那么它就真的无法实现了,这就是设定目标的艺术所在。

     

    加快进度

           谷歌也有很多延迟实现目标的情形,其实这会促使很多人不断更新他们的关注点,推动目标继续实现,特别当进度落后时,OKR的可视化和透明性的作用是动力来源。

           当你决定优先考虑什么,以及资源向哪里倾斜时,请始终记住,如果我们什么都不做,我们是不可能实现这个宏伟的目标的。

     

    相互支持

           谷歌鼓励员工设定高风险、有挑战性的目标并允许失败的,且公开、透明,也许正是这种强烈的责任感使得谷歌呈现10倍速的奔跑。

           获得高层领导支持,是员工OKR实现的一个重点,挑战性OKR具有强大的驱动力,并且你永远无法预知这个过程中,你有那些收获。

     

    学会宏观思考

           有挑战性的目标可以促使整个组织进行再设计,使得每个人都学会在宏观的角度去思考问题。

           在YouTube完成其日均观看时长10亿小时的目标时,员工会讨论,如果要做到那么大,是否要重新设计计算架构,要重新评估存储能力了。

     

    小结

           停下来思考为什么?

     

           OKR与CFR管理模式(二)-CFR与OKR的绩效管理:https://blog.csdn.net/Su_Levi_Wei/article/details/105638656

    展开全文
  • GoF是什么----设计模式

    千次阅读 2009-01-21 15:30:00
    定义:GoF(Gang of ... [编辑本段]GoF的起源 《Design Patterns: Elements of Reusable Object-Oriented Software》(即后述《设计模式》一书),由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides

    定义:GoF(Gang of Four),中文名——四人组。GoF是一种设计模式

    GoF的起源

      《Design Patterns: Elements of Reusable Object-Oriented Software》(即后述《设计模式》一书),由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著(Addison-Wesley,1995)。这几位作者常被称为"四人组(Gang of Four)",而这本书也就被称为"四人组(或 GoF)"书。

      在《设计模式》这本书的最大部分是一个目录,该目录列举并描述了 23 种设计模式。另外,近来这一清单又增加了一些类别,最重要的是使涵盖范围扩展到更具体的问题类型。例如,Mark Grand 在 Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML(即后述《模式 Java 版》一书)中增加了解决涉及诸如并发等问题的模式,而由 Deepak Alur、John Crupi 和 Dan Malks 合著的 Core J2EE Patterns: Best Practices and Design Strategies 一书中主要关注使用 Java 2 企业技术的多层应用程序上的模式。

      对软件设计模式的研究造就了一本可能是面向对象设计方面最有影响的书籍:《设计模式》。

    GoF是一座"桥"

      就Java语言体系来说,GOF是Java基础知识和J2EE框架知识之间一座隐性的"桥"。

      会Java的人越来越多,但是一直徘徊在语言层次的程序员不在少数,真正掌握Java中接口或抽象类的应用不是很多,大家经常以那些技术只适合大型项目为由,避开或忽略它们,实际中,Java的接口或抽象类是真正体现Java思想的核心所在,这些你都将在GoF里领略到它们变幻无穷的魔力。

      GoF表面上好像也是一种具体的"技术",而且新的设计模式不断在出现,设计模式自有其自己的发展轨道,而这些好像和J2EE,.Net等技术也无关!

      实际上,GoF并不是一种具体"技术",它讲述的是思想,它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧,让你能够真正掌握接口或抽象类的应用,从而在原来的Java语言基础上跃进一步,更重要的是,GoF反复向你强调一个宗旨:要让你的程序尽可能的可重用。

      这其实在向一个极限挑战:软件需求变幻无穷,计划没有变化快,但是我们还是要寻找出不变的东西,并将它和变化的东西分离开来,这需要非常的智慧和经验。

      而GoF的设计模式是在这方面开始探索的一块里程碑。

      J2EE等属于一种框架软件,什么是框架软件?它不同于我们以前接触的Java API等,那些属于Toolkist(工具箱),它不再被动的被使用,被调用,而是深刻的介入到一个领域中去,J2EE等框架软件设计的目的是将一个领域中不变的东西先定义好,比如整体结构和一些主要职责(如数据库操作 事务跟踪 安全等),剩余的就是变化的东西,针对这个领域中具体应用产生的具体不同的变化需求,而这些变化东西就是J2EE程序员所要做的。

      由此可见,设计模式和J2EE在思想和动机上是一脉相承,只不过

      1.设计模式更抽象,J2EE是具体的产品代码,我们可以接触到,而设计模式在对每个应用时才会产生具体代码。

      2.设计模式是比J2EE等框架软件更小的体系结构,J2EE中许多具体程序都是应用设计模式来完成的,当你深入到J2EE的内部代码研究时,这点尤其明显,因此,如果你不具备设计模式的基础知识(GoF的设计模式),你很难快速的理解J2EE。不能理解J2EE,如何能灵活应用?

      3.J2EE只是适合企业计算应用的框架软件,但是GoF的设计模式几乎可以用于任何应用!因此GoF的设计模式应该是J2EE的重要理论基础之一。

      所以说,GoF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。为什么说隐性的?

    GoF是隐性的"桥"

      因为很多人没有注意到这点,学完Java基础语言就直接去学J2EE,有的甚至鸭子赶架,直接使用起Weblogic等具体J2EE软件,一段时间下来,发现不过如此,挺简单好用,但是你真正理解J2EE了吗?你在具体案例中的应用是否也是在延伸J2EE的思想?

      如果你不能很好的延伸J2EE的思想,那你岂非是大炮轰蚊子,认识到J2EE不是适合所有场合的人至少是明智的,但我们更需要将J2EE用对地方,那么只有理解J2EE此类框架软件的精髓,那么你才能真正灵活应用Java解决你的问题,甚至构架出你自己企业的框架来。(我们不能总是使用别人设定好的框架,为什么不能有我们自己的框架?)

      因此,首先你必须掌握GoF的设计模式。虽然它是隐性,但不是可以越过的。

      附录:关于23种设计模式的有趣见解

      作者以轻松的语言比喻了java的23种模式,有很好的启发作用。

      创建型模式

      1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

      工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。

      2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖)

      建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

      3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。

      工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。

      4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。(100块钱一份,你要不要)

      原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类,产品类不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

      5、SINGLETON—俺有6个漂亮的老婆,她们的老公都是我,我就是我们家里的老公Sigleton,她们只要说道“老公”,都是指的同一个人,那就是我(刚才做了个梦啦,哪有这么好的事)

      单例模式:单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

      结构型模式

      6、ADAPTER—在朋友聚会上碰到了一个美女Sarah,从香港来的,可我不会说粤语,她不会说普通话,只好求助于我的朋友kent了,他作为我和Sarah之间的Adapter,让我和Sarah可以相互交谈了(也不知道他会不会耍我)

      适配器(变压器)模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

      7、BRIDGE—早上碰到MM,要说早上好,晚上碰到MM,要说晚上好;碰到MM穿了件新衣服,要说你的衣服好漂亮哦,碰到MM新做的发型,要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题,自己用BRIDGE组合一下不就行了

      桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以独立的变化。

      8、COMPOSITE—Mary今天过生日。“我过生日,你要送我一件礼物。”“嗯,好吧,去商店,你自己挑。”“这件T恤挺漂亮,买,这条裙子好看,买,这个包也不错,买。”“喂,买了三件了呀,我只答应送一件礼物的哦。”“什么呀,T恤加裙子加包包,正好配成一套呀,小姐,麻烦你包起来。”“……”,MM都会用Composite模式了,你会了没有?

      合成模式:合成模式将对象组织到树结构中,可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

      9、DECORATOR—Mary过完轮到Sarly过生日,还是不要叫她自己挑了,不然这个月伙食费肯定玩完,拿出我去年在华山顶上照的照片,在背面写上“最好的的礼物,就是爱你的Fita”,再到街上礼品店买了个像框(卖礼品的MM也很漂亮哦),再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……,我们都是Decorator,最终都在修饰我这个人呀,怎么样,看懂了吗?

      装饰模式:装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案,提供比继承更多的灵活性。动态给一个对象增加功能,这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

      10、FACADE—我有一个专业的Nikon相机,我就喜欢自己手动调光圈、快门,这样照出来的照片才专业,但MM可不懂这些,教了半天也不会。幸好相机有Facade设计模式,把相机调整到自动档,只要对准目标按快门就行了,一切由相机自动调整,这样MM也可以用这个相机给我拍张照片了。

      门面模式:外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。每一个子系统只有一个门面类,而且此门面类只有一个实例,也就是说它是一个单例模式。但整个系统可以有多个门面类。

      11、FLYWEIGHT—每天跟MM发短信,手指都累死了,最近买了个新手机,可以把一些常用的句子存在手机里,要用的时候,直接拿出来,在前面加上MM的名字就可以发送了,再不用一个字一个字敲了。共享的句子就是Flyweight,MM的名字就是提取出来的外部特征,根据上下文情况使用。

      享元模式:FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部,不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态,它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来,将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象,而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

      12、PROXY—跟MM在网上聊天,一开头总是“hi,你好”,“你从哪儿来呀?”“你多大了?”“身高多少呀?”这些话,真烦人,写个程序做为我的Proxy吧,凡是接收到这些话都设置好了自动的回答,接收到其他的话时再通知我回答,怎么样,酷吧。

      代理模式:代理模式给某一个对象提供一个代理对象,并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下,客户不想或者不能够直接引用一个对象,代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象,而仅仅持有一个被代理对象的接口,这时候代理对象不能够创建被代理对象,被代理对象必须有系统的其他角色代为创建并传入。

      行为模式

      13、CHAIN OF RESPONSIBLEITY—晚上去上英语课,为了好开溜坐到了最后一排,哇,前面坐了好几个漂亮的MM哎,找张纸条,写上“Hi,可以做我的女朋友吗?如果不愿意请向前传”,纸条就一个接一个的传上去了,糟糕,传到第一排的MM把纸条传给老师了,听说是个老处女呀,快跑!

      责任链模式:在责任链模式中,很多对象由每一个对象对其下家的引用而接

      起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求,系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择:承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

      14、COMMAND—俺有一个MM家里管得特别严,没法见面,只好借助于她弟弟在我们俩之间传送信息,她对我有什么指示,就写一张纸条让她弟弟带给我。这不,她弟弟又传送过来一个COMMAND,为了感谢他,我请他吃了碗杂酱面,哪知道他说:“我同时给我姐姐三个男朋友送COMMAND,就数你最小气,才请我吃面。”,:-(

      命令模式:命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否执行,何时被执行以及是怎么被执行的。系统支持命令的撤消。

      15、INTERPRETER—俺有一个《泡MM真经》,上面有各种泡MM的攻略,比如说去吃西餐的步骤、去看电影的方法等等,跟MM约会时,只要做一个Interpreter,照着上面的脚本执行就可以了。

      解释器模式:给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后,使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构,也就是一系列的组合规则。每一个命令对象都有一个解释方法,代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

      16、ITERATOR—我爱上了Mary,不顾一切的向她求婚。

      Mary:“想要我跟你结婚,得答应我的条件”

      我:“什么条件我都答应,你说吧”

      Mary:“我看上了那个一克拉的钻石”

      我:“我买,我买,还有吗?”

      Mary:“我看上了湖边的那栋别墅”

      我:“我买,我买,还有吗?”

      Mary:“你的小弟弟必须要有50cm长”

      我脑袋嗡的一声,坐在椅子上,一咬牙:“我剪,我剪,还有吗?”

      ……

      迭代子模式:迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集,聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中,从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象,每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

      17、MEDIATOR—四个MM打麻将,相互之间谁应该给谁多少钱算不清楚了,幸亏当时我在旁边,按照各自的筹码数算钱,赚了钱的从我这里拿,赔了钱的也付给我,一切就OK啦,俺得到了四个MM的电话。

      调停者模式:调停者模式包装了一系列对象相互作用的方式,使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时,不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化,把对象在小尺度的行为上与其他对象的相互作用分开处理。

      18、MEMENTO—同时跟几个MM聊天时,一定要记清楚刚才跟MM说了些什么话,不然MM发现了会不高兴的哦,幸亏我有个备忘录,刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存,这样可以随时察看以前的记录啦。

      备忘录模式:备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下,将一个对象的状态捉住,并外部化,存储起来,从而可以在将来合适的时候把这个对象还原到存储起来的状态。

      19、OBSERVER—想知道咱们公司最新MM情报吗?加入公司的MM情报邮件组就行了,tom负责搜集情报,他发现的新情报不用一个一个通知我们,直接发布给邮件组,我们作为订阅者(观察者)就可以及时收到情报啦

      观察者模式:观察者模式定义了一种一队多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时,会通知所有观察者对象,使他们能够自动更新自己。

      20、STATE—跟MM交往时,一定要注意她的状态哦,在不同的状态时她的行为会有不同,比如你约她今天晚上去看电影,对你没兴趣的MM就会说“有事情啦”,对你不讨厌但还没喜欢上的MM就会说“好啊,不过可以带上我同事么?”,已经喜欢上你的MM就会说“几点钟?看完电影再去泡吧怎么样?”,当然你看电影过程中表现良好的话,也可以把MM的状态从不讨厌不喜欢变成喜欢哦。

      状态模式:状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里,每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候,其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时,系统便改变所选的子类。

      21、STRATEGY—跟不同类型的MM约会,要用不同的策略,有的请电影比较好,有的则去吃小吃效果不错,有的去海边浪漫最合适,单目的都是为了得到MM的芳心,我的追MM锦囊中有好多Strategy哦。

      策略模式:策略模式针对一组算法,将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类,各种算法在具体的策略类中提供。由于算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。

      22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗?女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method),但每个步骤针对不同的情况,都有不一样的做法,这就要看你随机应变啦(具体实现);

      模板方法模式:模板方法模式准备一个抽象类,将部分逻辑以具体方法以及具体构造子的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架,而将逻辑的细节留给具体的子类去实现。

      23、VISITOR—情人节到了,要给每个MM送一束鲜花和一张卡片,可是每个MM送的花都要针对她个人的特点,每张卡片也要根据个人的特点来挑,我一个人哪搞得清楚,还是找花店老板和礼品店老板做一下Visitor,让花店老板根据MM的特点选一束花,让礼品店老板也根据每个人特点选一张卡,这样就轻松多了;

      访问者模式:访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话,接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统,它把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易,就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中,而不是分散到一个个的节点类中。当使用访问者模式时,要将尽可能多的对象浏览逻辑放在访问者类中,而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

    展开全文
  • 在面向对象程式设计的范畴中,命令模式是一种设计模式,它尝试以物件来代表实际行动。命令物件可以把行动(action) 及其参数封装起来,于是这些行动可以被: 重复多次取消(如果该物件有实作的话)取消后又再重做 ...

    面向对象程式设计的范畴中,命令模式是一种设计模式,它尝试以物件来代表实际行动。命令物件可以把行动(action) 及其参数封装起来,于是这些行动可以被:

    • 重复多次
    • 取消(如果该物件有实作的话)
    • 取消后又再重做

    这些都是现代大型应用程序所必须的功能,即“复原”及“重复”。----WIKIPEDIA


    个人理解


    命令模式是一个高内聚的模式,它将一个请求封装为一个对象,让你使用不同的请求将客户端参数化,在项目中应用比较广泛,他的封装性比较好,将请求方和接收方分离开来,扩展性较好。命令模式中主要有三种角色,一个是命令的接受者(Receiver),他负责对于收到的命令作出响应。一个是命令(Command)角色,他负责定义接受者需要执行什么样的命令。另一个是调用者(Invoker),接收命令调用并执行命令。但是命令模式也存在不足,如果命令较多的时候那么会存在多个子类,导致臃肿,可以结合其他的模式进行设计,如结合责任链模式实现命令的解析、结合模板方法模式减少子类的膨胀问题。


    案例解析


    命令模式模板


    三个主要角色

    1. 接收者(Receiver)

        负责具体执行哪些动作,也就是说他只负责提供一些任务的具体实现,不负责其他的部分。

    2. 命令(Command)角色

        负责定义好具体的命令,包括规定好接收者需要执行的哪些动作。

    3. 调用者(Invoker)角色

        负责调用命令执行,不需要知道谁是接收者,以及接收者怎么去执行,因为需要知道怎么执行的是接收者,他定义了任务的具体实现,另外不需要知道接收者是谁,这在命令角色中已经定义了哪些接收者执行哪些动作。


    命令模式模板类结构图


    主要代码

    接收者角色:

    public interface Receiver {
    
    	public void doSomthing();
    }
    

    具体实现类

    public class Receiver1 implements Receiver {
    
    	@Override
    	public void doSomthing() {
    		System.out.println("Receiver1");
    	}
    
    }
    

    命令角色

    public abstract class Command {
    
    	protected Receiver receiver;
    	
    	public Command(Receiver receiver) {
    		this.receiver = receiver;
    	}
    	
    	public abstract void execute();
    }
    

    具体实现类

    public class Command1 extends Command {
    
    	public Command1(Receiver receiver) {
    		super(receiver);
    	}
    
    	@Override
    	public void execute() {
    		this.receiver.doSomthing();
    	}
    
    }
    

    调用者角色

    public class Invoker {
    
    	private Command command;
    	
    	public void setCommand(Command command) {
    		this.command = command;
    	}
    	
    	public void action() {
    		this.command.execute();
    	}
    }
    

    测试类

    public class Test {
    
    	public static void main(String[] args) {
    		// 调用者
    		Invoker invoker = new Invoker();
    		
    		// 接收者
    		Receiver receiver = new Receiver1();
    		
    		// 命令角色
    		Command command = new Command1(receiver);
    		
    		invoker.setCommand(command);
    		invoker.action();
    	}
    }
    


    拓展案例解读

    案例背景介绍

    以家庭雇佣管家和保姆等佣人为例子,主要的人物有,老板、佣人,其中老板在命令模式中相当于调用者,而佣人则相当于接收者,老板对于佣人的指令相当于命令角色。那么从这一点出发来想这个案例中老板发号施令的好处所在,老板只需要说一下命令,然后,具体谁去做,怎么做老板不需要知道的,只需要等待命令的结果就行了。


    案例中类结构图


    主要代码

    接收者角色

    public interface Person {
    
    	/**
    	 * 劈柴
    	 */
    	public void chopping();
    	
    	/**
    	 * 做饭
    	 */
    	public void makeFood();
    	
    	/**
    	 * 喂马
    	 */
    	public void feedHorse();
    	
    	/**
    	 * 周游世界
    	 */
    	public void travelWorld();
    }
    

    具体实现类

    public class Man implements Person{
    
    	@Override
    	public void chopping() {
    		System.out.println("Man --- chopping");
    	}
    
    	@Override
    	public void makeFood() {
    		System.out.println("Man --- makeFood");
    	}
    
    	@Override
    	public void feedHorse() {
    		System.out.println("Man --- feedHorse");
    	}
    
    	@Override
    	public void travelWorld() {
    		System.out.println("Man --- travelWorld");
    	}
    
    }
    public class Woman implements Person{
    
    	@Override
    	public void chopping() {
    		System.out.println("Woman --- chopping");
    	}
    
    	@Override
    	public void makeFood() {
    		System.out.println("Woman --- makeFood");
    	}
    
    	@Override
    	public void feedHorse() {
    		System.out.println("Woman --- feedHorse");
    	}
    
    	@Override
    	public void travelWorld() {
    		System.out.println("Woman --- travelWorld");
    	}
    
    
    }

    命令角色

    public abstract class Command {
    
    	protected Man man = new Man();
    	protected Woman woman = new Woman();
    	
    	public abstract void executeBossCommand();
    }
    具体实现类
    public class ChoppingCommand extends Command {
    
    	@Override
    	public void executeBossCommand() {
    		this.man.chopping();
    	}
    	
    }
    
    public class MakeFoodCommand extends Command {
    
    	@Override
    	public void executeBossCommand() {
    		this.woman.makeFood();
    	}
    	
    }
    

    调用者

    public class Boss {
    
    	private Command command;
    
    	public void setCommand(Command command) {
    		this.command = command;
    	}
    	
    	public void executeCommand(){
    		this.command.executeBossCommand();
    	}
    }
    

    测试类

    public class MainTest {
    
    	public static void main(String[] args) {
    		Boss boss = new Boss();
    		Command command1 = new ChoppingCommand();
    		boss.setCommand(command1);
    		boss.executeCommand();
    		
    		Command command2 = new MakeFoodCommand();
    		boss.setCommand(command2);
    		boss.executeCommand();
    	}
    }
    

    模式扩展

    情景介绍

    假如此时老板很明确的是男的佣人要去劈柴和喂马,而女佣人可以去做饭和旅游,那么这种情况下是不是可以进行扩展呢?

    主要代码

    代码分析,如果说可以扩展的话,那么其余的部分需要进行变更,也就是在上面例子的基础上只需要扩展子类即可,那么这里我不再列出其类的结构图了,因为基本是一致的。

    扩展命令角色为ManCommand和WomanCommand两个具体的实现类。

    ManCommand

    public class ManCommand extends Command{
    
    	/**
    	 * 让男人干点劈柴喂马的事
    	 */
    	@Override
    	public void executeBossCommand() {
    		this.man.chopping();
    		this.man.feedHorse();
    	}
    
    }
    

    WomanCommand

    public class WomanCommand extends Command{
    
    	/**
    	 * 让女人干点做饭和周游世界的事
    	 */
    	@Override
    	public void executeBossCommand() {
    		this.woman.makeFood();
    		this.woman.travelWorld();
    	}
    
    }
    

    测试类

    public class MainTest {
    
    	public static void main(String[] args) {
    		Boss boss = new Boss();
    		ManCommand manCommand = new ManCommand();
    		boss.setCommand(manCommand);
    		boss.executeCommand();
    		
    		WomanCommand womanCommand = new WomanCommand();
    		boss.setCommand(womanCommand);
    		boss.executeCommand();
    	}
    }
    
    从此案例可以看出命令模式的确扩展性很强 ,符合开闭原则。


    命令模式的优点

    1. 解耦:调用者和接受者之间没有关系,调用者在调用的时候,只需要执行命令(Command)中的执行方法就可以了,不需要了解哪个接收者去实际的执行。

    2. 可扩展性:Command部分容易扩展,调用者不需要知道有什么改变,维持原有的设计即可完成扩展,从这点上看,符合开闭原则,对修改关闭对于扩展开放。


    命令模式的缺点

    命令过多的时候,会导致子类过多,系统类臃肿且难于维护,不过可以结合其他的设计模式进行整合,使得优点得到更好的发挥,如结合模板方法模式解决子类过多的问题。


    命令模式的适用场景

    只要可认为是命令的地方都可以采用命令模式,比如,按钮的点击和拖拽,相当于两个命令,而按钮作为接受者,此时就可以采用命令模式进行设计。


    源码下载

    设计模式源码下载地址


    展开全文
  • 什么是debug模式,,release模式?

    万次阅读 2006-02-26 20:55:00
    以往的讨论往往是经验性的,并没有指出会这样的真正原因是什么,要想找出真正的原因通常要凭运气。最近我看了一些这方面的帖子,拿来与大家共享。 -------------------------------------- 本文主要包含如下内容: 1...
    经常有人问 Debug 运行正常但 Release 失败的问题。以往的讨论往往是经验性的,并没有指出会这样的真正原因是什么,要想找出真正的原因通常要凭运气。最近我看了一些这方面的帖子,拿来与大家共享。 
    
    --------------------------------------
    本文主要包含如下内容:
    1. Debug 和 Release 编译方式的本质区别
    2. 哪些情况下 Release 版会出错
    2. 怎样“调试” Release 版的程序
    --------------------------------------
    关于Debug和Release之本质区别的讨论
    一、Debug 和 Release
    编译方式的本质区别 Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。 Debug 和 Release 的真正秘密,在于一组编译选项。下面列出了分别针对二者的选项(当然除此之外还有其他一些,如/Fd /Fo,但
    区别并不重要,通常他们也不会引起 Release 版错误,在此不讨论) Debug 版本: /MD
    d /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库) /Od 关闭优化开关 /D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对 assert函数) /ZI 创建 Edit and continue(编辑继续)数据库,这样在调试过 程中如果修改了源代码不需重新编译 /GZ 可以帮助捕获内存错误 /Gm 打开最小化重链接开关,减少链接时间Release 版本: /MD /ML 或 /MT 使用发布版本的运行时刻函数库 /O1 或 /O2 优化开关,使程序最小或最快 /D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数) /G F 合并重复的字符串,并将字符串常量放到只读内存,防止 被修改 实际上,Debug 和 Release 并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动。事实上,我们甚至可以修改这些选项,从而得到优化过的调试版本或是带跟踪语句的发布版本。
    二、哪些情况下 Release 版会出错
    有了上面的介绍,我们再来逐个对照这些选项看看 Release 版错误是怎样产生的
    1. Runtime Library:链接哪种运行时刻函数库通常只对程序的性能产生影响。调试版本的 Runtime Library 包含了调试信息,并采用了一些保护机制以帮助发现错误,因此性能不如发布版本。编译器提供的 Runtime Library通常很稳定,不会造成 Release 版错误;倒是由于 Debug 的 Runtime Library 加强了对错误的检测,如堆内存分配,有时会出现 Debug 有错但 Release 正常的现象。应当指出的是,如果 Debug 有错,即使 Release 正常,程序肯定是有 Bug 的,只不过可能是Release 版的某次运行没有表现出来而已。
    2. 优化:这是造成错误的主要原因,因为关闭优化时源程序基本上是直接翻译的,而打开优化后编译器会作出一系列假设。这类错误主要有以下几种: (1) 帧指针(Frame Pointer)省略(简称 FPO ):在函数调用过程中,所有调用信息(返回地址、参数)以及自动变量都是放在栈中的。若函数的声明与实现不同(参数、返回值、调用方式),就会产生错误————但 Debug 方式下,栈的访问通过 EBP 寄存器保存的地址实现,如果没有发生数组越界之类的错误(或是越界“不多”),函数通常能正常执行;Release 方式下,优化会省略 EBP 栈基址指针,这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。C++ 的强类型特性能检查出大多数这样的错误,但如果用了强制类型转换,就不行了。你可以在 Release 版本中强制加入 /Oy- 编译选项来关掉帧指针省略,以确定是否此类错误。此类错误通常有: ● MFC 消息响应函数书写错误。正确的应为 afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); ON_MESSAGE 宏包含强制类型转换。防止这种错误的方法之一是重定义 ON_MESSAGE宏,把下列代码加到 stdafx.h 中(在#include "afxwin.h"之后),函数原形错误时编译会报错 #undef ON_MESSAGE #define ON_MESSAGE(message, memberFxn) / { message, 0 , 0, 0, AfxSig_lwl, / (AFX_PMSG)(AFX_PMSGW)(static_cast< LRESULT (AFX_MSG_CALL / CWnd::*)(WPARAM, LPARAM) > (&memberFxn) }, (2) volatile 型变量:volatile 告诉编译器该变量可能被程序之外的未知方式修改(如系统、其他进程和线程)。优化程序为了使程序性能提高,常把一些变量放在寄存器中(类似于 register 关键字),而其他进程只能对该变量所在的内存进行修改,而寄存器中的值没变。如果你的程序是多线程的,或者你发现某个变量的值与预期的不符而你确信已正确的设置了,则很可能遇到这样的问题。这种错误有时会表现为程序在最快优化出错而最小优化正常。把你认为可疑的变量加上 volatile 试试。 (3) 变量优化:优化程序会根据变量的使用情况优化变量。例如,函数中有一个未被使用的变量,在 Debug 版中它有可能掩盖一个数组越界,而在 Release 版中,这个变量很可能被优化调,此时数组越界会破坏栈中有用的数据。当然,实际的情况会比这复杂得多。与此有关的错误有: ● 非法访问,包括数组越界、指针错误等。
    例如 void fn(void) { int i; i = 1; int a[4]; { int j; j = 1; } a[-1] = 1;//当然
    错误不会这么明显,例如下标是变量 a[4] = 1; } j 虽然在数组越界时已出了作用域,但
    其空间并未收回,因而 i 和 j 就会掩盖越界。而 Release 版由于 i、j 并未其很大作用
    可能会被优化掉,从而使栈被破坏。
    3. _DEBUG 与 NDEBUG :当定义了 _DEBUG 时,assert() 函数会被编译,而 NDEBUG 时不被编译。除此之外,VC++中还有一系列断言宏。这包括: ANSI C 断言 void assert(int expression ); C Runtime Lib 断言 _ASSERT( booleanExpression ); _ASSERTE( booleanExpression ); MFC 断言 ASSERT( booleanExpression ); VERIFY( booleanExpression ); ASSERT_VALID( pObject ); ASSERT_KINDOF( classname, pobject ); ATL 断言 ATLASSERT( booleanExpression ); 此外,TRACE() 宏的编译也受 _DEBUG 控制。 所有这些断言都只在 Debug版中才被编译,而在 Release版中被忽略。唯一的例外是 VERIFY() 。事实上,这些宏都是调用了 assert() 函数,只不过附加了一些与库有关的调试代码。如果你在这些宏中加入了任何程序代码,而不只是布尔表达式(例如赋值、能改变变量值的函数调用 等),那么 Release 版都不会执行这些操作,从而造成错误。初学者很容易犯这类错误,查找的方法也很简单,因为这些宏都已在上面列出,只要利用 VC++ 的 Find in Files 功能在工程所有文件中找到用这些宏的地方再一一检查即可。另外,有些高手可能还会加入 #ifdef _DEBUG 之类的条件编译,也
    要注意一下。 顺便值得一提的是 VERIFY() 宏,这个宏允许你将程序代码放在布尔表达式
    里。这个宏通常用来检查 Windows API 的返回值。有些人可能为这个原因而滥用 VERIFY
    () ,事实上这是危险的,因为 VERIFY() 违反了断言的思想,不能使程序代码和调试代码
    完全分离,最终可能会带来很多麻烦。因此,专家们建议尽量少用这个宏。
    4. /GZ 选项:这个选项会做以下这些事 (1) 初始化内存和变量。包括用 0xCC 初始化所有自动变量,0xCD ( Cleared Data ) 初始化堆中分配的内存(即动态分配的内存,例如 new ),0xD
    D ( Dead Data ) 填充已被释放的堆内存(例如 delete ),0xFD( deFencde Data ) 初
    始化受保护的内存(debug 版在动态分配内存的前后加入保护内存以防止越界访问),其
    中括号中的词是微软建议的助记词。这样做的好处是这些值都很大,作为指针是不可能的
    (而且 32 位系统中指针很少是奇数值,在有些系统中奇数的指针会产生运行时错误),
    作为数值也很少遇到,而且这些值也很容易辨认,因此这很有利于在 Debug 版中发现 Re
    lease 版才会遇到的错误。要特别注意的是,很多人认为编译器会用 0 来初始化变量,这
    是错误的(而且这样很不利于查找错误)。 (2) 通过函数指针调用函数时,会通过检查栈
    指针验证函数调用的匹配性。(防止原形不匹配) (3) 函数返回前检查栈指针,确认未被
    修改。(防止越界访问和原形不匹配,与第二项合在一起可大致模拟帧指针省略 FPO )
    通常 /GZ 选项会造成 Debug 版出错而 Release 版正常的现象,因为 Release 版中未初
    始化的变量是随机的,这有可能使指针指向一个有效地址而掩盖了非法访问。 除此之外,
    /Gm /GF 等选项造成错误的情况比较少,而且他们的效果显而易见,比较容易发现。 三、
    怎样“调试” Release 版的程序 遇到 Debug 成功但 Release 失败,显然是一件很沮丧
    的事,而且往往无从下手。如果你看了以上的分析,结合错误的具体表现,很快找出了错
    误,固然很好。但如果一时找不出,以下给出了一些在这种情况下的策略。 1. 前面已经
    提过,Debug 和 Release 只是一组编译选项的差别,实际上并没有什么定义能区分二者。
    我们可以修改 Release 版的编译选项来缩小错误范围。如上所述,可以把 Release 的选
    项逐个 注:那篇文章到此就完了,好像还有一些没了
       在VC中当整个工程较大时,软件时常为出现在DEBUG状态下能运行而在RELEASE状态下无法运行的情况。由于开发者通常在DEBUG状态下开发软件,所以这种情况时常是在我们辛苦工作一两个月后,满怀信心的准备将软件发行时发生。为了避免无谓的损失,我们最好进行以下的检查:
    1、时常测试软件的两种版本。
    2、不要轻易将问题归结为DEBUG/RELEASE问题,除非你已经充分对两种版本进行了测试。
    3、预处理的不同,也有可能引起这样的问题。出现问题的一种可能性是在不同版本的编译间定义了不同的预处理标记。请对你的DEBUG版本的软件试一下以下改动: 在"Pro
    ject Setting(ALT-F7)" 中的C/C++项中设置目录(category)为"General",并且改动"_DE
    BUG"定义为"NDEBUG". 设置目录为"Preprocessor"并且添加定义"_DEBUG到"Undefined Sy
    mbols"输入框. 选择Rebuild ALL,重新编译. 如果经过编译的程序产生了问题,请对代码
    进行如下改动: 将ASSERT() 改为 VERIFY(). 找出定义在"#ifdef _DEBUG"中的代码,如
    果在RELEASE版本中需要这些代码请将他们移到定义外。 查找TRACE(...)中代码,因为这
    些代码在RELEASE中也不被编译。 所以请认真检查那些在RELEASE中需要的代码是否并没有
    被便宜。
    4、变量的初始化所带来的不同,在不同的系统,或是在DEBUG/RELEASE版本间都存在这样的差异,所以请对变量进行初始化。
    5、是否在编译时已经有了警告?请将警告级别设置为3或4,然后保证在编译时没有警告出现.
    6、是否改动了资源文件.
    7、此外对RELEASE版本的软件也可以进行调试,请做如下改动: 在"Project Settings" 中 "C++/C " 项目下设置 "category" 为 "General" 并且将"Debug Info"设置为 "Program Database". 在"Link"项目下选中"Generate Debug Info"检查框。 "Rebuild All" 如此做法会产生
    的一些限制: 无法获得在MFC DLL中的变量的值。 必须对该软件所使用的所有DLL工程都
    进行改动。 另: MS BUG:MS的一份技术文档中表明,在VC5中对于DLL的"Maximize Spee
    d"优化选项并未被完全支持,因此这将会引起内存错误并导致程序崩溃。
    展开全文
  • 简言:java中总共有23种设计模式,每个模式的出现都是为了解决某一方面的问题,所以这23种设计模式有他们各自适用的地方(废话有点多),而设计模式的产生主要是为了降低类与类之间的耦合度。下面我们就简单的了解...
  • 设计模式大全

    万次阅读 热门讨论 2006-12-22 21:07:00
    Longronglin之设计模式:Christopher Alexander 说过:“每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动”。模式描述为:在...
  • 【C#进阶3-4】C#设计模式

    千次阅读 2020-05-19 10:00:41
    文章目录一、目录二、设计原则三、创建型模式3.1、单例模式(Singleton Pattern)3.2、工厂方法模式(Factory Pattern)3.3、抽象工厂模式(Abstract Pattern)3.4、建造者模式(Builder Pattern)3.5、原型模式...
  • 【设计模式】一文学透代理模式

    千次阅读 2021-04-03 11:18:43
    文章目录1、前言1.1、定义1.2 代理模式的实现1.3 代理模式的应场景1. 4 代理模式的分类:2、静态代理1.)首先新建一个买车的接口2.)声明一个要买车的客户,实现买车接口3.)声明一个买车代理汽车4S店,同样也实现买...
  • 设计模式之SOLID原则再回首

    千次阅读 2014-11-29 20:42:23
    这是一篇关于回顾设计模式SOLID五大原则的文章,我非常喜欢文章中的例子,每个例子都是我精选了描述模式的,通过Modom讲述了单一职责原则、通过加减法计算器讲述了开闭原则、通过企鹅动物讲述了里氏替换原则、通过...
  • 设计模式

    千次阅读 2012-07-05 13:33:31
    设计模式和框架  可复用面向对象软件系统现在一般划分为两大类:应用程序工具箱和框架(Framework),我们平时开发的具体软件都是应用程序,Java的API属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作...
  • 我们之前通过support-confidence association rule mining framework得到的规则不一定是有趣的,所以它不足以进行模式评估,甚至在一些情况下,甚至常用的lift和chi-square measures也没有很好的效果。...
  • 设计模式整理

    千次阅读 2015-04-03 16:54:49
    Christopher Alexander 说过:“每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动”。 模式描述为:在一定环境中解决某一...
  • 设计模式精解

    千次阅读 2012-05-18 09:52:37
    [编辑本段] 定义 ... 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。  GoF(“四人帮”,指Gamma, Helm, J
  • 【设计模式】观察者模式

    千次阅读 热门讨论 2016-11-04 19:55:00
    事实说明什么是观察者定义:  相信大家都聊过QQ、WeChat,那我们就用这个来讲述什么事观察者模式。就拿qq来说吧,我们大家都有三到好几个qq群,而我们都是qq群里面的一员,在我们没有屏蔽群消息的前提下,群里只要...
  • 关于Java 23种设计模式的有趣见解

    千次阅读 2016-04-15 13:00:56
     在网络上流畅很广的一篇旧文,暂时没找到原作者,目前所看到的最早转载时间是 2005 年 2 ...轻松的语言,形象解释了 23 种模式,有很好的启发作用。  创建型模式  1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和
  •  著名市场研究机构福莱斯特(Forrerster)研究公司最近公布的一项研究报告称,在今后4年之内,万维网将从目前的广告收费模式——即根据每千次闪现(impression)收费——CPM(这亦是大多数非在线媒体均所采用的模式)变为...
  • 23个设计模式

    千次阅读 2012-08-26 16:04:21
    设计模式分为三种类型,共23类。... 行为型模式:模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。  按alpha
  • 一、读后感 虽然商业模式方面小白一枚,但深感此书写的十分赞,深入浅出剖析平台战略的商业模式,如何做大做。其中的例子贴切易懂。匹配当前众多的超级平台,中兴平台等,无不符合平台战略的商业模式。 平台战略的...
  • [大话技术]话聊有趣的23种设计模式

    千次阅读 2016-09-15 22:13:30
    在网上看见了23种设计模式的有趣见解这篇文章,作者以轻松的语言比喻了java的23种模式,觉得蛮有意思的,我在其基础上再加工一下,分享给大家.大家一起学习.一起进步. 1、FACTORY(工厂模式) 追MM少不了请吃饭了,...
  • 对23 种设计模式的有趣见解

    千次阅读 2012-07-05 15:19:37
    创建型模式 1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅...
  • 乱砍设计模式之一 -- STRATEGY 模式

    千次阅读 2010-08-04 17:36:00
    乱砍设计模式之一 -- STRATEGY 模式—赵子龙单骑救主
  • 23种设计模式分析(4):结构型模式

    千次阅读 2014-04-05 22:37:27
    1.1.9 Composite复合模式  Composite(复合、合成、组合)模式是一种结构型模式,定义:将对象组合成树形结构以表示“部分-整体”的层次结构,它使得客户对单个对象和复合对象的使用具有一致性。  这里的复合...
  • 设计模式通俗理解

    千次阅读 2016-08-22 22:05:15
    第10个设计模式,享元设计模式 运用共享技术有效地支持大量细粒度的对象
  • JAVA 23种设计模式简介

    千次阅读 2017-03-24 10:32:48
    设计模式(Design Patterns) ——可复用面向对象软件的基础...设计模式的分类 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代
  • GOF设计模式

    千次阅读 2012-07-14 10:54:29
    GoF:(Gang of Four,GOF设计模式)---四人组 Design Patterns: Elements of Reusable Object-Oriented Software(即后述《设计模式》一书),由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides ...
  • 简明设计模式

    千次阅读 2010-09-12 20:39:00
    <br />设计模式 收藏 转贴:...这本书通常被称作"Gang of Four"或"GoF",开创性的创造了《设计模式》。   也有人说"三十六计"就是"模式"。  
  • 大数据架构和模式

    万次阅读 2016-03-14 12:10:41
    研究市场竞争对手的行动、发挥作用的市场力量,以及客户在寻找什么,会很有帮助。下表给出了来自各行各业的用例示例。 表 1. 来自各行各业的示例用例 行业 示例用例 电子商务和在线零售 电子零售商(比如 eBay)在...
  • 设计模式源代码下载 设计模式源代码下载 1 模板方法模式 模板方法模式定义了一个算法的步骤,并允许子类别为一个或多个步骤提供其实践方式。让子类别在不改变算法架构的情况下,重新定义算法中的某些步骤...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 44,613
精华内容 17,845
关键字:

强行动模式是什么