文档章节

管理军规200条

疯狂的兔子
 疯狂的兔子
发布于 2015/04/20 18:01
字数 8519
阅读 8
收藏 0

背景

Ray Dalio 是 Bridgewater 的创始人。Bridgewater 是美国最成功的投资公司之一。其成功程度应该不亚于伯克希尔哈萨维公司,Ray Dalio 最近发表了一篇文章,总结了公司成功的一些原则和200条管理经验。在这里翻译给大家分享。

原则

从文章来看,Ray Dalio 是强科学主义者,反馈、循环、改进提升的概念贯穿始终。

文章的原则部分,基本上可以总结成若干条:

  • 企业是一部机器,构成成分是人和文化

  • 企业这部机器输入的是目标,输出的是结果,并且具备输出反馈,不断通过结果调整机器以便达到目标,甚至调整目标,以便达成改进后的“目标”

分类

下面的200条军规,实际上分成几大类:

  • 找到正确的文化,是第1条到第36条介绍的内容

  • 找到正确的人,是第37到127条的内容

  • 分析、诊断和解决问题,是第128条到189条的内容

  • 高效的决策,是第190条到210条的内容

上面的每个大类又继续细分成若干个子部分,每个子部分又进一步细化成实际的细则,我会在下面用章节的方式区分开

军规200条

找到正确的文化

相信真相

  • 坚信真相没什么可怕的;

  • 创造一个环境,让人人都有权利知道真相;无人可以未经发言便持批判的观点;

  • 极度开放;

  • 为人正直、诚恳,同时也如此要求他人;

    • 决不说那些你不能当面和别人说的话,别在当面批评别人之前说话;

    • 莫让“忠诚”凌驾于真相和思想开放之上。

  • 极大透明

    • 所有会议都要有记录并且要与所有相关人员分享;

  • 不容任何不诚实的行为;

    • 如果有人犯过不诚实的言行,那就别指望他会彻底改正不会再犯。

建立这样一种文化: 允许犯错误,但不容忍不去从错误中标识、分析和学习经验的行为

  • 要知道:高效的、创新性的行为是可能会犯错误的;

  • 不要因为自己或他人犯的错误而烦心,而是要热爱错误;

  • 观察错误的模式,看看它们是不是弱点的产物;

  • 不要因为自己或他人的弱点而烦心;

  • 别纠结于是否好看,去纠结如何实现目标吧;

  • 抛开“责备”或“褒扬”,把注意力集中到“精准”和“错误”上;

  • 将错误的责任定位的到具体的个人;

  • 记录下自己和他人的弱点以便于牢记和了解弱点;

  • 如果经历痛苦,记得反映出来;

  • 自我反省,同时保证自己的团队能够做到自我反省;

  • 教育并加强员工们从错误中学习的意识

    • 错误学习这方面,我们最有价值的工具是“事件日志”(详见后文),这是我们用来标识错误以及从错误重学习进步的工具。

持续的保持同步

  • 对什么是真相,以及如何对待之需要持续不断保持同步

  • 讨论“这是真的吗?”和“这靠谱吗?”

  • 为正确而战;

  • 观点明确的同时态度开放

    • 扪心自问是否取得发表意见的权利;

    • 清楚自己拥有产生问题并且提问的权利;

    • 区分思想开放和思想封闭的人;

    • 不要与思想封闭并且毫无经验的人打交道;

    • 切忌自大者对其毫无经验的领域妄加评论;

    • 警惕那些觉得“不知道就很丢脸”的人(不知道很光明正大,没必要觉得丢人)

  • 确保负责的团队以开放的思维对待别人的质疑和批评;

  • 清醒的认识矛盾和摩擦是形成良好关系的基本要素,因为矛盾是人们判断相互之间原则是否一致的方法,也是人们协调解决这种不一致的方法;

    • Bridgewater的开放性分歧比绝大多数其它公司都多;

    • 分歧蕴涵巨大的潜能,尤其是有思想有见地的人之间的分歧;

  • 知道何时应当停止辩论并就要做的事情达成一致。

    • 当人们对某个话题是否有有辩论的必要性时,那就应该讨论下去;

    • 意识到“条条大路通罗马”。判断一个负责的团队是否尽其责应当看其是否用正确的方法做事情而非按照某人的意愿做事情。

    • 为了让分歧产生积极效应,人们在评价某个决策或者某个决策者的时候,应当从一个更为广阔的背景下看待问题;

    • 学会识别两种“投诉”:1)无意义的抱怨;2)能导致改进的抱怨;

  • 理解这一点:公开的辩论并不等于通过全民投票建立规则;

  • 评价一个事件是否会引起辩论、探讨或学习;

    • 避免引起混淆,弄清自己参与的是何种类型的交谈(辩论、探讨或是学习);

    • 如果目的是得到最好的答案,那应当让最相关的人参与沟通;

    • 如果目的是教育或者提升凝聚力, 那应当让比上面那条更广泛的人参与沟通;

    • 平衡并优化你的沟通。

  • 不要把所有观点都看作同样重要;

    • 观点的价值是有级别差别的,这个规律不仅是观点的普遍现象,而且还是观点的本质

  • 考虑自己和他人的可信度;(鉴于可信度比较抽象,难以精确衡量,我们可以通过个人的推理能力及其以往表现进行判。)

    • 自问是否赢取了提出观点的权利。通常来说,如果你有骄人的、有目共睹的业绩表现,那么你可以就问题提出自己的观点,否则,纵然你有通篇理论和问题,也最好不要发言;

    • 最可信的人是能够不断的成功解决问题,并且在被问询时能够提供详解的人,不具备这两个特质的员工是最不值得信赖的;

    • 如果有人向你提问,首先自问是否能对这个问题负责,以及是否为回答问题的合适人选;

  • 不要吝啬把时间和精力投入到“保持同步”里头。因为这是你最好的投资。由于时间限制,你将不可避免把事情进行先后排序,但是要意识到由于缺少高效沟通而导致的巨大代价;

  • 如果是由你主持的会议,要组织好对话;导致会议进展缓慢的原因很多,但往往是由于缺少对讨论主题的清晰了解。实现会议有效的进展,要做到:

    • 弄清会议的目的以及谁是会议的主导;(directing the meeting)

    • 依据目标的优先级弄清楚你将要进行何种类型的交流;

    • 在引导讨论时,要果断且开放;

    • 一场由3到5个聪明、概念清晰的人,以开放思维的方式寻找解决问题的办法找到的方案往往是最好的;

    • 1加1大于3;

    • 明确的引导讨论的水平

    • 切忌跑题;

    • 加强对话的逻辑;

    • 注重对话的内在本质而非外在风格;在某些特定的环境下,与某些特定的人进行沟通时,谈话的外在风格可以让谈话效率更高,但不要让所谓的风格或 腔调阻碍了同步。如果你认为有人的谈话风格有问题,把这个问题独立出来,(比如询问“情况是否属实”或者“这个事情是否重要”等等)。

    • 保证对话的完整。很多对话通常都不了了之,最终没有得出任何结论或者没有人采取任何实际措施,这样会浪费彼此的时间。

    • 开会时一定要指派人做会议纪要,并确保会议上的议题得到落实;

    • 群体决定不等于个人不负责。

  • 让大家明白:抱怨、建议、辩论的权利和决策的权利是两个不同的概念,切勿混淆;

  • 明白保持同步是双方的责任;

  • 如果无法保持同步,就升级

找到正确的人

记住: 你所做的最重要的决定就是选择谁来作为你的负责人群

  • 记住:几乎所有好事都是一堆优秀的人操作一种优秀的文化得到的

  • 让合适的人做对应的事

    • 最重要的一点是找到和你具有共同价值观的人;

    • 寻找愿意客观看待自己的且有个性人;

    • 选择某个目标(而不是某个任务)的负责人之时,应当找概念清晰、有常识的人;

  • 记住:负有不可推卸责任的阵营就是承担所作所为后果的一方。

  • 时间会给你一切应得的补偿

  • 最重要的责任阵营是那些对目标、产出、和机器(见原则)负有最大责任的人群(他们通常在权力金字塔顶端)

  • 选择那些明白目标和任务的区别的人办事;

要知道: 人与人之间差异是非常大的

  • 想想每个人独特的价值、能力和技能;

  • 了解每一个为你工作的人,这样你才能知道从他们身上能得到什么;

  • 要做到你雇来工作的人必须能够满足这个工作岗位的要求;

  • 使用个性评估测试和经验质量反馈来区别这种不同

  • 要明白看待以及思考问题的不同方式决定了不同的人适合不同的工作:

    • 员工往往在从事他们最擅长的工作时表现最为突出;

    • 即使你天生不擅长某种思考类型,也不意味着你不能依照这种思维办事;

  • 不用隐藏这些差异。带着研究自己和员工不同特质的目标,开放的研究这些差异,这样,我们才能让合适的人做合适的事,并且实现清晰的授权;

  • 要记住:用一种方式看待事情和思考问题的人往往不善于与思维方式不同的人沟通和相处;

招聘正确的员工, 因为招聘失误的后果很严重

  • 思考你要寻找的是哪种价值、能力和技巧;

  • 在衡量是否录用某个候选人时,价值和能力比技巧更重要;

  • 在你的jd(工作描述)里头写上你需要的人的特征;

  • 选择合适的人,对其进行所需的特质进行评测,然后把评测结果和你认为工作所要求的水准进行对比;

    • 记住:人们通常会选择“像”自己的候选人,所以,选择那些具备你需要的素质的人当面试官

    • 懂得如何利用和解读性格测试;

    • 关注候选人的日常表现;

    • 挖掘出候选人过去行为的深层原因;

    • 要意识到候选人在学校的表现并不能证明此人具备了你所需要的能力和价值;

    • 让候选人提供以前供职公司对其的工作评价;

    • 核对候选人的推荐信息;

  • 选择那些总有很多好问题的人;

  • 确保候选人访问了你和Bridgewater

  • 不要录用仅仅能够胜任Bridgewater工作职位要求的候选人,要录用那些你想与之分享生活的人;

  • 录用那些与众不同的人,而非路人甲、路人乙;

  • “听音开锁”:找到人与事/角色之间最佳的匹配;(注1)

  • 薪水是付给人的,而不是付给工作的;

  • 记住:不管你在招聘这方面做得有多好,你都很有可能招到并不是你需要的做该项工作的最佳人选;

像亲自设计和操作机器的人(比如奔驰)一样去管理团队以达到目标

  • 懂得管理、微管理以及放任不管三者之间的差别;

    • 管理向你汇报的人应该像“在一起滑雪”

    • 一个优秀的滑雪者对其它滑雪者的评论通常比一个新手的评论更尖锐,更有效

  • 经常拿你的输出和你的目标进行对比

  • 从更高的高度俯览你的机器,以及身在其中的你

  • 把手边的个案和自己的原则联系起来,以便将来能处理那类事情

  • 出现问题的时候,在两个层面归纳讨论:1)“机器”层面的讨论,讨论为何出现这种结果;2)“眼前问题”的讨论,讨论当下应该如何处理这个问题

  • 别想着被追随,想着被理解和理解别人

    • 别尝试通过下命令来控制别人

    • 沟通逻辑并欢迎反馈

  • 明确授予责任

  • 让人们负责,同时要感激那些向你负责的人

    • 区分违反“合约”(承诺)的失败和根本没有从合约开始的失败

  • 避免“将熊熊一窝”

    • 警惕分不清目标和任务的人,因为你不能让那些不能理解目标的人负责

  • 以主人翁心态思考问题,同时要求和你共事的人也这样思考问题

  • 强迫自己,以及与自己共事的人去做更难的事情

    • 让自己和同事负责

  • 别在乎别人是否喜欢你,你需要在意的是你是否在协助你的团队以及Bridgewater变的更伟大;

  • 了解自己想要什么,并且,如果你认为是对的,那就坚持它,即使别人想让你进入其它方向

  • 清晰地沟通计划

    • 所有人都知道并且同意目标和任务(包括负责部门的同事和监管部门的同事)

    • 警惕那些发散的、低效的“我们应该。。。(做这做那)”

  • 和你的姐妹弟兄保持持续的同步

  • 获得足够的理解

  • 避免时间空间间隔太久太远

    • 使用日报工具,保持对自己的弟兄所做所想的了解

  • 在过程中培养对部属的自信心,不要盲信

  • 根据信心指数动态调整参与程度

  • 避免“理论上应该”

  • 关心为你工作的人

  • 逻辑、因果和常识在决策中的位置应该是至高的

  • 逻辑驱动我们的决策,但感觉也是非常相关的

  • 如果没法保证自己能够负责,那么升级吧!确保和你共事的人也这么做

    • 确保你的同事工作效率足够高(如果他们觉得不能完成共识的目标,必须说出来,这个沟通至关重要)

    • 工具:升级按钮

  • 碰到实质的跨部门或者跨子部门的问题时,把金字塔尖的人拖进来

深入探索和挖掘能从你的“机器”里头获得什么东西

  • 了解你的人的风格,并且确保他们做事的时候保持这个风格

  • 持续了解向你汇报的人,并且鼓励他们了解你

    • 提醒你在了解的人,问题和错误是改进的动力

  • 了解那些层级比直接为你干活的人低的人

  • 要记住很少有人能客观看待自己,所以欢迎被了解,以及了解别人很重要。

  • 多观察、多了解,掌握充分信息,在爆发问题之前,先把握问题是否有可能发生。

    • 当危机正在酝酿的时候,团队的联系应该紧密到好像不可能有意外那样

    • 调查,并且让人们知道你要调查,以免让人意外,或者是觉得是真对个人的

  • 别“选择性战斗”,而是看见问题就要处理

  • 别让人们掉链子

  • 别假设人们的回答是正确的

  • 公开调查,而不是私下

准确的评估别人, 而不是“友善”的评估别人

  • 准确的评估

    • 使用类似表现调查表、评估矩阵和正规面谈这样的工具纪录一个人所有方面的表现。这些可以帮助澄清评估和评估相关的沟通。

    • 为你的人维护一组拍画卡(注2)和/或“信任矩阵”

  • 在评估人员方面,对待工作候选人和雇员一视同仁,同样严格

  • 知道你的人的动力(注3)是什么,因为人是你最重要的资源

  • 深知这个定律:尽管大多数人都喜欢被表扬而不喜欢被批评,但是没有比准确的批评更有价值的东西了

  • 人材发现与评估的过程需要做到公开、渐进与周而复始

  • 提供持续、清晰、诚实的反馈,并且鼓励对这种反馈的讨论

    • 把表扬和批评都做到清晰、明确,避免猜忌

    • 请记住:让人认识自己的能力要比让人认识自己的缺点更容易

    • 鼓励客观的的反应

    • 雇员评估:反馈是持续的、评估是周期性的

  • 理解这一点:你管理的人员会经历一个个人评估的过程

  • 认识这一点:你在Bridgewater的进化是在发现你自己的优缺点过程中的一个相对快速且自然的结果,因此,你的职业规划不会在一开始就设置好。

  • 记住:你观察人们在做什么事情的唯一目的是看看他们像什么类型的人。知道像哪种类型,就可以预期他们能如何处理自己的责任。

    • 观察行为的模式,但不要在一个具体事件中得出太多的结论

    • 不要认为一个人在某件事上头的好坏能决定这个人的好坏

  • 如果某人做事太差劲,思考一下这是因为缺乏学习(比如,培训/经验等),还是缺乏能力。培训和经验是时间可以弥补的,能力是没人能帮上忙的

  • 请记住,在评估人的时候,最大的两个错误是对自己的评估过份自信以及没能及时同步你做的评估。别犯这些错误

    • 在给出评估的时候要直接面谈,避免通过层级进行

    • 通过对错误和错误的根源进行非常坦率的沟通了解你的人,以及让你的人了解你

  • 帮助人们渡过认识自己的缺点的难关

  • 记住:当你真的和人们在弱点上(不管是你的还是他们的)达成同步了,那可能是真的。

  • 记住:在判断一个人的时候,你没必要达到“毫无怀疑”的地步。达到大部分的共识的程度然后逐步增进了解即可。无需过份追求完美。

  • 要明白:和一个人共事的头一年,就可以让你在很大程度上了解这个人的风格,以及他们在工作上是否足以胜任。

  • 一个人只要呆在Bridgewater,就要持续地评估之

通过经验训练和测试人材

  • 要知道:训练实际上引导个人进化的过程

  • 要知道:经验创造知识

  • 提供持续的反馈,让学习可以被接受

  • 记住:所有的事情都是案例分析。需要区分个例和原则的不同。

  • 授之以渔,而不是授之以鱼

  • 请注意,有时候让人们自己犯错然后从错误中学习经验,要比告诉他们更好的决策要好。

    • 批评的时候,争取给出有用的建议

    • 从成功中学习,一如我们从失败中学习

  • 知道可接受的错误和不可接受的错误是什么,别让给你干活儿的人犯下不能接受的错误

  • 要记住行为的改变通常需要十八个月的强化

  • 训练人,而不是改造人

    • 常见的错误:对一个表现不好的人进行培训或者考试,以判断他是否能获得所需的技能,但是却没有评估他的能力

  • 在你判断“什么是真相”(也就是说,在你了解你的人是什么类型的)之后,认真考虑下“该做什么”

Bridgewater的转岗或者解聘

  • 如果你发现某人不适合某个工作,让他离开那个岗位,越快越好

  • 要知道,把一个人放在一个不适合他的岗位,比解雇他更糟糕

  • 当缺乏某个人的位置的时候,思考下Bridgewater有没有更适合他的位置,如果没有,解雇他。

  • 不要降低标准

分析, 诊断和解决问题

了解如何有效的洞察问题

  • 记住本书第二部分介绍的5步法(注6)

  • 明白这个道理:洞察问题是迈向伟大的管理的第一步

  • 明白问题是改进的原动力

  • 你必须能识别事务是高于水准(也就是好事),还是低于水准(也就是不够好),并且要保证自己的人也能识别。

  • 不要容忍坏事

  • 主动尝试

  • 让尽可能多的人看到问题

    • 打开瓶塞(注4)。

    • 要求人们对自己的抱怨负责

    • 领导必须鼓励不同意见并且公正、开明

    • 最接近某项工作的人可能是了解该工作最充分的人,或者是至少具备你需要了解的实情的人,所以这些人是实现改进的基础。

  • 要想深入了解问题,就要对比实际工作结果和你的期望有何差别(注5)。

  • 不要使用匿名的“我们”、“他们”,因为这样会掩盖个人责任——用具体的名字。

  • 具体描述问题,不要从一般化的东西开始。

  • 工具:使用下列工具来捕获问题:事件日志、矩阵、调查、检查表、外部顾问、内部审计。

  • 最常见的无法识别问题的原因是我说的“温水煮鳖”问题——不能识别问题本质都是因为我们是温水煮的鳖,习惯了。

  • 有时候,人们接受那些不可接受的问题是因为这些问题被认为太难改正。但是改正不可接受的问题通常都比不改正要容易的多,因为不改正它们会让你死的很惨。

  • 具备很好的,有计划的解法的问题,是和那些不具备的问题截然不同的。

诊断并理解问题是什么事物的症状

  • 记住,所有问题都是其根本原因的表象,因此要诊断并理解问题是什么东西的症状。

  • 要明白诊断是进步和高质量人际关系的基础

  • 诊断的时候询问下面的问题

    • 询问经历问题的人:你经历的欠佳的体验是啥?

    • 询问相关领域的管理人员:有谁对整个“机器”负责并且可以回答你的输出和预期之间执行情况的问题?谁负责?

    • 询问责任方:这事在你头脑里应该怎么运作?

    • 询问责任人:是什么因素导致问题?是设计的问题还是设计中人员的行为的问题?

    • 询问“涉案”人员:为何他们以那种方式处理问题?

    • 询问“涉案”人员:这个问题是否广泛地和之前的模式一致(是/否/不确定)?系统化的解决方法是什么?系统/机器/责任人通过这个事件应该如何进化?

  • 请记住:根本原因不是行动,是原因。

  • 标识出失败是在5步法(注6)里头的哪一步发生的。

  • 记住:正确的诊断需要高质量的、合作的、诚实的讨论才能获得真相

  • 请记住,诊断是要生成输出的

  • 不要从一“点”(一个特定的输出)得出太多推论 - 快速榨取尽可能多的“点”,合成一个更丰富的图像,然后和其他人一起分析分解(注7)之。

  • 通过持续的诊断维持不断合成的图像

  • 如果要区分容量问题和能力问题,可以设想一个人在具备充分容量的情况下,在自己的角色上能表现出什么水准

  • 管理人员不能产出优秀的结果或升级通常是因为:

    • 他们也被解雇了

    • 他们无法判断高质量的差异

    • 他们被温水煮鳖了——习惯了

    • 他们太过自信,以至于不能承认自己无法解决自己的问题

    • 他们担心承认失败之后的广告效应

  • 避免“事后诸葛亮”(注8)

  • 标出违反了的原则

  • 请记住,如果你让同一个人干同样的事情,你应该预期有同样的结果

  • 使用如下(注10)的“钻探”技巧获取一个有问题的部门或者子部门的总体(注9)了解

    • 步骤一,列出问题

    • 步骤二,标识根本原因

    • 步骤三,制定一个计划

    • 步骤四,实现这个计划

全面看待事物

  • 先总结后前瞻

    • 工具:让新员工听录音,听听历史故事,让他们了解充分

  • 理解“高于标准”和“低于标准”的思考方式,以及了解如何在这两种方式之间定位

设计你的机器以实现目标

  • 记住:你是要设计一个会产出结果的“机器”或者系统

    • 短期目标通常不用你去设计机器

    • 当心,别因为眼前的事太多而忘记自己的责任、忘记自己的机器该如何运作以达到目标

  • 谋定而后动,磨刀不误砍柴工

  • 你制定的组织结构应该是问题最小化、机会资本最大化的

  • 把自己放到“痛苦的位置”。放一阵子,以获取自己需要设计的机器的更多的理解。

  • 注意:设计是一个逐步迭代的过程,在糟糕的“现实”和美好的“未来”之间的是“让我们搞定它”的阶段

  • 评估可选的机器和它们的输出结果,然后选择

  • 与首要结果一样考虑次要结果和次次要的结果

  • 最重要的是,围绕目标建立组织结构,而不是围绕任务

    • 首先拿出最好的工作流的设计,在组织结构图里头画出来,观察交互的各个部分,注明每个工作要求什么样的质量,完成这些之后,再选择合适的人填充到具体的工作中去

    • 围绕最具逻辑性的分组来建立部门和子部门

    • 尽可能令部门自给自足,这样它们可以控制达到目标所需要的资源

    • 组织效率的降低、官僚气息的增强,是和组织里头的人数和组织的复杂程度成正比的。

  • 自上而下制定组织结构

    • 每个人都必须有高质量的、可信的人监管

    • 每个金字塔尖的人都必须具备管理他们的直接汇报者的技巧和注意力,并且深刻理解自己的工作

    • 高级经理和初级经理的人数比,以及再下两个层级的层级间人数比,应该予以限制,这样才能保持高质量的沟通和共同理解。一般不要超过1:10,最好是1:5左右

    • 自顶向下的层级数和管理人员与直接汇报者之间的人数比会约束高效组织的规模

    • 组织越大,下面两个事情越重要:1)管理中的信息技术专业水平;2)跨部门沟通

    • 不要为了配合人而建立组织结构

  • 尽可能清晰的责任定义和汇报线定义

    • 组建的组织结构看上去应该像金字塔,线条笔直向下,没有交叉

  • 经常思考如何产生提升

    • 你应该能够委托别人处理细节

    • 通常来说,找几个聪明人,然后给他们最好的装备,要比找一大堆平庸且装备不良的人要好

    • 使用杠杆

  • 了解“苜蓿叶”(注11)设计 —— 通过相同结构的适当冗余获取最大的成功可能

  • 在没有周知其它部门的老板的情况下,不要为其它部门干活儿,也不好抓其它部门的人来给你干活儿

  • 警惕“部门越界”

  • 根据工作流程设计和人们的能力分派责任,而非根据头衔

  • 警惕顾问的滥用

  • 工具:维护一个过程手册

  • 工具:使用检查表

    • 不要混淆检查标和个人责任之间的关系

    • 请记住:系统化并不意味着计算机化

    • 为确保关键任务的成功,应该用“冗余执行”的方案,而不是“重复检查”

  • 警惕工作滑坡——没有明确思考和同意的工作改变,通常因环境变化或者临时需求导致

  • 想清楚事情该怎么干,如果事情没按预计进行,承认并调查之。

  • 把握全局,避免被别人欺骗,确保信任不是问题。

    • 负责审计的人应该向被审计部门之外的对象汇报,审计过程不应该让被审计的对象知道

    • 请记住:如果没有警察(审计员),法律/规则的存在就没意译

做你计划要做的

  • 推进!

高效的决策

要令决策高效, 就要认识到“知道如何对付未知”的威力

  • 要记住你的目标是为了得到最佳答案,而你得到最佳答案的可能想很小,即使你得到了,你也不能百分之百确认这个就是最佳答案,除非通过了其它可信之人的测试

  • 理解这点:处理未知的能力要比处理已知的能力更强大

    • 拥抱提问的威力:“我不知道啥?以及我应该怎么处理它们?”

    • 寻找成功的路径至少和发现正确的问题以及找到相应的答案是相关的

  • 记住:你的目标是找最佳答案,而不是给出你已有的最佳答案

  • 虽然每个人都有权利提问和有权拥有理论,只有可信之人才有权利拥有观点

  • 经常担心自己是否缺少什么东西

    • 成功人士请别人提出批评,并且思考其中的优点

    • 分解调查你的看法

让自己所有决策都有逻辑性, 以及计算预期的价值

  • 考虑结果的可能性和代价,确保不可接受结果的可能性为0

    • 糟糕的决策造成的损失等于或者大于好决策带来的收益,所以知道自己不知道什么至少是和知道自己知道什么同样宝贵的事情

    • 识别出来损失小、收益大的机会,即使收益发生的可能比较慢

    • 准确评估自己正确的可能性可以提高你的决策正确的可能性——能认识这点是非常宝贵的

  • 别在任何事情上赌太大。打15个或更多的,不相关的赌。

记住80/20定律, 知道关键的20%是什么

  • 区分重要和不重要要的事情,先做重要的事

    • 不做完美主义者

    • 因为80%的成果来自20%的努力,所以决策的时候,通常只需要考虑少数几个重要的事情(通常少于5个)。

    • 警惕“细节恐怖症”

  • 决策的时候,考虑一下多花时间获取更多信息来决策带来的边际效益与推迟决策带来的边际成本之间的关系——这个对决策的速度有影响

  • 在干任何其它事情之前,确保“必须做的事情”都高于平均水准

  • 记住:最好的选择是优点多过缺点的选择,而不是那些没有缺点的选择。要警惕那些只是因为发现某事有缺点而反对之,但却没有合理地思考全部优点和缺点的那些人。

  • 警惕毫无效率的列出可能的排列组合,而不给予可能性的行为,因为这种行为破坏了优先级

  • 理解概念,使用“大概”这样的字眼

    • 如果你问某人某事是否属实,回答说:“它可能不完全正确”,那么很可能这个事是对的

综合

  • 理解采样点并且将其概念化、抽象化

  • 理解可以接受的改进速率是多少,并且要明白,有意义的是改进速率这个标准,而不是改进速率本身

  • 如果你的最好的方案都不够好,那么就更认真地想想,或者升级问题,告知大家你不能思考出一个足够好的方案

  • 拒绝在不能降低标准的方面降低标准的诱惑

  • 不要试图让所有人都开心


© 著作权归作者所有

共有 人打赏支持
疯狂的兔子
粉丝 34
博文 178
码字总数 101541
作品 0
北京
后端工程师
信息安全管理的二十条军规

棱镜门事件至少告诉了我们一个事实,那就是NSA的安全技术和管理水平领先业界至少3-5年。 企业今天面临空前的安全威胁,犯罪集团、黑客散客、竞争对手、内部员工…如果没有周密的安全管理体系...

Cashcow
2014/02/17
0
0
「Mysql数据库」MySQL数据库开发的 36 条军规!

核心军规 尽量不在数据库做运算 控制单表数据量 纯INT不超过10M条,含Char不超过5M条 保持表身段苗条 平衡范式和冗余 拒绝大SQL,复杂事务,大批量任务 字段类军规 用好数值字段,尽量简化字...

ZhangLG
09/06
0
0
MySQL 数据库开发的 36 条军规

写在前面的话: 总是在灾难发生后,才想起容灾的重要性; 总是在吃过亏后,才记得曾经有人提醒过。 (一)核心军规 (1)不在数据库做运算:cpu计算务必移至业务层 (2)控制单表数据量:单表...

盼望明天
2017/03/07
0
0
MySQL数据库开发的赶集网三十六条军规

MySQL数据库开发的三十六条军规 View morepresentations frommysqlops

鉴客
2011/11/13
5.2K
16
推荐书籍 -《移动App测试的22条军规》

在今天的博文中,博主希望给大家分享一本博主同事黄勇的最新利作:《移动App测试的22条军规》。黄勇是ThoughtWorks资深敏捷QA和咨询师。对于我来说,和黄勇在一起的工作的这个项目,是我至今...

zting科技
2017/01/11
0
0

没有更多内容

加载失败,请刷新页面

加载更多

00.编译OpenJDK-8u40的整个过程

前言 历经2天的折腾总算把OpenJDK给编译成功了,要说为啥搞这个,还得从面试说起,最近出去面试经常被问到JVM的相关东西,总感觉自己以前学的太浅薄,所以回来就打算深入学习,目标把《深入理...

凌晨一点
今天
4
0
python: 一些关于元组的碎碎念

初始化元组的时候,尤其是元组里面只有一个元素的时候,会出现一些很蛋疼的情况: def checkContentAndType(obj): print(obj) print(type(obj))if __name__=="__main__": tu...

Oh_really
昨天
6
2
jvm crash分析工具

介绍一款非常好用的jvm crash分析工具,当jvm挂掉时,会产生hs_err_pid.log。里面记录了jvm当时的运行状态以及错误信息,但是内容量比较庞大,不好分析。所以我们要借助工具来帮我们。 Cras...

xpbob
昨天
122
0
Qt编写自定义控件属性设计器

以前做.NET开发中,.NET直接就集成了属性设计器,VS不愧是宇宙第一IDE,你能够想到的都给你封装好了,用起来不要太爽!因为项目需要自从全面转Qt开发已经6年有余,在工业控制领域,有一些应用...

飞扬青云
昨天
4
0
我为什么用GO语言来做区块链?

Go语言现在常常被用来做去中心化系统(decentralised system)。其他类型的公司也都把Go用在产品的核心模块中,并且它在网站开发中也占据了一席之地。 我们在决定做Karachain的时候,考量(b...

HiBlock
昨天
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部