thzt / book-excerpt Goto Github PK

分析的方法

1. 七步法

（1）确定革新的方针
（2）搜集有关资料数据，作革新的准备
（3）将搜集到的资料数据进行分析
（4）将自由思考产生出来的各种各样的创造性设想一一记录下来，并构思出革新方案
（5）提出实现革新方案的各种创造性设想
（6）综合所有可用的资料和数据
（7）对实现革新方案的各种创造性设想进行评价，从而筛选出切实可行的设想

2. 行停法

（1）行，想出所需要解决的问题相关联的地方；停，对此进行详细的分析和比较
（2）行，寻找对解决问题有哪些可用得上的资料；停，如何方便地得到这些资料
（3）行，提出解决问题的所有关键处；停，决定最好解决方法
（4）行，尽量找出试验的方法；停，选择最佳试验方案，直至发明成功

3. 八步法

（1）认清环境
（2）界定问题范围与定义
（3）搜集解决问题的创造性设想
（4）评价比较
（5）选择最佳方案
（6）初步设计
（7）实地试验
（8）追踪研究

4. 头脑助产法

（1）确定目标
（2）选择可能性
（3）提出优先考虑的问题
（4）考虑其他人的观点

---

委内瑞拉的第二大城市马拉开波准备建立一个新的医疗中心，为此邀请了政界、金融界和医务界的有关人士进行讨论。他们一直讨论了3个多小时毫无结果。

此时，一个跟随妈妈来的年仅10岁的儿童拉维尔向会议主持人提出了思考问题必须遵守的4个法则：
第一，确定目标；
第二，选择可能性；
第三，提出优先考虑的问题；
第四，考虑其他人的观点。

会议主持人并不因人废言，欣然接受了这位儿童的建议，不久，讨论会就得出了令各方都满意的结果。
一个10岁的小孩子怎么能够有如此大的能耐呢？
原来，在委内瑞拉，政府用法律的形式明文规定，每个小学生每周必须用2个小时的时间来学习和训练自己的思维分析技能。各级各类学校都有“思维分析训练”课程，以提高学生的思维分析素质。拉维尔并不是思维天才，只不过他在学校里接受了科学的思维分析训练，因而能给成年人作思维分析向导。

很多因素可能会导致项目偏离轨道，如官僚主义，目标不清，资源缺乏，等等。
但真正决定软件复杂性的是设计方法。
当复杂性失去控制时，开发人员就无法很好的理解软件，因此无法轻易、安全的更改和扩展它。
而好的设计则可以为开发复杂特性创造更多机会。

很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。
当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也是无济于事。

极限编程承认设计决策的重要性，但强烈反对预先设计。
相反，它将相当大的精力投入到促进沟通和提高项目快速变更能力的工作中。
具有这种反应能力之后，开发人员就可以在项目的任何阶段只利用『最简单而管用的方案』，
然后不断进行重构，一步一步做出小的设计改进，最终得到满足客户真正需要的设计。

这种极端的简约主义是解救那些过度追求设计的执迷者的良方。
那些几乎没有价值的繁琐文档只会为项目带来麻烦。
项目受到『分析瘫痪症』的困扰，团队成员十分担心会出现不完美的设计，这导致它们根本没法取得进展。
这种状况必须得到改变。

遗憾的是，这些有关过程的**可能会被误解。
每个人对『最简单』都有不同的定义。
持续重构其实是一系列小规模的重新设计，没有严格设计原则的开发人员将会创建出难以理解或修改的代码，
这恰好与敏捷的精神相悖。
而且，虽然对以外需求的担心常常导致过度设计，但试图避免过度设计又可能走向另一个极端，
不敢做任何深入的设计思考。

XP最适合那些对设计的感觉很敏锐的开发人员。
XP过程假定人们可以通过重构来改进设计，而且可以经常、快速的完成重构。
但重构本身的难易程度取决于先前的设计选择。

模型是一种知识形式，它对知识进行有选择的简化和有目的的结构化。
适当的模型可以使人理解信息的意义，并专注于问题相关的信息。

软件的核心是其为用户解决领域相关的问题的能力。
所有其他特性，不管有多么重要，都要服务于这个基本目的。
当领域很复杂时，这是一项艰巨的任务，要求高水平技术人员的共同努力。
开发人员必须钻研领域以获取业务知识。
他们必须练习建模技巧，并精通领域设计。

然而，在大多数软件项目中，这些问题并未引起足够的重视。
大部分有才能的开发人员对学习与他们的工作领域有关的知识不感兴趣，
更不会下力气去扩展自己的领域建模技巧。
技术人员喜欢那些能够练习技巧的可量化问题。
领域工作很繁杂，而且要求掌握很多复杂的新知识，而这些新知识看似对提高计算机科学家的能力并无裨益。

相反，技术人员更愿意从事精细的框架工作，试图用技术来解决领域问题。
他们把学习领域知识和领域建模的工作留给别人去做。
软件核心的复杂性需要我们直接面对和解决，如果不这样做，必将导致工作重点的偏离。

技术人员通常认为业务专家最好不要接触领域模型，他们认为：
领域模型对他们来说太抽象了，他们不理解抽象，这样我们就不得不用他们的术语来收集需求。
过于抽象？那你怎么知道抽象是否合理？你是否像他们一样深入的理解领域？
如果连经验丰富的领域专家都不能理解模型，那么模型一定是有问题的。

务必要记住模型不是图，图的目的是帮助表达和解释模型。
代码可以充当设计细节的存储库。
清晰的Java代码与UML具有同样的表达能力。

文档不应再重复表示代码已经明确表达出的内容。
代码已经含有各个细节，它本身就是一种精确的程序行为说明。
文档应努力寻求生存之道，并保持最新。

设计文档的最大价值是解释模型的概念，帮助在代码的细节中指引方向，或许还可以帮助人们深入了解模型的使用风格。

那些压根儿就没有领域模型的项目，仅仅通过编写代码来实现一个又一个的功能，
它们无法利用模型进行知识的消化和沟通，如果涉及复杂的领域就会使项目举步维艰。
另一方面，许多复杂的项目确实在尝试使用一些领域模型，但是并没有把代码的编写与模型紧密联系起来。
这些项目所设计的模型，在项目初期还可能用来做一些探索工作，但是随着项目的进展，
这些模型与项目渐行渐远，甚至还会起到误导作用。
所有在模型上花费的精力都无法保证程序设计的正确性，因为模型和设计是不同的。

程序代码就是模型的表达，修改代码可能就是改变模型。

人们总是把软件开发比喻成制造业。
通过这个比喻可以推断出一个结论：经验丰富的工程师做设计工作，而技能水平较低的劳动力负责组装产品。
这种做法使许多项目陷入困境，原因很简单，在软件开发中设计是无处不在的。
开发团队中的每个成员都有自己的职责，但是将分析，建模，设计和编程工作完全分离会产生不良影响。

开发人员-领域模型-领域专家

任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。
任何负责修改代码的人员，则必须学会用代码来表达模型。
每一个开发人员都必须不同程度的参与模型讨论并且与领域专家保持联系。

给复杂的应用程序分层。
在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。
采用标准的架构模式，只与上层进行松散连接。
将所有与领域模型相关的代码放在一个层中，并把它与用户界面层，应用层以及基础设施层的代码分开。
领域对象应该将重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，
也无需管理应用任务等内容。
这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效的使用这些知识。

用户界面层：负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。
应用层：定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。
领域层（或模型层）：负责表达业务概念，业务状态信息以及业务规则。领域层是业务软件的核心。
基础设施层：为上面各层提供通用的技术能力。为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。基础设施层还能够通过架构框架来支持四个层次间的交互模式。

注意，负责处理基本业务规则的是领域层，而不是应用层。

各层之间是松散连接的，层与层的依赖关系只能是单向的。
上层可以直接使用或操作下层元素，方法是通过调用下层元素的公共接口，保持对下层元素的引用，以及采用常规的交互手段。
而如果下层元素需要调用上层元素进行通信（不只是回应直接查询），则需要采用另一种通信极致，使用架构模式来连接上下层，比如回调模式或观察者模式。

软件的最终目的是为用户服务。但首先它必须为开发人员服务。
在强调重构的软件开发过程中尤其如此。
随着程序的演变，开发人员将重新安排并重写每个部分。
当具有复杂行为的软件缺乏一个良好的设计时，重构或元素的组合会变得很困难。
一旦开发人员不能十分肯定的预知计算的全部含意，就会出现重复。
当设计元素都是整块的而无法重新组合的时候，重复就是一种必然的结果。

如果软件没有一个条理分明的设计，那么开发人员不仅不愿意仔细的分析代码，
而且修改代码也可能会产生问题，要么加重了代码的混乱状态，要么由于某种未预料到的依赖性而破坏了某个结构。
在任何一种系统中（除非是一些非常小的系统），这种不稳定性使我们很难开发出丰富的功能，而且限制了重构和迭代式的精化。

为了使项目能够随着开发工作的进行加速前进，而不会由于它自己的老化停滞不前，
设计必须要让人们乐于使用，而且易于做出修改。
这就是柔性设计。（supple design）

很多过度设计借着柔性设计的名义而自认为是正当的，但是过多的抽象层和间接设计常常成为项目的绊脚石。
看一下真正为用户带来强大功能的软件设计，你会发现它们通常有一些非常简单的部分。
简单并不容易做到，为了把创建的元素装配到复杂系统中，而且装配之后仍然能够理解它们，
必须坚持模型驱动的设计方法，与此同时还要坚持适当严格的设计风格。

早起设计版本通常达不到柔性设计的要求，由于项目的时间限制和预算的缘故，很多设计一直就是僵化的。
我也从未见过哪个大型程序自始至终都是柔性的。
但是，当复杂性阻碍了项目的前进时，就需要仔细修改最关键，最复杂的地方，
使之变成柔性设计，这样才能突破复杂性带给我们的限制，而不会陷入遗留代码维护的麻烦中。

如果开发人员为了使用一个组件而必须要去研究它的实现，那么就失去了封装的价值。
当某个人开发的对象或操作被别人使用时，如果使用这个组件的新的开发者不得不根据其实现来推测其用途，
那么他推测出来的可能并不是那个操作或类的主要用途。
如果这不是那个组件的用途，虽然代码暂时可以工作，但设计的概念基础已经被误用了，两位开发人员的意图也是背道而驰。

在命名类和操作时要描述它们的效果和目的，而不要表露它们是通过何种方式达到目的的。
这样可以使客户开发人员不必去理解内部的细节，以便团队成员可以迅速推断出它们的意义。
在创建一个行为之前先为它编写一个测试，这样可以促使你站在客户开发人员的角度来思考它。

所有复杂的机制都应该封装到抽象接口的后面，接口只表明意图，而不表明方式。

多个规则或计算组合的相互作用所产生的结果是很难预测的。

声明式设计，对于不同的人来说具有不同的意义，但通常是指一种编程方式，
把程序或程序的一部分写成一种可执行的规格。
使用声明式设计时，软件实际上是由一些非常精确的属性描述来控制的。

声明式语言并不足以表达一切所需的东西，它把软件束缚在一个由自动部分构成的框架之内，使软件很难扩展到这个框架之外。
代码生成技术破坏了迭代循环，它把生成的代码合并到手写的代码中，使得重新生成的破坏作用变得更大。
许多声明式设计的尝试带来了意想不到的后果，由于开发人员收到框架局限性的约束，为了交付工作职能先处理重要问题，
而搁置其他一些问题，这导致模型和应用程序的质量严重下降。

很多声明式方法被开发人员有意或无意忽略之后会遭到破坏。
当系统很难使用或限制过多时，就会发生这种情况，为了获得声明式程序的利益，每个人都必须遵守框架的规则。
声明式设计的最大价值是用一个范围非常窄的框架来自动处理设计中某个特别单调且容易出错的方面，
例如持久化和对象关系映射。
最好的声明式设计，能够使开发人员不必去做那些单调乏味的工作，同时又完全不限制他们的设计自由。

特定于领域的语言，是一种有趣的方法，它有时也是一种声明式语言。
采用这种编码风格时，客户代码是用一种专门为特殊领域的特殊模型定制的语言而编写的。
例如，运输系统的语言可能包括cargo（货物）或route（路线）这样的术语，以及一些用于组合这些术语的语法。
然后，程序通常会被编译成一种传统的面向对象语言，由一个类库为这些术语提供实现。

在这样的语言中，程序可以具有极强的表达能力。
特定于领域的语言，是一个令人振奋的概念。但在我所见过的基于面向对象技术的方法中，这种语言也存在自身的缺陷。
为了精化模型，开发人员需要修改语言。这可能涉及修改语法声明和其他语言解释功能，以及修改底层的类库。
另一个缺点是，当模型被修改时，很难对客户代码进行重构，使之与修改之后的模型及与其相关的特定于领域的语言保持一致。
当然，有人认为可以通过技术修复来解决重构问题。

这种技术可能在非常成熟的模型中能够发挥出最大作用，在这样的模型中，客户代码可能是由另一个不同的团队编写的。
通常，这样的设置会导致产生一种有害的结果，团队被分成两部分，框架由那些技术水平较高的人来构建，而应用程序则由那些技术水平较差的人来构建了，
但也并不是非得如此。

我个人最喜欢的框架是数学，数学的强大功能令人惊奇，它可以用基本数学概念把一些复杂的问题提取出来。
很多领域都涉及数学，我们要寻找这样的部分，并把它挖掘出来。
专门的数学很整齐，可以通过清晰的规则进行组合，并且很容易理解。

如果一直等到完全证明了修改的合理性之后才去修改，那么可能要等待太长时间了。
项目正在承受巨大的耗支，推迟修改将使修改变得更难执行，因为要修改的代码已经变得更加精细，并更深的嵌入到其他代码中。
持续重构渐渐被认为是一种『最佳实践』，但大部分项目团队仍然对它抱有很大的戒心。

人们虽然看到了修改代码会有风险，还要花费开发时间；
却不容易看到的是维持一个拙劣设计也有风险，以及迁就这种设计也要付出代价。
想要重构的开发人员，往往被要求证明其重构的合理性。虽然这看似合理，但这使得一个本来就很难进行的工作变得几乎不可能完成，
而且会限制重构的进行（或者人们只能暗地里进行）。
软件开发并不是一个可以完全预料到后果的过程，人们无法准确的计算出某个修改会带来哪些好处，或者是不做某个修改会付出多大代价。

在探索领域的过程中、在培训开发人员的过程中，以及在开发人员与领域专家进行**交流的过程中，
必须始终坚持把『通过重构得到更深层理解』作为这些工作的一部分。
因此，当发生以下情况时，就应该进行重构了：
设计没有表达出团队对领域的最新理解；
一些重要的概念被隐藏在设计中了，而且你已经发现了把它们呈现出来的方法；
发现了一个能令某个重要的设计部分变得更灵活的机会。

大型系统领域模型的完全同意是不可行的，也不是一种经济有效的做法。

细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。

任何一个大型项目都会存在多个模型。
而当基于不同模型的代码被组合到一起后，软件就会出现bug，变得不可靠和难以理解。
团队成员之间的沟通变得混乱。
人们往往弄不清楚一个模型不应该在哪个上下文中使用。

因此，明确定义模型所应用的上下文。根据团队的组织、软件系统的各个部分的用法以及物理表现（代码和数据库模式）等设置模型的边界。
在这些边界中严格保持模型的一致性，而不要受到外界之外问题的干扰和混淆。

建立一个经常把所有代码和其他实现工件合并到一起的过程，并通过自动测试来快速查明模型的分裂问题。
以便在不同人的头脑中演变出不同的概念时，使所有人对模型都能打成一个共识。

如果下游团队对变更更具有否决权，或请求变更的程序太复杂，那么上游团队的开发自有就会受到限制。
由于担心破坏下游系统，上游团队甚至会受到抑制。
同时，由于上游团队掌握优先权，下游团队有时也会无能为力。
因此，在两个团队之间建立一种明确的客户/供应商关系。在计划会议中，下游团队相当于上游团队的客户。
根据下游团队的需求来协商需要执行的任务并为这些任务做预算，以便每个人都知道双方的约定和进度。
两个团队一起开发自动验收测试，用来验证预期的接口。把这些测试添加到上游团队的测试套件中，以便作为其持续集成的一部分来运行。
这些测试使上游团队在做出修改时不必担心对下游团队产生副作用。

当两个开发团队具有上下游关系时，如果上游团队没有动机来满足下游团队的需求，那么下游团队将无能为力。
由于利他主义的考虑，上游开发人员可能会做出承诺，但他们可能不会履行承诺。
下游团队由于良好的意愿会相信这些承诺，从而根据一些永远不会实现的特性来制定计划。
下游项目只能被搁置，直到团队最终学会利用现有条件自力更生为止。
下游团队不会得到根据他们需求而量身定做的接口。

通过严格遵从上游团队的模型，可以消除转换复杂性。
尽管这会限制下游设计人员的风格，而且可能不会得到理想的应用程序模型。
此外，这样还可以与供应商团队共享模型术语，供应商处于驾驶者的位置上，因此最好使他们能够容易沟通。
他们从利他主义的角度出发，会与你分享信息。
人们在主观上不愿意这样做，因此有时本应该这样选择时，却没有这样选择。

在设计大型系统时，有很多有用的组件，它们都很复杂而且绝对有必要把它们做好，
这导致真正的业务资产，领域模型，被掩盖和忽略了。

一个严峻的现实是我们不可能对所有设计部分进行同等的精化，而是必须分出优先级。
为了使模型领域成为有价值的资产，必须整齐的梳理出模型的真正核心，并完全根据这个核心来创建程序的功能。
但本来就稀缺的高水平开发人员往往会把工作重点放在技术基础设施上，或者只是去解决那些不需要专门领域知识就能理解的领域问题（这些问题都已经有了很好的定义）。

在制定项目规划的时候，必须把资源分配给模型和设计中最关键的部分。
要想达到这个目的，在规划和开发期间每个人都必须识别和理解这些关键部分。
这些部分是应用程序的标志性部分，也是目标应用程序的核心目标，它们构成了核心领域（core domain）。
核心邻域是系统中最优价值的部分。

因此，对模型进行提炼，找到核心邻域，并提供一种易于区分的方法把它与那些起辅助作用的模型和代码分开。
最有价值和最专业的概念要轮廓分明，尽量压缩核心领域。
让最有才能的人来开发核心领域，并相应的招募新人来补充这些人空出来的位置。
在核心领域中努力开发能够确保实现系统蓝图的深层模型和柔性设计。
仔细判断任何其他部分的投入，看它是否能够支持这个提炼出来的核心。

软件设计往往非常抽象且难于掌握，开发人员和用户都需要一些切实可行的方式来理解系统，并共享系统的一个整体视图。

制定战略设计决策的6个要点：
（1）决策必须传达到整个团队，
（2）决策过程必须收集反馈意见，
（3）计划必须允许演变，
（4）架构团队不必把所有最好、最聪明的人员都吸收进来
这样往往会把那些技术能力较差的人留下来实际构建应用程序，但要想开发出优秀的应用程序，是需要设计技巧的，因此这样的安排注定会失败。
即使战略团队建立了一个伟大的战略设计，应用程序开发团队也没有能力把它实现出来。
所有应用程序团队都应该有一些技术能力很强的设计人员，而且任何从事战略设计的团队也都必须具有领域知识，这两者都是非常重要的。
（5）战略设计需要遵守简约和谦逊的原则
（6）对象的职业要专一，而开发人员应该是多面手

有一种态度肯定会使框架流于失败——不要编写『傻瓜式』的框架。
在划分团队时，如果认为一些开发人员不够聪明，无法胜任设计工作，而让他们去做开发工作，
那么这种态度可能会导致失败，因为他们低估了应用程序开发的难度。
如果这些人在设计方面不够聪明，就不应该让他们来开发软件。
如果他们足够聪明，那么用『傻瓜式』的框架来应付他们只会为他们造成障碍，使他们得不到所需的工具。

变更是软件的固有性质。

我们为什么要测试？
两个主要原因是：对质量或可接受性作出判断，以及发现问题。

人们在编写代码时会出现过错，我们把这种过错叫做bug。
缺陷是错误的表现。

我们可以把缺陷分为过错缺陷和遗漏缺陷。
如果把某些信息输入到不正确的表示中，就是过错缺陷。
如果没有输入正确信息，就是遗漏缺陷。
在这两类缺陷中，遗漏缺陷更难检测和解决。

测试是采用测试用例执行软件的活动。
测试有两个显著目标：找出失效，或演示正确的执行。

测试用例在测试中占据中心地位。
测试过程可以再细分为独立的步骤：测试计划，测试用例开发，运行测试用例以及评估测试结果。

软件测试的本质是针对要测试的内容确定一组测试用例。

测试用例：

• 输入：前提，实际输入
• 输出：后果，实际输出
• 标识
• 原因
• 执行历史，执行者
• 执行通过/失败记录
• 测试软件的哪个版本

测试基本上关心的是行为，而行为与软件（和系统）开发人员很常见的结构图无关。
最明显的差别是，结构视图关注的是“它是什么”，而行为视图关注的是“它做什么”。

一直困扰测试人员的难点之一，就是基本文档通常都是由开发人员编写，
并且是针对开发人员的，
因此这些文档强调的是结构信息，而不是行为信息。

如果特定的描述行为没有被编程实现会出现什么问题？这就是遗漏缺陷。
类似的，如果特定的程序（已实现）行为没有被描述会出现什么问题？
这种情况对应过错缺陷，以及规格说明完成之后出现的错误。

测试的一种很好的观点是，测试就是确定既被描述又被实现的程序行为范围。
“正确性”只有在一个规格说明和一种实现背景下才有意义，正确性是一种相对术语，不是绝对术语。

如果测试用例没有对应的已描述的行为，则测试一定是不完备的。
如果特定测试用例对应未描述行为，则有两种可能：
要么这个测试用例是不正当的，要么规格说明是不充分的。

有两种基本方法可以用来标识测试用例：功能性测试（黑盒），结构性测试（白盒）。
这两种方法的目标都是标识测试用例，
功能性测试只利用规格说明标识测试用例，
而结构性测试使用程序源代码（实现）作为测试用例标识的基础。

两种方法单独使用都是不充分的。
如果所有已描述行为都没有被实现，则结构性测试永远也不会认识到这一点。
如果程序实现了没有被描述的行为，功能性测试用例永远也不会揭示这一点。

测试工程师的答案是：
明智的组合会带来功能性测试的置信，以及结构性测试的度量。

过程指我们怎样做事情，产品是过程的最终结果。
测试与软件质量保证（SQA）的交汇点是，SQA一般通过努力改进过程来改进产品。
SQA更注重减少开发过程中的错误做法，而测试更注重发现产品中的缺陷。

“软件异常IEEE分类”中，软件异常被定义为“对预期的偏离”。

尤其是在功能性测试方面，有三个级别定义（规格说明，概要设计，详细设计）直接对应于测试的三个级别。
即，单元测试，集成测试和系统测试。

需求规格说明：系统测试
概要设计：集成测试
详细设计：单元测试

---

拥有商业心态
大多数软件开发人员从职业生涯一开始就犯了几个严重的错误。截至目前，最大的错误就是没有把自己的软件开发事业当 作一桩生意来看待。
这种心态对于管理职业规划至关重要。因为只有你开始把自己当作一个企业去思考时，你才能开始做出良好的商业决策。

把雇主当作是你的软件开发企业的一个客户吧。
当然，你可能只有这么一个客户，你所有的收入都是从这一个客户处得来的，但是这种诠释雇用关系的方式可以将你从仰人鼻息的弱势地位转换成为自我治理和自我引导的主动地位。

像企业一样思考
作为一名软件开发人员，你也许有一款真实的数字产品可以卖，但是，大多数软件开 发人员卖的是开发软件这项服务。
通常软件开发人员售卖的就是他们把一个想法变成一个数字化的现实产品的能力。

企业需要持续不断地 改进和完善自己的产品。
你也应该这么做。
作为一名软件开发人员，你提供的服务具备有形价值，你要传达的不仅是这款软件的价值是什么，还有它与别的成千上万款软件开发人员提供的服务有何不同。

作为一名提供服务的软件开发人员，你也要关注市场营销。
产品营销做得越好，你就能给服务定越高的价格，也越有机会吸引更多潜在的客户。

你需要做到
（1）专注于你正在提供怎样的服务，以及如何营销这项服务
（2）想方设法提升你的服务
（3）思考你可以专注为哪一特定类型的客户或行业提供特定的服务
（4）集中精力成为一位专家，专门为某一特定类型的客户提供专业的整体服务

作为一个软件开发人员，你只有真正 专注于一类客户，才能找到非常好的工作。

另外，还要想想如何更好地宣传你的服务，如何更好地找到你的客户。
大多数软件开发人员在写好一份简历之后就随意丢 给一些公司和招聘人员。
但是，当你把职业生涯当作一个企业时，你真的认为这就是你拓展潜在客户的最佳途径或唯一方法吗？
当然不是。
大多数成功的公司都会开发出让客户主动上门购买的产品或服务，它们才不会一个接一个地追逐客户。

跳出思维定势，开始像企业一样思考，也是关键所在。

想象一下
有一家企业，拥有某个产品或服务。
他们将如何推广这一产品或服务从而可以做到卓尔不凡？

如果只用一句话来描述你能为潜在雇主或客户提供怎样的特定服务，这句话是什么？
把你的职业当作是一个企业，将会影响到你的：
（1）工作的方式
（2）处理自己的财务的方式
（3）寻求新工作或新客户的方式

---

定义业务目标
无论因为何种原因你没有为自己的职业生涯设定目标，现在都是时候设定目标了。
不是明天，也不是下周，就是现在。
没 有明确的方向，你走的每一步都是徒劳的。不要随心所欲地生活，不要随遇而安地行走在职业生涯的漫漫长路上。

如何设定目标
起步阶段最简单的就是在心中树立一个大 目标，然后再建立能帮你达成这个大目标的小目标。
一旦你想通了自己长远的大目标是什么，下一步就是设定路线，制订通往大目标的小目标。
如果你可以驱动小目标逐渐前行并靠近你的大目标，那么最终你一定会到达目的地。
设定大小不同的目标，确保你向着自 己的大目标前进，这一点非常重要。

把你的大目标写在自己每天的必经之地，每日三省吾身——我在追求什么。

---

事实是，在软件开发领域，我们大多数时候是与人而非与计算机打交道。
仔细想想自己在工作中有多少时间用在了与人互动上，你马上就能意识到改善人际交往能力的价值。

邮件是人发的，任务是人布置的。

如果你还是觉得自己的工作就是写写代码，那你最好要三思。
作为一个软件开发人员，你的工作就是与人打交道（其实几 乎所有的职业都是这样）。

学会如何与人打交道
（1）每个人都希望感到自己很重要
（2）永远不要批评
（3）换位思考
（4）避免争吵

如何处理“毒瘤”
有时候你会发现，有的人不管怎么样就是无法相处，有的人就是抓住一切机会贬低别人，对生活中的一切抱有消极态度。
我把他们称为“苛性碱”，你最好避开他 们。
如果你意识到某个人就是所谓的“苛性碱”，不要试图去改变他们，也不要试图去和他们打交道，就让他们停留在自己的轨迹上，你所要做的只是尽量限制自己与 他们互动。

但是，如果这样的人是你的老板或同事，你不得不面对，你该怎么做呢？
你能做的真心不多。
要么逆来顺受，要么调到新部门甚至换工作。
不管做什么，千万不 要卷入其中。
如果你不幸要与之打交道，限定在最小范围之内，切切不要投入感情。

认输
下一次当你被拖入一场争吵之前，想办法看看能不能逆转。
做个有趣的小测试，试着认输。
事实上，不仅仅要认输，更要果断站在对手一边。结果能让你大吃 一惊。

---

通过面试的最快捷的方式
与主流观念相反，大多数面试官决定雇 用某个人其实是基于各种各样的非技术因素。
简而言之，通过面试的最快捷的方式是让面试官对你怀有好感。

“破解”面试的要诀就是在面试开始之前就思考应对面试的策略。

大量工作岗位来自“个人推荐”。
你要试图确保你申请的职位也适用于个人推荐。
如果你是被他人推荐去面试，因为有推荐 人的社会公信力做背书，面试官会自然而然地高看你一眼。
推荐人的声誉及他与面试官的交情，有一部分就延伸到了作为应聘 者的你的身上。
当你进入面试环节，面试官早就对你有所偏爱，因为你是由他们喜欢和信任的人推荐来的。

你必须要突破常规，想尽办法与公司内部人员建立联系。

真正的面试会是什么样子的
如果顺利的话，在你走进面试间的时候，面试官已经知道你是谁了，但无论如何，你都需要了解在面试时自己该做什么。
现在，很明显，你需要从技术能力上证明你可以通过技术面试。就像你有两把刷子，那就说出来。
接下来要关注的事情就是自 信地展示自己的能力——知道要获得这份工作需要做什么，做就是了。

能够自 发地、无需过问就能做事的员工通常能增加公司的净收入，此外，他们也让老板少操心，只占用少量的管理资源。
与雇用技术高超但需要生拉硬拽才能干活的人相比，我宁愿雇用这样的开发人员：
知道的东西可以少一点，但是明确知道 要做什么，以及怎样去做。
从某种程度上，在你可控的范围之内，面试的时候你要集中精力证明自己就是无需督促也能自动自 发做好事情的员工。

你还必须要证明：在技术上你确实胜任工作。
同时，如果你能说服面试官相信你非常能干，不会被困难阻挡，那么他们不 仅会喜欢你，而且更有可能会录用你。

当下你能做什么
你应该做的第一件事是确保自己仍旧保持技术能力。
确保自己一直阅读技术书籍和博客文章，并会花些时间提升自己的技能。

你也可以未雨绸缪，拓展自己的社交网络。
开始与本领域不同公司的员工接触，建立联系，他们日后可能会帮到你。
通过 阅读并评论他们的博客，认识本领域的其他开发人员甚至是招聘人员。
想方设法扩大你的社交圈子。

集中精力推销自己会对你大有裨益。

采取行动
（1）即使你现在不需要努力找工作，也要整理一份清单，列出你想去工作的公司，以及你认识的这些公司的人。
（2）在这份清单上的公司里，如果有的公司你一个人都不认识，那么制订计划至少去认识这些公司中的一位员工，并与之建立联系。
（3）在自己所在领域找出至少一个本地用户组，参加聚会，并把自己介绍给尽可能多的人。

---

就业选择
（1）雇员
（2）独立咨询师
（3）创业者

---

专业化很重要
有大量的软件开发人员并没有具体的专业方向。
从表面上看，身为“专才”后，潜在雇主和客户群都变小了，但是实际上你对他们更具吸引力了。
只要你专业能力雄厚，市 场没有过渡饱和，与那些自称为“软件开发人员”的人相比，你能更轻松地找到工作或者赢得客户。

在一个专业方向上拥有专长
我的偏门专业让我对小范围内的潜在雇主极具价值。
这些雇主并不会在大多数城市存在，所以如果我的市场是美国甚至全 球的话，那在这个庞大的市场上，我的专长格外有用。

专业化的规则是：
专业化程度越深，潜在的机会就越少，但获得这些机会的可能性越大。

让我们回到你的情况。
假设你正在你所在地寻求一份工作，并且你是一个Java开发人员。
很多大都市对Java开发人员都有 相当大的需求，所以开始的时候你会拥有一个很棒的大水池——你可以得到很多工作机会。
但其实你并不需要所有的这些工作 机会，只要一个就够了。

现在，假设你决定走专业化路 线，限定自己的市场但提高或者这些工作的机会，那你的专长就是做Java Web开发人员。
或许这一决定减少了250个工作机 会，但是还有250个工作机会。
仍然很多，不是吗？记住，你只需要一份工作。

现在你决定更专业化一点，选择专攻Java Web开发栈。
也许这会将 你的工作机会降到50个，但可供挑选的工作机会依然很多，同时因为你现有的技能和知识都是针对这些工作的，于是你获得这 50个工作中的某一个的机会增加了。

选择你的专业
这里有一些技巧来帮你选择自己的专业。
（1）在你现在或以前工作的公司里，有哪些主要的痛点？你能成为一名专门解决这些痛点的专家吗？
（2）有没有一种特定的工作是无人能做，或者缺乏经验丰富的人？成为这个领域的专家，你就会获得大量业务。
（3）在各种会议上和用户组中哪些话题最常出现？
（4）哪类问题你回复的最多，无论是针对同事还是在Stack Overflow这样的网站上？

即使我推荐走“专业化”道路，也不 代表我认为你不应该同时具备广泛的技能。
这二者看起来似乎是矛盾的，其实并非如此。
做一个技术全面、多才多艺的软件开发人员非常棒。
能够使用多项技术和多 种编程语言，有助于你的职业发展，能让你比那些仅了解一项技术或一种编程语言的软件开发人员更有价值。
然而，这种“万 金油”式的人才在市场上并不吃香。

团队里有一个全能的开发人员是件好事，但是很少有公司或客户会去寻找这样的人才。
即便你各种技术能力惊人，通晓50 种编程语言，你最好还是选定某个专业领域，哪怕时不时换一下。

学富五车，或者灵活变通并同时仍有所专长让自己卓尔不群。
如果你非要二选一，那先从专业化开始，再拓展分支。

---

软件开发公司与拥有软件开发人员的公司
在决定自己要去哪种公司工作的时候，另一个需要考虑的重要因素是下面两类公司之间的区别：
一种是软件开发人员只负 责内部软件或他们正在生产的部分产品的公司，另一种是生产软件或者做软件开发就是核心业务的公司。

那些并非专注于软件开发业务的公司雇用软件开发人员只是为了开发自己系统的某些方面，对待软件开发人员的方式也与 那些主要专注于软件开发业务的公司截然不同。
如果公司的业务重心并非软件，那自然也不会给软件开发人员足够的尊重和发 展空间。这些公司的软件开发实践极有可能非常松散。
另一方面，那些以软件开发为生的公司则会更重视自己雇用的软件开发人员的价值。
他们的工作环境不一定会更好，但会 大不一样。

---

承担责任
在任何公司里能让你脱颖而出的最重要法宝就是承担更多的责任。
这看起来显而易见，但在你的职业生涯中，你经常会面对更多金钱还是更多责任的选择。
至少从长远来看，正确的选择几乎永远是更多责任。

金钱总是追随着责任。
有任何机会去承担更多责任时，承担起来！

没有人愿意涉足的领域是搜寻机会最好的地方。
可能有一个没人愿意碰的遗留应用，或者代码库里的某个特别令人讨厌的 模块。
正因为没有人愿意碰，所以你也无需去抢，这些就成为你日益强大的帝国的领地。
如果你能把沼泽变为良田，你也就展 现了自己的价值。

另一种间接承担责任的方式是成为团队中其他人的导师，自愿帮助新人加速成长，为任何有需要的人提供帮助。
通过介入 和解决别人的问题，你不仅可以学到更多自己专业之外的知识，而且随着时间的推移，你还能在团队中逐步树立“及时雨”的名 声。
最终，这样的声誉可能会令你成为团队领导或者其他管理职位，只要你愿意走这条路。

如何能让自己承担更多责任
（1）有一个不受重视的项目，你能去负责它吗？
（2）你能帮助团队里的新人快速成长吗？
（3）你能负责文档制作流程，并保证及时更新这些文档吗？
（4）哪项工作是没有人愿意去做，你愿意承担起来，并将其简化或者自动化的？

引人注目
如果你一直默默无闻，你的成就不为人知的话，即使你是团队中最聪明、最努力、最出色的开发人员，那也一文不名。
如 果找不到方法让你的老板或高层管理人员知道你在做什么，那你的所有努力都是徒劳的。

我能理解，知晓自己的直接下属在做什么对于管理者来说至关重要，所以我会通过发送周工作总 结的方式让他们的工作更轻松。

我当然推荐主动发送周报，不过还有其他许多方式能让你在所在的机构中更加引人瞩目。
其中最好的一种方法就是做一个 关于团队当前正面临的主题或者问题的演讲。
选一个自己能介绍的主题，然后向团队展示这一主题。

如何令自己引人注目：
（1）每天都记录自己的活动日志 ——把这个日志以周报的形式发送你的经理。
（2）提供演讲或培训 ——选择一个对你的团队有用的话题。
（3）发表意见 ——只要在会议上就这么做，或者只要你能得到的机会就这么做。
（4）保证 “曝光度 ” ——定期与老板会面，确保你经常被注意到。

自学
另一个可以获得提升的非常好的办法就是不断增加自己的技能和知识。
在你不断提高自己的教育水平时，很难停滞不前。
自学能让升职加薪变得容易，因为你可以很清楚地表明：现在的自己比之前更有价值。

在我职业生涯的早期，我感觉自己上升空间有限，于是决定去考取微软认证证书。
我努力学习，通过了所有测试，获得了 一个顶级微软认证。这并不容易，但我很快就看到它对我职业生涯的价值。
通过这些额外的努力，我向经理表明：我严肃对待 自己的职业生涯，于是机会的大门迅速为我打开。

另外，不要只学软件开发。
如果你把目标设定为更高级别的岗位甚至是行政岗位，你还需要学习领导力、管理和商科的相 关知识。

千万不要忘记分享自己学到的东西。
我们已经讨论过，你可以通过演讲的方式分享自己的知识，也可以创建自己的博客、 为杂志写文章或者写书，还可以在社区活动或者技术大会上发表演讲。
外部曝光有助于你建立自己在该领域的权威地位，也让 你看起来对所供职的公司更有价值。

成为问题的解决者
在任何组织中，总是有很多人会告诉你为什么这个想法行不通，为什么那个问题太难。
这样的人不胜枚举。千万不要成为 他们中的一员。
相反，你要成为那个永远能为各种问题找到解决方案的人，要成为勇于执行这些解决方案以获得成果的人。

在任何公司中，最有用的就是那种看似没有克服不了的障碍的人。
成为这种人是获得晋升的可靠方法。
忘记那些围绕职位 晋升的政治游戏和惺惺作态吧——如果你能解决别人无法解决或不愿解决的问题，无论在哪家公司，你都能轻而易举地成为最 有价值的人。

---

成为专业人士是一种心态。
如果我们总是与恐惧、自毁、拖延和自我怀疑作斗争， 那么问题就是：我们 正在像外行那样思考问题。
外行毫不起眼， 外行人废话连篇， 外行屈从于逆境。
专业人士可不这么想。
不管 怎样， 他引人注目， 他恪尽职守， 他始终如一。

成为专业人士的全部在于：引人注目，恪尽职守，以及不屈服于挫折。
成为专业人士，需要你克服自身的缺点，静下心来 创作出尽可能最好的作品。

什么是专业人士
简而言之，专业人士会严肃对待自己的责任和事业，愿意作出艰难的选择去做自己认为是正确的事情——往往还要自己承 担代价。

成为专业人士（养成良好习惯）
如果想成为一名专业人士，你需要培养自己的专业习惯。
作为一名专业人士需要养成的另一个强大的习惯是时间管理技能。

坚守正道
软件开发人员所要面对的最大的道德挑战就是：以他们了解的决策前行是正确的，也符合客户的最大利益，但是这样的决 定可能会危及自身福祉或职业稳定。

当病人告诉医生“我胳膊受伤了，我需要你把它砍掉”时，医生当然会说“不”。
但在许多情况下，当软件开 发人员面对类似的情形时，软件开发人员由于担心会触怒大人物而违心地说“是”，然后“砍掉”自己的代码。
一位专业人士需要知道在什么时候说“不”，即使是面对自己的老板。

有时候，专业人士必须对工作的优先级做出艰难的抉择。
不专业的开发人员经常浪费时间去画蛇添足，因为他们要么不能 确定下一步要做什么，要么他们得一直让别人来帮自己设定工作的优先级。
专业人士会评估需要完成的工作，判定优先级后再 开始工作。

追求品质， 完善自我
将品质管理应用到你工作的每个细节，而不仅仅是那些看似重要的部分，这一点非常重要。

你做的每一件事情就是你所做的一切。

别忘了，发挥你的长处。
你当然可以改善你的弱点，但最好了解自身的强项是什么并且充分发挥自己的优势。
专业人士对 自己的能力和弱点有着良好、精准而又客观的自我评估。

---

找到受众
许多软件开发人员一开始就深陷创业者最常犯的错误之中——在为产品找到客户之前就构建好产品。
从构建产品开始可能 有些道理，不过你要避免落入这个陷阱之中，否则你只是冒险为一个不存在的问题创造了一个解决方案。

人类创造出的每个产品（包括这本书在内）都是为了解决某个特定的问题。
没有要解决的问题的产品毫无意义，毫无意义 的产品自然也就不会有用户，也就意味着你不会赚到钱。

如果你想开发出一款产品，第一步应该是筛选出一组特定的受众，他们也是你的解决方案的目标用户。
针对这些人你要解 决的问题是什么，你可能已经有了总体概念。
不过在很多情况下，你要多做一些调研，找出要么没被解决的问题，要么没有被 很好解决的问题。

去目标客户常去的地方，与用户参与的社区交流，了解一下普遍存在哪些问题。
你能从中看到的痛点有哪些。

而许多开发人员是反着来的。
他们在尚未有受众的时候就创建产品，然后再四处推销，努力寻找受众。
当你以这样的方式 做事情时，你要冒很大的风险，因为执果索因往往更加困难。

如果你想让自己的产品也同样成功（虽然也许在规模上达不到），首先打造一个成功的博客，使用播客、演讲、视频和其 他媒体来发展自己的受众。
接下来，一旦你有了受众，你就能够向这些受众销售自己的产品。

测试市场
一旦你明确了产品的受众，并明确了如何用它解决用户的问题，在开发产品之前你还有一步工作需要完成。
你应该通过测 试市场来验证你的产品，看看你的潜在客户是否真的愿意为它买单。

---

着眼于利益，而不是立场。

利益驱动人的行为，是立场争执背后的动机。
你的立场就是你已作的决定，而利益是导致你作出这一决定的原因。

调和双方的利益而不是立场，这种方法之所以奏效有两个原因：
首先，每一项利益可以通过多种方式得到满足，人们往往只采取最显而易见的立场。
如果你能从对立的立场背后寻找利益动机，也许就能找到既满足自己利益，又能满足对方利益的新立场。
其次，对立的立场背后不止有冲突的利益，还有更多的其他利益。
所以，协调利益而不是在立场上妥协也会行之有效。

如何确定利益？

1. 问“为什么”
   分析对方采取的每一个立场，问自己对方“为什么”会这样做。
2. 问“为什么不”，考虑对方的选择
   问问自己，对方为什么没有那样做，那样做会影响到他们的什么利益？
   如果你想改变对方的主意，首先就要了解他们现在的想法。

最重要的利益是人的基本需求。
（1）安全感
（2）经济利益
（3）归属感
（4）获得他人认同
（5）能主宰自己的生活

讨论利益
谈判的目的是实现自己的利益。
只有与对方就此沟通，才能增加实现这些利益的可能性。
对方可能并不知道你的利益是什么，你也可能不知道对方的利益所在，你们中有一方或者双方只顾抱怨已经过去的事情，而不考虑下一步该怎么做，或许你们根本就没有听对方在说些什么。

如果希望对方认真考虑你的利益，那就明确告诉他们怎样做才符合你的利益。
你的任务就是，让对方准确了解你利益的重要性和合理性。

如果你希望对方重视你的利益，那么首先你就应当表明你重视对方的利益。
除了表示理解对方的利益之外，还应当把对方的利益作为你要解决的整个大问题的一部分。

先说问题，再拿出你的方案。
如果你希望对方倾听并理解你的解释，那么就先说出自己的考虑，然后再得出结论或提出建议。

令人惊讶的是，人们经常只是被动的对别人的言谈举止做出反应。
如果你问两个人为什么争吵，回答几乎都是因为什么事而不是出于某个目的。
人们在争吵的时候总是被动的对另一方的言行做出反应，而不是主动的为自己的长期利益做打算。

向前看比回头看更符合你的利益。
不要与对方争论已经发生的事情，谈谈你希望将来出现什么样的情况。
不要要求对方解释昨天的行为，而应该问“明天谁该做什么了？”

对问题强硬，对人要温和。
不仅要全力对付问题，而且要全力支持对方。
对实质性问题采取强硬态度会增加压力，促使双方找到有效解决的方案；支持对方则可增进双方的关系，加大达成共识的可能性。
支持与进攻结合起来能发挥作用，两者缺一不可。

（1）把人和事分开。
（2）着眼于利益，而不是立场。
（3）为共同利益创造选择方案。
（4）坚持使用客观标准。

虽然黑猩猩和人类的进化史大约有99.5%是共同的,但人类的大多数**家把黑猩猩视为畸形异状、与人类毫不相干的怪物,而把他们自己看成是上升为万物之主的阶梯。对一个进化论者来说,情况绝非如此。认为某一物种比另一物种高尚是毫无客观依据的。不论是黑猩猩和人类,还是蜥蜴和真菌,他们都是经过长达约三十亿年之久的所谓自然选择这一过程进化而来。

每一物种之内,某些个体比另一些个体留下更多的生存后代,因此,这些得以繁殖的幸运者的可遗传特性(基因),在其下一代中的数量就变得更加可观。基因的非随机性的区分繁殖就是自然选择。自然选择造就了我们,因此,要想了解我们的自身特性,就必须懂得自然选择。

我并不提倡以进化论为基础的道德观,我只是讲事物是如何进化的,而不是讲人类应该怎样行动才符合道德准则。我之所以强调这一点,因为我知道我有被人误解的危险。有些人不能把阐述对事物的认识同提倡事物应该如何这两件事区别开来,此类人为数实在太多。

我不准备以讲故事的方式来阐明一个论点。经过选择的例子对于任何有价值的概括从来就不是重要的证据。

动物的行为方式一般是为了有利其物种的永恒性,因而才有对同一物种的其他成员的利他主义。

为了整个物种的更大利益,个体就得成为牺牲品。

一个群体,如一个物种或一个物种中的一个种群,如果它的个体成员为了本群体的利益准备牺牲自己,这样的一个群体要比与之竞争的另一个群体,如果它的个体成员把自己的自私利益放在首位,灭绝的可能性要小。因此,世界多半要为那些具有自我牺牲精神的个体所组成的群体所占据。

在高级动物中,为了确保本物种的生存,会出现个体的自杀行为。

一个群体范围内的利他行为常常同群体之间的自私行为并行不悖。

我将论证,选择的基本单位,因此也是自我利益的基本单位,既不是物种,也不是群体,严格说来,甚至也不是个体,而是遗传单位基因。

---

达尔文的“适者生存”其实是稳定者生存(survivalofthestable)这个普遍法则的广义特殊情况。宇宙为稳定的物质所占据。所谓稳定的物质,是指原子的聚合体,它具有足够的稳定性或普遍性而被赋予一个名称。

肥皂泡往往是球状的,因为这是薄膜充满气体时的稳定形状。在宇宙飞船上,水也是稳定成为球形的液滴状,但在地球上,由于地球引力的关系,静止的水的稳定表面是水平的。盐的结晶体一般是立方体,因为这是把钠和氯离子聚合在一起的稳定形式。在太阳里,最简单的原子即氢原子不断熔合成氦原子,因为在那样的条件下,氦的结构比较稳定。

我们在这里要谈的是,远在地球还没有生命之前,通过一般的物理或化学过程,分子的某种形式的初步进化现象可能就已存在。没有必要考虑诸如预见性、目的性、方向性等问题。如果一组原子在受到能量的影响而形成某种稳定的模型,它们往往倾向于保持这种模型。自然选择的最初形式不过是选择稳定的形式并抛弃不稳定的形式罢了。这里面并没有什么难以理解的地方。事物的发展只能是这样。

大有机分子可以在稠浓的汤中平安无事地自由漂福到了某一个时刻,一个非凡的分子偶然形成。我们称之为复制基因(replicator)。

进化在某种含糊的意义上似乎是件”好事”,尤其是因为人类是进化的产物,而事实上没有什么东西“想要”进化。进化是偶然发生的,不管你愿意不愿意,尽管复制基因(以及当今的基因)不遗余力地防止这种情况的发生。

所谓稳定的意思是,那些分子或是本身存在的时间较长,或是它们能迅速地复制,或是它们能精确无误地复制。

我可以告诉你“达尔文是世界上最伟大的人物”,,而你可能会说“不,,牛顿才是最伟大的嘛”。我希望我们不要再争论下去了,应该看到,不管我们的争论结果如何,实质上的结论是不受影响的。我们把牛顿或达尔文称为伟大的人物也好,不把他们称为伟大的人物也好,他们两人的生平事迹和成就是客观存在的,不会发生任何变化。

---

自私的基因是什么?它不仅仅是DNA的一个单个的有形片断。它的目的就是试图在基因库中扩大自己的队伍。从根本上说,它采用的办法就是帮助那些它所寄居的个体编制它们能够赖以生存下去并进行繁殖的程序。

可是我们怎能指望可怜的生存机器进行这样复杂的运算啊!尤其是在匆忙间,那就更不用说了。甚至伟大的数学生物学家霍尔丹(他在1955年发表的论文里,在汉密尔顿之前就作出了基因由于援救溺水的近亲而得以繁殖的假设)也曾说,”……我曾两次把可能要淹死的人救起(自己所冒的风险是微乎其微的),在这样做的时候,我根本没有时间去进行演算。”不过:霍尔丹也清楚地知道,幸而我们不需要假定生存机器在自己的头脑里有意识地进行这些演算。正象我们使用计算尺时没有意识到我们实际上是在运用对数一样。动物可能生来就是如此,以致行动起来好象是进行过一番复杂的演算似的。

这种情况其实是不难想象的。一个人把球投入高空,然后又把球接住,他在完成这个动作时好象事先解算了一组预测球的轨道的微分方程。他对微分方程可能一窍不通,也不想知道微分方程是什么玩意儿,但这种情况不影响他没球与接球的技术。在某个下意识的水平上,他进行了某种在功能上相当于数学演算的活动。

---

抚养和生育的各种混合策略,如能适应物种生态上的具体情况,在进化上是能够稳定的。单纯的抚养策略在进化上不可能稳定。如果所有个体都以全副精力去抚养现有的幼儿,以至连一个新的个体也不生,这样的种群很诀就会受到精于生育的突变个体的入侵。抚养只有作为混合策略的一部分,才能取得进化上的稳定———至少需要进行某种数量的生育活动。

生存机器一般为自私的基因所操纵,完全可以肯定,自私的基因是不能够预见未来的,也不可能把整个物种的福利放在心上,这就是本书的基本假定。

---

亲代投资(P.I)的定义是:”亲代对子代个体进行的任何形式的投资,从而增加了该个体生存的机会(因而得以成功地繁殖),但以牺牲亲代对子代其他个体进行投资的能力为代价。”特

---

假如双亲的一方在对每一子女进行昂贵的资源投资时,其付出的份额比对方少,他或她的景况就会好一些;这是由于他或她有更多的资源用于同其他性配偶所生的其他子女身上,从而他或她的基因有更多的繁殖机会。因此,我们可以说,每个配偶都设法利用对方,试图迫使对方多投资一些。就个体来说,称心如意的算盘是“,希望”同尽可能多的异性成员进行支配(我不是指为了生理上的享乐,尽管该个体可能乐于这样做),而让与之交配的配偶把孩子抚养大。

特里弗斯特别强调指出,性配偶之间的关系是一种相互不信任和相互利用的关系。这种关于性配偶之间的相互关系的观点,对个体生态学家来说,是一种比较新的观点。我们过去通常认为,性行为、交配以及在此之前的追求行为,主要是为了共同的利益,或者甚至是为了物种的利益而相互合作共同进行的冒险事业!

然而性别有一个基本特性,可以据以标明一切动物和植物的雄性和雌性。这就是雄性的性细胞或”配子”(gametes)比雌性配子要小得多,数量也多得多。不论我们讨论的是动物还是植物,情况都是如此。。如果某个群体的个体拥有大的性细胞,为了方便起见,我们可以称之为雌性;如果另一个群体的个体拥有小的性细胞,为了方便起见,我们可以称之为雄性。

它们的一个卵细胞,其大小程度和合有的营养成分,足以喂养一个正在发育成长的幼儿长达数周。即使是人类,尽管卵子小得在显微镜下才能看见,但仍比精子大许多倍。我们将会看到,根据这一基本差别,我们就能够解释两性之间的所有其他差别。

两个同形配子相互融合时,各为新的个体提供数目相等的基因,而贡献的食物储存量也相等。精子同卵子为新的个体贡献的基因数目虽然也相等,但卵子在提供食物储存方面却远远超过精子:实际上,精子并不提供任何食物储存,只是致力于把自己的基因尽快输送给卵子而已。因此,在受孕的时刻,做父亲的对子代的投资,比他应支付的资源份额(50%)少。

生育同等数目的儿女的策略,是一种进化上的稳定策略,就是说,凡偏离这一策略的基因就要遭受净损失。

作为自私的机器,配偶双方都”希望“儿子和女儿数目均等。在这一点上他们是没有争议的。分歧在于,谁将承担抚养这些子女中每一个的主要责任。每一个体都希望存活的子女越多越好。在任何一个子女身上,他或她投资得越少,他或她能够生育的子女就会越多。显而易见,实现这种愿望的方法是诱使你的性配偶在对每一子女进行投资时付出比他或她理应承担的更多的资源,以便你自己脱身同另外的配偶再生子女。这种策略是一种两性都向往的策略,不过对雌性来讲,更难如愿以偿。

由于她一开始就以其大而食物丰富的卵子,付出比雄性多的投资额,因此做母亲的从怀孕的时刻起,就对每个幼儿承担了比做父亲的更大的”义务”。如果幼儿一旦死亡,她比做父亲的要蒙受更大的损失。更确切他讲,为了把另一个新的幼儿抚养到同死去的幼儿同样大小,她今后必须比做父亲的进行更多的投资。

当然,在许多物种中,做父亲的确实也非常勤奋,而且忠实地照料幼儿。但即使如此,我们必须估计到,在正常情况下,会有某种进化上的压力,迫使雄性个体略微减少一点对每个幼儿的投资,而设法同其他配偶生更多的子女。我这样讲指的仅仅是,基因如果说:“喂,如果你是雄性个体,那就早一点离开你的配偶,去另外找一个雌性个体吧,不必等到我的等位基因要你离开时才离开”,这样的基因往往在基因库中获得成功。

这种进化上的压力在实际生活中随着物种的不同而产生大小悬殊的影响。在许多物种中,例如极乐鸟,雌性个体得不到雄性个体的任何帮助,抚养子女完全靠自己。还有一些物种,诸如三趾鸥,结成一雌一雄的配对,是相互忠诚的楷模,它们相互配合共同承担抚养子女的任务。这里,我们必须设想。某种进化上的对抗压力起了作用:对配偶的自私剥削,不仅能得到好处,一定也会受到惩罚。在三趾鸥中,这种惩罚超过了所得利益。不管怎样,只有在妻子有条件不依赖他人抚养幼儿的前提下,父亲抛弃妻子和幼儿才会有好处。

家庭幸福策略的最简单形式是:雌性个体对雄性个体先打量一番,试图事先发现其忠诚和眷恋家庭生活的迹象。在雄性个体的种群中,成为忠诚的丈夫的倾向必然存在程度上的差异。雌性个体如能预先辨别这种特征,她们可以选择具有这种品质的雄性个体,从而使自己受益。

追求的仪式时常包括雄性个体在交配前所进行的重要投资。雌性个体可以等到雄性个体为其筑巢之后再答应与之交配。或者雄性个体必须喂养雌性个体以相当大量的食物。当然,从雌性个体的角度来讲,这是很好的事,但它同时也使人联想到家庭幸福策略的另一种可能形式。雌性个体先迫使雄性个体对它们的后代进行昂贵的投资,然后再交配,这样雄性个体在交配之后再抛弃对方,也就不会有好处了。

我曾在一篇论文中指出过,这里特里弗斯在推理方面有一个错误。他认为,预先投资本身会使该个体对未来的投资承担义务。这是一种荒谬的经济学。商人永远不会说:“我在协和式客机上(举例说)已经投资太多,现在把它丢弃实在不合算。”相反,他总是要问,即使他在这项生意中的投资数目已经很大,但为了减少损失,现在就放弃这项生意,这样做对他的未来是否有好处。同样,雌性个体迫使雄性个体在她身上进行大量投资,指望单单以此来阻止今后雄性个体最终抛弃她,这样做是徒劳的。这种形式的家庭幸福策略还要取决于一种进一步的重要假定:即雌性个体的大多数都愿意采取同样的做法。如果种群中有些雌性个体是放荡的,随时准备欢迎那些遗弃自己妻子的雄性个体,那么对抛弃自己妻子的雄性个体就会有利,不论他对她的子女的投资已经有多大。

我们把雌性的两种策略分别称为羞怯(coy)和放荡(fast),而雄性的两种策略分别称为忠诚(faithful)和薄情(philanderer),这四种策略在行为上的准则是:羞怯的雌性个体在雄性个体经过长达数周而且代价昂贵的追求阶段之后,才肯与之交配。放荡的雌性个体毫不迟疑地同任何个体进行交配。忠诚的雄性个体准备进行长时间的追求,而且交配之后,仍同雌性个体待在一起,并帮助她抚养后代。薄情的雄性个体,如果雌性个体不立即同其进行交配,很快就会失去耐心:他们走开并另寻雌性个体;即使交配之后,他们也不会留下承担起作父亲的责任,而是去另寻新欢。

如果你运算一下,就可证明,凡是羞怯忸怩的雌性个体占全部雌性个体的5/6,忠诚的雄性个体占全部雄性个体的5/8;的种群在遗传上是稳定的。当然,这仅仅是根据我们开始时任意假定的那些特定数值计算出来的,但对其他任何随意假定的数值,我们同样可以轻而易举地算出新的稳定比率。

凡一种性别的成员偏离其适中的稳定比率时,这种倾向必然受到另一种性别在策略比率方面相应变化的惩罚,这种变化对原来的偏离行为发生不利的影响。

这种令人惊讶的多样性说明,人的生活方式在很大程度上取决于文化而不是基因。

想出一个创意实在太容易了，最难的地方其实是把创意变成现实。从一个创意到让客户认可你的产品，还能快速上手使用，并愿意为之付费，这个过程的每个环节难度都在增加，每个环节都需要你组建合适的团队来完成。
你还需要学会招募人才的方法，要让他们聚焦到具体的事情上，还要确保他们一直记得所做事情的意义。

保护一个创意并不重要，重要的是保护把创意变为现实的过程。

我使用的管理方法由三个步骤组成：
首先，设置有挑战、可衡量的阶段性目标。
其次，确保你和你的团队一直朝着这个目标前进，不要被其他事情干扰。
最后，把握节奏，所有成员一直明确需要努力达成的目标，并相互支持、相互鼓励。

我发现很多人都会陷入两个误区：
要么是过于高估自己的能力，觉得自己无所不能；
要么就是过分谦虚，隐藏自己的真实实力，这都会让管理变得混乱。

作为管理者，你要清楚地知道哪些人推一推会有更高的产出，哪些人实际执行情况会出现问题。
每周对员工进行跟踪回顾，会让每个人更准确地预测自己的产出。

时间输不起，管理运营一个创业项目最怕的就是分心。

设置好目标，所有人承担起相应的责任，做好执行工作，一周结束时庆祝取得的成绩，这样的团队会令人惊叹并聚焦成长；
这样的习惯，也能保证团队不会被金苹果诱惑。

确定目标，确保团队聚焦到重要目标上
讨论关键结果，复盘OKR实施过程中的问题
评估OKR实施成果

影响目标达成的关键因素
因素1：没有给目标设置优先级
因素2：缺乏充分沟通，导致没能准确理解目标
因素3：没有做好计划
因素4：没有把时间花在重要的事情上
因素5：轻易放弃

你可以用这个简单的格式描述公司的使命：
我们通过（什么样的价值主张）在（什么领域或行业）（改善人们的生活或减少人们的痛苦）

OKR的基本原理
原则1：目标要明确方向并且鼓舞人心
原则2：目标要有时间期限
原则3：由独立的团队来执行目标

避开OKR常见的坑

1. 设置了多个目标
2. 设置的OKR周期过短——一周或者一个月
3. 用绩效指标来驱动目标的完成
4. 没有设置信心指数
5. 没有追踪信息指数的变化
6. 把周一的会议当作汇报例会，而不是谈话
7. 周五过于严肃

工作看板能让大家在日常工作中聚焦于OKR的目标，并保持跨部门之间的信息透明。

如何恢复目标的魔力

1. 用目标来定义和驱动成功
2. 传统学院派给不了让团队高产出的目标
3. 实时追踪目标进度
4. 在邮件中沟通目标
5. 自上而下的目标设置兼顾自下而上的成分

引言

大型项目
尽管对于最有经验的专业C程序员来说，C++的规模和复杂度在开始时都有点难以承受，
但一个能干的C程序员要写出一个小的但不是微不足道的C++程序，并不需要花太长时间。
然而，这种用C++创建小程序的未经训练的技术，来完成大型项目是完全不能胜任的。
也就是说，C++技术的不成熟应用不适合大型项目，不谙此道所造成的后果甚多。

物理设计
有若干关于逻辑设计的好书，但是也有不少这些书未涉及的问题，这些问题只有当程序变得很大时才出现。
这是因为与成功的大型系统设计相关的很多内容不属于逻辑设计的范畴，本书把它们作为物理设计。
物理设计涉及的问题包括与系统的物理实体有关的问题（如文件，目录和库等）以及组织问题（如物理实体之间的编译时依赖和连接时依赖等）。

对于小项目来说，一个文件目录就可满足要求，因而不必太重视物理设计。
但是对于大型项目来说，一个好的物理设计的重要性就大大提升了。
对于大型的项目来说，物理设计是项目成功的决定性因素。

重用
面向对象设计将易重用作为自己的优点。
但是正如其他风范一样，要获得好处，就要付出代价。
重用意味着耦合，而本身的耦合是我们不希望看到的。
如果若干程序员企图使用同一组件，并且不要求功能上的修改，则重用是合理和正当的。
但是，考虑这样的情形，有若干客户分别编写不同的程序，每个人都想重用一个公共组件以达到不同的目的。
如果另外一些独立客户也在积极寻求增强支持，他们会发现重用的结构彼此间不一致，
某一客户程序的加强可能会毁坏其他人的程序。
更糟糕的是，我们最终可能得到一个对谁都无用处的“超重”的类。

重用经常是好的方案，但是为了成功重用一个组件或一个子系统，该组件或子系统不应该与以一大块不需要的代码绑在一起。
也就是说，只有那些与系统其他部分没有必然联系的部分才有可能重用。
不是所有的代码都能重用。
试图实现过多的功能或者为实现对象进行完全彻底的错误检查，
都会增加不必要的研制和维护开销，也会增加可执行代码的大小。
实现者的以下两方面的知识对大型项目有益，何时重用代码和何时使代码能重用。

质量
通常，软件不能只是通过测试这一种手段来达到可靠性要求，
等到我们能测试软件的时候，软件的内在质量早已形成了，不是所有的软件都能够有效的测试。
要想让软件能够有效测试，必须从一开始就本着这个目标来对它进行设计。

为了易于测试而设计，虽然很少成为小项目最关注的事情，
却是成功构造大型和超大型系统的最重要的事情。
易测试性与质量本身一样，不可能是事后产生的想法，
它必须在编写第一行代码之前就预先考虑到。

必须在项目的一开始就考虑质量的各个方面，
设计一旦完成，就无法再提高质量了。

工具
没有工具能解决根本性问题，即固有的设计质量问题。
没有一个快捷和容易的方法可获得好的质量。
工具本身不能解决由低劣设计引起的基础性问题。
从根本上说，是经验，智力和规程产生高质量的产品。

小结
编译单元之间的循环“连接时依赖”会使程序难以理解，测试和重用。
不需要的或过多的“编译时依赖”会增加编译开销并且不利于维护。
当项目很大时，采用无组织的，无规程的或幼稚的C++开发方法，最终一定会出现这些问题。

重用不是无开销的，重用蕴含耦合，而耦合不是我们所希望的。
没有保障的重用应该避免。

质量的衡量标准有多个方面，可靠性，功能性，可用性，可维护性以及性能。
每一方面都会影响大型项目的成功或失败。

可靠性，是传统的质量定义（也就是说，“它有错误吗？”）。
功能性，是指一个产品是否能完成客户所期望的工作。
可用性，是指软件是否可以被有效的使用。
可维护性，和衡量支持一个系统工作相对开销的指标。
性能，是衡量产品速度和大小的指标。

获得高质量是一项工程的责任，从一开始就应积极追求质量，
质量不是在项目大体完成之后可以加入的东西。
良好的工具是开发过程的重要组成部分，
但是，在大型C++系统中，工具不能弥补固有的设计质量问题。

---

1. 预备知识

接口和实现
好的接口比好的实现要重要得多。
接口会对客户程序产生直接的影响，并且有全局影响力。
实现只影响作者和代码维护者。

有明确的理由要求在设计接口时实行严格的标准，尤其是在大型项目中。
修补接口通常要比修补实现更困难和昂贵。
假如有一个封装得很好的接口，那么扔掉一个糟糕的实现，
用一个更好的实现来取代它，通常并不会太困难。

特性爆炸
不断的修改和扩充对象功能是一种众所周知的把错误引进软件的方式。
同样，除非计划支持多个版本，否则不关心这些新功能的其他客户将被迫承担它们。

有些类的作者想让他们的类满足所有人的所有需求，
这样的类已经被亲切的称为温尼贝格（Winnebago）类。
这种很常见和似乎高贵的愿望令人忧虑，作为开发人员，我们必须记住，
只因为一个客户要求增加功能并不意味着对所有类都是适当的。

假如你是一个类的作者，10个客户中的每一个都请求你进行不同的增加。
如果你愿意，会发生两件事情：
（1）你将不得不实现，测试和存档10个新特征，你开始并没有认为这些新特征是你要实现的抽象的一部分。
（2）你的10个客户的每一个都会得到9个他们并没有请求和可能不必要或不想要的新特征。
每次你增加一个特性去取悦一个人，你就扰乱和潜在的*扰了你的客户库的其他人。
原本是轻量级的和很有用的类，经过一段时间后变得过于臃肿，不但不能做好每件事情，
而且毫不夸张的说，它们已经变得每件事情都做不好了。

这种只要组件足够但不必完备的最低限要求方法，适用于正在开发的大型项目。
若一个功能实现对一个抽象来说是本质的，则省略该功能将没有意义。
在进行这种权衡时，记住要考虑到功能总是更容易增加而不容易删除。

小结
有外部连接的定义在连接时可以用来解析其他编译单元中的未定义符号，
把这样的定义放在头文件中，几乎肯定是一个编译错误。

---

2. 基本规则

文档
为接口建立文档以便其他人可以使用，至少请另外一个开发者检查每个接口。

想要理解为什么让别的开发者检查接口是有价值的，可以假设你自己就是试图理解你的类的客户或者测试工程师。
你自己非常了解如何使用接口——毕竟是你自己设计的。
你用来给成员函数命名的简洁名称是“明显的”和“自解释的”。
但除非你已花时间让别人检查了你的接口和文档，否则一定有很多需要改进的地方——特别是在它的可用性方面。

可用性主要是指拿到一个不熟悉的头文件就可以开始使用它。
如果客户必须被迫查看实现以便能够领会到如何使用组件，那么该文档就是不合适的。

文档的另一个重要方面，是明确的确定行为没有定义的条件。
即，明确的声明条件，在该条件下行为没有定义。
除非明确在注释中声明，否则客户和测试工程师一般来说没有办法区分什么是特意设计的或必需的行为，
什么是仅由特定实现选择引起的巧合行为。

没有明确的规定未定义行为的条件，会不经意的使用软件支持无关的行为，
这种行为会影响性能或限制实现的选择。
通过不恰当的（或无意识的）使用，客户可能会依赖这种巧合的行为。

assert
对系统的每一层进行错误检查，以便找出逻辑错误，这样做代价很高，对于大型系统来说尤为如此。
使用assert语句，有助于为程序员实现编码时的假设建立文档，明确声明某些行为是未定义的。

文档和assert语句的有效使用可以使我们得到更简练但仍十分有用的代码，
如果有人误用了某个函数，这是他们自己的错——而且他们很快就能发现这个错误。

如果每个开发者总是很清楚函数的指针参数不能为空，这是值得称赞的。
但是负责任的客户不应该假设指针参数可以为空，除非结果行为是明确声明的。

小结
把一个类的数据成员暴露给其他客户程序违反了封装原则，
提供对数据成员的非私有访问，意味着表示上的局部改变可能迫使客户重新编写代码。

全局变量会污染全局名称空间，而且会歪曲设计的物理结构，
使得实际上不可能进行独立的测试和有选择的重用。

良好的文档是软件开发必不可少的一部分，缺少文档将降低可用性。
文档的一个重要部分是声明什么是没有定义的。
否则，客户可能会依赖巧合的行为，这种行为只能来自特定的实现选择。

不是所有的代码都必须是鲁棒的，在系统每个层次上的冗余的运行时程序错误检查，
可能对性能产生无法接受的影响，文档和断言的结合可以达到通用的目的，
但在最终产品里可以获得更优越的运行时性能。

---

3. 组件

物理设计
逻辑设计只研究体系结构问题，物理设计研究组织问题。
物理设计集中研究系统中的物理实体以及它们如何相互关联的问题。

一个组件就是物理设计的最小单位。
一个组件严格的由一个头文件和一个实现文件构成。
一个组件一般会定义一个或多个紧密相关的类和被认定适合于所支持的抽象的任何自由运算符。

在一个组件内部声明的逻辑实体，不应该在该组件之外定义。
每个组件的.c文件都应该将包含它自己的.h文件的语句作为其代码的第一行有效的语句。
通过确保一个组件自己分析自己的.h文件——不要外部提供的声明和定义，可以避免潜在的使用错误。
在一个组件的.c文件中，避免使用有外部连接并且没有在相应的.h文件中明确声明的定义。
避免通过一个局部声明来访问另一个组件中带有外部连接的定义，而是要包含那个组件的.h文件。

依赖关系
如果编译y.c时需要x.h，那么组件y展示了对组件x的编译时依赖。
如果对象文件y.o包含未定义的符号，因此可能在连接时直接或间接的调用x.o来辅助解析这些符号，
那么就说组件y展示了对组件x的一种连接时依赖。

一个编译时依赖，几乎总是隐含一个连接时依赖。

友元关系
因跨越了组件边界，（远距离）友元关系变成了一个组件的接口的一部分，并且会导致该组件的封装性被破坏。
远距离友元关系还会通过允许对一个系统的物理上较远的部分进行密切的访问而进一步影响可维护性。

---

4. 物理层次结构

接口测试
面向对象技术的一种实际有效的应用是把极大的复杂性隐藏在一个小的，定义良好的，易于理解和易于使用的接口后面。
但是，正是这种接口（如果被不成熟的实现）会导致开发出来的子系统测试起来极其困难。

一盎司预防相当于一磅治疗。

质量设计的一个主要部分是易测试性设计（DFT）。
目前DFT是IC工业的一种标准，没有哪个称职的硬件工程师会在考虑设计一个复杂芯片时不直接考虑易测试性问题。
比较起来，大型软件系统的功能可能比在最复杂的集成电路中的功能复杂好几个数量级。
令人吃惊的是，很多软件系统在设计过程中，并没有适当的计划来确保软件是可测试的。
在过去的十年中，要求软件具备易测试性的努力经常遇到在IC工业界遇到的同样的挫折。
通常是人而不是技术对解决一个技术问题形成巨大的挑战。

对于测试来说，软件中的一个类类似于现实世界中的实例。
如果直接对它进行操作，而不是试图将它作为一个更大系统的一部分来测试，那么测试一个类的功能是最简单和最有效的。
并且和IC测试不同，我们自动的拥有了对该软件子系统的接口的直接访问权。
对整个设计的层次结构进行分布式测试，比只在最高层接口进行测试有效得多。

隔离测试是指这样的规程，独立于系统的其他部分，对单个组件或子系统进行的测试。

层次号
每个有向无环图都可被赋予唯一的层次号，一个有环的图则不能。

层次0，一个在我们软件包之外的组件，
层次1，一个没有局部物理依赖的组件，
层次N，一个组件，它在物理上依赖于层次N-1上（但不是更高层次上）的一个组件。

一个组件的层次是一个最长路径的长度，该路径是指从那个组件穿过（局部）组件依赖图到外部库组件的集合（可能为空）的路径。
在大多数真实情况下，如果大型设计要被有效的测试，它们必须是可层次化的。

分层测试是指在每个物理层次结构上测试单个组件的惯例。
增量式测试是指这样的测试惯例，只测试真正在被测试组件中实现的功能。
白盒测试是指通过查看组件的底层实现来验证一个组件的期望行为。
黑盒测试是指仅基于组件的规范（即不必了解其基础实现）来检验一个组件的期望行为的惯例。
回归测试指的是这样的规程，运行一个程序（该程序被给定了一个有固定期望结果集合的特定输入），比较其结果，
以便检验程序从一个版本升级到另一个版本时，是否能够继续如所期望的那样运行。

---

5. 层次化

小结
实现层次化的技术包括：
（1）升级
将相互依赖功能在屋里层次结构中提高。
（2）降级
将共有功能在物理层次结构中降低。
（3）不透明指针
让一个对象只在名称上使用另一个对象。
（4）哑数据
使用表示对同层对象的一个依赖的数据，但只在单独的，较高层对象的上下文中。
（5）冗余
通过重复少量的代码或数据避免耦合来故意避免重用。
（6）回调
使用客户提供的函数，这些函数可以使较低层次的子系统能够在更全局的上下文中执行特定任务。
（7）管理类
建立一个拥有和协调较低层次对象的类。
（8）分解
将独立可测试子行为，从涉及过度物理依赖的复杂组件的实现中移出来。
（9）升级封装
将实现细节对客户隐藏的地点移到物理层次结构的更高层。

---

6. 绝缘

绝缘
一个被包含的实现细节（类型，数据或函数），如果被修改，添加或删除时，不会迫使客户程序重新编译，
则称这样的实现细节被绝缘了。

假设你是一个C++应用程序库的销售商，如果你供应一个完全绝缘的库实现，
那么你在增强性能和修复故障时，完全不用打扰你的客户。
给客户发送一个更新版本不会迫使用户程序重新编译或者连接，
客户需要做只是重新配置环境以指向新的动态装载的库，然后离开，让它们工作。

协议类
满足下列条件的抽象类是一个协议类：
（1）它既不包含也不继承那些包含成员数据，非虚拟函数或任何种类的私有（或保护的）成员的类。
（2）它有一个非内联虚析构函数（定义一个空实现）。
（3）所有成员函数（除了包含被继承函数的析构函数）都声明为纯虚的，并任其处于未定义的状态。

一个协议类几乎是一个完美的绝缘器。
一个协议类可以用来消除编译时依赖和连接时依赖。

完全绝缘的具体类
只保留一个不透明指针（指向包含一个类的所有私有成员的结构），
会使一个具体的类能够将其客户程序与其实现绝缘。

一个具体类如果满足下列条件，就是完全绝缘的，
（1）只包含一个数据成员，它表面上是不透明的指针，指向一个定义具体类的实现的non-const struct（定义在.c文件中）
（2）不包含任何其他种类的私有的或保护的成员
（3）不继承任何其他类
（4）不声明任何虚拟的或内联的函数。

小结
下面几种结构被认为可能会潜在的导致不希望的编译时耦合：
（1）继承和分层迫使客户程序看到继承的或嵌入对象的定义
（2）内联函数和私有成员把对象的实现细节暴露给了客户程序
（3）保护成员把保护的细节暴露给了公共的客户程序
（4）编译器产生的函数迫使实现的变化影响声明的接口
（5）包含指令人为的制造了编译时耦合
（6）默认参数把默认值暴露给了客户程序
（7）枚举类型会引起不必要的编译时耦合，因为不合适的放置或不适当的重用。

---

7. 包

包
一个包就是被组织成一个物理内聚单位的组件集合。

最小化修改之后的源代码的重编译时间，可以显著的减少开发开销。
从一个定义了main的编译单元中分解出独立可测试和潜在可重用的功能，
本质上能够使程序的整个实现在一个更大型的程序中重用。

程序中的每一个非局部静态对象结构，都会潜在的增加启用时间。

---

8. 构建一个组件

---

9. 设计一个函数

---

10. 实现一个对象

很多高度敏感型人选择独自生活，这满足了他们的敏感型人格所需要的宁静、平和，给了他们驻足品味生活的机会，但有时也难免寂寞。
允许自己偶尔做一个自由而无用的灵魂。

我不需要依靠别人获得快乐，相反，我会因此获得自由。

高敏感是上天给予你最好的礼物

多年来，我也总是拿自己与别人比较，懊恼自己不够好。
为此，我不得不坚持训练自己，努力将注意力从“我不能”转移到“我能”。

你是高敏感族吗

在我们身边，每5人就有1人高度敏感
高敏感是与生俱来的气质
我们更加谨慎，危机管理能力更强

研究显示，在挑战情境中出现强烈生理反应的孩子（敏感型儿童）会比其他孩子更容易生病，压力较大时也更容易出状况。
相反，在积极和熟悉的环境下，他们会比其他儿童更少生病，更少出问题。

高度敏感型人拥有发达的神经系统。
我们可以感知到事物细微的差别，并对信息进行更深入的加工。
我们拥有活跃的想象力和丰富的内心世界，这意味着我们从外部世界接收和感知到的信息，会触发大脑里各种概念、想法并建立联结。
如此一来，大脑“硬盘”很快就被填满，我们也会不堪重负。

多数高度敏感型人都会厌恶自身所处环境中的冲突。
比如目睹一场争吵，或者只是待在一个氛围紧张的环境中。

但是，这种感受性的优点在于，我们能进行高度共情，并给予共情式的倾听。
很多高度敏感型人做着照顾他人的工作，拥有良好的口碑、为人所称道。

许多高度敏感型人都有着强烈的责任感，认为自己需要承担整个世界的责任。
从很小的时候起，我们就能感知到身边的不安和焦虑，并总是想尽办法去解决。

其实，没有人能为所有事情负责。
当你正在为某些人或者某些事尽责时，你其实并没能同时兼顾到其他人或者其他事。
有时，学着后退一步，让他人负责，使之从错误中汲取教训或许会更好。

高度敏感型人总是努力避免给他人带来不便或痛苦。
他们也花更多精力去维持与他人的关系。
而那些相对神经大条的人，似乎更少去考虑将要说的话或者做的事。
这让敏感者们非常难以接受。
他们难以置信有人会说出如此不适宜甚至伤人的话。
因为他们认为所有人都应该跟自己一样，习惯在人际交往中深思熟虑，谨小慎微。
但事实上，并不是所有人都如此。

在与别人争辩的过程中你可能常常败下阵来，但是只有到了第二天你才会意识到当时应该如何说、如何做。

高度敏感型人拥有无比丰富的想象力，他们梦想中的人生总是精彩纷呈，内心世界也是五彩斑斓。
从个人经验来讲，独自一人时，我很少感到孤独无聊，甚至享受其中。
我不需要依靠别人获得快乐，相反，我会因此获得自由。

进入一个完全陌生的环境，你有两种可能的选择：
一种是立即投入到新环境之中，进行探索；
另一种是先等一等，看一看，思虑周全之后再行动。

一些人和动物会采取第一种策略，因为他们总是反应迅速，行为果敢，喜欢冒险；
而另一些会选择第二种策略，因为他们总是谨小慎微，习惯行动之前先耐心观察一段时间。

相比之下，高度敏感型的人更偏好第二种策略，在说话做事之前总是先仔细观察，认真思考。
你可能对这类场景再熟悉不过：
在开始一段对话之前，你可能已经想了很多：“如果他拒绝了，我就这样做；如果他看起来比较高兴，那我就……”
行动之前，你可能已经把所有可能的结果都考虑了一遍。

或许会有人鼓励你，要敢于尝试，别瞻前顾后，学着“兵来将挡、水来土掩”。
但是，如果你是一个高度敏感型人，行动之前花一点点时间考虑一下反而会更加明智。
因为你并没有多余的精力去处理冲突和失误，你的身体里储存的能量实在有限。

敏感者们总是能看透整件事情。
这也是为什么你需要比别人更多的时间来思考一件事。
它的好处在于，无论你说什么或者做什么都是经过深思熟虑的，或者是富有创造性的。
许多作家、艺术家或者**家都带有典型的高度敏感型人格特征。

高度敏感型的人很快会为之前的行为后悔，尤其是当他们的行为给别人带来痛苦或者不快时。
作为一个高度敏感型的人，你非常想要避免出现任何失误。一旦你伤害了他人，即使是动物，不管以什么方式，你都会感到极度愧疚，长时间处于深深的自责中。

一旦你将自己定义为某一特定类型，你就会根据该角色给自己设定界限，进而忘记自己还有改变和成长的潜能。

高敏感人最应学会的，是停止内耗

典型的高度敏感型的人总是给自己设定很高的标准来评判自己的行为。

在任何情况下，我都必须尽全力去做事
我不能让别人发现我的缺点
我不能做一个自私的人
我必须时刻留意他人，确保他们不出问题
当有他人在场时，只顾满足自己的需要是很不礼貌的
我不可以犯错

你会发现即使你表现得不够好，人们也会喜欢你。

一些高度敏感型人可能从小就因为自己的缺点而备受指责。
我们总是很擅长在自己身上寻找问题的根源。

学会做自己，不用时时为别人付出。

高敏感族的断舍离

学会说“不”是敏感者们必备的生存技能。
跟别人聊一聊你内心的挣扎或许会有所帮助。

你是生活的创造者，而非被动适应者。
允许自己偶尔做一个自由而无用的灵魂。
做点“无用的事”，给自己充电。

如果你是一个思维消极的人，那么你很容易被灰暗的想法和不断的自责所淹没。
如果真是如此，你可以尝试一些认知技巧，来更好地控制自己的思维。

高敏感族在人际交往中具有无与伦比的天赋

高度敏感型人擅长与人建立非常深入的关系，因为他们在一段关系中，能察觉到比别人更多的信息。

当你跟他人倾诉你的想法和感受时，你需要得到反馈，了解别人如何看待你讲的东西。
如果你是一个很在意他人想法的人，或者想要保证对话中信息交换的协调性，反馈就显得尤为重要。

平衡他人眼中的自己和现实中的自己。

作为一个高度敏感型人，深入的对话总是能引人入胜；
相反，肤浅的聊天却让你索然无味。
你喜欢将精力用于那些看起来有趣的事上，因为在你看来那是值得的。

高敏感族面对冲突、愤怒、内疚、羞耻时的处理方式

那些在暂时的争执中获胜的人其实并没有过多考虑道德准则，他们能赢是因为他们并不在意是否伤害到对方。

我觉得自己很没用，因为我总是那个在争吵中节节败退，不断做出让步的人，无法说服对方接受我的观点。

对自己想要的和厌恶的东西越明确，交流也会越顺畅。
清晰的界限有助于建立两个人之间的联结。
你越能明确地表达自己，这段关系也会越深入。

愤怒产生距离，而悲伤拉近距离。

愤怒之下隐藏着一种愿望，期盼着现实终会按照自己的意愿来改变。

但问题在于，有的时候你努力抗争、想要实现的改变其实是不会出现的。
如果你因为不喜欢同伴的某些方面而生气，幻想着如果你不断地纠正他、责骂他，他就会改变，你其实只能让你们的生活都变得更糟罢了，并不会带来任何好处。
因为我们的某些特质是天生带来，几乎不会变化。

从“应该”到“希望”，从愤怒到悲伤。

内疚感其实是把愤怒转向自己。
如果你为一些没有产生任何实质性的影响或者根本无法人为控制的事感到内疚，那么这种内疚感就是多余的。

敞开心扉：在他人的故事里看见自己是莫大的惊喜。
寻找同类：与相似的人在一起，你会得到解脱。

与那些跟你一样，为同样的事而感到羞耻的人待在一起，可以帮助你得到解脱。

高敏感人常见的心理问题

不是情绪决定认知，而是认知决定情绪。

如果你的神经系统相对敏感，那么情绪上提前为最糟糕的情况做好准备是更好的选择。
这可以帮助你在事情真正发生时不被压垮。

同样的一件事可以唤起多种不同的情绪，这取决于你对这件事的认知。
举一个例子，你在街上遇到一个大学同学，但对方并没有跟你打招呼。对此，你或许会有很多想法。

如果你想：“他一定对我不满。”这种想法会让你感到焦虑。
如果你想：“他以为他是谁啊，他凭什么不跟我打招呼？”你可能会因此而生气。
如果你想：“他可能只是没看到我。”这样一来你就不会有太大的情绪波动了。”
如果你想：“他眼神儿真不好——看看我，不戴眼镜都能看见他呢。”你会因此而心情愉悦。

如果你很容易心情抑郁，说明你的思维模式太消极了。

在麻木的世界，敏感地活

现在，我允许自己按照自己的步速行走，即使很慢也没关系。
一直以来我都想让自己能走得更快。但现在我不再这样了。

关于高敏感族的心理学研究成果

每一个反应性强的孩子在成长过程中，会对新异刺激的输入表现出持续的强烈反应。
高敏感族脑区共情部分明显比旁人活跃。

“高度敏感”可以视为新的人格分类。
关于人格，遗传因素比环境和教养的影响更大。

---

5.规模错觉

在极度贫困状态下，你不可能也不应该把事情做得完美。如果你这么做，你就是在从其他更需要这些资源的地方窃取资源。

当我们过度地把精力集中在可见的局部而忽略了不可见的整体的时候，我们就会错误地把资源投入一小部分问题上面，从而只能拯救一小部分人的生命。
这一原则适用于所有资源紧缺的情况。
面对拯救生命的问题，我们很难来讨论资源的分配，因为这样会让人觉得我们冷酷无情。
但只要资源是有限的，我们就需要开动大脑，找到使得我们的资源得到最有效利用的方式。
这才是真正的同情心。

人们总是容易注意局部而忽略整体。这是我们的本能之一。我们总是会注意到一个单一的数字而误判它的重要性。

这种规模错觉会使我们把有限的注意力和资源集中到看得见的受害者和个体事件上。

要想避免对事物重要性的误判，最重要的事就是不要只看单一数字。永远不要认为单个数字本身就有很大的意义。
当你看到一个数字的时候，你应该马上想到用它和其他的数字做对比。

人们很容易只见树木，不见森林，但幸运的是有一些简单的解决方法。
每当我要把很多数据放在一起做比较，并找出其中最重要的数字的时候，我就采用最简单的方法。我会找出其中最大的数字。
这就是二八原则。

我们总是倾向于认为在清单上的所有事情都同样重要，但是通常其中几件事的重要性就远远超过了其他所有事情的总和。
不论是分析死亡原因还是预算，我总是聚焦在那些能够占到80%重要性的事情上。在我于细枝末节上花时间之前，我总是会问自己，最重要的80%在哪里？这几个数字为什么这么大？这背后意味着什么？

要做到实事求是就是当你看到一个单一的数字并且它令你印象深刻的时候，要记得把它和其他数字做对比或做除法，得到比例之后，你有可能得到完全不同的观点。
要想控制规模错觉，我们就要关注比例。

（1）对比
大的数字总是看起来很大，而单一数字很容易误导我们。
当我们看到一个单一数字的时候，一定要记得做对比，或者做除法，得到某种比例。

（2）二八原则
如果你得到了一个长长的清单，就应该先排序，然后找到最大的几项并且做深入分析。
通常这几项的重要性要远大于其他所有项目加在一起的重要性。

（3）比例
数字和比例有可能代表着完全不同的含义。
尤其当我们在不同大小的组别之间做对比的时候，比例总是更有意义。
具体来讲，我们在对国家和地区进行比较的时候，应该更加关注人均数字。

---

解决正确的问题

在采取行动说服别人接受我们的方案之前，必须问自己一个非常重要的问题。
我们是在解决问题，还是在推行方案？
只有这样，你才有可能放弃自己偏爱的方案，信心十足的去推行最合适团队的方案。
在关键时候，才能迈出下一步，寻找其他方案，然后客观的权衡利弊。

之所以要在推销方案前先努力想清楚问题所在，主要原因在于。
（1）这样做可以先让自己弄明白到底是不是真的存在问题
（2）这样做可以强制你站在听众的角度来思考问题
（3）这样做可以让你拿出最适合听众的解决方案
甚至，你都得问问自己，到底有没有需要解决的问题？

要解决正确的问题，最困难的莫过于把目光从自己最倾心的方案转移到其他方案了。
为此，必须要有兼容并包的胸怀，勇于放弃先入为主的成见。
记住要从问题出发，而不要从特定的实现方法出发。

即使摸底调查没有给你带来什么灵感，但至少可以通过谈话了解人们当前的困惑程度，
知道他们可能接受你提出的什么解决方案。

强迫自己列出各种可能的替代方案，就算不是太好也不要紧。
如果你跟别人说没有别的替代方案，人家不会相信你。
替代方案始终都会有的，即使你到头来不会采用，但至少还得考虑它们。
这时候主要的挑战就是做不到真正客观的考虑替代方案。
越是公平公正的对待替代方案，你的心胸也就会更加宽广，掉进这个陷阱的可能性就越低。

在拿出你的解决方案之前，先做一番研究，看看那些创建方案的人是想用它解决什么问题。
学习一种能替代你的解决方案的技术，至少要能搞明白替代方案是怎么回事。

怀疑者模式

知道了要跟谁打交道，才能找出与其打交道的方法。

孤陋寡闻型，随波逐流型，百般挑剔型，激情燃尽型，时间紧迫型，发号施令型，不可理喻型。

应对孤陋寡闻型的人，只需要告诉他们这种技术即可，不过，他们很可能会皈依别的怀疑者模式，而不是被你说服。

应对随波逐流型的人，必须运用你的领导力，带领他们，让他们跟在你后面。

应对百般挑剔型的人，要明白他只是为了表现的比你聪明而已，要么让他们少开口，要么做好充分的准备。

应对激情燃尽型的人，最关键的是要弄明白他们经历过什么事，必须知道自己建议的方案是不是用得其所。

应对时间紧迫型的人，问题的关键在于搞清楚时间紧迫到底是什么原因造成的，
而且也不要在不恰当的时机，向不恰当的人推销，而你只要能给他们节省时间，他们就愿意跟你合作，
最难的地方就是让他们相信一定能节省时间。

应对发号施令型的人，他们一般是管理者，关键在于能否让他们把你推荐的工具当成解决他们问题的方案。
因此，必须把自己的工具作为解决管理者问题的方案来讲解。

应对不可理喻型的人，关键不在于转变他们的想法，而在于运用各种工具和技巧将它们的反对意见公之于众，
同时扭转他们的说法，但是不要搞错了，不是要尽力说服他们，而是要尽力包容他们，
如果无论如何也不可能说服他们，那就只好忽略他们，让管理者批准使用你推荐的技术。

技巧

（1）取得经验

千万不要推荐别人使用那些自己都不熟悉的工具和技术。
除了广告词里宣传的那几个特色功能之外，你还得知道这种工具什么情况下，什么地方存在局限性。
一定要让你的同事在面临继续或放弃这个问题的时候，能够再多一个选择，问你。

怎样成为专家。
研究技术和工具的沿革，搞清楚发明它们的初衷。
搞清楚它们是什么时候，在什么地方，为什么，由谁，以及怎么创造出来的。
还要知道存在哪些竞争性技术。
要清楚它为什么合适，而另一种技术为什么不合适。

由于知识的更新速度太快，真正的专家与过气的专家之间的区别就在于能否持续不断的学习和更新。
记住这一点，就可以随时保持自信和谦逊。
不能与时俱进的专家就算不上专家，也只有与时俱进才能让人成为专家。

从和蔼可亲的专家到高高在上的“万事通”，这中间很可能只有一步之遥。
归根到底，就看你能否倾听别人的意见。
“万事通”只听自己的，只要他相出一个方案，就没有别人说法的余地了。不管可行与否，这种人都会口若悬河，滔滔不绝。
而专家呢？真正的专家会认真倾听每一个人的声音，并在倾听的基础上找到解决方案。

（2）传达理念

你得向别人宣传自己想要推荐的工具，在宣传这些工具的同时，还要牢记两点，不要吓跑听众，要吸引听众。
无论你自己觉得多么有吸引力，但一吓着他们，他们就会跑掉。

不要告诉人家他们现在的这个选择“不对”，不要就好像人家误入歧途一样跟人家谈话。
那谈什么呢？谈你的工具如果管用，如何高效。
关键在于不要强调你的工具好还是不好，正确还是不正确。

很多时候，在听说别人还没有使用我们推荐的技术时，我们的第一反应就是去吓唬他们。
你这么一说，只会激起别人反驳的欲望。
要想鼓励人去做什么，更好的办法是提建议，而不是申饬别人。
命令别人去做什么事很难成功，因为他们会维护自己的立场。
更好的做法是多听而不是多说，理解他们的背景，明了他们的问题，争论应该围绕他们的问题展开。

怎么去传达，比传达什么更重要。
还有一点很重要，不管你说了什么，他们只相信自己听到的。

（3）展示技术

表演，不要光说。百闻不如一见。
要想让人了解一种工具，它的功能，优势以及使用方法，最好的方式莫过于把它展示出来。
演示失败并且不就措施也不管用的时候，最恰当的做法是停下来，从容的跟大家解释，不要让人察觉你内心的慌乱。

（4）建立信任

假如没人相信你，即便是推广最简单的工具和技术，你都可能会面临孤军奋战，无人响应的境地。
建立信任之所以可行，是因为人们都不喜欢被操纵。
在更换工具或技术时，你经常会发现所有的经验都拿出来比对过了，所有的选择也都细细的斟酌过了，
而此时对于到底该选择哪一个大家仍然莫衷一是。这时候，通常都需要有人打破僵局，最终一锤定音。
这个一锤定音可能并不是靠理性，也不是靠什么经验，某种程度上，最终的决定源自对一个人的信任。

如何建立信任？不要故意撒谎，不要回避事实，避免“狼来了”，承认错误。

现实中，诱惑人说谎的因素比比皆是，特别是为了一些短期利益。
从长远来看，说谎的代价实在太大了。说出事实的真相吧，超越短视的行为，放眼长远吧。

宫廷的朝臣们常常处于这样微妙而复杂的境地：
一方面，他们必须伺候主子，讨好奉承，
另一发面，如果他们谄媚拍马得过于明显，别的朝臣就会注意和警惕，并采取敌对的行动。
因此，要赢得主子的欢心和垂青，必须手段高明巧妙，使他人难以觉察，而这些娴熟高超的手腕还可以保护自己，
防备那些处心积虑想把你拉下马的同僚。

任何一位试图永远为善的人，必定会毁灭在那些有意为恶的人手中。——马基雅维利

有一些人会认为，有意识的玩弄权术，不管多么隐秘，都是邪恶和自私的，是旧时代的不良遗产。
他们认为只要做事儿不玩弄权术，就可以置身于权力游戏之外。
对这样的人必须特别注意，因为如此公开的表明自己观点的人，往往是玩弄权术最老练的人。
他们只不过是用聪明的策略，巧妙的避免陷入权力争斗之中。

还有另一种回避权力游戏的方法，那就是完全的诚实与坦率，
因为追求权力的人的主要手段就是隐蔽和欺诈。
而完全的坦诚不可避免的会冒犯和伤害很多的人，其中有些人会实施报复。
没有人会认为你的坦诚是完全客观，丝毫没有个人动机的。
实际上，他们也许是对的。
事实上，表现诚实确实是一种权力的策略，试图要使别人相信你的高尚，无私和善意的品格。
这是一种说服的方式，甚至是一种巧妙的强制的手段。

整个世界就像一个勾心斗角的巨大宫廷，我们都深陷其中，如果试图置身于游戏之外，那是徒劳无益的。
因为那只会使你失去力量，而失去力量你将会陷入悲惨的境地。
与其抗拒必然的规律去争论，怨恨或充满罪恶感，还不如努力精于权力之道为好。
实际上，你越善于操控权力，你就越能成为一个好朋友，好情人，好丈夫或好妻子。
遵循成功朝臣的权力之道，你将会使别人感觉更好，成为他们快乐的源泉。
他们将仰仗你的才能，渴望聚集在你的周围。

这些技巧中最重要的，也是权力最关键的基石，就是控制自己情绪的能力。
对任何情况或局面都产生情绪上的反应是通向权力道路最大的障碍，这样的错误会让你付出巨大的代价。
情绪会遮蔽理性。
如果不能清醒的看清形势，你就无法做好准备，正确应对，从容掌控。

愤怒是情绪反应中破坏性最强的。
愤怒会阻碍你的视野，它还会产生连锁反应，使局面变得难以控制，甚至增强敌人的决心。
如果你想要毁灭曾经伤害你的敌人，最好的办法是假装友善而不是表现愤怒，让他毫无戒备。

爱和感情同样具有潜在的破坏性。
它会使你盲目，看不出他们自私自利的心计，从而丝毫不会怀疑他们在玩弄权术。
然而人们很难压抑爱或愤怒，很难回避也不会回避这样的感情，但你应该知道如何谨慎小心的表达它们。
最重要的是，不论在什么情况下，绝对不能让爱与愤怒影响你的计划和策略。

增强自己控制情绪的能力，最好的办法是让自己跳出眼前的情境或事情，冷静客观的思考过去和未来。
没有任何事情会让你惊慌失措，因为在事情发生之前你早就把它们预见到了。
与其花时间梦想着美满的结局，不如细致周密的排列推演各种可能的结果，步骤和突发的失误。
你看的越远，事前的计划越周密，你的力量就越强大。

欺骗和伪装不应简单的看成是丑恶和不道德的，
人与人之间的交际互动在很多方面都需要欺骗。
在某种意义上说，人类之所以与动物有区别，就是在于人类有说谎和欺骗的能力。
欺诈是文明社会高度发达的一种艺术，也是权力角逐场上最强有力的武器。

要灵活运用各种不同的外表，包括你自己的，内心不要有沉重的负疚感，因为它会拖累很多人。
要让你我的面孔就像演员一样有很强的可塑性，富于变化，在别人面前隐藏你的意图，并练习把别人引诱入圈套。
具有多变的外表并掌握欺骗的艺术，你会拥有美好而快乐的人生，而这也是你获取权力的关键所在。

要想获取权力，最重要的技能之一，就是能够根据形势变化而不是根据善恶来洞察情势，做出判断和应对。
你应该以自己的所见所感来衡量对手的策略与力量，至于他的个人意图只会混淆概念，模糊主题，起到欺骗的作用。

如果你的朋友心怀善意，而且内心一直是为了你的利益而努力，可行动的结果却是带来极大的损害和混乱，那又如何呢？
这些人会很自然的找出各种各样的理由来掩饰他们的行动，假惺惺的说都是出于好意。
每次听到这些你就应该在内心大笑，你要学会永远不要以固定的道德来判断他人的意图与行动，以免落入陷阱。

一件事情的价值，有时并不在于我们从中得到了什么，而在于为此付出什么——即我们所付出的代价。
可以将这一标准用于所有事物上，包括是否要与他人合作或给他人帮助。
归根结底，人生苦短，机会稀少，而你能投入的能力是有限的。
在这个意义上，时间是必须考虑的一个重要因素。
千万不要为了别人的事情浪费自己宝贵的时间，或打破自己精神的宁静，否则这代价就太昂贵了。

永远不要去区分谁是你应该研究的，谁是你可以信赖的。
永远不要完全信任任何人，而应该研究每一个人，包括朋友和你所爱的人。

最后，你必须学会永远要走迂回的路线去获取权力，要掩盖你的精明或狡诈。
你的行动必须周密计划，以最不显眼的方式来实施。

1. 不要显得比上司聪明能干
2. 不要相信朋友，知道如何利用敌人
3. 隐藏你的动机
4. 少说话
5. 用生命来维护你的声誉
6. 不惜代价来保持别人的注意
7. 让别人做事，你拿走结果
8. 让别人投奔你，有必要的话使用诱饵。
9. 通过行动来赢得胜利，而不是辩论。
10. 不要与不快乐和不幸运的人为伍
11. 让别人依靠你
12. 有选择的诚实和慷慨来让你的牺牲品缴械
13. 当你有求于人的时候，让别人觉得有利可图，而不是博得别人的怜悯和慷慨
14. 表现的像个朋友，实则去探听别人的弱点和意图
15. 穷寇要灭
16. 通过不到席来增加你的尊敬和荣誉
17. 不要让别人掌握你的行踪
18. 不要孤立自己
19. 不要得罪不该得罪的人
20. 不要轻易加入一边，让两边都来争取你
21. 让别人觉得自己比你聪明
22. 学会投降，等待敌人衰弱
23. 集中精力打大仗
24. 学会完美的溜须拍马
25. 学会塑造自己
26. 不要让错误和缺点和自己沾边
27. 制造宗教般的信仰氛围
28. 行动大胆
29. 眼光要看远，看到事情发展的结果
30. 让你的成就看来得来不费吹灰之力
31. 让你的下属无论选择什么都在你的掌控之中
32. 让人们有美妙的希望
33. 找到每个人的弱点
34. 有自己的风格，表现的像个君王
35. 懂得掌握时机
36. 对那些你无法掌握的东西表现不屑
37. 外表要让人印象深刻
38. 行为与语言不要标新立异，想法可以
39. 让敌人感情失控，自己平静来取得好处
40. 不要相信免费的午餐
41. 不要步一个伟人的后尘，这样你要两倍伟大才可以有一样的声誉
42. 擒贼先擒王
43. 要引诱别人的心
44. 通过模仿敌人来麻痹和激怒敌人
45. 要变革，但不要一次变革太多
46. 不要显得太完美，别人的嫉妒会毁了你
47. 不要让胜利冲昏你的头脑而不切实际
48. 随时准备变化，让敌人无法攻击你

如果您遇到很痛苦的事情，似乎一个比较好的建议就是更频繁的去做这件事。

关于持续集成，一件有趣的事情就是人们常常对它产生的影响感到吃惊。
我们经常发现人们认为它的好处不大，但它却给项目带来了完全不同的感觉。
项目的可见性变得好了很多，因为问题能够更快的检测出来。

因为引入缺陷和发现缺陷之间的时间变短了，缺陷的发现就更容易，您可以很容易的看看改变了什么，以便帮助您找到问题的根源。
与良好的测试程序配合时，可以大大减少缺陷的数量。
结果是，开发者在调试上花的时间减少了，在增加功能上花的时间更多了，他们相信自己是在一个坚实的基础上开发软件。

---

对我来说，它代表了我成为一名高效率软件开发者的主要目标之一：
将重复的，容易出错的过程自动化。

一个人开发的项目中，依赖外部系统又比较少的话，软件集成不会成为太大的问题，但是随着项目复杂度的增加（即使只增加一个人），
就会对集成和确保软件组件能够一起工作提出更多的要求——要早集成，常集成。
等到项目快结束时才来集成会导致各种各样的软件品质问题，解决这些问题代价很大，常常会导致项目延期。

CI（continuous integration）以较小增量的方式迅速的解决这些风险。

开发团队不应该相信因为CI系统自动化了，就可以避免集成问题。

持续集成增加了您获得反馈信息的机会。这样，您每天都能多次了解项目的状态。
CI可以用来减少引入缺陷和修复缺陷的时间，从而改进总体软件品质。

“持续”这个术语从技术上来说是不对的。“持续”意味着某事一旦启动就不会停止。
这意味着集成过程一直在执行，但是即使对于最密集的CI环境来说，也不是这样的。
所以，“持续集成”的含义更像是“经常集成”。

---

“每天吃一个苹果”和实际这么去做是两码事。

一次构建不止是一次编译。
一次构建可能包含编译，测试，审查和部署以及其他一些事情。
一次构建的将源代码放在一起，并验证软件可以作为一个一致的单元运行的过程。

CI场景中的步骤通常是这样的：
（1）一名开发者向版本控制库提交代码。同时，集成构建计算机上的CI服务器正在轮询检查版本控制库中的变更。
（2）在提交发生之后，CI服务器检测到版本控制库中发生了变更，所以CI服务器会从库中取得最新的代码副本，执行构建脚本，该脚本将对软件进行集成。
（3）CI服务器向指定项目成员发出电子邮件，提供构建结果的反馈信息。
（4）CI服务器继续轮询版本控制库中的变更。

CI需要具备的特征：
（1）与版本控制系统连接
（2）构建脚本
（3）某种类型的反馈机制
（4）集成源代码变更的过程

CI的一个关键目标就是要提供集成构建的反馈信息。
因为您需要尽快知道最近一次构建是否存在问题。
如果立即得知这些信息，您就可以很快的修复问题。

很多人认为，没有自动化的，持续的测试的CI不能算作是CI。
我非常同意。
没有自动化的测试，开发者或其他项目风险承担者对软件的变更很难有信心。

一个好的CI系统的关键特征就是“速度”，CI系统的本质是及时向开发者和项目风险承担者提供反馈信息。

---

假定是所有麻烦之母。

软件开发中最重要的问题之一就是假定。
如果您假定一个方法将得到正确的调用参数，那么这个方法就会失败。
如果假定开发者都会坚持编码标准和设计标准，那么软件就会变得很难维护。
如果假定配置文件没有改变，那么您就会花上不少宝贵的开发时间来追踪不存在的问题。
如果在软件开发时对某些问题想当然，我们就会浪费时间，增加风险。

持续集成在每次版本控制系统发生变更时就执行构建，这有助于减少项目中的假定。

开发软件需要对变更做好计划，持续的观察结果，并根据结果增量的修正路线。
这正是CI的工作方式。

CI包含了一组策略，让软件开发者能够对代码进行修改，知道如果我们对软件造成了破坏，就会马上收到反馈信息。
这种即时的反馈让我们有时间修正路线，根据变化迅速的调整。

检查软件的品质，就是检查最新的集成构建，就这么简单。

CI的价值是什么：
（1）减少风险
（2）减少重复过程
（3）在任何时间，任何地点生成可部署的软件
（4）增强项目的可见性
（5）对开发团队的软件产品建立起更强大的产品信心

最好在项目早期就实现CI。
如果你在项目晚期开始实现CI，要从较少的工作开始，在时间允许的情况下加入更多的东西。

CI不仅是一种技术上的实现，它也是一种组织上和文化上的实现。
人们常常拒绝改变，在组织中引入改变的最佳方式可能是一点一点的在过程中增加这些自动化的机制。

在项目中实现CI的团队有好处的7项实践：
（1）经常提交代码
（2）不要提交无法构建的代码
（3）立即修复无法集成的构建
（4）编写自动化的开发者测试
（5）必须通过所有测试和审查
（6）执行私有构建
（7）避免签出无法构建的代码

---

大部分开发团队在一开始都怀有良好的意愿，但有一些团队还是被项目中遇到的问题压垮了。
产生这些问题就是因为没有管理风险。

我们很少听到开发团队会说“我们认为测试和代码复查是不好的实践”，
但是，当受到进度压力的影响时，这些实践通常会被开发团队率先放弃。

如果您可以减少某些软件开发风险，您就能够改进软件品质。
在任何项目中，都有许多风险需要管理。
我们关注那些可以利用CI来减少的关键风险。
（1）没有可部署的软件
（2）很晚才发现缺陷
（3）缺少项目的可见性
（4）低品质的软件

您可能意识到了某些风险，却没有对它进行必要的缓解。

---

软件开发过程中耗时的任务同样也可以通过自动化构建实现机械化。
如果工人的工作在他的8小时工作日中都忙于一些手工任务，那肯定就没有时间来监控过程和产品，计划改进以及其他工作。

有时候开发者就像是鞋匠，为他的所有客户都提供了鞋子，却忘记了为他自己的孩子做鞋。
我们为用户创建了应用程序使过程自动化，但我们没有自动化自己的软件开发过程。

把所有需要的东西都放到源代码版本控制库中，以便于您通过单个命令就能构建整个系统。

为了能够有效的构建软件，所有软件资产都必须集中放置。
在使用版本控制库集中存放“所有”软件资产时，您仍然需要判断“所有”都包含了哪些东西。
要利用项目的级别或风险来确定放在版本控制库中的软件资产至少应该包含哪些东西。

为了能够在项目开发过程中从版本控制库中取出所有各种可供使用的资产组合，您必须创建一致的，有逻辑的目录结构。

让构建快速失败。
好的构建知道如何快速的失败。
在构建的许多部分都成功之后再失败，这让人很恼火，而且您在确定失败的目标时也会失去宝贵的时间。

对于一个具体的项目，这取决于什么最有可能经常会失败。
它越有可能失败，您就应该越早的在构建脚本中执行它。

---

持续数据库集成（CDBI）是一个过程，即每次项目的版本控制库中发生变更时，重建数据库和测试数据。

数据库集成是集成按钮的一部分，因为它基于一个原则，
即数据库代码在本质上与系统的其他源代码没有差别。

通过对数据库集成自动化，您还能获得一项重要的能力，
即团队中的每个人都能在他们自己的工作站上创建一个本地数据库实例。
每个团队成员因此可以创建一个数据库“沙盒”，使得对数据库进行变更和测试不会影响到他人。

实现自动化，共享和构建数据库集成过程的目的就是要让这些过程持续进行。

让每个开发者能够修改数据库。
每个开发者都应该能够修改任何一部分数据库脚本。
这并不是意味着每个开发者都会去修改这些数据库脚本，因为并非每个开发者都有必要的数据库专业知识。

因为每个开发者都有自己的数据库沙盒，所以每个人都能修改本地的数据库然后将变更提交到版本控制库。
这将减少DBA的瓶颈，使开发者能够进行必要的变更。

不论什么使得构建失败，首要的工作就是修复它。
回报随之而来，所做的修复得到集成，这个问题不会再次发生。

打破障碍，让数据库小组成为开发团队的一部分。

---

可靠性——在连续的试验中给出同样的结果。

系统工程有一项原则，线性系统的可靠性是每个系统组件的可靠性的乘积。

为了获得高可靠性，大桥的建造者和钢笔的制造者，必须从最低层开始确保组件的可靠性，
因为这才是确保整体可靠性的唯一方式。

大部分软件系统如果没有几千个对象，也有几百个对象，
对于包含100个组件的线性系统来说，如果每个组件的可靠性是99%，整个系统的可靠性就只有37%。

如果您想构建一个软件系统，它在服务层面的承诺达到100%，您绝对需要在单个对象的层面上确保可靠性。
如果您不能从最低层确保并测量可靠性，您就不可能在系统层面上达到要求。
然而，这正是我们整个行业一直以来构建和交付软件的主要方式。
设计，构建，然后抛给质量保证（QA）小组。QA小组在系统层面上进行测试，然后不可避免的发现许多缺陷。

所以作为底线，如果我们要构建真正可靠的软件系统，我们就必须确保对象层面的可靠性，这只能通过成功的单元测试来实现。
否则，我们就不能期望构建出高可靠的应用程序。
当然，只是为对象编写单元测试不一定能保证可靠性。测试必须有效的使用了被测对象，而且必须经常执行。

因为软件系统中的对象相互之间进行通信，每次当系统发生变更时，测试都必须执行。
在CI系统中包含持续的测试让您能够做到这一点。

开发者测试和CI可以减少软件缺陷发生的频率，但说实话，缺陷仍会发生。
为缺陷编写测试，保证缺陷一旦被发现，就再也不会出现。

---

代码复查是由人来执行的，而人是讲感情的。
这意味着人们可能不会告诉其他同事他们的代码写的很臭，在一个工作环境下工作的同事可能会在复查别人的工作时不客观。
代码复查比较费时，即使是在沟通很好的环境之中也是如此。

基于人的审查与静态分析工具执行的审查之间的区别有两点：
（1）这些工具经常运行的成本很低
（2）这些工具具有计算机的无所畏惧和无情的客观性

利用工具进行自动化的代码审查能解决的80%的问题，让人来处理另外20%的重要问题。

传入耦合（Afferent Coupling）和传出耦合（Efferent Coupling）都反映了一个架构维护问题：
要么这个对象对其他太多对象负有责任（高传入耦合），要么这个对象不够独立于其他对象（高传出耦合）。

传入耦合高的对象会造成破坏，传出耦合高的配件则会受到破坏。
同样，为这些配件编写足够的测试，达到一定的代码覆盖率，将会有助于开发团队快速定位问题。

不稳定性 = 传出耦合 / (传出耦合 + 传入耦合)
值为1表示不稳定，值为0表示稳定。

持续评估代码品质。

---

如果组织机构付钱让您写软件，那么付钱的组织机构很可能希望您在一段时间之后向最终用户提供能工作的软件，这段时间是可预测的，也是符合实际情况的。
因此，我们有理由认为我们这个行业应该已经找到了一种可靠的方法，在期望的时间表内向最终用户提交高品质的，能工作的软件。
但是我们仍然会听到“噩梦发行版”的故事，它们失去控制，每个人有过惊慌失措，失眠，长出更多白头发——而且仍然可能没有办法向最终用户提供新的发行版。

高效的创建能工作的软件是专业软件开发者存在的理由。
没有成功的开发，软件就不可能存在。

如果您不能发布您的软件，那么其他事情就几乎相当于不存在。

---

软件项目中的信息一直在变化。
我们必须与客户，开放者，管理层或项目的其他风险承担者沟通信息，沟通恰当，准确和及时是特别重要的。

在正确的时间，以正确的方式，将正确的信息发送给正确的人——CI是让这种反馈信息自动化，目标化和实时化（持续化）的最好工具。

向项目中的每一个人发送信息通常只会导致每个人都忽略该信息。

持续集成的核心是减少缺陷引入，发现和修复之间的时间间隔。

1. 经济学十大原理

（1）人们如何做出决策
a) 人们面临交替关系
b) 某些东西的成本是为了得到它所放弃的东西
c) 理性人考虑边际量
d) 人们会对激励做出反应

（2）人们如何相互交易
a) 贸易能使每个人状况更好
b) 市场通常是组织经济活动的一种好方法
c) 政府有时可以改善市场结果

（3）整个经济如何运行
a) 一国的生活水平取决于它生产物品与劳务的能力
b) 当政府发行过多货币时，物价上升
c) 社会面临通货膨胀与失业之间的短期交替关系

2. 像经济学家一样思考

经济学家努力以科学家的客观态度来研究他们的学科。
像所有科学家一样，他们做出了适当的假设并建立了简单的模型，以便解释我们周围的世界。

经济学领域分为两个分领域：微观经济学和宏观经济学。
微观经济学家研究家庭和企业做出决策以及家庭和企业之间在市场上的相互交易。
宏观经济学家研究影响整体经济的力量和趋势。

实证表述是关于世界是什么的论断。
规范表述是关于世界应该是什么的论断。
当经济学家做出规范表述时，他们的行为更像决策者而不是科学家。

那些向决策者提出建议的经济学家提出了互相冲突的建议，
既是因为科学论断的差别，也是因为价值观的差别。
有时政策制定者得到了互相冲突的建议，是因为一些不懂装懂的人对难题提出了一个不切实际的简单的解决方法。
在另一些时候，经济学家提供的建议是一致的，但决策者可能选择不理会这些建议。

3. 相互依存性与贸易的好处

比较优势原理表明，贸易可以使每个人的状况变得更好。
每个人都消费本国和世界各国许多其他人所生产的物品和劳务。
相互依存和贸易之所以合意，是因为它可以使每个人享受更多数量和品种的物品和劳务。

有两种方法比较两个人在生产一种物品时的能力。
一个可以用较少量投入生产物品的生产者，被称为在生产这种物品上具有绝对优势，
某一个人生产一种物品其机会成本小，被称为有比较优势。
贸易的好处是根据比较优势，而不是绝对优势。

贸易可以使每个人状况更好，是因为它使人们可以专门从事自己有比较优势的活动。
比较优势原理适用于国家与个人。
经济学家用比较优势原理支持各国间的自由贸易。

4. 供给与需求的市场力量

只要你到商店去买东西，你就对那种东西的需求做出了贡献。
只要你找工作，你就对劳动服务的供给做出了贡献。
由于供给与需求是如此普遍的经济现象，所以，供求模型是一种十分有用的分析工具。

任何一种经济制度中，资源都要配置到竞争性用途中。
市场经济利用供给与需求的力量来实现这个目标。
供给与需求共同决定了经济中许多不同物品与劳务的价格，价格又是指导资源配置的信号。

例如，考虑一下海滩土地的配置。
由于这种土地量有限，并不是每一个人都能享受海滩的奢华生活。
谁得到这种资源呢？答案是愿意支付这种价格的人。
海滩土地的价格要一直进行调整，直至这种土地的需求量与供给量平衡。
因此，在市场经济中，价格是配置稀缺资源的机制。
同样，价格决定了谁生产每种物品，以及生产多少。
食物价格和农业工人工资调整确保了有足够的人选择当农民。

经济是一大群从事许多相互依存的活动的人。
什么因素使分散决策免于陷入混乱呢？
用什么来协调千百万有不同能力与欲望的人的行动呢？
用什么来保证需要做到的实际上也实现了呢？
用一个词来回答就是价格。

5. 弹性及其应用

需求价格弹性，衡量需求量对价格变动的反应程度。
如果某种物品是奢侈品而不是必需品，如果可以得到相近的替代品，
如果市场范围狭小，或者如果买者有相当长时间对价格变动做出反应，
那么，这种物品就倾向于更富有弹性。

可以用需求量变动百分比除以价格变动百分比来计算需求价格弹性。
如果弹性小于1，以至于需求量变动比例小于价格变动，那么就可以说需求缺乏弹性。
如果弹性大于1，以至于需求量变动比例大于价格变动，那么就可以说需求富有弹性。

总收益，即对一种物品的总支付量，等于该物品的价格乘以销售量。
对于缺乏弹性的需求曲线，总收益随着价格的上升而增加。
对于富有弹性的需求曲线，总收益随着价格的上升而减少。

需求收入弹性，衡量需求量变动对收入变动的反应程度。

供给价格弹性，衡量供给量变动对价格变动的反应程度。
这种弹性往往取决于所考虑的时间长短。
在大多数市场上，供给在长期中比在短期中更富有弹性。

6. 供给，需求与政府政策

经济学家有两种作用，作为科学家，他们提出并检验解释我们周围世界的理论。
作为决策者，他们用自己的理论努力使世界变得更好。

经济受两种规律支配：供求规律和政府制定的法规。
当分析政府政策时，供给和需求是首要的，最有用的分析工具。

价格上限是某种物品与劳务法定的最高价格。
租金控制是一个例子，如果价格上限低于均衡价格，需求量则大于供给量。
由于引起了短缺，卖者必须以某种方式在买者中配给物品或劳务。

价格下限是某种物品或劳务法定的最低价格。
最低工资是一个例子，如果价格下限高于均衡价格，供给量则大于需求量。
由于引起了过剩，必然要以某种方式在卖者中配给买者的物品或劳务需求。

当政府对一种物品征收税收时，该物品的均衡数量减少。
这就是说，对市场收税缩小了市场的规模。

对一种物品征税是在买者支付的价格和卖者得到的价格之间打入了一个楔子，
当市场向新均衡变动时，买者为该物品支付的价格高了，而卖者从该物品得到的价格低了。
在这种意义上说，买者与卖者分摊税收负担。
税收归宿并不取决于是向买者征税，还是向卖者征税。

税收归宿取决于供给和需求的价格弹性。
税收负担倾向于落在缺乏弹性的市场一方，因为市场的这一方难以通过改变购买或销售量来对税收做出反应。

7. 消费者，生产者与市场效率

供求力量可以有效的配置资源。
尽管市场的每个买者与卖者值关心他自己的福利，但他们共同被一只看不见的手指引到使买者与卖者总收益最大化的均衡。

为了得到市场有效率的结论，我们做出了一些关于市场如何运行的假设。
当这些假设不成立时，我们关于市场均衡有效率的结论可能就不再正确了。
（1）我们假设市场是完全竞争的。
世界上有时竞争的极不完全的，在一些市场上，只有一个买者或卖者（或一小群买者或卖者）可以控制市场价格。
这种影响价格的能力被称为市场势力。市场势力，可以使市场无效率，因为它会使价格和数量背离供求均衡。

（2）我们假设市场结果只与买者和卖者相关。
世界上，买者和卖者的决策有时影响那些根本不参与市场的人。
污染是影响不参与市场的人的市场结果的一个单行例子，这种负作用称为外部性，
它使市场福利还要取决于买者评价和卖者成本之外的其他因素。
由于买者和卖者在决定消费和生产时并没有考虑这种负作用，所以从整个社会的角度看，市场均衡可能是无效率的。

市场势力和外部性是被称为市场失灵的普遍现象的例子。
市场失灵是一些不受管制的市场，不能有效的配置资源。
当市场失灵时，公共政策就有潜力解决这些问题并增加经济福利。
微观经济学家耗费许多精力去研究什么时候会发生市场失灵，以及哪种政策能最好的纠正市场失灵。
尽管有市场失灵的可能性，市场中看不见的手仍然是极其重要的。

消费者剩余等于买者对一种物品的支付意愿减去它们实际为此所支付的量，它衡量买者从参与市场中的得到的收益。
生产者剩余等于卖者由其物品得到的量减去它们的生产成本，它衡量卖者从参与市场中得到的收益。

使消费者和生产者剩余的总和最大化的资源配置是有效率的。
决策者通常关心经济结果的效率以及平等。
供给和需求的均衡使消费者与生产者剩余的总和最大化。
这就是市场中看不见的手指引买者与卖者有效的配置资源。
在存在市场势力或外部性这类市场失灵的情况下，市场不能有效的配置资源。

8. 应用：税收的代价

税收是我们为文明社会所付出的代价。
没有某种形式的税收，我们的社会无法存在。
我们期望政府提供某些服务，例如，道路，公园，警察和国防，这些公共服务需要税收收入。

市场通常是组织经济活动的一种好方法，但是，当政府对一种物品的买者或卖者征税时，社会就损失了市场效率的某些利益。
税收使市场参与者付出代价，不仅是因为税收把这些参与者的资源转移给了政府，还因为税收改变了激励，并扭曲了市场结果。

一种物品的税收减少了该物品买者与卖者的福利，而且，消费者和生产者剩余的减少通常超过了政府增加的收入。
总剩余————消费者剩余、生产者剩余和税收收入之和————的减少被称为税收的无谓损失。

税收有无谓损失是因为它引起买者少消费和卖者少生产，
而且，这种行为变动使市场规模缩小到使总剩余最大化的水平之下。
由于供给和需求弹性衡量市场参与者对市场状况变动的反应程度，所以，弹性越大意味着无谓损失越大。

税收增加越多，它对激励的扭曲越大，而且, 无谓损失增加也越多。
税收收入起初随着税收规模扩大而增加。但是，最终由于高税收减少了市场规模，也就减少了税收收入。

9. 应用：国际贸易

通过比较没有国际贸易时的国内价格和世界价格，可以确定自由贸易的影响。
国内价格低表明，该国在生产这种物品上有比较优势，而且，该国将成为出口者。
国内价格高表明，世界其他国家在生产这种物品上有比较优势，而且，该国将成为进口者。

当一国允许贸易并成为一种物品的出口者时，该物品的生产者状况变好，而该物品的消费者状况变坏。
当一国允许贸易并成为一种物品的进口者时，消费者状况变好，而生产者的状况变坏。
在这两种情况下，贸易的好处大于损失。

关税——进口的税——使市场接近于没有贸易时存在的均衡，因此，减少了贸易的好处。
虽然国内生产者状况变好，而且政府增加了收入，但消费者的损失大于这些好处。

有各种限制贸易论：保护工作岗位，保卫国家安全，有助于幼稚产业，防止不公平竞争，以及对外国的贸易限制作出反应。
尽管这些观点在某些情况下有某些优点，但经济学家相信,，自由贸易通常是一种更好的政策。

10. 外部性

看不见的手是有力的，但不是万能的。市场均衡使生产者和消费者剩余之和最大化。
当市场上买者和卖者是仅有的利益各方时，从整个社会的角度看，这种结果是有效率的。
但是，当存在污染这种外在效应时，评价市场结果还要考虑第三方的福利。
在这种情况下, 市场中看不见的手也许不能有效地配置资源。

当买者和卖者之间的交易直接影响第三方时，这种影响称为外部性。
像污染这样的负外部性引起市场的社会最适量小于均衡量。
像技术溢出效应这样正外部性引起社会最适量大于均衡量。

受外部性影响人有时可以用私人方式解决问题。
例如，当一个企业为另一个企业提供了外部性时，两个企业可以通过合并把外部性内在化。
此外，利益各方也可通过签订合约来解决问题。
根据科斯定理，如果人们没有成本地谈判，那么，他们总可以达成一个资源有效配置的协议。
但是，在许多情况下，在许多利益各方中达成协议是困难的，因此，科斯定理并不适用。

当私人各方不能适当地解决污染这类外在效应时，政府往往就出现了。
有时政府通过管制行为阻止社会无效率的活动。

11. 公共物品和共有资源

存在一些市场不能充分提供的物品。
市场没有确保我们呼吸的空气是清洁的,也没有确保我们的国家不受外国**。
相反，社会依靠政府来保护环境并提供国防。

某些有价值的东西并没有在法律上有权控制它的所有者。
例如，虽然没有人怀疑清洁的空气或国防这种物品是有价值的，但没有一个人有权给它定一个价格，并从它的使用中得到利润。

当没有产权引起市场失灵时，政府可以潜在地解决这个问题。
有时，例如在出售污染许可证的情况下，解决的方法是政府帮助确定产权，从而重新焕发市场力量。
如果能很好地计划并实施政策，就可以使资源配置更有效率，并从而增进经济福利。

物品的差别在于它们是否具有排他性和是否具有竞争性。
如果排除某个人使用某种物品是可能的，这种物品就具有排他性。
如果一个人对某种物品的享用排除了其他人享用同一物品，这种物品就具有竞争性。
市场运行最适于既有排他性又有竞争性的私人物品。
市场运行不适用于其他类型的物品。

公共物品既无竞争性又无排他性。
公共物品的例子包括烟火表演，国防和基础知识的创造。
由于不能对使用公共物品的人收费，所以在私人提供这种物品时，就存在搭便车的激励。
因此，政府提供公共物品，以成本-收益分析为基础作出供给量的决策。

共有资源有竞争性但无排他性。
例子包括共有的草地，清洁的空气和拥挤的道路。
由于不能向使用共有资源的人收费，他们往往会过度地使用共有资源。
因此，政府努力限制共有资源的使用。

12. 税制的设计

几乎每一个人都同意，平等和效率是税制的两个最重要目标。但这两个目标往往是冲突的。
许多人主张改变税法以提高效率减少平等，或者提高平等而降低效率。
人们对税收政策的分歧往往是由于他们对这两个目标的侧重不同。

只靠经济学家并不能确定平衡效率与平等目标的最好方法。这个问题涉及到政治哲学以及经济学。
但经济学家在关于税收政策的政治争论中起着重要作用。
他们可以说明社会所面临的交替关系，并帮助我们避免那些牺牲了效率而从平等来看也没有任何好处的政策。

税制的效率是指它给纳税人带来的成本。
除了资源从纳税人向政府的转移，税收还有两种成本。
第一是税收改变了激励和行为引起的资源配置扭曲。
第二是遵守税法的管理负担。

13. 生产成本

企业的目标是利润最大化，利润等于总收益减总成本。

当我们分析企业的行为时，重要的是要包括生产的所有机会成本。
一些机会成本是显性的，例如，企业支付给工人的工资。
另一些机会成本是隐性的，另一些机会成本是隐性的，例如，企业所有者在企业工作而不去找其他工作所放弃的工资。

企业总成本可以分为固定成本和可变成本。
固定成本是在企业改变生产量时不变的成本，可变成本是在企业改变生产量时改变的成本。

两种相关的成本衡量都是从企业的总成本派生出来的。
平均总成本是总成本除以产量，边际成本是如果产量增一单位总成本应该增加的量。

在分析企业行为时，画出平均总成本和边际成本的图形往往是有用的。
对一个典型企业来说，边际成本随着产量增加而增加。
平均成本随着产量增加先减少，然后随着产量进一步增加而增加。
边际成本曲线总是与平均总成本曲线相交于平均总成本曲线的最低点。

14. 竞争市场上的企业

由于竞争企业是价格接受者，所以，它的收益与产量是同比例的。
物品的价格等于企业的平均收益和边际收益。

为了利润最大化，企业选择使边际收益等于边际成本的产量。
由于竞争企业的边际收益等于市场价格，所以，企业选择使价格等于边际成本的产量。
因此，企业的边际成本曲线是它的供给曲线。

在短期中，当企业不能收回其固定成本时，如果物品价格小于平均可变成本，企业将选择停止营业。
在长期中，如果价格小于平均总成本，当企业不能收回其固定和可变成本时，企业将选择退出。

在有自由进入与退出的市场上，长期中利润为零。
在长期均衡时，所有企业在有效规模时生产，价格等于最低平均总成本，而且，企业数量的调整满足在这种价格时的需求量。

需求变动在不同时间范围之内有不同影响。
在短期中，需求增加引起价格上升，并使利润增加，而需求减少降低了价格，并引起亏损。
但是，如果企业可以自由进入和退出市场，那么，在长期中企业数量调整使市场回到零利润均衡。

15. 垄断

由于垄断者生产的小于社会有效率的量，并收取高于边际成本的价格，所以，它们引起了无谓损失。
可以通过谨慎的公共政策，或者在某些情况下通过垄断者的价格歧视来减少这种无效率。

垄断是在其市场上作为惟一卖者的企业。
当一个企业拥有一种关键资源，当政府给一个企业排他性地生产一种物品的权力，
或者当一个企业可以比许多企业以较少成本供给整个市场时，垄断就产生了。

由于垄断者是其市场上惟一的生产者，所以它面临它的产品向右下方倾斜的需求曲线。
当垄断者增加一单位产量时，就引起它的产品价格下降，这就减少厂所生产的所有产量赚到的收益量。
因此，垄断的边际收益总是低于其物品的价格。

正如竞争企业一样，垄断企业也通过生产边际收益等于边际成本的产量来实现利润最大化。
这时垄断者根据需求量选择价格。与竞争企业不同，垄断企业的价格高于它的边际收益因此它的价格高于边际成本。
因此它的价格高于边际成本。

垄断者利润最大化的产量水平低于使消费者与生产者剩余之和最大化的产量。
这就是说，当垄断者收取高于边际成本的价格时，一些对物品评价大于其生产成本的消费者不购买这种物品。
因此，垄断引起的无谓损失类似于税收引起的无谓损失。

16. 寡头

寡头通过形成一个卡特尔并像垄断者一样行事来使自己的总利润最大化。
但如果寡头独立地作出生产决策，结果是产量大于垄断的结果，价格低于垄断结果。
在寡头市场上企业数量越多，产量和价格越接近于竞争下存在的水平。

囚犯两难处境表明，利己使人们即使在合作符合他们共同利益时也无法维持合作。
囚犯两难处境的逻辑适用于许多情况，包括军备竞赛做广告，共有资源问题和寡头。

决策者用反托拉斯法来防止寡头从事减少竞争的行为。
这些法律的适用性是有争论的，因为一些看来可能减少竞争的行为，实际上可能有合理的经营目的。

17. 垄断竞争

由于垄断竞争企业生产有差别的产品，所以，每个企业都要靠做广告来打出自己的品牌吸引顾客。
在某种程度上，广告控制了消费者的嗜好，促成了无理性的品牌忠诚，并抑制了竞争。
在更大程度上，广告提供了信息，建立了可靠质量的品牌，并促进了竞争。

垄断竞争市场有三个特点：许多企业，有差别的产品，以及自由进入。
垄断竞争中固有的产品差别引起使用广告与品牌。
广告与品牌的批评者认为，企业用这些方法利用了消费者的无理性，并减少了竞争。
广告与品牌的支持者认为，企业用这些方法向消费者提供信息，并使价格和产品质量的竞争更为激烈。

18. 生产要素市场

根据新古典理论，每种生产要素所得到的报酬量取决于那种要素的供给与需求。
需求又取决于某种要素的边际生产率。在均衡时，每种生产要素赚到了它对生产物品与劳务的边际贡献的价值。

经济的收入是在生产要素市场上分配的
三种最重要的生产要素是：劳动，土地和资本。

19. 收入与歧视

在竞争市场上，工人赚到的工资等于他们对物品与劳务生产边际贡献的价值。
但是，有许多事情影响边际产量值。企业对那些较有才能，较勤奋，较有经验而受教育较多的工人支付得更多一些，因为这些工人生产率较高。
企业对那些受到顾客歧视的工人支付少一些，因为这些工人对收益的贡献少。

人力资本多的工人得到的工资高于人力资本少的工人。
累积的人力资本的收益是高的，而且在过去10年来一直在增加。

虽然教育年限，经验和工作特性都像理论预期的那样影响收入，但仍有许多收入差别不能用经济学家可以衡量的事情来解释。
收入中无法解释的变动主要归因于天赋能力，努力和机遇。

一些经济学家提出，受教育更多的人得到更高工资并不是因为教育提高了生产率，而是因为有更高天赋能力的工人把教育作为一种向雇主表示他们高能力的信号。
如果这种信号理论正确的话，那么，提高所有工人的教育程度就不会提高整个工资水平。

20. 收入分配

人们面临交替关系，当考虑经济不平等时记住这个原理是重要的。
惩罚成功和奖励失败的政策减少了对成功者的激励。因此，政策制定者面临平等和效率之间的交替关系。
更加平等地分割蛋糕，蛋糕就会变得越小。这是几乎每一个人都同意的有关收入分配的一个结论。

有许多不同的政策旨在帮助穷人——最低工资法，福利，负所得税，以及实物转移支付。
虽然这每一种政策都帮助了一些家庭脱贫虽然这，但它们也有意想不到的副作用。
由于经济资助随收入增加而减少，所以，穷人往往面临很高的实际边际税率。
这种高实际税率不鼓励贫困家庭依靠自己的力量脱贫。

21. 消费者选择理论

消费者选择理论描述了人们如何作出决策。
消费者选择理论并不想对人们如何作出决策提供一种忠实的描述，它是一个模型。

消费者预算约束线表示在其收入与物品价格既定时他可以购买的不同物品的可能组合。
预算约束线的斜率等于这些物品的相对价格。

消费者的无差异曲线代表他的偏好。无差异曲线表示能使消费者同样幸福的各种物品组合。
对较高无差异曲线上各点的偏好大于对较低无差异曲线上各点。
任何一点上无差异曲线的斜率是消费者的边际替代率——消费者愿意用一种物品交换另一种物品的比率。
消费者通过选择既在预算约束线上又在最高无差异曲线上的一点而实现最优。

当一种物品价格下降时，对消费者选择的影响可以分解为收入效应和替代效应。
收入效应是由于低价格使消费者状况变好而引起的消费变动。
替代效应是由于价格变动鼓励更多消费变得便宜的物品而引起的消费变动。
收入效应反映在无差异曲线由低向高的移动上，而替代效应表现为沿着一条无差异曲线向有不同斜率的点的移动上。

互联网思维就是口碑为王，因为今天用户主要以口碑来选择产品。
谷歌就深谙这个道理：“一切以用户为中心，其他一切纷至沓来。”

信息传播发生了以下三个重要的转变：
（1）信息从不对称转变为对称
（2）信息传播速度暴增，影响范围空前扩大
（3）互联网信息是去中心化的传播，通过社会化媒体，每个普通人都是信息节点，都有可能成为意见领袖

在新的移动互联网时代，我们要坚定以口碑做传播，并要善用社会化媒体。

口碑的铁三角：
（1）发动机：产品
（2）加速器：社会化媒体
（3）关系链：用户关系

社交网络的建立是基于人与人之间的信任关系，信息的流动是信任的传递。
企业建立的用户关系信任度越高，口碑传播越广。

和用户做朋友这个观念转变，是因为今天不是单纯卖产品的时代，而是卖参与感。

---

互联网思维核心是口碑为王，口碑的本质是用户思维，就是让用户有参与感。

参与感三三法则：
三个战略：做爆品，做粉丝，做自媒体
三个战术：开放参与节点，设计互动方式，扩散口碑事件

---

用户模式大于一切工程模式。
优先处理浮出水面的需求。
用户体验的核心是为谁设计。

“为谁设计”，很多人都可能忽略，但这是用户体验设计的原点，
在它确定之后，设计坐标系统才能明确下来；
而如果没有它，就无法正确定位产品好用、好看的努力方向，产品设计就会很苍白，
因为不同用户群体的需求可谓千差万别。

活动产品化，产品活动化。
把活动当做产品来设计和运营，持续优化。
做产品要运用运营思维，把一些活动的环节植入设计成为产品的功能。

极致就是先把自己逼疯。
产品第二，团队第一。

创业成功最重要的因素是什么？
最重要的是团队，其次才是产品，有好的团队才有可能做出好产品。

最专业，就是行业经验和专业能力，尤其是招聘工程师，一个靠谱的工程师不是顶10个，可能是100个；
最合适，则是他要有创业心态，对所做的事情要极度喜欢。
员工有创业心态就会自我燃烧，就会有更高主动性，这样就不需要设定一堆的管理制度或KPI考核什么的。

让用户来激励团队。
做出有爱的产品，用户就会回报予爱，用户的爱会持续激励团队。

---

不是劈开脑海，而是嵌入大脑。

我是谁？
这是做品牌要解决的第一个问题，关乎定位。
经典定位理论是指开创并主导一个新品类，如何在潜在用户的心智中与众不同。

先做忠诚度再做知名度。

对于一个品牌，知名度意味着能让用户听见，美誉度以为这走到用户身边，而忠诚度则代表已在用户心里。
所谓的粉丝文化，就是看你的品牌有多少忠诚的用户。

粉丝效应让猪也能飞。
粉丝效应是无法设计的，可以理解它是互联网**家凯文·凯利“失控理论”的一种表现。
粉丝效应不可设计，但可因势利导，应给予他们更多可参与的互动方式。

每个用户都是明星。
实际上，这也是小米和很多传统品牌最大的不同：
我们和用户一起玩，不管是线上还是线下，无论是什么时候，
我们都在想，怎样让用户参与进来，让他们和小米官方团队一起，成为产品改进、品牌传播的“大明星”。

做品牌不要输在起跑线上。
（1）中文名要易记易传播
（2）配套的定级域名可获得
（3）商标可注册
（4）便于国际化推广
（5）生活中早已熟悉，本身带有色彩感和富于情绪

创业的产品能够成功的前提是先挠自己的痒处。

办一场剧场式的发布会。
如今，我们追求做有“沉浸感”的剧场式发布会。

发布会上新产品是唯一的明星，产品有料才能获得大声量的传播。
有的发布会搞一堆不是产品的点，比如请某明星登场，搞一些高大上的模特、抽奖，都是错的。

用互联网思维做电视广告：
（1）要全网互动，把电视广告本身当产品做二次传播
（2）偶尔到电视上做广告，信息越简单越好，尽量做品牌而不是功能广告
（3）电视资源段选择上，选最大平台集中爆破

抢首发，上头条。
做产品，噱头成不了卖点；做市场，段子也成不了头条。

产品和营销的关系，是1和0的关系。
你的包装，你的海报，你的营销，你的推广，都是跟在产品这个1后面的0。
如果没有好产品，一切都会变得没有意义。而如果产品给力，哪怕营销做得差一点，也不会太难看。

互联网公关要练“不生气”功。

互联网是注意力经济，一个品牌和事件的关注度，一定要有碰撞、有矛盾、有张力才起得来。
所以，传播途中有不同声音不但正常，还可能是好事，在其中因势利导、抓主流就可以了。
一件传播事件中，如果有七成是正面声音就很好了，剩下三成负面的其实也无所谓。

有些品牌公关事件，偶尔也要讲究娱乐精神。
娱乐不仅可以表达态度，还能扭转战局。

不是做广告，而是做自媒体。

新营销的第一步，让自己的公司成为自媒体。
传统思路是做好媒介渠道，现在是做好内容，以前是找媒介，现在是媒介来找你。
这其中，内容很关键。

企业要花精力让自己成为能持续提供优质内容的自媒体，
同时，也应该发动用户来产生内容。

学不可以已。

学习是不可以停止的。

---

故木受绳则直，金就砺则利，君子博学而日参省乎己，则知明而行无过矣。

木材用墨线量过，再经辅具加工就能取直，
刀剑等金属制品在磨刀石上磨过就能变得锋利，
君子广泛地学习，而且每天检查反省自己，那么他就会聪明机智，而行为就不会有过错了。

---

干、越、夷、貉之子，生而同声，长而异俗，教使之然也

干越夷貉之人，刚生下来啼哭的声音是一样的，而长大后风俗习性却不相同，这是教育使之如此。

---

吾尝终日而思矣，不如须臾之所学也。
吾尝跂而望矣，不如登高之博见也。

我曾经整天思索，却不如片刻学到的知识多；
我曾经踮起脚远望，却不如登到高处看得广阔。

---

登高而招，臂非加长也，而见者远；
顺风而呼，声非加疾也，而闻者彰。
假舆马者，非利足也，而致千里；
假舟楫者，非能水也，而绝江河。
君子生非异也，善假于物也。

登到高处招手，胳膊没有比原来加长，可是别人在远处也看见；
顺着风呼叫，声音没有比原来加大，可是听的人听得很清楚。
借助车马的人，并不是脚走得快，却可以行千里，
借助舟船的人，并不是能游水，却可以横渡江河。
君子的本性跟一般人没什么不同，只是善于借助外物罢了。

---

故君子居必择乡，游必就士，所以防邪辟而近中正也。

君子居住要选择好的环境，交友要选择有道德的人，才能够防微杜渐保其中庸正直。

---

物类之起，必有所始。
荣辱之来，必象其德。

事情的发生都是有起因的，荣辱的降临也与德行相应。

---

积善成德，而神明自得，圣心备焉。

积累善行养成高尚的品德，自然会心智澄明，也就具有了圣人的精神境界。

---

故不积跬步，无以至千里；不积小流，无以成江海。
骐骥一跃，不能十步；驽马十驾，功在不舍。
锲而舍之，朽木不折；锲而不舍，金石可镂。

不积累一步半步的行程，就没有办法达到千里之远；不积累细小的流水，就没有办法汇成江河大海。
骏马一跨跃，也不足十步远；劣马拉车走十天，也能走得很远，它的成功就在于不停地走。
如果刻几下就停下来了，那么腐烂的木头也刻不断。如果不停地刻下去，那么金石也能雕刻成功。

---

蚓无爪牙之利，筋骨之强，上食埃土，下饮黄泉，用心一也。
蟹六跪而二螯，非蛇鳝之穴无可寄托者，用心躁也。

蚯蚓没有锐利的爪子和牙齿，强健的筋骨，却能向上吃到泥土，向下可以喝到泉水，这是由于它用心专一啊。
螃蟹有六条腿，两个蟹钳，但是如果没有蛇、鳝的洞穴它就无处存身，这是因为它用心浮躁啊。

---

是故无冥冥之志者，无昭昭之明；无惛惛之事者，无赫赫之功。

没有刻苦钻研的心志，学习上就不会有显著成绩；没有埋头苦干的实践，事业上就不会有巨大成就。

---

其仪一兮，心如结兮。

行为专一不偏邪，意志才会如磐石坚。

---

昔者瓠巴鼓瑟，而流鱼出听；伯牙鼓琴，而六马仰秣。故声无小而不闻，行无隐而不形。
玉在山而草润，渊生珠而崖不枯。为善不积邪？安有不闻者乎？

古有瓠巴弹瑟，水中鱼儿也浮出水面倾听，伯牙弹琴，拉车的马会停食仰头而听。
所以声音不会因为微弱而不被听见，行为不会因为隐秘而不被发现。
宝玉埋在深山，草木就会很润泽，珍珠掉进深渊，崖岸就不会干枯。
行善可以积累，哪有积善成德而不被广为传诵的呢？

---

故学数有终，若其义则不可须臾舍也。
为之，人也；舍之，禽兽也。

所以学习的教程虽有尽头，但进取之愿望却不可以有片刻的懈怠。
毕生好学才成其为人，反之又与禽兽何异？

---

君子之学也，入乎耳，着乎心，布乎四体，形乎动静。
端而言，蝡而动，一可以为法则。
小人之学也，入乎耳，出乎口；口耳之间，则四寸耳，曷足以美七尺之躯哉！

君子学习，是听在耳里，记在心里，表现在威仪的举止和符合礼仪的行动上。
一举一动，哪怕是极细微的言行，都可以垂范于人。
小人学习是从耳听从嘴出，相距不过四寸而已，怎么能够完美他的七尺之躯呢？

---

古之学者为己，今之学者为人。
君子之学也，以美其身；小人之学也，以为禽犊。

古人学习是自身道德修养的需求，现在的人学习则只是为了炫耀于人。
君子学习是为了完善自我，小人学习是为了卖弄和哗众取宠，将学问当作家禽、小牛之类的礼物去讨人好评。

---

故不问而告谓之傲，问一而告二谓之囋。
傲、非也，囋、非也；君子如向矣。

没人求教你而去教导别人叫做浮躁；问一答二的叫罗嗦；
浮躁罗嗦都是不对的，君子答问应象空谷回音一般，不多不少、恰到好处。

---

学莫便乎近其人。

学习没有比亲近良师更便捷的了。

---

故礼恭，而后可与言道之方；辞顺，而后可与言道之理；色从，而后可与言道之致。

对于恭敬有礼的人，才可与之谈道的宗旨；对于言辞和顺的人，才可与之谈道的内容；态度诚恳的，才可与之论及道的精深义蕴。

---

跟不可与之交谈的交谈，那叫做浮躁；跟可与交谈的不谈那叫怠慢；不看对方回应而随便谈话的叫盲目。
因此，君子不可浮躁，也不可怠慢，更不可盲目，要谨慎地对待每位前来求教的人。

故未可与言而言，谓之傲；可与言而不言，谓之隐；不观气色而言，谓瞽。
故君子不傲、不隐、不瞽，谨顺其身。

---

百发失一，不足谓善射；千里蹞步不至，不足谓善御；伦类不通，仁义不一，不足谓善学。
学也者，固学一之也。
一出焉，一入焉，涂巷之人也。

射出的百支箭中有一支不中靶，就不能算是善射；
驾驭车马行千里的路程，只差半步而没能走完，这也不能算是善驾；
对伦理规范不能融会贯通、对仁义之道不能坚守如一，当然也不能算是善学。
学习本是件很需要专心至致的事情，学一阵又停一阵那是市井中的普通人。

---

全之尽之，然后学者也。

能够全面彻底地把握所学的知识，才算得上是个学者。

---

君子知夫不全不粹之不足以为美也，故诵数以贯之，思索以通之，为其人以处之，除其害者以持养之。

君子知道学得不全不精就不算是完美，所以诵读群书以求融会贯通，用思考和探索去理解，效仿良师益友来实践，去掉自己错误的习惯性情来保持养护。

---

是故权利不能倾也，群众不能移也，天下不能荡也。
生乎由是，死乎由是，夫是之谓德操。
德操然后能定，能定然后能应。

如果做到了这般地步，那么，在权利私欲面前就不会有邪念，人多势众也不会屈服的，天下万物都不能动摇信念。
活着是如此，到死也不变。这就叫做有德行、有操守。
有德行和操守，才能做到坚定不移，有坚定不移然后才有随机应对。

---

天见其明，地见其光，君子贵其全也。

天显现出它的光明，大地显现出它的广阔，君子的可贵则在于他德行的完美无缺。

选择太多与心智有限，给组织社会带来了空前的紧张与危机，因为组织存在的目的，不在于组织本身，而在于组织之外的社会成果。
当组织的成果因未纳入顾客选择从而变得没有意义甚至消失时，组织也就失去了存在的理由与动力。

我们已经进入组织的社会，所有组织的共通点（这或许多多少少是第一次有共通处）就是组织的成果只限于外部……
可是当你去看现今所有关于管理学的著作和**（包括我所写的一切）就会发现，其实我们只看得到内部，不管各位举出哪一本早期的作品，例如我写的《管理的实践》，或是哈佛商学院教授迈克尔·波特讨论战略的著作，都是一样。
这些著作看起来是从外部观察，但实际上讨论的都是组织内部的事情。
因此，如果你想要了解管理是怎么回事，管理在做些什么，就必须从外在的成果入手……

特劳特曾说：“《韦氏词典》对战略的定义是针对敌人（竞争对手）确立最具优势的位置（position）。这正好是定位要做的工作。”
在顾客心智中针对竞争对手确定最具优势的位置，从而使品牌胜出竞争赢得优先选择，这就是企业需全力以赴抵达的成果，也是企业赖以存在的唯一理由。

定位四步法
第一步，分析整个外部环境，确定“我们的竞争对手是谁，竞争对手的价值是什么
第二步，避开竞争对手在顾客心智中的强势，或是利用其强势中蕴含的弱点，确立品牌的优势位置——定位。
第三步，为这一定位寻求一个可靠的证明——信任状。
第四步，将这一定位整合进企业内部运营的方方面面，特别是传播上要有足够多的资源，以将这一定位植入顾客的心智。

第一次生产力革命，是通过泰勒的《科学管理原理》，大幅提升了体力工作者的生产力。
第二次生产力革命，是通过德鲁克开创的管理学，大幅提升了组织的生产力。
第三次生产力革命，是通过特劳特发现的“定位”（核心著作是《定位》和《商战》，读者应该先从这两本著作开始学习定位），大幅提升了品牌的生产力。

定位也不仅仅是“最具革命性的营销观念”（菲利普·科特勒语），而且是战略的核心，“战略就是创建一个有利的定位”（迈克尔·波特语）。

无论个人还是组织都要学会运用定位这一新工具“由外而内”地为自己建立品牌（个人如何创建品牌详见特劳特商战经典之《人生定位：特劳特教你营销自己》），从而在竞争中赢得优先选择。

组织最有价值的资源固然不再是土地与资本资源，甚至也不是人力资源、知识资源了，这些资源没有消失，但其决定性的地位都要让位于品牌所代表的心智资源。

衡量企业经营决定性绩效的方式也从传统的财务赢利与否，转向为占有定位（心智资源）与否。
这也解释了为何互联网企业即使不赢利也能不断获得大笔投资，因为心智资源（定位）本身就是成果。
历史上，新生产工具的诞生，同时会导致新生产方式的产生，这种直取定位（心智资源）而不顾赢利的生产方式，是由新的生产工具带来的。

不仅是新创企业，即便现有组织的同一个品牌，在其他任何条件不变的情况下，通过定位的调整，生产力的差距也是惊人的。

当定位明确后，几乎可以立刻识别出企业投入中哪些20%的运营产生了80%的绩效，从而通过删除大量不产生绩效的运营并加强有效的运营而大幅提升生产力。

事实上，已不存在要不要定位的问题，而是要么你是在正确、精准地定位，要么你是在错误地定位，从而根据错误的定位配置企业资源。
这一点与管理学刚兴起时，管理者并不知道自己的工作就是管理非常类似。

---

更努力地工作、更坚定地相信自己、更积极地思维，单凭这些，都不能让你攀上成功的阶梯。
实际上，成功根本不是某种你能自发产生的结果。
成功的关键是你能从别人那里获得什么。

本书的主题就是如何借助外力取得成功。
实际上，你必须走出去，去推销自己。

失败者是那些只关注自己、认为成功的全部要素都在自己身上的人。
胜利者通过善用他人而获取自己的成功。想要成功，你必须知道该看哪里、该找什么。

---

在这个崇尚**、平等的社会，人们早已淡忘了成功之路曾经的经典诠释：重要的不是你知道什么事，而是你认识什么人。

在制定目标时，假设单凭一己之力就能实现的情况非常罕见。任何人也无法单凭自己的努力就登上天堂，他还需要上帝的小小帮助。

毕加索（Pablo Picasso）说：“一旦你真的弄清楚了什么是自己渴望的，那你这辈子充其量也就只能获得这么多了。”

在制定目标的时候，我们通常忘记其他人也有自己的目标。如果人人都希望成为山中之王，那这座山不就太挤了吗。也许我们可以换个目标，比如山谷之王，怎么样？
不如换个目标试试。
让我们对成功保持开放的心态，不要只为自己锁定一个目标。

罗斯·佩罗（Ross Perot）说过：“人生就像一张蜘蛛网，各条网线以奇妙的角度交叉。能否成功并不取决于你的计划，特别是商学院教的那种所谓的5年战略计划，制订得有多完美。面对各种意想不到的机遇，你会做出什么样的反应，这才更有决定意义。”

多数人一旦达到事业的巅峰，就会掩饰自己成功的轨迹。
他们从不认为成功乃运气使然，也不把成功归结于天时地利。
相反，他们认为努力工作、设定目标、相信自己才是成功之王道。

他们不想让你知道他们是如何成功的，保持神秘会让他们觉得高人一等、与众不同。

---

你是否聪明机智、进取心强、风度翩翩，这都无关紧要。不要只盯着自己，你要看看外面，找到一匹好马，你的人生将会精彩纷呈。

要想获得人生的巨大成功，你必须找到一匹可以驾驭的好马。

有些人永远长不大，他们力争获得外在的成功，总想以此来证明自己的聪明与能干。

利用外在的成功来安抚自己内心的不安全感，这是人类常有的一种心态。
这种心态也解释了为什么大多数企业里都有一群工作狂。
他们对其他人的依靠越少，就能越能证明自己是真正成功的人。

这颇具讽刺意味。人们在本应借助外力的时候，却要自己做。
但是只靠自己是不可能获得成功的，是其他人使得你成功。
因此，你必须重点关注他人，而不是自己。

要正确看待各种事情。
其实，如果你能把成功看做别人为你所做的事，而不是你为自己所做的事，你就不太可能陷入追逐成功的不安之中。
没有人能够让你成功，但是其他人的所作所为能够助你成功。

教皇不是他自己推选出来的，董事会主席也不是他自己任命的。

---

商务和生活一样也是一种社会活动，合作与竞争并存。
政府工作也好，社会工作也罢，不管你从事的是哪个行业，也都大抵如此。

以销售为例，只有你一个人是不可能做成买卖的，必须得有另一个人购买你所推销的东西。

请你谨记，赛马场上获胜次数最多的骑师不一定体重最轻、头脑最好或者体能最强。
最好的骑师未必能赢得比赛，而能赢得比赛的骑师通常都拥有最好的赛马。

努力型赛马

如果你的个人营销策略是完全依靠自身的才干和能力，对外部环境视而不见，那么你的坐骑就是你自己。

这是一个棘手的问题。
通常来说，你会落在后面，然后你便开始鞭打自己。
所谓鞭打自己，换一种说法就是“努力工作”。
如果其他人每天工作7个小时，你会工作8个小时。
如果其他人每天工作8个小时，你就会干上9小时（周末还要加点班）。

你了解这种模式。
大多数人都非常乐意多花点时间工作，因为他们相信只有这样才能超越他人。

骑着努力型赛马的人通常在一开始的时候就每周额外工作一两个小时，然后慢慢加量。
如果加班没有带来晋升，也没有赢得表彰，他们就会拿出鞭子，更加用力地抽打自己。
过不了多久，他们就会觉得疲惫不堪了。

那些试图通过更加努力地工作扭转败局的人尤其招人怜悯。

但是，不都说成功人士往往会努力工作吗？是的，他们确实如此。不过，这并不等于说努力工作的人往往就能获得成功。

如果你工作的时间太长，往往会犯更多的错误。
结果，为了纠正错误，又不得不赔上更多的时间。
仅仅因为你在一个项目上花的时间比较多，并不一定表示你完成得更加出色。
在建筑中，少常常就是多，在工作中也是如此。

智商型赛马

高层管理者的智商水平属于中等。
正如一位大学校长对教职工所说的：“要善待你的A等生，将来他们会回来，做你的同事，但更要善待你的那些B等生和C等生，将来他们会回来，给我们新添一个礼堂和一栋科研大楼。”

智力与成功并无太大的关联，有一个原因就是：越聪明的人越会依靠自己。
毕竟，他们无所不知，他们依靠自己获得成功。但那是一匹高风险赛马。

不太聪明的人知道自己不够聪明。
因此，他们更有可能寻找他人，帮助自己爬上梯子。

教育型赛马

要记住，教育型赛马的作用是让你进入比赛。仅凭学历不大可能让你的马跑得更快。

企业型赛马

不管你多么聪慧敏锐，把注压在一个输家身上是永远得不到回报的。
泰坦尼克上最优秀的官员到最后也要与最没用的人待在同一条救生艇里，前提是他要足够幸运，没有掉进水里。

怎样才能识别一家尚在襁褓中的大型企业呢？
你不要识别，你要寻找另一个看似有前途的人、产品或者创意。

---

才华型赛马

你需要其他人的认可，他们能够让你获得成功。

创造性人才同样必须学会如何聆听观众的心声。
观众希望他们怎样，他们就得去适应，而不是让观众来适应你。

不要抵御同一类角色，成功的不二法则就是总演同一类角色。

如果你想让人们觉得你有才华，你就得看上去像那么回事。

才华型赛马要获得成功，几乎比其他任何类型的赛马都更需要外界的认可。
有时，那种外界的认可永远都不会来临。

如果你的才华未能很快获得外界的认可，你不要以头撞墙（也不要磨平你的棱角）。
实际上，你应该能够料想到这个结果。
你的问题的实质是外界的认可，无论你是作家、画家、演员、歌手、舞者或摄影师等诸如此类的角色，你都要把大部分时间用来寻找能够证明你的创造力的外部专家。

请始终谨记，才华的世界与这个大千世界本身并无二致，在这里，让你获得成功的正是其他人。
是影评家让电影制片人成功的。

产品的外包装与产品一样重要，有时还比产品本身更重要。

爱好型赛马

有那么多成功的职业都是由业余爱好或兴趣逐渐发展而来的，这颇令人惊讶。

如果你喜欢做什么事情，往往就会做得很多。而你做得越多，就越得心应手，你获得的自信也越多。

地利型赛马

成功就在你身边。
不要浪费时间寻找什么最合适的地方、最合适的环境，你是找不到的。
即便你找到了，可能也认不出它。

生活中的成功从接受开始，接受那些无法改变或者难以改变的事物。然后，开始改变一件完全在你掌控之中的东西，那就是你自己。

宣传型赛马

在公司特别是在大公司里，可见性比能力更为有效，这是一个不争的事实。
如果你兼而有之当然很好，可是如果你只能二选一，那就选可见性吧。

90%的人都不会独立思考，所以你完全可以骑着宣传型赛马一路登顶。
90%的人只相信他们从报纸上看到的、广播里听到的、电视上看到的或者是别人告诉他们的，而这些“别人”的想法又是从哪里来的呢？
当然也是从报纸上看到的、广播里听到的、电视上看到的。

大量的宣传也没有效果。
你应该力争写出一个极具感染力的正面故事，可以让你翻来覆去地使用。

一个主意，就是你应该寻找并依附在你名字上的东西。
如果你打算骑上宣传型赛马，首先要给自己一个称号或主意。

你要个什么样的称号呢？宣传可不是一匹容易驾驭的赛马。
你必须下定决心丢弃各种资料，这样才能将焦点集中在一个主意或概念上。

要想很好地驾驭宣传型赛马，你必须学会如何“应对媒体”。
你不能太好斗，也不能太腼腆。
一般情况下，不要给他们打电话，让他们打电话给你。

正是那些标新立异、令人震惊或者颇有争议的观点才会引起媒体的关注，没人想写关于母亲或苹果派的报道。

---

产品型赛马

认可他人的天赋几乎总是让人成功的关键。
大部分人碰到一个好的产品理念时都没能识别。

拿麦当劳兄弟与雷·克罗克进行比较是很有启迪意义的。
麦当劳兄弟发明了产品理念，而雷·克罗克认识到这一理念的潜力。谁赚了大钱？
是发明者，还是识别者？

那就做一个识别者吧。从自身之外识别能让你发财的产品。

迄今发明的最成功的产品都没有给发明者带来足够的利益，但是却让识别者发了大财。

即便是发明本身也常常是一次意外的结果。

做个灵活的人。
有太多专心致志、目标明确的人本可以通过制作裤子来赚大钱的时候，他们却坚持做帐篷。
或者他们在可以通过瓶装水发财的时候，却坚持在经纪公司工作。

创意型赛马

我们都知道，创意可以比任何事情都能更快地让你一跃达到事业的巅峰。
但是有时候人们对创意期待得太多，他们希望心目中的那个创意非常出色，也希望其他人都认可它的伟大。

这样的创意根本就不存在。
如果你要等到某个创意被大家都接受的时候，那就太晚了，其他人可能已经取得了优先权。

任何显然入时的东西都已经在过时的路上。

驾驭创意型赛马，你必须愿意面对可笑的、有争议的创意，你也必须乐意逆潮流而行。

除非你勇于承担风险和大量的非议，否则你不可能成为第一个想出新创意的人。

专家常常是错的，尤其当他们武断地对那些可能对其专长带来不利影响的主题做出结论的时候。

好的创意具有宣传价值，而最具宣传价值的是那些震撼人心的创意。
广告公司知道震撼人心的广告能够创造好的宣传价值，而好的宣传价值可以造就成功的广告公司。

他人型赛马

成功的关键总是依靠他人。
即使你驾驭着一个可以让你走向巅峰的创意或者一个产品，还是得依靠他人识别该创意或者该产品的价值。

你个人不能完成销售，要靠他人来购买。
推销产品的方法也适用于推销自己。
首先，别人得认识到你的优秀品质，然后通过给你一份工作或者一次晋升来“购买”你。

人都喜欢聘请与自己相似的人。

达到事业的巅峰，你不必非要成为一个全能型的人。你可以做一个专家，发掘他人、利用他人的力量。

但是作为坐骑的人，不同于动物的赛马，他内心有自己的利益，他不会盲目地载着你去你想去的地方，他们会去他们想去的地方。

伙伴型赛马

伙伴型赛马是他人型赛马的一种变体，其区别之处在于伙伴是平等的人的组合。平等具有很多优点，真正的伙伴之间彼此信任，他们对彼此毫无偏见。

你不能对自己的想法做出正确的判断，你需要有可信之人评价你的想法，或者提出改变、修订的建议。
当然，反之亦然。

你的自负逐渐扼杀了你的客观性，你对别人越来越挑剔。
除了你自己的想法，你看不到别人想法的优点。
认为没有人可以像你做得那样好。
如果你的老板再明智些，就会看到你是多么有能力，也会采取措施提升你。
如果你真的这样想，你就真的与现实脱轨了。

99%的法则表明，你达到事业巅峰的概率只有1%。
当你的晋升意味着同事们永远不能脱离底层时，他们为什么要帮你一把呢？

伙伴能让你脚踏实地，伙伴能让你客观地把自我意识控制住。
你们可以合作完成你单独一人不能完成的大事。

配偶型赛马

正如一朵花需要有成长的花园才能绽放，如果才能想要绽放也需要机遇。

历史上有很多这样的故事，男人或者女人通过自己的配偶走向成功。
然而，这种成功的方法常被人认为不那么高尚。更多的人还是希望依靠自己的力量实现成功的目标。

“我想自己做”似乎是年轻一族的箴言（当你老一些时，你会意识到你可能错过了一个重要的机遇）。

家族型赛马

你是不能因为某件事跟儿子、女儿或者父母断绝关系的，这样的事实就让家族型赛马比配偶型赛马占据了优势。

---

企业型赛马

残酷的现实是，对于成功来说，能力是最不重要的因素。
企业并不是理性实体，不会为个人的最佳发展提供无尽的帮助。
企业是那些试图超过他们竞争对手的各类人的组合。

在很多方面，他们极像马拉松比赛。一听到枪响，成千上万的人冲出去，为了取得最佳位置，互相推撞。
刚开始的赛程，尽显人们的凶恶本质，直到比赛进行了一段时间，彼此拉开了距离，你才能得到一些跑步的空间。

到达通往企业顶层的道路有5条，无一例外都很艰难。

（1）做一只“早起的鸟儿”

（2）做一个政治家

大企业里的生活就是一碗意大利面，你不能太直率，你必须委婉、间接。
你必须学会怎样做一个政治家。

你不能依靠自己的努力到达企业的高层，你必须依靠提拔。

谁来提拔你？别人。
这就是你想要在大企业里出人头地就必须成为一个政治家的原因。
把工作做好只是第一步，你必须找到一种方法，让别人知道你能够把工作做得很好。
你的工作技能没有你的政治技能重要。

如果你在为一家《财富》500强企业工作，或者任何类型的一家大型机构，要问自己最重要的问题不是“我做得怎么样”，而是“我的保人是谁”。
没有保人，你将停滞不前。

你的工作做得多好并不重要。

许多企业都有严格保密的“高潜力”员工名单。
你在你们企业的快车道名单上吗？
尽最大可能证实这点，这样也能省去你多年的痛苦。
如果你不在快车道名单上，我们给你的建议就是继续阅读本书、继续跳槽。

你可以看到这种模式。
如果你想在大企业升迁，就必须做一个政治家。你必须广交朋友，而不是兴风作浪。
在企业这种环境里，说的比做的重要，尤其是当你把这些话在合适的时间说给合适的人听时。
无论如何，跟你的首席执行官谈论下你的配偶和可爱的孩子，谈谈你所属的宗教派别，讲讲在你家里聚会的男女童子军，聊聊你花时间和金钱支持的诸多慈善机构。

人们都喜欢和自己相似的人。

当为大企业工作时，你有两个选择：
①进入快车道名单；
②离开该企业。

做一个克隆人，找到一个保人，进入快车道名单，是一个政治家的三种最重要的属性。

骑上企业型赛马，你也必须要有多面性。
从外表看，你必须是团队的一员，而在内心深处，你必须是一个顽固的个人主义者，你必须掩饰你的竞争本能。

到达企业高层的人中，很大比例的人都避免发生冲突。

企业的规模越大，缺乏合作精神的员工越有可能在远没有到达高层之前就被清除出局。
你必须不断地展示你的忠诚，而不是你的才智。

这就是猫和狗的区别。
狗会摇着尾巴欢迎你回家，它会讨好你，对你的每次心血来潮的想法做出快速的反应。
相反，猫一般会忽略你，对你的愿望也无动于衷，猫有自己优先考虑的事情。

企业有很多为它们工作的猫和狗，狗是急切的、热情的、温顺的、笨手笨脚的团队成员。
而猫是安静的、有能力的、深思的、性情平和的个人主义者。
那么谁会得到提拔呢？当然是狗。

为了在企业世界里如鱼得水，你必须折中你的原则。

（3）做一个耀眼的人

如果你想取得进步，就必须找到一种方法把自己展现给高级管理层。这在大企业行得通，在大的政府机构也同样有效。

个人关系是你努力攀登企业阶梯的关键。

几乎所有成就卓越的人都得到过他人的提携。

最好的方法就是像那位IBM年轻的分部经理获得销售总经理的职位一样，做一次精彩的演示。
想要有机会坐上董事长的交椅，你必须擅长独立。
任何才能都最多只能让你有能力做一次精彩的演讲。
对于你将来的成功，好的演讲才能比思考或者写作的能力更加重要。嘴比大脑更有力量。

演讲就像打高尔夫球，不管你有多少天赋，如果你勤加练习，会做得更好。

（4）做一名英雄

你怎样变成企业内部的一名英雄？
最简单、最直接的方法就是，让自己与你的企业计划推出的最耀眼、最激动人心的新产品或服务联系在一起。

今天在大企业里的趋势是：袖手旁观，谨慎做事。

与露脸工作相反的是提供“良好经验”的职位，比如，一份海外职务。
避免这样的工作。
不要接受首席执行官视线之外的任何工作，这种任务都是死路一条。
即便你取得了成功，也无法成为赢家。

（5）做一个救星

如果你出牌正确的话，你也可以骑着白马，以救星的身份迅速到达顶峰。

当企业陷入困境时，它们会向救星求助。“雇请外部管理者有望成为20世纪90年代的主要趋势。”

---

产品型赛马

其实，你是否具有创新能力并没有那么重要。即使你没有什么创新的天分，也同样可以跨上这匹产品型赛马。

事实上，天分有可能成为你前进路上的障碍。而要将成功的希望寄托在产品型赛马身上，其中的关键则是你判别他人天分的能力。

几乎所有产品上的重大突破都会涉及两种人：一种是发明者，另一种则是意识到其中价值的人。

发明者或许能得到超级订单，而意识到其中价值的人则能赚取超级财富。

把目光放得更加开阔一些，摆脱局限你自己的各种因素。通过观察周围发生的一切，发挥你的天分，而不是挖空心思闭门造车。

许多在经济上取得成功的发明都基于简单的观察发现。

要留心，重要的产品创意的检验结果通常不会很好。

在一生当中时机尤为重要。

成功是你发现的东西，而不是从你的脑子里跳出来的。所以，你要始终睁大眼睛，忘掉自我。

找到一个简单的产品创意，然后改名换姓，把它变成一个激动人心的全新产品，这个模式已经被重复了很多次。

从根本上说，你要改变一切的原因在于你试图让自己介入那个产品。忘记自己吧。要仅仅根据那是不是一匹骏马来评估产品。

如果你过于自我，以至于忽略了周遭发生的事情，那么即使你在正确的时间出现在正确地方也毫无助益。

不管你在哪里——上大学、在公司上班或者自己创业，你都应该睁大双眼。
当你看见那匹可以带你到达顶峰的赛马时，不要犹豫。
放弃你正在做的一切，跳上马背。
你可能永远都不会再有这样的机会了。

如果你用一种开放的心态看待生活，你就永远不会太老。
可惜，随着年龄的增长，你的心里往往会装满各种各样的事实。
很快，你就什么都知道了，这会让你处于一个运气不佳的位置，无论一个新的产品创意有多么出色，你也无法加以识别。

通常来说，年龄和经验会与你识别优秀产品创意的能力相互抵触，你会成为万事通心态的牺牲品。

机会是在你最意想不到的时候来临的。
你必须对周遭发生的事情，尤其是意外事件有所警觉。

---

创意型赛马

“这绝对行不通”是人们对新创意最常见的反应。
然而如果别人提出的想法正是你仔细思考过的，你就会脱口而出：“好创意。”

你会爱上自己的想法，不假思索地否定别人的想法。

或许你并不善于出创意，但是当别人给你出创意时，你一定很善于评判。

如果你想驾驭创意型赛马，你必须抑制住自己爱挑剔的本能。

很多极具影响力的想法都有其冒险性，这些想法往往会令在座的人感觉极不舒服。
如果在想法提出的时候并没有人感到紧张或不安，那么很有可能这个想法并不是什么激动人心的想法。

人们都对复杂深奥的东西不胜佩服，他们不相信那些看上去过于简单的东西。
但是，只有简单的想法才行得通，最强有力的创意都有其优雅的简单性。少就是多。

大多数人对于各种创意的认识都是错误的。
他们以为创意是发生在某个人身上的一种独特经历，仿佛如果没有天才爱迪生，我们现在还在使用蜡烛呢。
其实不然。
雨果说：“军队的入侵可以阻挡，业已成熟的想法却阻挡不了。”
窍门就在于，要第一个发现尝试某种新想法的时机已经成熟。

识别一个好创意比想出一个好创意更容易名利双收，胜率也更高。
有数百万计以自我为中心的人都有可能想出你成功所需要的那一个创意，他们都有可能是你成功的源头。
如果你一个劲儿地靠自己去想，那么你成功的源头就锐减成了一个。

不管你的想法多么有前途，如果你不愿意把一生中的大部分时间和资源用在这个想法上，那么其他人也不大可能这么做。
你不能用业余时间来骑创意型赛马。
所以，下次你再想到一个伟大的推销概念，觉得宝洁会心甘情愿为此花上100万美元的时候，你不妨问问自己：我愿意终身致力于此吗？
如果答案是“不”，那就别再想着去辛辛那提了。

而且企业越大，就越不大可能考虑一个外来的想法。

别再想着向别人推销你的想法了，试着推销给你自己吧。

你一旦找到了创意型赛马，接下来，你的任务就是保护和培养这个创意。
各种想法在早期都是最脆弱的，人们总能找到某个想法有什么不对的地方。

在大企业里，这个问题尤为棘手。
要想在《财富》500强的赛道上驾驭创意型赛马，你就得格外努力地工作。
首先，一定不要让反对者近身。

不管是以哪种形式，备忘录也好，演示也罢，或者是非公开的会议，重要的是让企业的管理层知道你才是这个想法的提出者。
千万不要把你的想法往你的上司桌上一丢，然后让他来决定是否实施。
那样的话，就等于放弃了你的所有权。

一旦你让大老板信服了你的想法确实不错，你就得做好准备，接受夹道攻击。
要知道，几乎没有几个大老板会干脆地说：“太好了，我们就这么做。”
大多数老板会把你打发出去，让大家都看看你的想法，从其他同事和部门那里征求一些反馈意见。
这种建立共识的老一套做法使得大老板在情况不妙时能够获得一些保护。
这就叫做分摊责任，或者保护你的企业资产。

你必须事先意识到的情况是，当你带着想法来到你的同僚面前时，他们多半会表示不赞同。
对他们来说，你刚刚成为企业官阶上的一个有力的竞争对手。
他们肯定不会认为你的想法对企业有什么好处，他们会认为它对你和你的职业生涯有好处，这将会打乱既有的等级排序。
如果你的想法与他们的个人计划有冲突，你就会有麻烦。
很快你就会听到诸如你的想法问题重重，与企业的规划存在冲突之类的评价。

千万不要忽视他们的反对意见，要表现得亲切友好，要感谢他们的帮助，并且请他们用书面形式提交反对意见（这一做法通常会阻止掉那些更加愚蠢的反对意见）。
如果他们敢于将反对意见写下来，那么你也要以书面形式一一回应。

如果确实有一些与你没有竞争关系的同事赞成你的想法，要确保他们提供相关的证明文件，让他们每个人都给你写一份备忘录。
然后，你应该把这些备忘录整理好，回去做一次井然有序的一致同意的演示，向大老板汇报。
你要保证列出正反两方面的意见，而且要指出提出意见的人的名字。
虽然大多数大老板喜欢“一致同意”这个结局，不过他们也能看得出来哪些人是藏有私心的。

如果你的想法闯过了夹道攻击这一关，那么你的最后一项任务就是要确保该想法得以实施，而且还能得到适当的资助。
在这个信息传播过度频繁的社会里，一个想法如果不进行适当的宣传或者推广，是不会引起多少人的关注的。
你要为自己的想法争取足够的资源，使之能够顺利出台。

---

他人型赛马

在很早的时候，年轻人就知道有三种方式可以赚钱：
（1）跟富人联姻；
（2）以漂亮、干净且合法的方式窃取；
（3）结交合适的人。

工作狂、事无巨细型的老板都不是理想的选择对象。
在内心深处，他们宁可事事亲为。
你永远不可能与这种老板建立起一种不可或缺的关系。
你要找一个稍微有点懒惰的老板。

与那种事无巨细型的老板相比，这种老板会放手让你做很多事情。
那么随着时间推移，你的能力就会给领导留下深刻印象，而他就会更加倚重你。
如果你打算在这家企业长期干下去的话，你就需要让他们对你产生这种依赖感。

当你的未来老板的对手们永远都捉摸不透他的意图时，你的候选坐骑就占据了有利地位。

因此，如果你的老板略微有些圆滑，那你就找对人了。

领导能力和决策能力事关成败。你的老板坐骑应该表现出激发他人热情的能力，有人称其为“拉拉队长”，但是我们称其为优秀推销员。

你会注意到，我们从未说善良、慷慨或者热情是一位老板所应具备的特征。
不幸的是，这些都是作为一个人所应具备的美德。
也许要实现人的救赎，这些美德是必需的，但是对于成功来说这些却并非必要。
作为将军，拿破仑和巴顿也许并不十分讨人喜欢，但是他们无疑是十分优秀的坐骑。

你应该如何对待自己的老板呢？
奉承是关键。
如果你能讨得老板欢心的话，在企业里要升职就会容易得多。

那些致力于讨好当权者与那些已经在团体中取得了有利地位并拥有相当权力的人之间存在着高度关联。

你怎样才能讨好自己的老板呢？
奉承，毫无疑问。
但最好不要过于直白。
德卢加的建议是，锁定一个与你的老板经常接触的人（这个人可以是你的同事、你老板的上司或者老板的秘书），然后在他面前说老板的好话，他会把话传过去的。

你该不该在某些时候跟老板意见不一致呢？当然应该，德卢加说，但条件是事后你要潇洒地举手投降。
如果能说服你改变想法，老板会感觉非常良好。

更加优秀的“坐骑”是你老板的老板。
换句话说，要抬高自己的起点。
这一点很难付诸实施。你必须既谨慎又大胆，两者要同时同步，缺一不可。

当你为一家大企业工作时，引起他人注意就意味着你已经成功了一半。
之所以说在总部工作比在一线要轻松得多，也正是这个原因。

如果能仔细搜索事业成功的线索，你一定会很早就与某个高层管理人物建立联系。

---

工程问题都很简单，人际关系才是最难的。
我们逐渐发现一个项目成功的关键不仅仅是写出漂亮的代码：所有人向着同一个目标一起合作也是同样重要的。

我们认识的软件工程师大多数都花了4~10年的时间在学校里学习计算机科学和软件工程。
截止本书出版为止，我们不知道有任何一门课程是真正教你怎么在团队和公司里与人合作交流的。
好吧，大多数学生都会在学校里被要求参与某个项目，但是教一个人怎么好好的和另一个人协作，与把他直接丢到一个迫使他协作的环境里完全是两码事。

所谓成功的程序员不仅仅是追逐最新的语言，或是编写最快的代码。
职业程序员几乎都是要参与团队合作的，而且事实上团队直接影响个人生产力和幸福感的程序，超出了很多人的想象。
编写软件是集体项目，而且我们认为人的因素对结果的影响不亚于技术因素。
大多数人虽然在编程技术上耕耘数载，但是在人际关系上，却从来没有下过功夫。

没有人是完美的，在给同事挑错之前，你得先知道自己的毛病。
在处理人际关系的问题上花的精力越少，你就有越多的时间编写漂亮的代码。
软件开发是集体项目。
要在团队里获得成功，你必须以谦虚，尊重和信任为核心原则。

没人喜欢被批评，特别是还没完成的工作。
那么迈克尔·乔丹呢？我们还是一样崇拜他，但事实上他是不可能靠自己一个人就赢得每一场篮球赛的，他真正天才的地方是他和球队一起打球的方式。

天才也会犯错，好点子和高超的技术并不是软件成功的充分条件，你的职业生涯能否成功完全要看你能不能与人合作。
很多程序员都害怕和别人分享他刚刚开始做的东西，因为这意味着同行会看到他们的错误，从而知道这些代码背后的作者并非天才。
如果别人看到我未完成的作品，我会非常忐忑，觉得他们会因此对我产生质疑，把我当成一个傻瓜。
这是程序员这个人群里很普遍的看法，所以最自然的反应就是躲起来不断的努力工作。
只要没人看到你犯错，你就还有机会最终一鸣惊人。

假如你一直都是单打独斗的话，你其实是增加了自己失败的风险，而且浪费了自己成长的可能性。
单打独斗的结果往往令人失望。
真正做出产品之前不愿分享好创意实际上是一场很大的赌博，你很容易在一开始就犯下很基本的错误，你有可能是在重新发明轮子。
你需要确定自己在做的事情是对的，方法也是对的，而且不是重复劳动。
一开始就踏错步的概率总是很高的，越早征求意见和反馈，就越能把风险降低。
记住这句久经考验的原则：确保失败尽早发生，尽快发生，经常发生。

公车因子：一个项目里，需要有多少人被公车撞到才能令其完全瘫痪。
足够多的眼睛，可以确保你的项目保持正确的方向。
闭门造车的结果往往是当实现最初的创意后，却发现世界已经完全改变，原本的产品已经失去意义了。
相比担心自己的创意被偷走或是被人笑话，你更应该担心自己是不是在错误的方向上浪费了大量时间。
令人遗憾的是，这种『创意要保密』的想法并非软件行业独有的，所有领域都普遍存在这个问题。

在编程领域里，真正的独行侠是很罕见的，就算他们真的存在，他们的非凡成就也不是凭空而来的。
这些改变世界的成就几乎都是集体智慧努力得来的结晶。
因此，建立一支全明星团队才是真正的目标。
用一句话来说就是，软件开发是集体项目。

一个人躲在自己小黑屋里抖聪明是没用的。
光靠自己神神秘秘的搞创造发明是不可能改变世界，令千百万用户受益的。
你需要合作，告诉别人你的想法，让别人帮你分担劳力，向别人学习，进而打造一支出色的团队。
高效的团队才是通向成功的关键所在。

社交技巧『三支柱』：谦虚，尊重，信任。
谦虚：没有人是宇宙中心。谁也不是万能的，谁都会犯错。你必须不断提高自己。
尊重：你必须真心实意的关心同事。他们都是活生生的人，他们的能力和成绩都需要得到肯定。
信任：要相信别人的能力和判断力，在适当的时候懂得放权。

不要低估社交的力量。
社交不是勾心斗角，或是操纵别人，它是通过建立起人与人之间的关系来把事情做成功，而且这种关系延续的时间肯定比项目本身要长。

放下自负，不要去担心你的个人形象是不是高大，而应该努力去营造一种团队和集体荣誉感。
只有真正关心对方的人，才会提出建设性意见，希望对方在自身或是工作上有所进步。
作为谈话的一方，应该学会接受批评，这不是说你在技术上要谦虚，而是说你要信任对方，相信他是从心底为你好，完全没有把你当傻瓜的念头。
同样，你的自尊和你的代码不应该有什么联系，换句话说，你和你写的代码是两回事。

如果没有经历过失败的话，就说明你的创新还不够，或者你承担的风险还太小。
失败是可以接受的，失败是更上一层楼的绝佳机会。
托马斯·爱迪生曾经说过，即使我找到了一万种行不通的办法，也不代表我失败了，我并不会因此而泄气，因为每次试错都是在前进。

不要等到完美的时候再出来。
只要产品大致可用，就立刻把它按照原样公开给大众。
这种办法使得成功和失败的地方得以立即显现出来，这样编程团队就可以尽快从中学习，迭代，然后发布新版本。
不要抹掉自己的足迹，像跑道一样点亮它们，为后来人指路吧。

成为人群中最睿智的人的确很让人高兴，而且能够指导别人绝对可以带来了不起的成就感。
但是问题在于一旦攀至峰顶，人们往往就会停止学习了。
而当一个人不再学习的时候，他就会开始觉得厌倦，一不小心还会变得落伍。
这说穿了其实还是谦逊的问题，和是不是愿意像指导别人一样接受别人的指导。

你越是容易受影响，你就越能影响别人。
你越是示弱，你就越强壮。
接受意见改变自己没什么大不了的，不要随意挑起争斗。
承认自己犯错或是无知从长远来讲其实能提升你的形象。
有的时候，最好的答案就是『我不知道』。
重要的改变要从自己做起，然后慢慢影响其他人。

史蒂夫·乔布斯曾经说过，顶尖的人会雇佣和自己一样优秀的人才，而差一点的人只雇得到更差的人。
其实，你应该努力去雇佣那些比你聪明，可以替代你的人。
这对很多人来说难以接受，因为这些人会经常挑战你。
但同样是这些工程师，他们还会不断的给你惊喜，交出漂亮的工作。

他们能引导自己更上一层楼，有些人还会主动想要去带领团队。
你不应该视此为意图篡夺权位，而应该把它看做是让你多领导一支团队的机会，让你可以去探索新的机会，甚至可以放心去度假，而不必每天盯着团队的进度。

领导的人越多，保持淡定和冷静就越是重要，因为众人都会（不算是不是有意识的）看着你，看你在面对事物时的态度和反应是怎么样的。
当队员向你寻求建议的时候，通常都是很让人兴奋的，终于有机会来修复点什么东西了。
在担任领导职务前，你已经在这行干了好多年了，所以很多时候你会直接跳到解题模式，但是其实最不应该的就是这么做。
工程师来问你建议通常不是要你去解决他的问题，而是要你帮助他解决问题，所以最简单的方法应该是问问题。
帮助他解析分析问题，从而达到让他自己解决问题的目的。
这通常能引导工程师得出答案，最重要的是，这是他自己想出来的答案，因此也更有主人翁精神和责任感。
不管你是不是知道答案，这种办法几乎总是能让工程师觉得其实你早就知道答案了。

团队主管最经常要做的事情之一就是引导大家达成共识。
人是植物，每个工程师都需要不同的养分才能成长。

不要把用无知可以解释的行为归结为恶意的。
请求谅解比请求许可要容易得多。
只做正确的事，随时准备被炒。
要是没有被炒，那说明我做的事情对大家都有好处，要是真的被炒了，那说明这不是我想要服务的雇主。

如果没有基本的营销策略，你的软件会无人问津。
用户才应该是你关注的焦点。
如果你想要知道自己的产品入门门槛高不高，不妨做一个简单的试验，随便找一些人（懂技术的和不懂技术的都要），来用你的软件，观察一下他们在头一两分钟内的反应，保证有惊喜。

最好的软件之所以成功，是因为它解决了一个很特定的问题，而且解决的非常漂亮。
与其拙劣的解决所有问题，还不如解决大多数用户都真正会遇到的问题，然后做到最好。
别偷懒，偷懒的典型反面教材就是展示太多的选择给用户。
将复杂的问题分解开来，然后隐藏住复杂性，或者至少也要设法让软件看起来很简单。

人们选择你的软件，是因为他们想要那么做，不是因为被绑架。
这样建立起来的信任，是你最神圣的资源。

倾听用户比什么都重要。
失望越多，抱怨就越多，用户就会更不满，希望和软件工程师公开交流的意愿就越强烈。

由于绝大多数人都没有养成逻辑思考的习惯，所以就缺少了能够解决问题的思路。
思考绝非一时的想法。
不要把假设和结论混为一谈，认清现象和原因的不同。

在解决问题之前，必须不断重复假设，验证，实验，这就是科学方法。
解决问题的能力，就是为印证假设不辞劳苦的行动力。
时刻进行解决问题的思维训练。

不是自己想说的顺序，而是对方能理解的顺序。
为了让语言能够完整的为我们传达信息，我们必须锻炼扎实的逻辑表达能力。
一个优秀的提案者，一定能够一边想下一页的内容，一边做这一页的说明。
真正的建议能力，也就是能够让别人采信的能力，是要靠信息搜集及反复的分析，假设，验证磨炼出来的。

所谓洞悉本质，就是看清楚问题真正的原因，并导出正确的解决方法。
不论你多么厌恶这位对手，你还是要忠于事实，这才是解决问题的根本原则。
让自己置身于一个同类人构成的群体中时，就会失去训练自己解决问题的机会。

学校的功能应该是培养孩子们养成动脑思考的习惯，让孩子对于无解的问题设法提出假设，并不厌其烦努力证明自己的假设是正确的。
麦肯锡重视的是如何才能导出结论，而不是有没有知识。所以重要的是基本的思维路径，而不是知识。
当目前能掌握的信息不足时，要分不同的前提导出结论，这样一旦某个前提成立，相应的结论就有了。

总是说自己很忙没时间的人，其实浪费了太多时间。
生活简单，才能思考。
构想是通过不断的对自己提出质疑，然后找出问题解决方法而产生的。
思考，就是对自己提出疑问。

---

应该考的是思考方式而不是知识

麦肯锡公司在二十几年前就开发了“不测试知识，而测试思考方式”的考试制度。
考试的内容是：在考试者面前展示某项证据，然后询问：“你从这个证据当中，得到什么样的结论？”，“只有这些证据，没办法得到结论吗？”。
这种考试可以清楚区分出两种人：一种是没有足够证据就无法得到结论的人，另一种则是只有小部分证据却可以得到结论的人。

也就是说，麦肯锡重视的是如何才能导出结论，而不是有没有知识。
因为懂得思考方法的人，能够胜任经营管理顾问工作的可能性比较高，所以重要的是基本的思考路径，而不是知识。

我自己在麦肯锡时也开发了许多面试问题，接下来这个问题就是其中之一。
公司突然派你明天开始到坦桑尼亚出差半年，能够携带的行李只有一个背包，你会在背包里装入什么东西？

进入麦肯锡之后能够胜任工作的人，通常在被问的那一瞬间会回答：“抱歉，我并不清楚坦桑尼亚在哪里。但是如果我以这是非洲一个炎热的地方为前提，来回答这个问题的话……”
他们会把问题的前提先做个明确的假设。

这类人不会像学校优等生那样一下子就陷入恐慌。
因为这种回答方式，就算后来才知道自己所设的前提是错误的，还可以改变前提再回答。
因此，就算并不清楚坦桑尼亚的位置，却能够“以假设前提进行回答”的人，在主考官告知“坦桑尼亚在北极圈附近”之后，可以立即改变回答内容说：“那么，我会这么准备……”。

具备“有前提就有结论”的思考模式的人，任何时候都不会陷入恐慌。
因为就算前提有变，还是能导出不一样的结论，这种人不仅能够胜任麦肯锡的工作，相信其他工作也一样能够胜任。

我们将人工智能定义为对从环境中接收感知信息并执行行动的智能体的研究。
每个这样的智能体都实现了一个把感知序列映射到行动的函数。
我们讨论了表达这些函数的各种不同方法，诸如产生式系统，反应式智能体，实时条件规划器，神经元网络，以及决策理论系统等。
我们把学习所扮演的角色解释为把设计者能接触的范围扩展到未知环境中，并且我们说明了这个角色是如何约束智能体设计，形成明确的知识表示和推理的。
我们并不把机器人学和视觉当做各自独立定义的问题对待，而是出现在为实现目标而服务的过程中。

（1）人工智能：围绕智能化智能体的概念，即能够决定要做什么然后执行行动的系统。
（2）问题求解：集中讨论了当需要提前思考若干步骤时决定要做什么的方法。
（3）知识与推理：讨论了关于世界的知识的表示方式，以及如何使用这些知识进行逻辑推理。
（4）规划：继续讨论了如何利用这些推理方法来决策做什么，特别是通过构造规划的方法。
（5）不确定知识与推理：集中讨论了当世界中存在不确定因素时的推理与决策。
（6）学习：描述了为这些决策元件生成所需知识的方法。
（7）通讯，感知与行动：描述了智能化智能体能够感知其环境的方式，以便了解正在进展的各种情况，以及能够将它的规划转换为真实行动的方法。
（8）结论：分析了人工智能的过去与未来，以及人工智能的哲学与伦理含义。

1. 人工智能

绪论

图灵测试是阿兰·图灵提出的，设计的目的是为智能提供一个满足可操作的要求的定义。
他建议预期提出一个长长的而可能有争议的清单来列举智能所需要的能力，不如采用一项基于人类这种无可质疑的智能实体的辨别能力的测试。
如果人类询问者在提出一些书面问题后，无法判断答案是否由人写出，那么计算机就通过了测试。

“思维法则”方法：
19世纪的逻辑学家发展处一种描述世界上的一切事物及其彼此之间关系的精确的命题符号。
与之形成对照，普通的算术符号主要用于描述数与数之间的相等和不相等关系的命题。
到了1965年，原则上，已经有程序可以求解任何用逻辑符号描述的可解问题。（如果问题无解，程序也许永远不会停止求解）
人工智能领域中传统上所谓的逻辑主义，希望通过编制上述程序来创造智能系统。

理性智能体方法：
智能体（agent）就是某种能够行动的东西。
但是人们期待计算机智能体有其它区别于简单”程序“的属性，诸如自主控制的操作，感知环境，持续能力，适应变化，以及有能力承担其它智能体的目标。
理性智能体则要通过自己的行动获得最佳结果，或者在不确定的情况下，获得最佳期望结果。
AI的“思维法则”方法中，强调的是正确的推论。
做出正确推论有时也是理性智能体的部分功能，因为实现理性行动的一个途径就是通过逻辑推理得出指定行动能达成目标的结论，再付诸实施。
另一方面，正确的推论并不是理性的全部内容，因为在许多情况下，没有能证明正确性的事情可做，但是仍然必须有所行动。
还有一些完成理性行动的方式不能说与推理过程有关。

我们需要表示知识并用之进行推理的能力，因为只有这样我们才能在多种不同的环境中制定出好的决策。
我们需要生成可理解的自然语言语句的能力，因为只有这样才能够被复杂的社会接受。
我们需要学习，不只是为了博学，而是因为对世界运转的更好理解使得我们可以找到解决问题的更有效的策略。
我们需要视觉感知，不仅仅因为世界是缤纷多彩的，更是为了对行为的可能后果由更好的了解。

由于上述原因，将AI的研究视为理性智能体的设计过程至少有两个好处。
首先，它比“思维法则”方法更加通用，因为正确的推理只是实现理性的几种可能的机制之一。
其次，它比建立在人类行为或者思维基础上的方法更经得起科学发展的检验，因为理性的标准有着清楚的定义并且是十分普遍的。
另一方面，人类行为可以很好的适应特定环境，并且部分取决于还远远未达到完善程度的复杂而未知的进化过程。

应该牢记的一个重点是：
我们将看到很长一段时间内实现完美的理性（即总能做正确的事情）在复杂的环境下是不可行的，这对计算能力的要求是在是太高了。

人工智能的基础：
（1）哲学：公元前428年——现在
a) 形式化规则能用来抽取合理的结论吗？
b) 精神的意识是如何从物质的大脑产生出来的？
c) 知识从哪里来？
d) 知识是如何导致行动的？
（2）数学：约800年——现在
a) 什么是抽取合理结论的形式化规则？
b) 什么可以被计算？
c) 我们如何用不确定的知识进行推理？
（3）经济学：1776年——现在
a) 我们如何决策以获得最大收益？
b) 我们在他人不合作的情况下如何做到这样？
c) 我们在收益遥遥无期的情况下如何做到这样？
（4）神经科学：1861年——现在
a) 大脑是如何处理信息的？
（5）心理学：1879年——现在
a) 人类和动物如何思考和行动的？
（6）计算机工程：1940年——现在
a) 我们如何才能制造出能干的计算机？
（7）控制论：1948年——现在
a) 人工制品怎样才能在自己的控制下运转？
（8）语言学：1957——现在
a) 语言和思维是怎样联系起来的？

智能化智能体

智能体，可以被视为通过传感器感知所处环境并通过执行器对该环境产生作用的东西。
一般而言，智能体在任何时刻的行动选择取决于到那个时刻为止该智能体的整个感知序列。
从数学上看，我们可以用一个把任意给定感知序列映射到智能体的行为的智能体函数来描述智能体的行为。
从智能体内部来看，人造智能体的智能体函数是通过智能体程序实现的。
智能体函数是一个抽象的数学表示，智能体程序是一个具体的实现，该程序在智能体自身的结构上运行。

智能体的概念，只是我们用来分析系统的一个工具，
而不是用来把整个世界划分成智能体和非智能体的绝对特性。

理性智能体，是做事正确的智能体。
当把智能体置于一个环境中后，它将针对收到的感知信息产生行动序列。
该行动序列引起环境历经一个状态序列，如果该状态序列正是想要的，那么这个智能体的性能良好。
性能度量，是智能体成功程度标准的具体化。

理性智能体的定义：
对于每个可能的感知序列，根据已知的感知序列提供的证据和智能体内建的先验知识，
理性智能体应该选择期望能使其性能度量最大化的行动。

我们需要仔细的区别理性和全知的概念。
一个全知的智能体知道它的行动产生的实际结果并且做出相应的动作，但一个全知者在现实中是不可能的。
理性是使期望的性能最大化，而完美是使实际的性能最大化。

扩展一个智能体依赖于设计者的先验知识而不是它自身的感知信息，
我们就说该智能体缺乏自主性。
理性智能体应该是自主的，它应该能够尽可能的学习，以弥补不全面的或者不正确的先验知识。

任务环境，是理性智能体要“解决”的基本“问题”。

AI的任务是设计智能体程序，通过它实现把感知信息映射到行动的智能体函数。
我们假设该程序要在某种具备实际传感器和执行器的计算装置上运行，我们称之为体系结构。
智能体 = 体系结构 + 程序

2. 问题求解

用搜索法对问题求解

本章介绍了在确定的，可观察的，静态的和完全已知的环境下，智能体可以用来选择行动的方法。
在这样的情况下，智能体可以构造行动序列达到目的，这个过程称为搜索。

在智能体可以开始搜索之前，它必须对目标加以形式化并且用目标对问题加以形式化。
一个问题由四个部分组成：初始状态，行动集合，目标测试函数和路径耗散函数。
问题的环境用状态空间表示，一条穿过状态空间从初始状态到达目标状态的路径是一个解。

（1）广度优先搜索
（2）代价一致搜索
（3）深度优先搜索
（4）深度有限搜索
（5）迭代深入搜索
（6）双向搜索

有信息的搜索和探索

本章考察了应用启发式减少搜索耗散，我们考虑了很多实用启发式的算法，
并发现即使用好的启发式，从搜索耗散角度来看，满足最优性也要付出相当的代价。

（1）最佳优先搜索
（2）贪婪最佳优先搜索
（3）A*搜索
（4）爬山法
（5）模拟退火
（6）遗传算法
（7）联机搜索

约束满足问题

约束满足问题（CSP）由变量和变量上的约束组成。
许多重要的现实世界问题都可以描述为CSP问题，CSP的结构可以用约束图表示。

（1）回溯搜索
（2）弧相容算法
（3）割集调整，树分解

对抗搜索

博弈游戏通过下列元素定义：初始状态，每个状态的合法行动，一个终止测试和可用在终止状态上的效用函数。

（1）极小值极大值算法
（2）α-β搜索算法

3. 知识与推理

逻辑智能体

本章说明了如何定义一种逻辑，使得智能体可以对世界进行推理。

智能化智能体需要关于世界的知识以便达到良好的决策。
知识以知识表示语言的语句形式包含在智能体内，这些语句存储在知识库中。
基于知识的智能体是由知识库和推理机制组成的，它的运转方式是把关于世界的语句存储到它的知识库中，
运用推理机制推导出新的语句，并用这些语句来决策采取什么行动。

表示语言，可以通过它的语法和语义来定义，其中语法指定语句的结构，而语义定义了每个语句在每个可能世界或模型中的真值。
语句α蕴含另一语句β，如果β在所有α为真的世界中都为真。
推理是从旧语句中生成新语句的过程。
可靠的推理算法只生成被蕴含的语句，完备的算法生成所有被蕴含的语句。

推理规则是可以用来寻找证明的可靠推理模式，归结规则产生一个用于表示为合取范式的知识库的完备推理算法。
前向链接和反向链接，都是用于以霍恩范式表示的知识库的非常自然的推理算法。

命题逻辑对于智能体内的特定任务是合理有效的，但是无法放大到大小无界的环境，
因为它没有足够的表达能力来准确的处理时间，空间以及对象间关系的普遍模式。

一阶逻辑

本章介绍了一阶逻辑，一种比命题逻辑表达能力更强的表示语言。

知识表示语言应该是陈述性的，可合成的，有表达能力的，上下文无关的以及无歧义的。
逻辑学在它们的本体论预定和知识论约定上存在不同，
命题逻辑只是对事实的存在进行限定，而一阶逻辑对于对象和关系的存在进行限定，因而获得更强的表达能力。

一阶逻辑的一个可能世界或模型是通过对象集，对象之间的关系以及可以应用于对象的函数来定义的。
常量符号命名对象，谓词符号命名关系，而函数符号命名函数。
解释制定了符号到模型的一个映射，复合项把函数符号应用于项，以命名对象。
给定一个解释和模型，就可以判断语句的真值。

一阶逻辑中的推理

本章对一阶逻辑中的逻辑推理以及实现推理的许多算法进行了分析。

（1）合一
（2）分离规则
（3）逻辑程序设计系统
（4）前向链接和反向链接

知识表示

本章通过深入研究如何表示各种知识，已经对如何构造真实的知识库有了一定认识。

大规模知识表示需要通用本体论来组织和结合各种特定领域的知识。
通用本体论需要涵盖各种广泛的知识，并且原则上应该有能力处理任何域。
我们提出了基于类别和事件演算的上位本体论，我们涉及了结构化对象，时间和空间，变化，过程，物质以及信度。
行动，事件和时间能在情景演算或更有表达力的表示方法中表示，这些表示方法使智能体能够根据逻辑推理构建规划。
智能体的精神状态能够用表示信度的字符串来表示。

专用表示系统，例如语义网络和描述逻辑，被设计用来帮助组织类别层次。
继承是推理的一个重要形式，允许对象属性从它们在类别中的隶属关系演绎出来。
在逻辑程序中实现的封闭世界假设，提供了一个避免必须说明大量否定信息的简单方法，它最好被解释为能够被附加信息覆盖的缺省。
非单调逻辑，诸如界限和缺省逻辑，通常想要捕捉到缺省推理，解集程序设计能加速非单调推理。
真值维护系统高效的处理知识更新和修正。

有看似合理的主张宣称，形式化知识表示研究开始于古印度关于印度教圣典的梵语语法的经典理论化，这可以追溯到公元前的第一个千年。
在西方，古希腊数学中术语定义的使用可以被看做最早的例子。
事实上，任何领域的技术术语的发展都可以被视为一种形式的知识表示。

对时间，变化，行动和事件的表示已经在哲学和理论计算机科学，也在人工智能中进行了广泛研究。
最古老的方法是时序逻辑，这是专门的逻辑，在其中每个模型描述一个随着时间变化的完整轨迹，而不是一个静态的关系结构。

4. 规划

规划

提出能达到一定目标的行动序列的任务称为规划。
本章我们在确定性，完全可观察的环境中定义了规划问题。
我们描述了用于规划问题的主要表示方法和一些用来求解它们的算法方法。

规划系统是问题求解算法，它在关于状态和行动的明确命题（或一阶）表示上运转。

（1）偏序规划（POP）算法
（2）规划图
（3）Graphplan算法
（4）Satplan算法

现实世界的规划与行动

本章处理了真实世界的规划和行动的一些复杂因素。

（1）调度算法
（2）分层任务网络（HTN）
（3）条件规划
（4）无传感的或一致性的规划
（5）重新规划，持续规划，多智能体规划

5. 不确定知识与推理

不确定性

本章论证了概率理论是进行不确定性推理的合适方法。
不确定性是因为惰性和无知而出现的，在复杂的，动态的或者难以接近的环境中，不确定性是不可避免的。
概率表达了智能体无法得到语句真值的确定决策的无呢过程度，概率概括了智能体的信心。

（1）先验概率
（2）条件概率
（3）全联合概率分布
（4）贝叶斯法则

概率推理

本章描述了贝叶斯网络，一种已经得到成熟发展的不确定知识表示方法。
贝叶斯网络所扮演的角色大致相当于命题逻辑在确定知识中的角色。
贝叶斯网络是一个节点对应于随机变量的有向无环图，每个节点在给定父节点下都有一个条件概率分布。
贝叶斯网络提供了一种表示域中条件独立关系的简洁方式。

（1）变量消元法
（2）似然加权，马尔可夫链蒙特卡洛方法
（3）关系概率模型（RPM）
（4）真值函数性系统

关于时间的概率推理

本章所强调的主要是关于概率时序过程的表示与推理的一般问题。

（1）隐马尔可夫模型
（2）卡尔曼滤波器
（3）动态贝叶斯网络

语音识别和运动对象跟踪是时序概率模型的两类重要应用。

制定简单决策

本章说明了如何将效用理论与概率结合起来，以使一个智能体能够选择最大化其期望性能的行动。

概率理论描述在证据的基础上，一个智能体应该相信什么。
而效用理论描述一个智能体想要什么。
决策理论则将两者结合起来，以描述一个智能体应该做什么。

我们可以使用决策理论建造一个系统，通过考虑所有可能的行动，选择能导致最佳期望结果的那个行动，从而做出决策。
这样的一个系统被称为理性智能体。

（1）多属性效用理论
（2）决策网络
（3）专家系统

制定复杂决策

本章显示了如何使用关于世界的知识进行决策，即使行动的结果是不确定的以及行动的回报可能直到很多行动完成以后才会兑现。

（1）马尔可夫决策过程（MDP）
（2）价值迭代算法
（3）策略迭代
（4）动态决策网络
（5）博弈论
（6）机制设计

6. 学习

从观察中学习

本章所关注的内容是从实例中归纳学习确定性的函数。

如果从教室那里或者从环境中得到可用的反馈，能够为实例提供正确的值，那么这样的学习问题称为有监督的学习。
这个也被称为归纳学习的任务，要从函数输入和输出的实例中学习一个函数。
学习离散值函数的被称为分类，而学习连续函数的则被称为回归。
归纳学习涉及寻找一个与实例相符合的一致假设。

（1）奥卡姆剃刀原则
（2）决策树
（3）学习曲线
（4）集体学习方法
（5）计算学习理论

学习中的知识

本章研究了各种使用先验知识帮助智能体从新的经验中进行学习的方法。
因为很多先验知识是用关系模型而不是基于属性的模型来表示的，所以我们也讨论了一些允许对关系模型进行学习的系统。

（1）累积学习
（2）基于即使的学习（EBL）
（3）基于相关性的学习（RBL）
（4）基于知识的归纳学习（KBIL）
（5）归纳逻辑程序设计

统计学习方法

统计学习方法的范围包括从简单的平均值计算到构造诸如贝叶斯网络以及神经元网络这样的复杂模型的方法。
它们有许多应用，遍及计算机科学领域，工程领域，神经生物学领域，心理学领域以及物理学领域等等。

（1）贝叶斯学习
（2）最大后验学习方法（MAP）
（3）最大似然学习方法
（4）EM算法
（5）基于实例的模型
（6）神经元网络
（7）感知器
（8）多层前馈神经元网络
（9）反向传播算法

强化学习

本章考察了强化学习问题，只提供感知信息和偶尔获得的回报，一个智能体如何在未知的环境中变得精明能干。
强化学习可以视为整个人工智能问题的缩影，不过在许多简化设置中进行研究，推动了进步。

（1）直接效用估计
（2）自适应动态规划（ADP）
（3）时序差分方法（TD）
（4）策略搜索

7. 通讯，感知与行动

通讯

自然语言理解是人工智能最重要的子领域之一。
它从哲学和语言学，以及逻辑方法，概率知识表示和推理技术中获得启迪。
与人工智能的其它领域不同，自然语言理解需要有关实际人类行为的经验化的研究。

智能体之间为了达到确定的意图而互相发送信号：通知，警告，请求帮助，共享知识或者是做出承诺。
用这样的方式发送信号被称为言语行为。
最终所有的言语行为都是为了使另一个智能体相信某事或去做某事而进行的努力。

语言由约定俗成的，传达含义的符号组成。
在这种意义上，很多动物也是用符号。
不过人类看来是唯一能够使用语法产生多种多样无限量的结构化消息的动物。

形式语言理论以及短语结构语法（特别是上下文无关文法）都是处理自然语言某些方法的有用工具。
上下文无关语言中的语句可以用图分析器在O(n^3)的时间内完成句法分析。
为了处理类似主语与动词一致以及代词格的问题，增强一个语法是很方便的方法。
确定子句语法（DCG）是一种考虑了增强的形式化方法。
通过DCG，句法分析和语义解释（甚至生成）都可以用逻辑推导实现。

语义解释也是可以用增强语法处理的，准逻辑形式能够成为句法树和语义之间一种有用的中间形式。

歧义性，篇章，语法归纳。

概率语言处理

（1）n元的概率语言模型
（2）概率CFG
（3）信息检索系统
（4）信息抽取系统
（5）机器翻译系统

感知

虽然感知看起来对人类来说是一种不费力气的活动，它却需要大量的复杂计算。
视觉的目标是为诸如操纵，导航和物体识别等任务抽取所需的信息。

（1）成像过程
（2）初级视觉处理算法
（3）姿态估计算法

机器人学

机器人学关心的是操纵物理世界的智能化智能体。

机器人装备有传感器来感知它们的环境，以及它们用来对其环境施加物理力的效应器。
机器人感知关心的是根据传感器数据对与决策相关的量进行估计。

（1）卡尔曼滤波器
（2）粒子滤波器
（3）机器人运动规划
（4）单元分解技术
（5）势场技术

8. 结论

哲学基础

“机器能够智能的行动”（或者也许更确切的，其行动看起来如同它们是有智能的），这种断言被哲学家称为弱人工智能（weak AI）假设。
而“能够如此行事的机器确实在思考”（与模拟思考相对）的断言，则被称为强人工智能假设（strong AI）。

图灵拒绝了问题“机器能思考吗？”，而用一个行为测试取而代之。
他预见到了许多对思维机器的可能性的反对意见。
很少有人工智能研究者关注图灵测试，他们更喜欢关注自己的系统在实用任务上的性能，而不是模仿人类的能力。

人工智能：现状与未来

我们只能向前看到很短的距离，但是我们能够看到仍然有很多事情要做。——图灵

1. 洞察

营销是和人打交道的艺术，必然要遵守人的沟通原则——沟通的目的是为了了解、解决问题；沟通之 前，先耐心倾听。因此， “听”清楚问题，“看”清楚局面， 是解决问题的关键所在。

营销之前，先仔细观察。营销的目的是为了卖货，因此，卖给谁、怎么卖、为什么卖，都是需要在营 销之前要了解的——找到问题所在，才是解决问题的关键所在。

做市场也是 一样的道理，有限的资源投资在看得见回报的地方，要向猎豹学习，没有胜算，宁可多看多听，多找机会， 一役而大获全胜。

好的产品，必然来自细微的生活观察。

观察只是记录人们所做的事情，而洞察则是回答人们为什么会那样做， 只有真正做到了洞察，才能从根本上了解消费者的动机。

消费者的内心就好像冰山一样，你能轻易观察到的就是露出冰面的冰山一角；而消费者的真实动机深 藏在冰面下，需要深入洞察才能撼动整座冰山。根据冰山理论，人类的潜在绝大部分意识对表层的意识和 行为产生影响，用户的潜在需求才是产品真正的购买动机。

因此，好的洞察会给我们一个清晰的结果，消费者需要的是什么，他们为什么需要，以及我们怎么满 足他们的需要。

以消费者为导向——提醒我们，去找出“消费者需要的是什么”，去“注意消费者”，而不是问“我们的消 费者在哪儿”、“请消费者注意”。

在我们决定生产一个产品之前，我们先要去问一问消费者：消费者需要什么样的产品？消费者能承受 的产品价格为多少？消费者希望在什么地方接触或购买我们的产品？

消费者是一个什么样的人？其性别、年龄、收入、教育程度、家庭结构及其本人的家庭角色是怎么样 的？有什么样的性格、价值观？

消费者如何认识产品、看待品牌？消费者现时头脑里的市场地图（产品类别与品牌地图）是怎样摆布 的？他有哪些购买习惯？以及这些习惯形成的缘由和历史？

消费者对产品真正的关心点是什么？他在哪里、什么时间、何种场合使用某类产品？

消费者对使用产品有什么感觉？会如何去表达这种感觉？可能产生什么样的影响？这包括未使用前受 使用者的影响，及使用后对其他消费者的影响。

太多的营销活动及广告以以往的经验估计为基础，而不是以消费者真正的了解及知识为基础。没有真 正足够的调查来了解不同动机、不同偏好、不同风格的消费者。

很多时候消费者是被当做“平均的消费者”，一切都被数据化、平均化。其实，消费者是具体的，不是 抽象的。

洞察，构成了品牌和消费者之间的桥梁，能够让消费者对品牌有着情感上的认同——他们很理解我； 那正是我的感受；他们知道我为什么需要他⋯⋯就好像大家都知道的“春天的故事”：当乞讨的木板上写着“我 是瞎子”时，没人同情他；而写上“现在是春天，而我是个瞎子”时，大家都十分的同情他， “春天”就是洞察 力，是激发出同情的洞察力。品牌要与你的消费群体产生关联，就是需要找到春天这样犀利的洞察力。

调研要与营销紧密结合， 衡量调研 的标准，就是看它能为营销带来多少实用价值。

正合奇胜！要比消费者快上半步，才能赢得先机。

洞察其实没有什么方法论，其原点就在于对人性的理解和关怀。很多产品的起点都是正确的，但距离 成功的终点，总是间隔了那么多的遗憾：这份遗憾，恰恰是因为对生活缺乏好奇心，对人缺少关怀、关注 和关爱。

因此，当一个产品从冷冰冰的生产线上下来，握在你的手上时，一定一定请你千万记得，它除了能帮 助消费者解决问题，满足需求之外，还能带来点什么附加值？还能给人带来何种与众不同的心理感受？带 来什么意外之喜？可能正是这产品功能之外的附加和意外，让你从同类产品中脱颖而出。

市场并不是一块铁板，看似成熟的市场，里面也一定有机会；再强大的对手，也一定有其破绽和软肋。 关键在于能否发现机会。

---

2. 冲突

就如同莎士比亚所说的：冲突产生了戏剧。

人生不如意事十之八九，既然不是仙，难免有杂念，难免有问题，难免有与人冲突、与自己冲突、与 事物冲突、与周围环境冲突的时候，冲突的过程是纠结的过程，也是难受不舒服的过程，如果有一样东西 能让你舒服起来，解决了你的冲突和不适，请问它的价值有多大？如果有一件产品能让你摆脱内心的不爽 与天人交战，请问你买不买？

冲突是指对立的、互不相容的力量或性质(如观念、利益、意志)的互相干扰。

冲突理论认为：冲突之所发生，是当事人和冲突方价值观难以契合导致的，价值观通指一个人对外界 的感知判断和自己的行为规范，包含两部分，一部分是精神的，一部分是物质的，物质是精神的基础，即 有什么样的物质基础则有什么样的价值观，冲突源自价值观，价值观统一则冲突不会发生，价值观不统一， 双方彼此难以说服的时候，冲突就发生了。

解决冲突，就是营销的根本所在。

冲突是获得巨大成长的机会，认识到冲突发生的原因， 就会诞生相应的解决之道；解决之道就意味着满足了需求。

营销首先要——洞察需求； 洞察需求的目的是——帮助消费者解决问题； 解决问题的目的是——获取利益； 问题是什么？问题就是冲突！
三流营销寻找冲突
二流营销解决冲突
一流营销制造冲突

双趋式冲突： “鱼与熊掌不可兼得”
双避式冲突： “两害相权取其轻”
趋避式冲突： 趋利避害，抓住主要矛盾。

只有趋避式冲突是王道。

当人面对两种或两种以上的互不兼容的选择， 而每一种都颇具诱惑力时， 冲突就产生了。 为冲 突找到平衡点， 满足人性的不同面需求的品牌， 就能得到消费者的认可。

人的心理需求和实际需求， 永远都存在冲突；能为消费者找到冲突的原点所在， 并且满足人的 心理和实际的需求， 让人面对诱惑， 不必取舍。

对于营销人员， 能够具备一双慧眼找到冲突， 是基本条件， 我们也为各位看官提供一些方法能够 更快地找到冲突的关键字。

找反义词
树立矛盾，故意违背一般的认知
逆向思维，叛逆者的思维
男女冲突

“没有冲突就没有戏剧。”——冲突制造需求， 没有冲突就没有营销

对于市场营销而言， 发现冲突只是眼睛的胜利， 挖掘并扩大“冲突”的价值， 才是心智的胜利。

你永远也不晓得自己有多喜欢一个人， 除非你看见他和别人在一起！
而有的时候，冲突首先要给你找点不痛快的，让你能够记得她！

生活总是让我们 遍体鳞伤，但到后来，那些受伤的地方一定会变成我们最强壮的地方。那些让我们不太痛快的地方，往往 也会成为最难忘的地方。

一定要和消费者习惯、偏好等等发生关联，不要做些对人不痛不痒的事 情，犹如隔靴搔痒，一定要让消费者的小心脏漏跳一拍。

从个体内在的矛盾、到人与人之间的对立不统一、再到人与社会、品牌之间的形形色色的问题；从发 现冲突、到解决冲突、再到主动制造冲突；这社会没有一刻安宁过，也没有一刻平静过。

一个企业完成全球化以后，随后就应该 进入本土化的阶段。

营销和战争并无两样，克劳塞维茨在《战争论》中已经明确论述清楚：“战争归属于商业竞争版图，同 时也是一种人类利益和活动的冲突。 ”

---

3. 诉求

发现冲突的目的是发现有效的市场空间，这为企业提供相对应的冲突的解决方案指明方向；
市场需要什么样的产品，你的产品解决了消费者什么样的冲突？这是营销成功的基础。
但，我们都知道，再好的产品本身都不会说话，酒香不怕巷子深，毕竟巷子再深，我们也只需要有一 个高音喇叭而已，但那条巷子卖酒的可能有几十家，这个时候如果你没有说法没有内涵就不行了，所以如 何更有效的沟通就非常重要了。

消费者购买一种商品的动机，总是出于对于物质层面和精神层面的两大需求。
作为连接产品和消费者沟通桥梁的诉求，也必须在物质和精神两个层面上进行一一的对应。

产品是用来与消费者交换的；品牌是用来与消费者进行沟通的。
产品定位关键是找到差异化机会。
品牌 定位不是宣传产品，而是找到兼容产品的理念，找到拨动消费者心弦的魂。

产品的魂和品牌的魂并不是二 合一的，而是截然不同的两个层次两个方向。
可惜很多企业把它们混为一谈。

产品诉求就是 要与消费者沟通产品的差异化，既然是沟通，讲人话就够了。

品牌真相是可以唤起消费者心中潜在渴望的有沟通力的内涵，它来源于产品但又必须高于产品本身的 属性。如果说产品真相引导出的产品诉求是引导消费者进行理性的思考和选择，那么品牌真相就是要去“解 开灵魂的密码”，和消费者建立更深层次的关联，在“**、心灵和精神”上形成共鸣。

在建立了产品差异化定位后，塑造品牌就是如何通过创立象征和一系列的传播符号，触动人们 的内心和灵魂，在营销中满足并且占有所在产品类别中人们最根本的需求和渴望，进而让品牌最终成为大 众文化的一部分。

产品的三重属性：核心产品、实体产品、周边产品，这是营销学中最基本也是最重要的概念。

单纯用眼睛看自己的产品是要不得的，而是要学会用心去洞察消费者的真实需求；千万不 要被产品太多的属性迷惑，消费者只会为自己的需求买单；这个需求才是产品真正的价值所在，才是核心 产品。

正因为任何一个产品都具备三重属性，所以在市场竞争中我们就可以根据自身产品、市场环境及消费 者的需求的不同，有针对性的打造产品竞争力，并围绕产品竞争力的方向提炼产品诉求。

昔时乾隆下江南，望见江上百舸争流，一时兴起便问纪晓岚，说阿岚啊，朕今天没戴隐形眼镜看不清， 你给数数江上现在有几条船哦。岚子其实也是个深度近视，但是脑子清楚的一塌糊涂，立刻回应：老大， 江上一共就两条船，一条叫追名，一条，叫逐利。按照市场营销学的诉求上来说，一个是精神诉求，一个 是物质诉求。乾隆很满意，说，你就根据这个写个微博呗，朕跟和大人给你转发。于是一时君臣皆喜。

从最低级的生存需要，到最高级的自我实现。每一级的需求，都是我们在世上度过每一天的理由，我 们也时刻需要去满足这每一种理由，不管是被自己，还是被别人。放大到市场上来说，谁成功地成为了这 个满足消费者的“别人”，谁也就成功占据了消费者心智资源，也就成功了占据了市场竞争的高点。

---

4. 舍得

有所舍才能有所得，大舍才能大得——对于大多数中小企业而言，我们认为其品牌目标不应该是做行 业第一大，而是要去打造和形成不可复制或者难以复制的核心竞争力。而一个优秀的、被消费者心智所认 可的品牌认知，在某种程度上不就是企业核心竞争力之一吗？因此，有所牺牲、长期坚持其实都是值得的。

从产品层面来说，舍去什么都想做，什么钱都想挣，挣快钱的短视行为，将产品做精，做好，保持上 乘品质，短期看，不如那些不顾质量和长久发展的企业来钱快，来钱轻松，长期看，会为企业赢得长期发 展的良好基础；

从品牌层面来说，铸造一个优质品牌远比打一枪换一个地方复杂和艰难的多，但坚持铸造优质品牌对 成就一个卓越企业更具有现实意义；

从传播层面来说，眉毛胡子一把抓，什么都想说，什么都要说，一版广告恨不能密密麻麻全是文字说 明、夸奖企业的溢美之词，反倒不如舍弃荒腔走板的王婆卖瓜，找对诉求焦点，清晰准确表明观点；选择 媒体方面，天女散花不如集中火力精准输送；

从企业层面来说，当企业财力物力人力资源不足够多元化拉长线四面开花的时候，不若专注从而专业。

很多经营者都会不自觉的爱上自己的产品，有关于产品的一切，都几近可能想告诉消费者，我们的产 品有多么完美，不放过任何一个细节，不放过任何一个表述的机会。但，设身处地换位思考，消费者有耐 心听完一个陌生人唠唠叨叨、漫长的叙述吗？

面对这样的现状，说得越多，失去的就会越多。

不要怪，你总是失去他们，怪就怪，你不懂得取舍。给得多固然是拉拢 消费者的一种方法，给得准，解决他们的燃眉之急才是正道。

“这就是我的秘诀——专注和简单。 简单比复杂更难，你必须努力让你的想法变得清晰明了，让它变得简单。 到最后，你会发现它值得你去做。因为一旦你做到了简单，你就能搬动大山。 ”——乔布斯

而舍得的目标就是让你更为专注，将有限的时间无限的专注在最高的价值上，以获得最大价值的回报。

而要想成为专家，你就必须更加专注，做人如此，做产品更是如此。

有的时候，选择太多，就表明了诱惑太多。在众多诱惑中拨开迷雾，直取最适合你的那一个，这是一 种智慧，这种智慧让你成为专家，这种智慧的核心是判断力和“舍”的魄力，判断力令你知道自己需要什么， 舍的魄力让你将有限的时间，资源，更专注在最需要的东西上。

说得简单，做起来反而很难，就好像书法里最难写的，永远就是那个“一”字。大多数的时候，人的一 生都是在和自己的贪婪做斗争。

这些简化的措施，目的只有一个，就是将宝贵的时间和精力都致力于更重要的事情上。尤其在当下， 极其快速的生活节奏下，唯有简单化的事物，才能让我们全身心的投入。

就好像富兰克林说的：与所有的人以诚相待，同多数人和 睦相处，和少数人常来常往，只跟一个人亲密无间。

话说，舍就一定得吗？

非也，非也⋯⋯

在市场中这点体现的尤为明显。据说舍得这词一开始在民间广为传播，是因为其诉求的“善恶终有报”、 “塞翁失马焉知非福”这类的因果报应、劝人向善的观念， 但在这世界上最险恶的环境——市场之中，你还 抱着这样的心态试图赚钱的话，那请你自求多福，出门右转不送。

---

5. 重复

神经心理学家与认知心理学家认为:人们95%的消费行为直接来自于习惯。

重复的刺激所带来的记忆会变成习惯

马丁·林斯壮 (Lindstrom, Martin)曾经说过：我们的大脑有85%的时间处于自动驾驶的状态，多数人不 喜欢主动思考，脑部会自动根据你长久以来的”习惯”、甚至是与生俱来的”模式”自动反应，在你还没有意 识到的时候潜意识就已经为你做了选择

大脑会为我们自动过滤掉很多主动思考的机会，多年养成的习俗，习惯，体验等等会自动为我们做出 选择，很难改变，这也就是我们为什么经常说不要教育消费者，而要迎合消费者的原因所在，因为大脑巨 大的惯性，不是轻易能够改变的。

而惯性是怎么产生的？就是由于一次一次的重复产生的!

我们不妨来看看重复是如何形成习惯的？
1、重复带来刺激， 这是重复最直接也是最有效的作用。
2、不断地重复可以形成条件反射的效果。
3、重复21次才可能形成习惯

就好像亚里士多德说的：“让人卓越的不是行为，而是习惯，是重复的习惯造就了天才。 ”
苏格拉底对 学生们说：“今天咱们只学一件最简单也是最容易做的事。每人把胳膊尽量往前甩，然后再尽量往后甩。 ”
杰克·韦尔奇说过：“一旦你产生了一个简单而坚定的想法，只要不停地重复它，终会使之变为现实。 提炼、坚持、重复——这就是你成功的法宝。 “

没有所 谓的天才，只有重复的练习！
所谓的才华，是经由反复训练，最后不断修正学习而来！最厉害的高手，往 往是将一项技能训练成自己下意识的习惯，所有的反应都不用思考就自动生成。

就像德鲁克说的：只有偏执狂才能真正成就大事，其他的人，或许生活多姿多彩，却白白浪费光阴。

当努力成为一种惯性的时候，成功是你挡都挡不住的。

你百 学不厌，才能达到如此高的境界啊

品牌形象切忌朝令夕改， 贵在坚持重复！

说到底，品牌的定位不是宣传产品，而是发掘出兼容具体产品的理念。同样，重复的内容，最后也要 回到原点上，去重复品牌的核心价值。

一个品牌得以在严酷的市场竞争下存活，靠的是其难以复制的核心竞争力，而真正要去重复积累的， 也正是这一品牌的内核部分，相比表象的重复来说，核心价值的重复更为深刻，当然难度也更大。

“愚钝领袖”——“那些外表灵敏聪慧、让人寄予厚望、期待其能继承公司重责大任的青年们， 没过几年 就辞职了，离开了京瓷。相对地，那些外观乍看反应迟钝，让人觉得做事不够心细，未来没什么大作为的 青年，却没有辞职，反倒一贯地埋头努力。然而，当我历经四十年岁月，重新回过头检视发现，那些年轻 时看似愚钝的人，后来，都成长为十分出色的领袖人物。 ”

日本“经营之圣”稻盛和夫提及：年轻时，看似资质愚钝的人，由于长 期持续不断地做同一件事，于是，成长为卓越不凡的优秀人才。

---

6. 劝诱

劝是推动，推动催促他（她）张开眼睛，注意你要给的东西
诱是拉动，你要给的东西充满魅惑，吸引他（她）的视线
先让他（她）注意到，再利用这产品本身传达的魅惑吸引他（她），这种推力和拉力双管齐下的手段， 就是劝诱。

劝，是通过强大的拉力进攻消费者，告诉消费者：“来买我吧，不买我你就是傻子。 ”是通过各种手段 给消费者一个购买的理由，一个无法拒绝的理由，其实也就是消费者向自己内心的罪恶屈服的过程。

一般来说，消费者态度的形成分为三个阶段
第一阶段：依从（迫于压力）
第二阶段：认同（情感联系发生改变）
第三阶段：内化（价值观发生变化）

劝就是理性地告诉消费者，你应该拥有。

1898年美国 广告学家E.S.刘易斯提出了一个名为AIDMA的消费者购买法则。AIDMA法则的含义为：
A (Attention)引起注意；
I (Interest)产生兴趣；
D(Desire)培养欲望；
M(Memory)形成记忆；
A(Action)促成行动。

所谓AIDMA法则，是指在消费者从看到广告，到发生购物行为之间，动态式地引导其心理过程，并将 其顺序模式化的一种法则。

其过程是首先消费者，注意到(attention)该广告，其次感兴趣(in-terest)而阅读下去，再者产生想买来试 一试的欲望(desire)。然后记住 (memory)该广告的内容最后产生购买行为(action)。

广告的本质就是说服，说服别人，劝诱别人。

---

7. 产品

产品是用来满足人们需求和欲望的物体或无形的载体。

大发明家爱迪生所说的：你不知道男人和女人多么喜欢享受，多么贪婪。

实际上人类是很贪婪的，永远都会有一些欲望没有被满足，这个没有被满足的东西你就要舍得去挖掘 它，市场营销其实就是研究需求，研究怎么卖，卖给谁，这是最初级的。最重要的是研究需求，这个需求 甚至消费者本人都不能意识到，这个才是非常厉害的。

1.学我者生， 似我者死——齐白石
2.反映在具体手段上， 归纳为：以“新”对“好”

差异化最佳的时机就是在空白的盲点上，创造“新”—新的需求，新的产品，新的洞察，新的人群，新 的观念⋯⋯因为“新”所以无从比较，所以没有竞争，所以才有机会天下无敌。

---

8. 价格

在现实生活中，如果你善于观察，就会发现在我们日常生活中已经被免费的商品所包围着。

不用怀疑，当你还可能在为产品如何定价烦恼的时候，免费作为一种营销策略乃至商业模式，已经越 来越多地被那些具备洞察力的企业和品牌所认知和广泛运用，并创造着可观的利润，不仅仅是数字经济领 域，在传统实体市场同样如此。

让产品免费很简单，但要通过产品免费实现盈利却很难。
也就是说在免费的同时还必须想好如何收更 高的费用。在数据驱动的年代，投资回报已成为一门严密的科学，而免费创造的却非直接利润。

价格是售价，价值是内在。价格往往不等于价值，理论上价格也不应该等于价值。可是如何让价格远 远抛离价值？

消费者其实并不知道什么东西该值多少钱。

消费者的主要敏感点是相对差异，而非绝对价格。

我们不是通过价格在出售产品，我们是在出售价格。

绝大多数公司的做法通常还是先设计出一个产品，然后再尝试计算出一个目标价格。但，在一些优秀 的公司，价格是首先被考虑的关键因素，产品在未开发之前就先确定销售价格，设计开发者根据商品的最 终售价来选择制造商和设计产品。

优秀的价格策略能迎合消费需求，也能引导消费，能让消费者感觉占了便宜，也能激发消费者爆棚的虚荣心……消费者心理看似被一个个不同的商品、不同的品牌包围着满足着，但实则是被各种各样的价格魔术给催眠着，被各种商品后面的价格策略在操纵着！

价格给虚荣心制造的极致境界就是“让他渴望去吧，你不 可能拥有我”！

奢侈品就是商家给物质主义者营造的幻觉，价格和任何成本都没有关系，几乎遥不可及东西可以操纵 绝大多数的消费者。

在营销学上，我们通常将这种给消费者制造的价格幻觉，称为“心理定价法”。心理定价适应以自我 感觉为主的产品，例如香水和昂贵的汽车，用心理定价法是特别有效的。

同样这种幻觉也是可以被打造出来的，比如像星巴克从来不是卖咖啡的，所以他的咖啡可以更贵。星 巴克出售的是星巴克体验，是某种生活方式，因此，他的消费者对价格是不敏感的，所以星巴克可以以更 贵的价格出售咖啡。

马克·吐温曾经在《汤姆·索亚历险记》中描写的那样：“汤姆无意中发现了人类行为的一个重要定律， 那就是要让人们渴望做一件事，只需使做这件事的机会难以获得即可。 ”

乔布斯说过，顾客并非要买便宜，而是想“占便宜”。

你真正便宜了，他反而不买你了，认为你廉价、差劲，便宜没好货！你能提供绝佳品质和醉人体验， 让他觉得像捡了个大便宜，再贵他也趋之若鹜。

---

9. 树敌

树敌有三重含义：
第一重含义是树立敌人， 即，因为自己不当行为或者言行，导致别人与你为敌,或是将自己的资源、势 力分割出去创造一个或者一群敌人与自己为敌对抗。
第二重含义是指：寻找一个强大的敌人， 并以战胜他作为自己的目标和事业，这个“敌人”更像为自己 成长设定的一个高度，一个障碍、一个必须收归囊中的战略高地。
第三重含义是指：利用一个强敌， 借力上位。

没有敌人， 就没有竞争和发展
越了解敌人， 越了解市场
以敌明鉴， 成功需要敌人
柿子要拣硬的捏

完美的竞争战略并不是要成为行业的第一， 而是要使自己做到与众不同， 难以复制！

敌人就好似一盏明灯，不仅照亮你的眼睛，还能照亮你的 心灵。只不过，首先你要放下敌对的心，看清楚敌人对你的帮助。如果，实在不能冷静地面对竞争，那无 论怎么样，首先要做的就是千万不要和敌人一模一样，毕竟同一个战场上，穿着和敌军一样的服装，厮杀 起来，很难分辩是敌是友，伤及自己人实在是很不合算。正如我们所说的：了解敌人的目的，不是为了学 他，或者战胜他，而是首先要做到和他不同！

小成功需要好朋友， 大成功需要厉害的敌人

敌人的选择权在你手中，但千万不要太低估了自己。
你的敌人就应该是行业第一！

最大的敌人是你自己， 征服了别人， 最后还要征服自己
“昔之善战者， 先为不可胜，以待敌之可胜。不可胜在己，可胜在敌。 ”

凡是敌人支持的， 我们都反对；凡是敌人反对的， 我们都支持。
彻底和敌人划清界限，彻底和敌人背道而驰，两者的反差 越是大，才越有戏剧效果，才越能清晰的表明品牌主张。

进攻， 永远是最好的防守
斗不过你， 我先跟着你！
师夷长技以制夷
将敌人的优势变为劣势
比竞争对手快半步

“畜之以道， 则民和；养之以德，则民合。和合故能习。 ” 管仲认为，赋予规则，人与人能和谐相处； 培养德行，人与人可相互合作。一个和谐完美的合作可以所向披靡，不畏强敌。

丘吉尔说，没有永远的敌人，只有共同的利益，我想说的是，掠夺没有仁慈，利益面前，人性彰显出 的都是贪婪。

没有永远的敌人，只有永远的利益！

---

10. 游戏

美国总统竞选是很能体现“营销”的，一个竞选人的背后是一个团队，一个竞选人成功与否往往取决于 这个团队的能力。竞选人和竞选人所代表的**就是产品，竞选人的名字就是品牌，这个品牌的内涵、价 值、定位、传播渠道、沟通方式、产品形象涵盖了营销学所涉及的每个领域。

营销不是单纯的卖货， 而是去研究人的心理， 当然也包括研究竞争对手的心理， 想要突出重围， 有时候需要剑走偏锋， 有时候需要正合奇胜， 总而言之， 去创造一些规则下的意外之喜。 说到底， 营 销也是一场游戏， 一场人和人， 团队和团队的游戏⋯⋯

营销， 是一个淘孩子的游戏，只有淘孩子，才能洞察游戏的精髓。

人其实就是这样劣根性凶猛的动物，表面上口口声声号称众生平等，其实心底里大多期望自己站在金 字塔的顶端高人一等、俯视众生。

做营销很简单，只要陪着人们做游戏，强行把他们分成三六九等就ok了。

对一个人的最高评价不是他地位多高，财富多惊人，而是“这是一个很有趣的人。 说得太好了。

在营销的世界里， 会玩的孩子才能玩得如鱼得水，不喜欢游戏的孩子根本不占便宜！

**人说，淘小子出将军，淘气的小孩子大都是很会玩的，会玩就难免闯祸，被贬斥为“狗都嫌”，可 是，总有好事者要较真，哭着喊着要证明，小孩子淘气，会玩长大有出息，经过多年的跟踪观察得来的数 据表明：淘小子出将军这句俗语确实事出有因，有理有据啊。

兵者， 诡道也。

会玩的孩子，通过游戏给自己创造的“技能训练机会”更多；

会玩的孩子在游戏中所获得对抗经验更多，要获得对抗的经验，就需要多次重复练习技艺和思考如何 战胜对手。从而提高运筹帷幄的全盘策划能力、协作能力、领导能力、进攻能力、借势能力、另辟蹊径的 能力、逆向思维的能力⋯⋯

---

11. 娱乐

公司的本质上就是一个舞台，你要在这个舞台上，为你的客户、员工， “秀”出你要卖的东西！

所有的行业都是娱乐业！

娱乐的本质和营销的目的是相通的。

“好好赚屌丝的钱， 这是**互联网业的真理。腾讯是赚海量屌丝的小钱，百度是赚海量屌丝中小企业的钱，淘 宝赚海量屌丝网商的钱——嗯，多玩也是如此。 ”
——《商界评论》

---

12. 俗

赵本山自己非常清醒，他在多次接受采访时都曾说过：“我的艺术生命是人民给的，我的创作来源于普 通东北乡间，我就是个农民，离开人民我什么都不是！”

越是“好”的广告，死得越快，而越是“差”广告，反而生 命力更强。

你想让广告被消费者记住，那必然就得印象深刻和频次高，而 一旦频次高和印象深刻，消费者就一定不喜欢你。因为不管拍的如何，消费者都不会喜欢广告，那为何不 多播放一点，直接一点，或者说，俗一点呢？你的广告，到底是想去博取专家的欢心拿专业大奖呢，还是 想让消费者记住去卖货呢？其问题的关键就是，到底是“好”广告卖货，还是“坏”广告卖货。

广告首要要做的就是说人话。

---

13. 借势

如果说我看得比别人更远些，那是因为我站在巨人的肩膀上——牛顿

《孙子兵法》也提到过：“故 善战者求之于势，不责于人，故能责人而任势”。

有大理想的就是大企业家，有小理想的就是小企业家。

即是那些大事件，大浪潮。只要不是瞎子，都看得到的事情都关注的势能强大的事情，皆有利可图。

企业应该时刻准备着，机会总是垂青有准备的人啊，在突发性事件发生后，企业的即时的反应往往给 自己寻找到机会。小概率事件不仅仅是战争，各种各样的突发性社会性事件同样是企业发展的契机。

不知哪位哲人说过， 在和平年代，体育竞赛就是现时的战争。

---

14. 非对称

我们发现在**这样一个超大型的非对称型市场中，品牌应该从自身业态的状况和 品牌的实际定位出发，或者迅速发展空间铺开市场，或者打造精品策略。而这样的思维方式并不一定是一 成不变的。

渠道结构的非对称性，让**市场成了一个很可爱的市场。太多太多的小企业利用时间和空间的空当 成就了自己阶段性的战术辉煌，而当真正的战略性企业开始发力时，这些所谓的在大市场里的“小经销”和 “小终端”， 自然就成为了争夺的前线。

大家总能发现，不管在大街上还是在学校里，美女旁边总会有个不太漂亮的女朋 友，好像不是那么对称，但细细思量，这也是选择的必然，美女旁边站着普通姑娘，更凸显自己漂亮的凶， 而普通姑娘也得借美女朋友多认识点小帅哥，多好，双赢的结果。

---

15. 碎·营销

世界即便再琐碎，即便再杂乱，即便碎如齑粉，也一样有规律可循，用钢笔写作的莫言获得了诺贝尔 文学奖，同样用钢笔写作的贾平凹获得了法国骑士勋章。即便在碎片化的世界中，也仍然有人驾驭的很好， 因为，鱼不会被水淹死，人自然也不会被信息的海洋淹死，给自己和世界一个距离，重新审视，你将重新 获得这个世界，脸贴着脸看美人，除了粉刺和黑头，你看不到她的美，退后几步，你会收获她的美丽，身 为广告人，该如何在日益微观的世界中保持宏观的视角和能力呢？

碎片时代里的宏观视角

即便是碎片化令他们的注意力无法集中，只要掌握了他们的本能，吸引他们并非难事。

碎片化时代并不可怕，因为营销的本质并无不同。依旧是洞察消费者的需求，谁解决了消费者的需求， 谁就能走上发展的快车道， 这依然是营销的公理。

---

16. 试错

试错不是错。
就如同别人觉得你是个白痴而你不自知时，你确实是个彻彻底底的白痴，而你明确地知 道自己在做白痴的事时，这事就没这么白痴了，甚至你还可能是个聪明人。

试错是一条曲线成长之路

营销不仅仅是研究规律，更是一门关于实践的艺术。

我们应该还记得失败是成功之母这句老话，但在成功学泛滥的今天，越 来越多的人更愿意相信成功带来成功的逻辑。

塞翁失马焉知非福，市场营销也同样如此，定位意味着牺牲，成功需要取舍，关键还是在于我们是否 用积极的心态去面对，有时候为了更长远的战略目标，企业必须学会走曲线甚至去主动经历错误。

乔布斯有一句名言：你不可能充满预见地将生命中的点点滴滴串联起来，只有你回头看的时候，你才 会发现这些点点滴滴之间的联系。
所以，你要坚信，你现在所经历的一切都将或多或少与你的未来产生关 联。

“销售圣经”里最重要的一条是—你推销的是煎牛排时的嗞嗞声， 而不是牛排本身，因为是嗞嗞声让人 流口水。

对无常对，错无常错，直线不一定短，曲线不一定长，只要不偏离战略方向，何妨试一试呢？

市场调研不能 替 代“试错”

事实上市场调研的作用在于预测并依此做出决策，但这其中存在一个决策正确与否的困惑。

企业的成本莫过于机会成本、时间成本、金钱成本，而我们一向强调机会成本应该放在第一位，错失 机会是资金弥补不回来的。

试错在调研之前——在市场机会微光乍现时能够及时地把握住，先做再纠正通常比等调研结果来得快。

如何做到快速反应？柳井正的快速应对，很大一部分来自于重视、倾听了客户的投诉与不满。

试错的最终目的是为了纠错，得到正解

营销型企业要赢得竞争就必须塑造品牌，而塑造品牌的原点是基于对目标顾客未来需求的满足以及竞 争对手可能行动的假设，假设是否能成立，关乎营销战略最终的成败，充分的规律研究和判断非常重要。

将任务化简为繁的七个原则：
（1）应用储存于外部世界和头脑中的知识
（2）简化任务的结构
（3）注重可视性，消除执行阶段和评估阶段的鸿沟
（4）建立正确的匹配关系
（5）利用自然和认为的限制性因素
（6）考虑可能出现的认为差错
（7）若无法做到以上各点，就采用标准化

Norman's Seven Principles of Design are:

1. Use both knowledge in the world and knowledge in the head.
2. Simplify the structure of tasks.
3. Make things visible: bridge the gulfs of Execution and Evaluation.
4. Get the mappings right.
5. Exploit the power of constraints, both natural and artificial.
6. Design for error.
7. When all else fails, standardize.

我完全被“基础设施即代码”（infrastructure as code）的理念所折服了。
Luke一边喝着咖啡，一遍更详细的向我阐述了他的想法。
他告诉我，他相信运维人员的工作模式可能会变得像开发人员一样，
他们必须在源代码控制系统里维护系统的配置，并在工作中使用持续集成/持续交付（CI/CD）的模式。

DevOps不仅是自动化，就像天文学不只是望远镜一样。

今天，不管我们身处什么行业，想要获取客户并向客户交付价值的方式都要依赖于技术价值流。

每个公司都是科技公司，无论他们认为自己处在哪个行业。
银行也只是拥有银行执照的IT公司而已。

困于这种恶性循环中多年，特别是那些处于开发下游的人，经常感觉被困在一个注定失败的系统中，无力改变结果。
伴随这种无力感的是倦怠感，还有疲劳，愤世嫉俗，甚至是无助和绝望。

许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事。
我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚，失败或危及生命而不敢做正确的事。
这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。

高绩效者要更加敏捷和可靠，这证明DevOps能够打破根本的，长期的冲突。

当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。

IT公司所特有的全部典型问题：项目预算超支，进度一再拖延，为了公司的存亡不得不上线。

---

精益的两个主要原则包括：
坚信前置时间（把原材料转换为成品所需的时间）是提升质量，客户满意度和员工幸福感的最佳度量指标之一；
小批量任务的交付是缩短前置时间的一个关键因素。

在敏捷宣言中，一个重要的原则是，
频繁的交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期。
并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。

精益社区中大多数企业都没有抓住精益的核心——改善套路（kata）。
所有企业都有日常工作流程，而这些日常工作决定了最终的产出。
通过设定目标，制定每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和改进的目的。

---

精益中的一个基本概念叫价值流。
价值流，指的是一个组织基于客户的需求所执行的一系列有序的交付活动。
或者是，为了给客户设计，生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值。

为了缩短和预测价值流中的前置时间，通常需要持续的关注如何建立一套流畅的工作流程，
包括减少批量尺寸，减少在制品（work in process，WIP）数量，避免返工等，
同时还需要确保不会将次品传递到下游的工作中心，并持续不断的基于全局目标来优化整个系统。

在制造业中加速物理产品加工流程的原则和模式，同样可以应用到技术工作（及所有知识工作）中。
在DevOps中，我们通常将技术价值流定义为，
把业务构想转化为向客户交付价值的，由技术驱动的服务所需要的流程。

---

通过持续加强工作内容的可视化，减少每批次大小和等待间隔，内建质量以防止缺陷向下游传递，从而增强流动性。
通过加速技术价值流的流动，可以缩短满足内部客户和外部客户需求的前置时间，进一步提高工作质量，
并使我们更加敏捷，能够比竞争对手更为出色。

技术行业的工作内容是不可见的，这是其与制造业价值流相比的一个显著差异。
相对于工业产品的生产过程而言，在技术价值流中很难发现工作过程的阻塞点，
例如，在哪里受阻了，在哪个环节产生了积压。

另一方面，技术工作的流转通过单击一次鼠标就可以完成，譬如将工单重新指派给另一个团队。
由于单击的操作太过容易，所以不同团队可能会因为信息不完整而将工作“踢来踢去”，
存在的问题也会被传递到下游工序，而这些问题完全是不易觉察的，直到无法按时向客户交付产品，或者应用程序在生产环境中出了问题。

为了能识别工作在哪里流动，排队或停滞，就需要将工作尽可能的可视化。

通过限制在制品数，还能更容易的发现工作中的阻碍。
例如，当限制在制品时，可能会发现居然没什么工作可干的，因为要等待其他人。

虽然进行一项新工作（即，干点什么总比什么都不干强）可能很诱人，
但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。

实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，
造成了很多优先级冲突问题。

建立平滑而快速的工作流的另一个关键点，是通过小批量的模式完成工作。

在精益中，一个重要的经验是：
为了缩短前置时间和提高交付质量，应当持续不断的追求小批量模式。

理论上，最小的批量是单件流，也就是每次操作只执行一个单位产品的处理。

对于技术价值流而言，大批量的副作用和制造业一样。
我们制定了软件发布的年度计划，将一整年的开发成果一次性的都发布到生产环境中。
这种大批量的发布会造成突发的，大量的在制品，导致所有下游工作中心大规模的混乱，其结果是流动性变差，质量下降。

在技术价值流中，单件流可以通过持续部署实现。

即使在最好的情况下，有些信息或者知识也不可避免的在交接过程中丢失。
为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，
要么重新调整组织结构，让团队不必依赖其他人就可以独立的为客户提供价值。

因此，要通过减少队列中的等待时间以及非增值工作的时间来增加流动性。

为了缩短前置时间，提高吞吐量，我们需要不断识别系统中的约束点，提高工作产能。
在任何价值流中，总有一个流动方向，一个约束点，任何不针对此约束点而做出的优化都是假象。

如果我们优化约束点之前的那个工作中心，那么工作必将在这个约束点上更快的积压起来。
反之，如果优化约束点之后的工作中心，那么它还会处于饥饿状态，等待约束点处工作的结束。

浪费是业务兴盛的最大威胁，精益中对浪费的常用定义是，
使用了超出客户需求和他们愿意支付范围的任何材料或资源的行为。

浪费和困境是软件开发过程中导致交付延迟的主要因素。
我们的目标是将这些浪费和困境都可视化，并系统的进行改进，减轻或消除这些负担，从而实现快速流动的目标。

---

复杂系统的组件之间通常是紧耦合且紧密关联的，不能仅仅依据组件的行为来解释系统的行为。

Charles Perrow博士研究了三里岛核事故，他发现没有人能了解核反应堆在所有情况下的行为，以及在何种情况下会发生故障。
当核反应堆的一个组件出现故障时，很难将其与其他组件隔离，以不可预测的方式快速的流过阻力最小的路径。

复杂系统的另一个特点：相同的事情做两次，结果未必相同。
即便施行了有价值的静态检查和最佳实践，还是不足以防止灾难发生。

复杂系统中的故障是存在且不可避免的。

在安全的工作系统中，我们要不断的对设计和假设进行验证。
目标是更早，更快，以尽可能低的成本，从尽可能多的维度增加系统的信息流，
并尽可能清晰的确定问题的前因后果。

在制造业，如果缺乏有效的反馈机制，往往会酿成重大质量和安全问题。
在高绩效的制造业运营中，整个价值流里存在着快速，频繁和高质量的信息流，
每个工序的操作都会被度量和监控，任何缺陷或严重偏差都能被快速发现和处理。

Elisabeth Hendrickson说，
在我负责质量验证的时候，我将自己的工作描述为“建立反馈回路”。
而测试仅仅是一种反馈。

我们不应该绕开问题，也不应该用“有更多时间时再解决”来搪塞，
而要立刻群策群力修复问题。

触发了安灯绳时，我们就聚集在一起解决问题，停止开展任何新工作，直到问题解决。

---

在复杂系统中工作时，精确的预测出结果是不现实的。
因此，在日常工作中，即便未雨绸缪，小心谨慎，意外依然会发生，甚至有时还会发生灾难性的事故。

不公正的事故和意外处理会阻碍安全调查，让安全工作者感到恐惧，让整个组织更加官僚，
甚至还会导致信息封闭，责任逃避和滋生自我保全意识。

如果团队没有能力或者意愿去改进现有的流程，那么就会持续饱受眼前问题的困扰和折磨，
而且痛苦指数还会与日俱增。

就算不去优化现状，流程也不会是一成不变的，
由于混乱和无序，流程会随着时间的推移持续恶化。

比日常工作更重要的，是对日常工作的持续改进。

一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益。
换句话说，当单个团队或个人获得了独有的专业知识或经验时，我们的目标是把这些隐性知识（即很难通过文档或沟通的方式传递的知识）转换为显性知识，
从而帮助其他人吸取这些专业知识并在实践中应用。

在技术价值流中，我们也应该通过类似的机制建立全局知识库。

低绩效组织想方设法缓解问题，换句话说，他们疲于应付问题。
相对而言，高绩效组织则通过改善日常运营，持续的引入张力提高生产效率，同时在系统中注入更大的弹性，来实现或达到更佳的效果。

还可以通过演习的方式来预演大规模故障。
或者在生产环境中注入大规模故障，
如Netflix著名的“捣乱猴”，它会随机杀死生产环境中的进程和服务器，
来验证系统的可靠性是否达到了预期。

领导者通过“做出所有正确的决定”来领导团队。
然而，有证据表明，领导力的优秀并非体现在做出的所有决定都是对的。
相反，更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。

领导者必须强调解决问题的能力和学习的价值。

---

应用的年龄并不是影响性能的主要因素，
相反，性能取决于应用架构在当前（或重构后）是否具有可测试性和可部署性。

在每一个组织中，不同的团队或个人都会对创新持有不同的态度。
创新者 2.5%：技术爱好者，“试试看”
早期采用者 13.5%：有远见者，“走在潮流之前”
早期从众者 34%：实用主义者，“顺应潮流”
晚期从众者 34%：保守主义者，“经过验证才行”
落后者 16%：怀疑论者，“坚决说不”

创新者和早期采用者，往往能迅速接受新的想法，而其他人则较为保守。

我们不会花费太多时间去改变保守的群体，特别是在早期阶段。
相反，应该把精力在能创造成功且愿意承担风险的团队上，并以此为基础慢慢扩大范围。

即使取得了高层的支持，也要避免使用“大爆炸”的方式（即遍地开花式的开始），
而应该将精力集中于少数几个试点领域，确保它们取得成功，然后再逐步扩展。

不管如何选定切入点，都要尽早展示成果，并积极宣传。

变革需要勇气，尤其是当有人不断的挑战和抵制你的时候。

---

和所有核心干系人一起演练价值流映射，从而帮助团队梳理出创造价值的所有步骤。

无论价值流的复杂程度如何，其中都没有一个人能够知道为客户创造价值所要做的每一项工作，尤其是当工作由多个团队完成时。
因此，在选择好DevOps试点应用或服务后，必须确定价值流的所有成员，他们有责任共同为客户创造价值。

针对团队工作绘制价值流图
绘制价值流图的目标并不是记录所有的步骤和细节，
而是识别出阻碍价值流快速流动的环节，从而缩短前置时间和提高可靠性。

根据我的经验，这样的价值流映射演练总是让人大开眼界。
很多人通常是第一看到，为了向客户交付价值，到底需要完成多少工作。

根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作。
（1）需要等待数周甚至数月的工作
（2）引发或处理重大返工的工作

任何一个成功运作多年的组织都已经建立了符合自身的实践和运行机制。
同时，公司还采取各种措施延续和保护当前的运作流程。
虽然这对维持现状很有好处，但为了适应市场的变化，往往需要改变工作方式。
这需要颠覆和创新，必然会和当前负责日常业务和内部流程的群体产生冲突，而且后者往往会胜出。

两位博士的研究成果表明，应该组建专门的转型团队，并使之独立于负责日常运作的部门。

当背负沉重的金融债务时，组织只能还利息，从来都无法偿还贷款本金，而且很有可能陷入连利息都还不起的窘境。
同样，无法还清技术债务的组织也会发现，在日常工作中，应付老问题已经让自己不堪重负，根本无法开展新的工作。
换句话说，这些组织目前仅仅是支付技术债务的利息而已。

为了积极的管理技术债务，要确保至少把20%的开发和运维时间投入到重构，自动化工作，架构优化以及非功能性需求上，
例如，可维护性，可管理性，可扩展性，可靠性，可测试性，可部署性和安全性等。

Marty Cagan指出，如果组织不愿意支付这20%的税，那么技术债务将会最终恶化到耗尽所有可用资源的程度。

---

康威定律：系统设计受限于组织自身的沟通结构。
组织的规模越大，灵活性就越差，这种现象也就越明显。

软件的架构和软件团队的结构是一致的。
软件开发团队的结构对软件产品的架构和成果有着巨大的影响。

让问题变得更复杂的是，执行工作的人通常都不太理解自己的工作与价值流目标有什么关系，
“我之所以要配置这台服务器，是因为别人要我这么做。”
这样就无法让员工发挥创造性和主动性。

在高效能组织中，人们有着共同的目标。
保证质量，可用性和安全性，不是某个部门的职责，而是所有人日常工作的一部分。

实现高绩效的另一种方法是组建稳定的服务团队，持续提供资金，让他们执行自己的战略和计划。
在传统的开发模型中，开发团队和测试团队被分配到某一个项目中，
当项目完成或资金耗尽后，团队解散，他们又被重新分配到另一个项目中。

这种方式导致很多不尽人意的结果，
包括开发人员无法看到他们所做决策的长期效果（一种反馈形式），以及投资模式只注重和支付软件生命周期的初始阶段，
不幸的是，对于成功的产品或服务而言，初始阶段是成本最低的阶段。

不当的组织方式需要各个团队进行大量的沟通和协调，
但仍然可能导致大量返工，对需求定义有分歧，工作交接低效，以及由于等待上游人员完工而造成的人员闲置等。
在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，
从而避免过多不必要的沟通和协调。

在紧耦合的软件架构中，即使是微小的变更也可能导致大规模的故障。
因此，负责某个组件的开发人员不得不和负责其他组件的开发人员不断的协调和沟通，
包括走各种复杂的变更管理流程。

松耦合的架构意味着在生产环境中可以独立更新某一项服务，而无需更新其他服务。

发布软件时，你应该确保 QA 找不到任何问题。
故意发送明知有缺陷的代码，这种做法是极其不专业的。

什么样的代码是有缺陷的呢？
哪些你没把握的代码都是！

有些家伙会把 QA 当做捉虫机器看待。
他们把自己没有全盘检查过的代码发送过去，想等 QA 找出 bug 再反馈回来。

且不说这么做是否会大幅增加公司成本，严重损害软件，是否会破坏计划并让企业对开发小组的信心打折扣，
也不去评判这么做是否等同于懒惰失职，把自己没把握的代码发送给 QA 这么做本身就是不专业的。

每次 QA 找出问题时，更糟糕的是用户找出问题时，你都该震惊羞愧，并决心以此为戒。

---

你怎么知道代码能否正常运行呢？
很简单，测试！
一遍一遍的测，翻来覆去，颠来倒去的测，使出浑身解数来测！

你或许会担心这么狂测代码会占用很多时间，毕竟，你还要赶进度，要在截止日期前完工。
如果不停的花时间做测试，你就没时间写别的代码了。
言之有理！所以要实行自动化测试。

写一些随时都能运行的单元测试，然后尽可能多的执行这些测试。
要用这些自动化单元测试去测多少代码呢？还要说吗？全部！全部都要测！

我是在建议进行百分之百测试覆盖吗？不，我不是在建议，我实在要求！
你写的每一行代码都要测试。完毕！

这是不是不切实际？当然不是。
你写代码是因为想执行它，如果你希望代码可以执行，那你就该知道它是否可行。
而要知道它是否可行，就一定要对它进行测试。

但是有些代码不是很难测试吗？是的，但之所以很难测试，是因为设计时就没考虑如何测试。
唯一的解决办法就是要设计易于测试的代码，最好是先写测试，再写要测的代码。

---

成熟的专业开发人员知道，聪明人不会为了发布新功能而破坏结构。
结构良好的代码更灵活。
以牺牲结构为代价，得不偿失，将来必追悔莫及。

所有软件项目的根本指导原则是，软件要易于修改。
如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。

不幸的是，实在是已有太多的项目因结构糟糕而身陷失败的泥潭。
那些曾经只要几天就能完成的任务现在需要耗费几周甚至几个月的时间。
急于树立威信的管理层于是聘来更多的开发人员来加快项目进度，但这些开发人员指挥进一步破坏结构，乱上添乱。

如果你希望自己的软件灵活可变，那就应该时常修改它。
要想证明软件易于修改，唯一办法就是做些实际的修改。
如果发现这些改动并不像你预想的那样简单，你便应该改进设计，使后续修改变简单。

该在什么时候做这些简单的小修改呢？随时！
关注哪个模块，就对它做点简单的修改来改进结构。
每次通读代码的时候，也可以不时调整一下结构。

这一策略有时也叫“无情重构”，我把它叫做“童子军训练守则”：
对每个模块，每检入一次代码，就要让它比上次检出时变得更为简洁。
每次读代码，都别忘了进行点滴的改善。

这完全与大部分人对软件的理解相反。
他们认为对可工作软件不断的做一系列修改是危险的。
错！让软件保持固定不变才是危险的！
如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化”了。

为什么大多数开发人员不敢不断修改他的代码呢？
因为他们害怕会改坏代码！
为什么会有这样的担心呢？因为他们没做过测试。

话题又回到测试上来了。如果你有一套覆盖了全部代码的自动化测试，如果那套测试可以随时快速执行，
那么你根本不会害怕修改代码。

怎样才能证明你不怕修改代码呢？那就是，你一直在改。

专业开发人员对自己的代码和测试极有把握，他们会极其疯狂随意的做各种修改。
简单说，他们对待代码，就如同雕塑家对待泥巴那样，要对它进行不断的变形与塑造。

---

职业发展是你自己的事。雇主没有义务确保你在职场能够立于不败之地，
也没义务培训你，送你参加各种会议或给你买各种书籍充电。这些都是你自己的事。
将自己的职业发展寄希望于雇主的软件开发人员将会很惨。

另外，雇主也没义务给你留学习时间。
雇主出了钱，你必须付出时间和精力。
为了说明问题，就用一周工作 40 小时的美国标准来做参照吧。
这 40 小时应该用来解决雇主的问题，而不是你自己的问题。

你应该计划每周工作 60 小时。前 40 小时是给雇主的，后 20 小时是给自己的。
在这剩余的 20 小时里，你应该看书、练习、学习，或者做其他能提升职业能力的事情。

或许你不愿那么勤勉。没问题。
只是那样的话你也不能自视为专业人士了，因为所谓 “术业有专攻” 那也是需要投入时间去追求的。

---

我们需要招聘的不是“经历丰富”的人，而是“有职业素养的人”。
你遇到的问题可能很容易也可能很难，但我看重的并不是问题的难度，而是解决问题的方式，步骤以及反思的深度。
拿恢复误删数据来说，这可能算非常简单的任务。
我更感兴趣的是怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后做了哪些措施来避免这种错误再次出现。
在我看来，相比问题本身的难度，解决问题的方式和步骤以及反思的深度，都体现出一个人的职业素养。

技术人员经常太容易说“是”，往往在没有明确目标和期限的情况下，就草率给出了确认的答复，而且并不将其视为自己的一种承诺。
屡见不鲜的项目延期，有相当原因就是在这种不负责任的情况下说“是”导致。

有时候，获取正确决策的唯一途径，便是勇敢无畏的说出“不”字。
我们要明白，委屈专业原则以求全，并非问题的解决之道。
舍弃这些原则，只会制造出更多的麻烦。
（注：放弃原则，本身就是一种不专业的做法。

一看到已经满足的需求，关于到底想要什么，他们就会冒出更好的想法，通常并不是他们当时看到的样子。
真正的解决办法，是约定共同认可的验收测试标准，并在开发过程中保持沟通。

---

非专业人士不需要为自己所做的工作负责，他们大可把责任推给雇主。
如果非专业人士把事情搞砸了，收拾摊子的往往是雇主，而专业人士如果犯了错，只好自己收拾残局。
实际上，专业主义的精髓就在于将公司利益视同个人利益。
看到了吧，“专业性”就意味着担当责任。

开发的软件有bug会损害软件的功能。因此，要做得专业，就不能留下bug。
“等等！”你肯定会说，“可是那是不可能的呀。软件开发太复杂了，怎么可能会没bug呢！”
当然，你说的没错。软件开发太复杂了，不可能没什么bug。
但很不幸，这并不能为你开脱。
人体太复杂了，不可能尽知其全部，但医生仍誓言不伤害病人。

代码中难免会出现bug，但这并不意味着你不用对它们负责。
没人能写出完美的软件，但这并不表示你不用对不完美负责。
所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免。
职业经验多了之后，你的失误率应该快速减少，甚至渐近于零。
失误率永远不可能等于零，但你有责任让它无限接近零。

（1）让QA找不出任何问题
在发布软件时，你应该确保QA找不出任何问题。
故意发送明知有缺陷的代码，这种做法是极其不专业的。
什么样的代码是有缺陷的呢？那些你没把握的代码都是！
把自己没把握的代码发送给QA这么做本身就是不专业的。

QA会发现bug吗？可能会吧，所以准备好道歉吧，然后反思那些bug是怎么逃过你的注意的，想办法防止它再次出现。
每次QA找出问题时，更糟糕的是用户找出问题时，你都该震惊羞愧，并决心以此为戒。

（2）要确信代码正常运行
你怎么知道代码能否正常运行呢？很简单，测试！
一遍遍的测，翻来覆去，颠来倒去的测，使出浑身解数来测！

写一些随时都能运行的单元测试，然后尽可能多的执行这些测试。
你写的每一行代码都要测试。
你写代码是因为想执行它，如果你希望代码可以执行，那你就应该知道它是否可行。
而要知道它是否可行，就一定要对它进行测试。

有些代码不是很难测试吗？
是的，但之所以很难测试，是以为设计时就没考虑如何测试。
唯一的解决办法就是要设计易于测试的代码，最好是先写测试，再写要测的代码。

（3）自动化QA
作为开发人员，你需要有个相对迅捷可靠的机制，以此判断所写的代码可否正常工作，并且不会干扰系统的其他部分。

---

成熟的专业开发人员知道，聪明人不会为了发布新功能而破坏结构。
结构良好的代码更灵活，以牺牲结构为代价，得不偿失，将来必追悔莫及。
所有软件项目的根本指导原则是，软件要易于修改。
如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。

不幸的是，实在是已有太多的项目因结构糟糕而深陷失败的泥潭。
那些曾经要几天就能完成的任务现在需要耗费几周甚至几个月的时间。
急于重新树立威望的管理层，于是聘来更多的开发人员来加快项目进度，
但这些开发人员只会进一步破坏结构，乱上添乱。

描述如何创建灵活可维护的结构的软件设计原则和模式已经有很多了。
专业的软件开发人员会牢记这些原则和模式，并在开发软件时认真遵循。
但是其中有一条实在是没几个开发人员会认真照做，那就是：
如果你希望自己的软件灵活可变，那就应该时常修改它！

要想证明软件易于修改，唯一办法就是做些实际的修改。
如果发现这些改动并不像你预想的那样简单，你便应该改进设计，使后续修改变简单。

对每个模块，每检入一次代码，就要让它比上次检出时变得更为简洁。
每次读代码，都别忘了进行点滴的改善。
这完全与大多数人对软件的理解相反，他们认为对可工作的软件不断的做一系列修改是危险的。错！
让软件保持固定不变才是危险的！
如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化了”。

为什么大多数开发人员不敢不断的修改他们的代码呢？
因为他们害怕会改坏代码！
为什么会有这样的担心呢？
因为他们没做过测试。

话题又回到测试上来了，如果你有一套覆盖了全部代码的自动化测试，如果你那套测试可以随时快速执行。
那么你根本不会害怕修改代码。
怎样才能证明你不怕修改代码呢？那就是，你一直在改。
专业开发人员对自己的代码和测试极有把握，他们会极其疯狂的做各种修改。
简单的说，他们对待代码，就如同雕塑家对待泥巴那样，要对它进行不断的变形和塑造。

---

职业发展是你自己的事，雇主没有义务确保你在职场能够立于不败之地，
也没有义务培训你，送你参加各种会议或给你买各种书籍充电，这些都是你自己的事。
将自己的职业发展寄希望于雇主的软件开发人员将会很惨。

雇主出了钱，你必须付出时间和精力。
为了说明问题，就用一周工作40小时的美国标准来做参照吧。
这40小时应该用来解决雇主的问题，而不是你自己的问题。
你应该计划每周工作60小时，前40小时是给雇主的，后20小时是给自己的。
在这剩余的20小时里，你应该看书，练习，学习，或者做其他能提升职业能力的事情。

或许你不愿那么勤勉，没问题，只是那样的话你也不能自视为专业人士了，
因为所谓“术业有专攻”那也是需要投入时间去追求的。

---

近50年来，各种观点，实践，技术，工具与术语在我们这一领域层出不穷。
你对这些了解多少呢？如果想成为一名专业开发者，那你就得对其中的相当一大部分有所了解，而且要不断扩展这一知识面。
下面列出了每个专业软件开发人员必须精通的事项。
（1）设计模式：必须能描述GOF书中的全部24种模式，同时还要有POSA书中多数模式的实战经验。
（2）设计原则：必须了解SOLID原则，而且要深刻理解组件设计原则。
（3）方法：必须理解XP，Scrum，精益，看板，瀑布，结构化分析及结构化设计等。
（4）实践：必须掌握测试驱动开发，面向对象设计，结构化编程，持续集成和结对编程。
（5）工件：必须了解如何使用UML图，DFD图，结构图，Petri网络图，状态迁移图，流程图和决策表。

---

你会找那些已经不看医学期刊的医生看病吗？
你会聘请那些不了解最新税法和判例的税务律师吗？
雇主们干嘛要聘用那些不能与时俱进的开发人员呢？

业精于勤，真正的专业人士往往勤学苦干，以求得自身技能的纯熟精炼。
只完成日常工作是不足以称为练习的，那只能算是种执行性质的操作，而不是练习。
练习，指的是在日常工作之余专门练习技能，以期自我提升。

对软件开发人员来说，有什么可以用以操练的呢？
乍一听，这概念显得荒唐，但是再仔细想一会儿，想想音乐家是如何掌握演练技能的。
他们靠的不是表演而是练习。
他们又是如何练习的呢？首先，表演之前，都需要经历过特别的训练，音阶，练习曲，不断演奏等。
他们一遍又一遍的训练自己的手指和意识，保持技巧纯熟。

俗话说，教学相长，想迅速牢固的掌握某些事实和观念，最好的方法就是与由你负责的人交流这些内容。
这样，传道授业的同时，导师也会从中受益。
同样，让新人融入团队的最好办法是和他们坐到一起，向他们传授工作要诀。
专业人士会视辅导新人为己任，他们不会放任未经辅导的新手乱打乱撞。

---

每位专业软件开发人员，都有义务了解自己开发的解决方案所对应的业务领域。
你未必需要成为该领域的专家，但你仍需勤勉，付出相当的努力来认识业务领域。

开始一个新领域的项目时，应当读一两本该领域相关的书，要就该领域的基础架构与基本知识作客户和用户访谈。
还应当花时间和业内专家交流，了解他们的原则和价值观念。
最糟糕，最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。
相反，你应该对这一领域有所了解，能辨别，质疑规格说明书中的错误。

---

能就是能，不能就是不能。不要说“试试看”。——尤达

每位经理都承担着工作职责，绝大多数经理也知道该如何尽职尽责。
其中一部分的工作职责，便是要竭尽所能追求和捍卫他们设定的目标。
同样，程序员也自有其工作职责所在，绝大多数程序员也知道该如何出色的尽职尽责。
如果他们是专业程序员的话，他们也会竭尽所能的去追求和捍卫自身的目标。

你的经理要求你在明天之前完成登录页面，这就是他在追求和捍卫一个目标，那是尽他的工作职责。
如果你明知第二天之前不可能完成登录页面，嘴上却说“好的，我会试试的”，那便是你的失职了。
这时候，唯一的尽职方式便是说“不，这不可能”。

可是难道你不该照经理说的话去做吗？
当然不该，你的经理指望的是，你能像他那样竭尽所能的捍卫自己的目标。
这样你们俩才能得到可能的最好结果。
可能的最好结果，是你和你的经理共同追求的目标。
最关键的是要找到那个共同目标，而这往往有赖于协商。

或许你觉得Paula应该解释下为什么“登录页面”还要花那么长时间才能完成。
我的经验是，“为什么”远不如“事实”重要。
事实是，“登录页面”还需要两个星期才能完成。而为什么需要两个星期，则只是个细节。
有时候，提供太多细节，只会招致更多的微观管理。

最要说“不”的是那些高风险的关键时刻，越是关键时刻，“不”字就越具价值。
这一点应该不证自明，当公司存亡成败皆系于此时，你必须尽己所能，把最好的信息传递给你的经理。
这往往意味着要说“不”。

许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。
许诺“尝试”，意味着只要你再加把劲还是可以达成目标的，而且这也是一种表示你再接再厉去实现目标的承诺。
因此，只要你许诺自己会去“尝试”，你其实是在承诺你会确保成功。
这样，压力就要由你自己来扛了，如果你的“尝试”没有达成预期的结果，那就表示你失败了。

如果你此前并未有所保留，如果你没有新方案，如果你不会改变你的行为，如果你对自己原先的估计又充分的自信，那么从本质上讲，
承诺“尝试”就是一种不诚实的表现，你在说谎。
你这么做的原因，可能是为了护住面子和避免冲突。

尽管客户一再声明交付日期很重要，尽管他们对此表现得似乎非常迫切，但他们永远不会像你那样在乎应用程序的按时交付。
一切尘埃落定之后再想想，客户从始至终倒是说对了一件事：这个程序是“应急”的。

急于完成，却迟难面市：
（1）告诉开发人员这个应用很简单，这能误导整个开发团队进入一种错误的思维框架，还能让开发人员们更快开工。
（2）挑剔职责开发团队没能发现他们的需要，并借机添加各种功能。
（3）一而再的推后项目截止日期，在你已加班20小时把一切差不多都弄好时，他们又多给你几天时间，然后再加一周时间，好提出新的需求。

接受错误的决定，才是失败的真正根结，成功的唯一途径就是坚持专业行为。
委屈专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造更多的麻烦。

---

做出承诺，包含三个步骤：
（1）口头上说自己将会去做
（2）心里认真对待做出的承诺
（3）真正付诸行动

很少有人会认真对待自己说的话，并且说到做到。
有些人在说话时是认真的，但从来都不会说到做到。
而更多的人在做出承诺后，几乎从不会认真履行诺言。

更糟的是，我们常常会因为直觉摔跟头，有时我们轻信他人会说话算话说到做到，但事实上，他并没有像承诺的那么去做。
我们可能会相信某位开发人员所说的，他们能在一星期内完成原本两星期才能完成的任务，但其实他们是迫不得已才这么说的。
我们不能轻易相信此类承诺。

在承诺做某事时，应当留意自己的用词，因为这些用词透露了我们对待承诺的认真程度。
例如：需要/应当，希望/但愿，让我们，等等。
你会发现，我们有极力逃避承担责任的倾向。

识别真正的承诺的诀窍在于，要去搜寻与下列相似的语句：
我将在……之前……（如：我将在星期二之前完成这个任务。）
这句话的关键在哪里呢？你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。
那不是指别人，而是说的自己。
你谈的是自己会去做的一项行动，而且，你不是可能去做，或是可能做到，而是会做到。

如果最终目标依赖他人，那么你就应该采取些具体行动，接近最终目标。
即使目标无法完成，你仍能全力前进，离目标更近些。而弄清楚目标能否达到这件事，便是你可能采取的努力行动之一。
有些时候真的无能为力，有些事情先前你可能没预料到，但如果你希望自己能够不负众望，那就赶紧去调整别人对你的预期，越快越好。
如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好。
你越早向各利益相关方发送预警信号，整个团队就越有可能抓住机会，中止并重新评估当前的活动，并决定是否采取某些措施或做出些改变。（比如调整优先级等）
这么一来，你仍有可能达成之前的承诺，或者用另一个承诺代替先前的承诺。
如果你不尽早告诉他人可能的问题，就错失了让他们帮助你达成目标，兑现承诺的机会。

如果是专业开发人员，就不会放弃底线，多年的经验告诉我们，打破这些纪律和原则，必然会拖慢进度。
专业人士对自己的能力极限了如指掌，他们十分清楚自己还能保持效率加班多长时间，也非常明白要付出的代价。
如果自己加班的话，一定可以完成代码修改和文档编写的任务，但是在这之后的几天需要休整，才有精力回来继续工作。

---

能够感知到错误确实非常重要，不只对“录入”是这样，对于一切事情莫不如此。
具备“出错感知能力”，说明你已经能够非常迅速的获得反馈，能够更为快速的从错误中学习。

当你无法全神贯注的编码时，所写代码就可能出错。
代码中可能会存在不少错误，也可能会存在错误的结构，模糊晦涩，令人费解，无法解决客户的实际问题。
总之，最终你可能必须返工修改代码甚至重写，在心烦意乱的状态下工作，只会造成严重的浪费。
如果感到疲劳或者心烦意乱，千万不要编码。
强而为之，最终只能再回头返工。相反，要找到一种方法消除干扰，让心绪平静下来。

疲劳的时候，千万不要写代码，奉献精神和职业素养，更多意义上指要遵守纪律原则而非成为长时间工作的工作狂。
要确保自己已经将睡眠，健康和生活方式调整到最佳状况，这样才能做到在每天的8个小时工作时间内全力以赴。
焦虑的时候，根本就不应该编码，这时产生的代码都会是垃圾，这时应该先想办法解除焦虑情绪。

流态区，指的是程序员在编写代码时会进入的一种意识高度专注，但思维视野却会收拢到狭窄的状态。
在流态区，人们会感到效率极高，但其实没有顾忌全局，很可能会做出一些后来不得不推到重来的决策。

中断无法避免，总有干扰会打断你，消耗你的时间。
发生这种情况时要记住一点，也许下次也会轮到你去打断别人请求帮助。
因此，礼貌的表现出乐于助人的态度才是专业的态度。

结对是用以应对中断的一种好方法，当你接电话或回答其他同事的问题时，结对搭档能够维护住中断处的上下文。
另一种很有帮助的方法便是采用TDD，如果有一个失败的测试，它就能帮你维护住编码进度的上下文。

很久之前我已经明白这一点：“创造性输出”依赖于“创造性输入”。
我平时广泛阅读，不放过各种各样的资料。
包括软件，政治，生物，航天，物理，化学，数学，还有其他许多方面的资料。

出于某些原因，软件开发人员会认为调试时间并非编码时间，他们认为存在调试时间是天经地义的，调试不等于编码。
但是对于公司来讲，调试时间和编码时间是一样昂贵的。
因此，如果我们能够做些事情避免甚或消除调试活动，那是最为理想不过的。

不管是否采用TDD或其他一些同等效果的实践，衡量你是否是一名专业人士的一个重要方面，
便是看你是否能将调试时间尽量降到最低。

软件开发是一场马拉松，而不是短跑冲刺。
你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。
无论是赛前还是赛中，马拉松选手都会仔细调整好自己的身体状态。
专业程序员也会同样仔细的保存好自己的精力和创造力。

当碰到困难而受阻时，当你感到疲倦时，就离开一会，让富有创造力的潜意识接管问题。
精力分配得当，你将能在更短的时间内以更少的精力完成更多的事情。
让自己保持好节奏，让团队保持好节奏。
了解你的创造力和智力运行的模式，充分发挥它们的优势而非与之背道而驰。

管理延迟的诀窍，便是早期检测和保持透明。
最糟糕的情况是，你一直都在告诉每个人你会按时完成工作，到最后期限来临前你还在这样说，但最终你只能让他们大失所望。
不要这么做，相反，要根据目标定期衡量进度。

坚决坚持你的估算，你最初的估算比你在老板在面前时做出的任何调整估算都要准确的多。
告诉老板你已经考虑过所有情况，唯一能够加快进度的方法便是缩减范围。
不要经受不住诱惑盲目冲刺。
如果可怜的开发人员在压力之下最终屈服，同意尽力赶上截止日期，结局会十分悲惨。
那些开发人员会开始抄近路，会额外加班加点工作，抱着创造奇迹的渺茫希望。
这是制造灾难的最佳秘诀，因为这种做法给自己，给团队以及利益相关方带来了一个错误的期望。
这样每个人都可以避免面对真正的问题，把做出必要的艰难决定的时机不断后延。

其实，快速冲刺时做不到的。
你无法更快的写完代码。你无法更快的解决问题。
如果试图这么做，最终只会让自己变得更慢，同时也只能制造出一堆混乱，让其他人也慢下来。

加班确实有用，而且有时候也有必要。
有时候，通过一天工作10小时再加上周末加班一两天，你确实能够达成原本不可能的进度。
但这么做的风险也很高，在额外加班20%的工作时间内，其实你并无法完成20%的额外工作。
而且，如果连续两三个星期都要加班工作，则加班的措施必败无疑。

因此，不应该采用额外加班加单工作的方案，除非以下三个条件都能满足：
（1）你个人能挤出这些时间
（2）短期加班，最多加班两周
（3）你的老板要有后备预案，以防万一加班措施失败了
最后一条至为关键，如果老板无法向你清楚说明加班方案失败的后备预案，那么你就不应该同意接受加班方案。

在程序员所能表现的各种不专业行为中，最糟糕的是明知道还没有完成任务却宣称已经完成。
我们自欺欺人的认为任务已经完成得足够好，然后转入下一项任务。
我们自己给自己找借口说，其他还没来得及完成的工作可以等有更充裕时间的时候再来处理。
这种做法具有传染性，如果一名程序员这么做，其他程序员看见了一会效仿。

可以通过创建一个确切定义的“完成”标准来避免交付失误。
最好的方法是让业务分析师和测试人员创建一个自动化的验收测试，只有完全通过这些验收测试，开发任务才能算已经完成。

---

任何事情，要想做得快，都离不开练习。
尽可能快的重复编码/测试过程，要求你能迅速做出决定。
这需要识别各种各样的环境和问题，并懂得应付。

如果有两个习武者在搏斗，每个人都必须能够迅速识别出对方的意图，并且在百分之一秒内正确应付。
在搏斗时，你不可能有充足的时间来研究架势，思考如何应付。
这时候，你只能依靠身体的反应。
实际上，真正做出反应的是你的身体，大脑是在更高级的层面上思考。

无论如何，专业人士都需要练习。

---

我们把验收测试定义为业务方与开发方合作编写的测试，其目的在于确定需求已经完成。
验收测试都应当自动进行。
在软件开发周期中，确实有时候需要手动测试，但是验收测试不应当手工进行，原因很简单：要考虑成本。

验收测试是业务方写给业务方的（虽然可能最后是身为开发者的你来写），它们是正式的需求文档，描述了业务方认为系统应该如何运行。
关心验收测试结果的是业务方和程序员。
单元测试是写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。
关心单元测试结果的是程序员而不是业务人员。

这两种测试并不是重复劳动，它们的主要功能其实不是测试，测试只是它们的附属职能。
单元测试和验收测试首先是文档，然后才是测试。
他们的主要目的是如实描述系统的设计，结构，行为。

编写GUI的验收测试很麻烦，但如果把GUI当成API那样处理，而不是看成按钮，滚动条，格子，菜单，那验收测试就简单多了。
布局，格式，工作流，都会因为效率和美观的原因而变化，但是GUI背后的功能却不会因此变化。
测试系统功能时，应当调用真实的API，而不是GUI，测试程序应当直接调用GUI使用的API。
几十年来，设计专家一直教导我们，要把GUI和业务逻辑分开。
（注：GUI只是API的一层包装。

请务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。
整套持续集成系统应该由源代码管理系统来触发。
持续集成不应该失败，如果失败了，团队里的所有人都应该停下手里的活，看看如何让测试通过。

交流细节信息是件麻烦事，尤其是开发方和业务方交流关于程序的细节时，更是如此。
通常，各方握手言欢，以为其他人都明白自己的意思。
双方以为取得了共识，然后带着截然不同的想法离开，这种事太平常不过了。

要解决开发方和业务方沟通问题，我所知道的唯一有效的办法就是编写自动化的验收测试。
它们就是无可挑剔的需求文档。

---

预估不是一个定数，预估的结果是一种概率分布。
专业开发人员能够清楚区分预估和承诺，只有再确切知道可以完成的前提下，它们才会给出承诺。
此外，它们也会小心避免给出暗示性的承诺，他们会尽可能清楚的说明预估的概率分布，这样主管就可以做出合适的计划。

你可以根据3个数字预估某项任务，这就是三元分析法。
（1）O，乐观估计：这是非常乐观的数字。如果一切都异常顺利，你可以在这个时间内完成，概率小于1%。
（2）N，标称估计：这是概率最大的数字。
（3）P，悲观估计：这是最糟糕的数字。
有了以上三个预估，我们可以像下面这样描述概率分布：
（1）任务的期望完成时间为：μ=(O+4N+P)/6
（2）任务的概率分布的标准差：σ=(P-O)/6，用来衡量不确定性，如果这个数字越大，就表示非常不确定。

例子：
任务 乐观估计 标称估计 悲观估计 μ σ
alpha 1 3 12 4.2 1.8
beta 1 1.5 14 3.5 2.2
gamma 3 6.25 11 6.5 1.3
则，总的μ=4.2+3.5+6.5=14.2，总的σ=(1.8^2+2.2^2+1.3^2)^(1/2)=~3.13。
所以，任务大概需要14天完成，也可能需要17天（1σ），甚至是20天（2σ）。
3项任务最乐观的估计是5填，即便是按照标称估计，也需要10天，那么为什么需要14天或者17天甚至20天呢？
答案是，因为这个数字是把各个任务的不确定性叠加起来，让计划更加现实。
如果你是有几年经验的程序员，可能看过过于乐观的项目预估，它们最终花的时间是预估的3到5倍。

预估是非常容易出错的，所以才叫预估。
控制错误的方法之一是使用大数定律，该定律的意思是，把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确的多。
这样做之所以能提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。

专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。
但是大多数情况下，他们都不会做这种承诺，而是提供概率预估，来描述期望的完成时间及可能的变数。
对需要妥善对待的预估结果，专业开发人员与团队的其他人协商，以取得共识。

---

即使有压力，专业开发人员也会冷静果断，尽管压力不断增大，他仍然会坚持所受的训练和纪律，
他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法。

在压力下保持冷静的最好方式，便是规避会导致压力的处境。
应当避免对没有把握能够达成的最后期限做出承诺，这一点很重要。
业务方总是期望能够拿到这些承诺，因为他们想消除风险。
我们要做的就是使风险定量化并将它们陈述给业务方，这样他们就能做好相应准备。
做不切实际的承诺会阻碍目标的实现，对公司和个人都没好处。

有时有人会代我们做出承诺，发生这种事情，由于责任感我们必须主动帮助业务方找到方法来兑现这些承诺，但是一定不能接受这些承诺。
专业人士总会千方百计的帮助业务方找到达成目标的方法，但并不一定要接受业务方代为做出的承诺。
最终，如果我们无法兑现业务方所做出的承诺，那么该由当时做出承诺的人来承担责任。

快速前进确保最后期限的方法，便是保持整洁。
专业人士不会为了快点前进而乱来，他们明白“快速但脏乱”是自相矛盾的说法，脏乱只会导致缓慢。
让系统，代码和设计尽可能整洁，就可以避免压力。
这并非是说我们要花无穷无尽的时间去清理代码，而只是说不要容忍混乱。
混乱会降低速度，导致工期延误，承诺失信，因此，要尽力保持输出成果整洁干净。

观察自己在危机时刻中的反应，就可以了解自己的信念。
如果在危机中依然遵循着你守持的几率，就说明你确实相信那些纪律。
反过来说，如果在危机中改变行为，就说明你并不真正相信常规行为中的原则。
如果你在非危机时刻你会遵循测试驱动开发的纪律，但是在危机时刻你放弃了这种做法，这说明你并不真正相信TDD是有帮助的。
如果在平常时候你会注意保持代码整洁，但在危机时刻你却会产出混乱的代码，这说明你并不真正相信混乱会导致速度下降。
如果在危机时刻你会结对编程，但平时却不结对，就说明你相信结对工作比不结对更有效率。

选择那些你在危机时刻依然会遵循的几率原则，并且在所有工作中都遵守这些纪律。
遵守这些纪律原则是避免陷入危机的最好途径。
当困境降临时，也不要改变行为。

---

专业程序员的首要职责是满足雇主的需求，这意味着要和你的经理们，业务分析师们，测试工程师们和其他团队成员更好的写作，深刻理解业务目标。
专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问。
你的工作职责就是要让业务免于陷入困顿，让公司可以长久发展下去。
因此，专业程序员会花时间去理解业务，他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。
简而言之，他们会将注意力放在如何与业务同舟共济上。

不正常的团队最糟糕的症状是，每个程序员在自己的代码周边筑起一道高墙，拒绝让其他程序员接触到这些代码。
我曾在许多地方看到过，不少程序员甚至不愿让其他程序员看见他们的代码，这是招致灾难的“最佳秘诀”。

许多程序员都不喜欢“结对编程”这一理念。但很奇怪，在紧急情况下，大多数程序员又愿意结对编程。为什么呢？
很显然，因为这是解决问题最有效的方法。

如果我们真想终生能以编程度日，那么一定要学会交流，和人们交流。

---

形成团队是需要时间的，团队成员需要首先建立关系。
他们需要学习如何互相协作，需要了解彼此的癖好，强项，弱项，最终，才能凝聚成团队。
有凝聚力的团队通常由大约12名成员，最多的可以有20人，最少可以只有3个人，但是12个人是最好的。
这个团队应该配有程序员，测试人员和分析师，同时还要有一名项目经理。
由12个人组成的理想团队，人员配备情况是这样的，7名程序员，2名测试人员，2名分析师，1名项目经理。

分析师开发需求，为需求编写自动化验收测试。
测试人员也会编写自动化验收测试，但是他们两者的视角是不同的。
分析师关注业务价值，而测试人员关注正确性。
项目经理跟踪项目团队的进度，确保团队成员理解项目时间表和优先级。
其中一名团队成员可能会拿出时间充任团队教练或Master的角色，负责确保项目进展，监督成员遵守纪律。

银行和保险公司试图围绕项目来构建团队，这是一种愚蠢的做法。
按照这种做法，团队永远都不可能形成凝聚力，每个人都只在项目中短期停留，只有一部分时间是在为项目工作，因此他们永远都学不会如何默契配合。
专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕项目来组建团队。

团队比项目更难构建，因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是较好的做法。

---

计算机科班毕业生的质量一直令我颇感失望。究其原因，并不是这些毕业生不够聪明或缺乏天份。
而是由于大学并没有教授真正的编程之道。

我注意到，那些符合要求的毕业生有个共同点，他们几乎都在进入大学之前就已经自学编程，并且在大学里依然保持自学的习惯。

学校能够传授的是计算机编程的理论，但是学校并不会也无法传授作为一名编程匠者所需掌握的原则，实践和技能。
这些东西只有经由师徒个体间多年的细心督导和辅导才能获得。
软件行业中像我们这样的一批人必须要面对这一事实，即指引下一代软件开发人员成熟起来的重任无法寄希望于大学教育，
现在这个重任已经落到了我们肩上。
建立一种包含学徒期，实习期和长期指引的机制已是迫在眉睫。

主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？
吾以此知胜负矣。

双方君主哪一方施政清明，有道？将领哪一方更有才能？
天时，地利哪一方占得多？军中法令哪一方执行得好？
兵力哪一方更强大？士兵哪一方更训练有素？
奖赏与惩罚哪一方更严明？
我凭着对这些情况的分析比较，就可以知道战争胜负的情形了。

---

将听吾计，用之必胜，留之；将不听吾计，用之必败，去之。

如果您能接受我的军事**，任用我领兵作战一定胜利，我就留下。
如果您不能接受我的军事**，用我领兵作战必定失败，我就离开。

---

兵者，诡道也。
故能而示之不能，用而示之不用，近而示之远，远而示之近；
利而诱之，乱而取之，实而备之，强而避之，怒而挠之，卑而骄之，佚而劳之，亲而离之。
攻其无备，出其不意。
此兵家之胜，不可先传也。

用兵，是以诡诈为原则的。
因而，『能』要使敌人看成『不能』，『用』要让敌人看作『不用』，
『近』要让敌人看做『远』，『远』要让敌人看做『近』，
敌人贪利，就诱之以利而消灭它；敌人混乱，就抓紧时机立刻消灭它；
敌人实力雄厚，则须时刻戒备它；敌人精锐强大，就要注意避开它的锋芒；
敌人煸急易怒，就挑逗它，使它失去理智；敌人小心谨慎，稳扎稳打，就设法使它骄傲起来；
敌人内部和睦，就离间其关系。
在敌人没有准备的情况下进攻，在敌人意想不到的条件下出击。
这些，是军事家用兵之佳妙奥秘，是不可事先规定或说明的。

---

其用战也胜，久则钝兵挫锐，攻城则力屈，久暴师则国用不足。
夫钝兵挫锐，屈力殚货，则诸侯乘其弊而起，虽有智者不能善其后矣。
故兵闻拙速，未睹巧之久也。夫兵久而国利者，未之有也。
故不尽知用兵之害者，则不能尽知用兵之利也。

用兵打仗就要做到胜任裕如，举兵必克。
否则，长久僵持，兵锋折损，锐气被挫，攻城就力竭，长期陈兵国外则国内资财不足。
如果兵锋折损，锐气受挫，兵力耗尽，财政枯竭，那么其他诸侯国就会趁这个困顿局面举兵进攻，
即使睿智高明的人也难以收拾好这个局面。
用兵打仗，只听说计谋不足但靠神速取胜的，没有听说有计谋却要拖延战争时日的。
战争时间长而对国家有利这种事，从来就没有过。
因此，不能全面了解战争害处的人，也就不能真正懂得战争的有利之处。

---

故智将务食于敌，食敌一钟，当吾二十钟；芑杆一石，当吾二十石。

高明的将领务求从敌方夺取粮草。
就地从敌方夺取粮食一钟，相当于自己从本国运出二十钟；
就地夺取敌人饲草一石，相当于自己从本国运出二十石。

---

故杀敌者，怒也；取敌之利者，货也。
车战得车十乘以上，赏其先得者而更其旌旗。
车杂而乘之，卒善而养之，是谓胜敌而益强。

激励士卒奋勇杀敌，是使之威怒；
鼓励将士夺取敌人资财，要用财物奖励。
因此在车战中，凡缴获战车十辆以上的，奖赏那先夺得战车的士卒，
并且更换敌战车上的旌旗，将其混合编入自己的车阵之中。
对于俘虏，则予优待，抚慰，任用他们作战。
这就是战胜敌人而使自己日益强大。

---

故兵贵胜，不贵久。

用兵作战以胜任裕如，举兵必克为贵，不主张力不从心，僵持消耗。

---

是故百战百胜，非善之善者也；不战而屈人之兵，善之善者也。

百战百胜，并非好的用兵策略中最好的，
不交战而使敌屈服，才是用兵策略中最好的。

---

故上兵伐谋，其次伐交，其次伐兵，其下攻城。攻城之法，为不得已。

最好的用兵策略是以谋略胜敌，其次是以外交手段胜敌，
再其次是通过野战交兵胜敌，最下等的是攻城。

---

故善用兵者，屈人之兵而非战也，拔人之城而非攻也，毁人之国而非久也，必以全争于天下，
故兵不顿，而利可全，此谋攻之法也。

善于用兵的人，使敌军屈服而不用野战交兵的办法，
夺取敌城不用蚁附攻城的办法，消灭敌国而不用长久用兵的办法。
一定本着不诉诸兵力就使敌完整的屈服的原则争横天下，
做到军队不受挫而胜利可全得，这便是谋攻的原则。

---

故知胜有五：
知可以战与不可以战者胜；
识众寡之用者胜；
上下同欲者胜；
以虞待不虞者胜；
将能而君不御者胜。
此五者，知胜之道也。

预测胜负有五条：
懂得什么条件下可以战，什么条件下不可以战的，胜；
懂得众与寡的灵活运用的，胜；
上下一心，同仇敌忾的，胜；
以有准备之师击无准备之敌的，胜；
将领富于才能而君主又不从中干预牵制的，胜。
这五条就是预知胜负的途径。

---

故曰：知彼知己，百战不殆；
不知彼而知己，一胜一负；
不知彼,不知己，每战必殆。

可以说：了解对方也了解自己的，百战不败；
不了解对方而了解自己的，胜负各半；
不了解对方，也不了解自己的，每战必败。

---

孙子曰：昔之善战者，先为不可胜，以待敌之可胜。
不可胜在己，可胜在敌。
故善战者，能为不可胜，不能使敌之必可胜。
故曰：胜可知，而不可为。

孙子说：古代善于指挥作战的人，总是先创造条件使自己处于不可战胜的地位，
然后等待敌人能被我战胜的时机。
做到不可战胜，关键在于自己创造充分的条件；
可以战胜敌人，关键在于敌人出现可乘之隙。
因而，善于作战的人，能做到自己不可战胜，不能使敌人一定被我战胜。
所以说，胜利可以预测，但不可强求。

---

不可胜者，守也；可胜者，攻也。
守则不足，攻则有余。

有了不可战胜的条件，就可以守；
地方出现了可胜之隙，就可以攻；
守，应依靠自己不可战胜，力有裕如；
攻，要针对地方弱点，不足，举兵必克。

---

古之所谓善战者，胜于易胜者也。
故善战者之胜也，无智名，无勇功，故其战胜不忒，不忒者，其所措必胜，胜已败者也。
故善战者，立于不败之地，而不失敌之败也。
是故胜兵先胜而后求战，败兵先战而后求胜。
善用兵者，修道而保法，故能为胜败之政。

古代善战的人，总是取胜于容易取胜的敌人。
因而，这些善战者的胜利，既没有智谋的名声，也没有勇武的功劳。
他所进行的战争的胜利是不会有丝毫误差的，
之所以没有误差，是因为他们所进行的战斗举动是必胜的，
是战胜那已处于失败地位的敌人。
善于作战的人，总是自己先立于不败之地，而不放过任何一个打败敌人的时机。
因此，胜利之师是先具备必胜的条件然后再去交战，
失败之师总是先同敌人交战，然后期求从苦战中侥幸取胜。
善于用兵的人，总是注意修明政治，确保治军法度，所以能成为战争胜负的主宰。

---

故善战者，求之于势，不责于人，故能择人而任势。

高明的指挥员，总是从自己造『势』中去追求胜利，而不苛求部下以苦战取胜。
因而，他能恰当的选择人材巧妙的任用『势』。

---

故善战者，致人而不致于人。

善于指挥作战的人，总是设法调动敌人而自己不为敌人所调动。

---

进而不可御者，冲其虚也；
退而不可追者，速而不可及也。
故我欲战，敌虽高垒深沟，不得不与我战者，攻其所必救也；
我不欲战，画地而守之，敌不得与我战者，乖其所之也。

进攻而地方不可抵御，那是冲击在敌人的薄弱环节；
撤退而敌人不可追及，那是行动神速，敌人追之不及。
我想与敌交战，虽然敌人高筑防御工事也不得不出来与我交战，
是因为我攻击它必然要救援的地方；
我不想同敌交战，只要在地上画个界线便可守住，敌人无法与我交锋，
是因为我设法调动它，使它背离所要进攻的方向。

---

故形人而我无形，则我专而敌分。
我专为一，敌分为十，是以十攻其一也，则我众而敌寡；
能以众击寡者，则吾之所与战者，约矣。
吾所与战之地不可知，不可知，则敌所备者多；
敌所备者多，则吾所与战者，寡矣。
故备前则后寡，备后则前寡，备左则右寡，备右则左寡，无所不备，则无所不寡。
寡者，备人者也；众者，使人备己者也。

示敌以假像而我不露真情，那么，我就可以集中兵力而敌势必分散兵力。
我集中兵力为一处，敌分散兵力为十处，这就形成局部的以十防一的态势，
那么我就兵力众多而敌人就兵力寡少了。
能以众多兵力对付寡少兵力，与我交战的敌人就陷入困境了。
我与敌交战的地点敌人不知道，那么敌人防备的方面就多，在局部与我交战的敌兵就少了。
着重防备前方，后方就薄弱；着重防备后方，前方就薄弱；
着重防备左翼，右翼就薄弱；着重防备右翼，左翼就薄弱；
无处不防备，那就无处不薄弱。
造成兵力薄弱的原因就是处处设防，形成兵力集中的优势在于迫使敌人处处防备。

---

故形兵之极，至于无形。
无形，则深间不能窥，智者不能谋。
因形而错胜于众，众不能知；
人皆知我所以胜之形，而莫知吾所以制胜之形。
故其战胜不复，而应形于无穷。

以假像迷惑敌人的用兵方法运用到极致程度，就会不露一丝真迹，使人无形可窥。
那么，即使埋藏很深的间谍也不能窥测到实情，即使很有智谋的人也无法设谋。
通过以假像迷惑敌人的『示形』方法取得胜利放置在众人面前，众人不能了解其中的因由。
众人都知道我取胜的外在作战状况，而没有谁了解我导致胜利所用的内在方略。
因而，我取胜的谋略方法不重复，而随着敌情变化所采取的应变『示形』方法是无穷无尽的。

---

水因地而制流，兵因敌而制胜。故兵无常势，水无常形，能因敌变化而取胜者，谓之神。

水流根据地形决定流向，用兵根据敌情采取致胜方略。
战争无固定不变的态势，流水无固定不变的流向。
能随着敌情发展变化而采取灵活变化的措施取胜的人，才称得上是神秘莫测的高明者。

---

故用兵之法，高陵勿向，背丘勿逆，佯北勿从，锐卒勿攻，
饵兵勿食，归师勿遏，围师遗阙，穷寇勿迫，此用兵之法也。

用兵的原则是：占据高地的敌人，不要去仰攻；
背靠山丘的敌人，不要去迎击；
假装败退的敌人，不可跟踪追赶；
精锐的敌军，不要去进攻；
充当诱饵的小部队，不要去吃掉；
回撤的敌人，不要去遏止；
包围敌人要网开一面；
陷入绝境的敌人，不可逼迫太甚。
这些都是用兵的原则啊。

---

途有所不由，军有所不击，城有所不攻，地有所不争，君命有所不受。
故将通于九变之地利者，知用兵矣；
将不通于九变之利者，虽知地形，不能得地之利者矣。
治兵不知九变之术，虽知五利，不能得人之用矣。

有的道路不宜通过，有的敌军可以不击，有的城邑可以不攻，
有的地盘可以不争，甚至国君的命令有的也可以不接受。
将领能通晓灵活机变的好处的，就算懂得用兵了。
将领不通于灵活机变的好处，即使了解地形，也不能得到地利。
治军不了解机变的权术，即使懂得『有的道路不宜通过』等『五利』，
也不能充分发挥士卒们最大的战斗能力和作用。

---

是故智者之虑，必杂于利害。
杂于利，而务可信也；杂于害，而患可解也。

高明的将领考虑问题，一定兼顾利与害两个方面。
在不利的条件下看到有利的一面，事情就可以顺利进行。
在有利的条件下看到不利的因素，祸患便可及早解除。

---

故用兵之法，无恃其不来，恃吾有以待也；无恃其不攻，恃吾有所不可攻也。

打仗的原则是：不要寄希望于敌人不来，而要依靠自己有充分的准备，严阵以待。
不要寄希望于敌人不会进攻，而要依靠自己有敌人不可攻破的条件。

---

故将有五危：
必死，可杀也；必生，可虏也；
忿速，可侮也；廉洁，可辱也；
爱民，可烦也。
凡此五者，将之过也，用兵之灾也。
覆军杀将必以五危，不可不察也。

将领有五个方面的性格偏执是危险的：
勇而无谋，一味死拼，可以诱杀；
贪生怕死，畏葸疑惧，可以俘获；
浮躁易怒，刚忿偏急，可以凌侮；
矜于名节，可以污辱；
过于仁慈，可予烦扰。
大凡这五个方面，都是将领素质上的缺陷，是用兵的大害。
全军覆没，将领被杀，一定因为这五个方面的危险因素，因而，不能不看清这个道理啊。

---

辞卑而益备者，进也；辞强而进驱者，退也。

敌人使者措辞谦卑却又在加紧战备的，是准备进攻；
措辞强硬而军队又做出前进姿态的，是准备撤退。

---

兵非益多也，惟无武进，足以并力、料敌、取人而已。
夫惟无虑而易敌者，必擒于人。
卒未亲附而罚之，则不服，不服则难用也。
卒已亲附而罚不行，则不可用也。
故令之以文，齐之以武，是谓必取。
令素行以教其民，则民服；令不素行以教其民，则民不服。
令素行者，与众相得也。

打仗不在于兵力越多越好，只要不轻敌冒进，并集中兵力，判明敌情，取得部下的信任和支持，也就足够了。
那种既无深谋远虑而又轻敌的人，必定会被敌人俘虏。
士卒还没有亲近依附就执行惩罚，那么他们会不服，不服就很难使用。
士卒已经亲近依附，如果不执行军纪军法，也不能用来作战。
所以，要用怀柔宽仁使他们**统一，用军纪军法使他们行动一致，这样就必能取得部下的敬畏和拥戴。
平素严格贯彻命令，管教士卒，士卒就能养成服从的习惯；
平素从来不严格贯彻命令，管教士卒，士卒就会养成不服从的习惯。
平时命令能贯彻执行的，表明将帅同士卒之间相处融洽。

---

故战道必胜，主曰无战，必战可也；战道不胜，主曰必战，无战可也。
故进不求名，退不避罪，唯人是保，而利合于主，国之宝也。

根据分析有必胜把握的，即使国君主张不打，坚持打也是可以的；
根据分析没有必胜把握的，即使国君主张打，不打也是可以的。
所以，战不谋求胜利的名声，退不回避失利的罪责，只求保全百姓，符合国君利益，
这样的将帅，才是国家的宝贵财富。

---

夫吴人与越人相恶也，当其同舟而济，遇风，其相救也如左右手。
是故方马埋轮，未足恃也；齐勇若一，政之道也；刚柔皆得，地之理也。
故善用兵者，携手若使一人，不得已也。

吴人与越人是相互仇视的，当他们同船过渡突遇大风时，他们相互救助起来如同左右手。
因此，缚马埋轮，是不足以倚恃的稳定军阵的办法；
三军严整，勇敢如一人，靠的是治军有方；
勇敢的人和怯弱的人都得以发挥其战斗力，靠的是巧妙的运用地形。
古代善于用兵的人，能使部队携手如同一个人一样服从指挥，是将部队置于不得已的情况下形成的。

---

将军之事：静以幽，正以治。
能愚士卒之耳目，使之无知。
易其事，革其谋，使人无识；易其居，迂其途，使人不得虑。
帅与之期，如登高而去其梯；帅与之深入诸侯之地，而发其机，焚舟破釜，若驱群羊，驱而往，驱而来，莫知所之。
聚三军之众，投之于险，此谓将军之事也。
九地之变，屈伸之利，人情之理，不可不察。

统帅军队这种事，要沉着镇静而幽密深邃，公平严正而整肃有方，
能蒙蔽士卒的耳目，使他们无知。常改变所行之事，常变更所设之谋，使人无法识破用意；
驻扎常变地方，行军常迂回绕道，使人无法捉摸真实意图。
将帅给部队下达战斗命令，像登高抽去梯子一样，使士卒有进无退；
将帅与士卒深入诸侯重地，捕捉战机，发起攻势，焚舟毁桥，砸烂锅灶，像驱赶群羊一样，
赶过去，赶过来，没有谁明白到底要到哪里去。
聚集三军之众，将他们至于危险的境地，这就是领兵作战的职责。
各种地形的灵活运用，攻守进退的利害关系，士卒在不同环境中的心理变化规律，不得不认真加以考察。

---

故兵之情，围则御，不得已则斗，过则从。

士兵的心理变化规律是：被包围就会合力抵御，不得已时就会殊死奋战，陷于深重危难境地就非常听从指挥。

---

犯之以事，勿告以言；犯之以利，勿告以害。
投之亡地然后存，陷之死地然后生。夫众陷于害，然后能为胜败。
故为兵之事，在于顺详敌之意，并敌一向，千里杀将，此谓巧能成事者也。

授以任务，不说明意图；告诉他有利的条件，不告诉他危险的一面。
把士卒投入危亡境地，才能主动的奋力夺取胜利。
领兵作战这件事，就在于假装顺着敌人的意图，我则集中精锐兵力指向敌人一处，
哪怕奔袭千里也可斩杀敌将，这便是通常说的机智能成就大事。

---

非利不动，非得不用，非危不战。
主不可以怒而兴师，将不可以愠而致战；合于利而动，不合于利而止。

不是于国有利就不要采取军事行动，没有必胜的把握就不要用兵，
不是处于危险境地不要交战。
君主不可因为一时愤怒而发动战争，将领也不能因为一时恼火而命令作战。
合于国家长远利益就行动，不合符国家长远利益就停止。

---

故明君贤将，所以动而胜人，成功出于众者，先知也。
先知者，不可取于鬼神，不可象于事，不可验于度，必取于人，知敌之情者也。

英明的君主，贤能的将帅，之所以动辄就能取胜敌人，成功高于一般的人，
就在于他们事先了解敌情。
要事先了解敌情，不可从鬼神取得，不可从往事中去类比，也不能用度数去应验，
一定只能从人的口中得知，这种人，就是了解敌情的人。

---

故惟明君贤将，能以上智为间者，必成大功。
此兵之要，三军之所恃而动也。

明君贤将中，能够以很有智谋的人做间谍，必定成就大功。
这是军事的要点，是军队行动的依靠。

编程很有乐趣，但开发高质量的软件却是困难的。
从好的观点，需求或“构想”开始，到最终变成一个实际运行的软件产品，
所需要的不仅仅是编码这一项工作。

分析和设计，定义如何解决问题，需要对哪些内容编程，
用易于交流，评审，实现和演化的多种方式来获取这个设计，这正是本书的核心所在。

如果没有软件工程过程作为背景，软件设计就显得有些枯燥和神秘。
Craig Larman加入并介绍了统一过程UP（Unified Process），
并介绍如何以一种相对简单和实际的方式来应用统一过程。

通过在一个迭代的，风险驱动的，以架构为中心的过程中介绍案例研究，
揭示了软件开发中实际的动态发展，并分析外部作用的影响。
设计活动与其他任务相关，它们不再是一个纯粹的系统化转换或使用创造性直觉的脑力活动。

设计模式表达了面向对象设计专家用于创建系统的“最佳实践”的习惯用法和方案。

UML并不是OOA/D，也不是方法，它只是图形表示法。
如果没有真正掌握如何创建优秀的面向对象设计，或者如何评估和改进现有设计，
那么学习UML或者UML CASE工具是毫无意义的。
对象**才是重点和难点。

我们需要一种用于OOA/D和“软件蓝图”的语言，
这既是思考的工具，也是一种沟通的形式。

在OO开发中，至关重要的能力是熟练的为软件对象分配职责。

分析是强调对问题和需求的调查研究，而不是解决方案。
设计强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。
最终，设计可以实现，而实现（如代码）则表达了真实和完整的设计。

有益的分析和设计可以概括为：做正确的事（分析）和正确的做事（设计）。

关键步骤：
（1）定义用例
（2）定义领域模型
（3）定义交互图
（4）定义设计类图

在面向对象分析（OOA: object-oriented analysis）过程中，强调的是在问题领域内发现和描述对象（或概念）。
在面向对象设计（OOD: object-oriented design）过程中，强调的是定义软件对象以及它们如何协作以实现需求。
最后，在实现或面向对象程序设计过程中，会实现设计出来的对象。

需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例（use case）。
用例是需求分析中的一个常用工具。

面向对象分析的结果可以表示为领域模型（domain model），在领域模型中展示重要的领域概念或对象。
领域模型并不是对软件对象的描述，它使真实世界领域的概念和想象可视化。
因此，它也被称为概念对象模型（conceptual object model）。

面向对象设计关注软件对象的定义——它们的职责和协作。
顺序图（sequence diagram）是描述协作的常见表示法。
它展示出软件对象之间的消息流，和由消息引起的方法调用。

除了在交互图中显示对象协作的动态视图外，还可以使用设计类图（design class diagram）来有效的表示类定义的静态视图。
这样可以描述类的属性和方法。

领域模型表示的是真实世界的类，设计类图表示的是软件类。
（注：先用领域模型为真实世界建立对象模型（数学模型），再用设计类图中的软件类表达它。
（领域模型和设计类图是不同的概念，但是都可以用UML可视化的表示。

统一建模语言（UML）是描述，构造和文档化系统制品的可视化语言。
在UP（统一过程）中，领域模型中的UML框被称为领域概念（或概念类），领域模型表示的是概念透视图。
设计模型中的UML框被称为设计类，设计模型一句建模者的需要，表示的是规格说明透视图或实现透视图。

概念类：现实世界中的概念或事物。
软件类：软件构件在规格说明或实现透视图中的类。
实现类：特定OO语言中的类。

“没有银弹”指的是，不存在某种特殊的工具或技术，可以在生产率，缺陷减少，可靠性和简易性等方面给软件带来极大的变化。
工具无法弥补设计上的疏漏。

UML仅仅是标准的图形化表示法，例如框，线等。
使用常用符号的可视化建模能够带来极大的帮助，但它不可能与设计和对象**同等重要。
设计知识是极不寻常的且更为重要的技能，它并不是通过学习UML表示法或者CASE或MDA工具就可以掌握的。
如果不具备良好的OO设计和编程技能，那么即使使用UML，也只能画出拙劣的设计。

软件开发过程，描述了构造，部署以及维护软件的方式。
统一过程已经成为了一种流行的面向对象系统的迭代软件开发过程。

UP是十分灵活和开放的，并且鼓励引进其他迭代开发方法中的有用的实践，诸如极限编程（Extreme Programming, XP），Scrum等等。
例如，在UP项目中可以引入XP的测试驱动开发，重构，持续集成等实践。
同样，也可以引入Scrum的公共项目室（“作战室”）和Scrum日常会议等实践。

UP把普遍认可的最佳实践（如迭代生命周期和风险驱动开发）结合起来，成为联系紧密并具有良好文档的过程描述。

迭代开发（iterative development）是UP和大多数其他现代方法中的关键实践。
在这种生命周期方法中，开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代。
每次迭代都产生经过测试，集成并可执行的局部系统。
每次迭代都具有各自的需求分析，设计，实现和测试活动。
迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。
随着时间和一次又一次迭代的递进，系统增量式发展完善，因此这一方法也被称为迭代和增量式开发。
因为反馈和调整使规格说明和设计不断进化，所以这种方法也称为迭代和进化式开发。

UP提倡风险驱动与客户驱动相结合的迭代计划。
这意味着早期的迭代目标要能够识别和降低最高风险，并且能构造客户最关心的可视化特性。
风险驱动迭代开发更为明确的包含了以架构为中心迭代开发的实践，
意味着早期迭代要致力于核心架构的构造，测试和稳定。
为什么？因为没有稳固的架构就会带来高风险。

敏捷开发方法通常应用时间定量的迭代和进化式开发，使用自适应计划，
提倡增量交付并包含其他提倡敏捷性（快速和灵活的响应变更）的价值和实践。
由于特定实践多种多样，因此不可能精确的定义敏捷方法。
然而，具备进化式精化的计划，需求和设计的短时间定量迭代是这些方法所共有的基本实践。

Scrum敏捷方法中的实践范例包括公共项目工作室和自组织团队，
这些实践通过每日例行会议来协调工作，在例会上要求每位成员回答四个特定问题。
极限编程方法中的实践范例包括结对编程和测试驱动开发。

建模（构建UML草图……）的目的主要是为理解，而非文档。
建模的真正行为能够并且是应该能够对理解问题或解决方案空间提供更好的方式。
从这个角度而言，“实行UML”（或“实行OOA/D”）的目的并不是指设计者创建大量详细的UML图并递交给编程者（这其实是非敏捷和面向瀑布的思维方式），
而是指为良好的OO设计快速探索可选的方案和途径。

UP项目将其工作和迭代组织为四个主要阶段：
（1）初始：大体上的构想，业务案例，范围和模糊评估。
（2）细化：已精化的构想，核心架构的迭代实现，高风险的解决，确定大多数需求和范围以及进行更为实际的评估。
（3）构造：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
（4）移交：进行beta测试和部署。

需求，就是系统（或者项目）必须提供的能力和必须遵从的条件。
UP提出了一系列的最佳实践，其中之一就是需求管理。
需求管理部主张采用瀑布的观点，即在编程之前项目的第一个阶段就试图完全定义和固化需求。
在变更不可避免，涉众意愿不明朗的情况下，UP更推崇用“一种系统的方法来寻找，记录，组织和跟踪系统不断变更的需求”。

需求分析的最大挑战是寻找，沟通和记住（通常是记录）什么是真正需要的，并能够清楚的讲解给客户和开发团队的成员。
UP能够包容需求中的变更，并将其作为项目的基本驱动力。

在统一过程中，需求按照“FURPS+”模型进行分类：
（1）功能性：特性，功能，安全性
（2）可用性：人性化因素，帮助，文档
（3）可靠性：故障频率，可恢复性，可预测性
（4）性能：响应时间，吞吐量，准确性，有效性，资源利用率
（5）可支持性：适应性，可维护性，国际化，可配置性。

任何提出“尽可能定义大多数需求，然后再进行设计和实现”的建议，都与迭代进化式开发和UP的**相悖。

用例（use case）就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。
用例强调了用户的目标和观点，“谁使用系统？他们使用的典型场景是什么？他们的目的是什么？”。
用例就是需求，主要是说明系统如何工作的功能性或行为性需求。
用例的主要**是：为功能性需求编写用例，从而降低详细的老式特性列表的重要性或减少这种列表的使用。

黑盒用例，是最常见和推荐使用的类型，它不对系统内部工作，构件或设计进行描述。
反之，它以通过职责来描述系统，这是面向对象**中普遍统一的隐喻主题——软件元素具有职责，并且与其他具有职责的元素进行协作。
通过使用黑盒用例定义系统职责，人们可以规定系统必须做什么（行为和功能性需求），而不必决定系统如何去做（设计）。
实际上，“分析”和“设计”的区别就在于“什么”和“如何”的差异。
这是在优秀软件开发中的重要主题：在需求分析中应避免进行“如何”的决策，而是规定系统的外部行为，就像黑盒一样。
此后，在设计过程中，创建满足该规格说明的解决方案。

发现用例的基本过程：
（1）选择系统边界
（2）确定主要参与者
（3）确定每个主要参与者的目标
（4）定义满足用户目标的用例，根据其目标对用例命名
当然，在迭代和进化式开发中，在开始阶段不必完整或准确的定义所有目标和用例，这是不断深入发掘的过程。

在开始用例建模时，首先要询问的是“谁来使用系统，他们的目标是什么？”
而非“系统的任务是什么？”

初学者通常会犯的错误是，将用例图和用例关系作为当务之急，而不是编写文本。
Flower和Cockburn等世界级的用例专家都对用例图和用例关系不予重视，而是注重编写文本。
用例图是一种优秀的系统语境图，也就是说，用例图能够展示系统边界，位于边界之外的事物以及系统如何被使用。
用例驱动设计，小组设计协作对象和子系统是为了执行或实现用例。

领域模型，是对领域内的概念类或现实世界中对象的可视化表示。
领域模型也称为概念模型，领域对象模型和分析对象模型。
在UP中，术语“领域模型”指的是对现实世界概念类的表示，而非软件对象的表示。

面向对象开发者在创建软件类时，受到真实世界领域的启发。
因此，涉众所设想的领域与其在软件的表示之间的表示差异被降低。

在对领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性。

没有所谓唯一正确的领域模型，所有模型都是对我们试图要理解的领域的近似。
领域模型主要是在特定群体中用于理解和沟通的工具，
有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息，并且可以帮助人们理解领域的概念，术语和关系。

逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间），子系统和层等。
之所以称其为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署（后一种决定是部署架构的一部分）。

领域层与应用逻辑层：领域对象
典型的软件系统都有UI逻辑和应用逻辑，例如GUI窗口小部件的创建和税金计算。
现在关键问题是，我们如何使用对象设计应用逻辑？
我们可以创建一个称为XYZ的类，然后将所有方法置入其中，以实现所有需要的逻辑。
这一方法在技术上是可行的（尽管在理解和维护上有较大困难），但是OO**并不提倡这种方法。
那么提倡的方法是什么呢？答案是：
创建软件对象，使其名称和信息类似于真实世界的领域，并且为其分配应用逻辑职责。
这种软件对象称为领域对象，领域对象表示问题领域空间的事物，并且与应用或业务逻辑相关。
以这种方式设计对象，则可以将应用逻辑层更准确的称为架构的领域层，即包含领域对象，处理应用逻辑的层。

另一个关键问题是，领域层和领域模型之间具有怎样的关系。
我们着眼于领域模型（将重要的领域概念的可视化）以获取对领域层类命名的灵感。
领域层是软件的一部分，领域模型是概念角度分析的一部分，它们是不同的。
但是利用来自领域模型的灵感创建领域层，我们可以获得在实现世界和软件设计之间的低表示差异。
（注：领域模型是真实世界的对象模型，领域对象是用软件类表示的软件对象。

应该花费时间使用交互图进行动态对象建模，而不仅是使用类图进行静态对象建模。
应该把时间花费在交互图（顺序图或通信图），而不仅是类图上。
忽视这一原则是十分常见的UML错误实践。

UML使用交互图来描述对象间通过消息的交互。
交互图可以用于动态对象建模，交互图有两种类型，顺序图和通信图。
大部分UML初学者知道类图，并且通常认为类图是OO设计中唯一重要的图形，但实际上并非如此。
尽管静态视图类图确实有效，但动态视图的交互图（更确切的说是动态交互建模中的“动作”）的价值更高。
因为当我们要考虑真正的OO设计细节时，就必须要“落实”发送哪些消息，发送给谁，以何种顺序发送等具体问题。

UML使用类图表示类，接口及其关联，类图用于静态对象建模。

思考软件对象设计以及大型构件的流行方式是，考虑其职责，角色和协作。
这是被称为职责驱动设计（RDD）的大型方法的一部分。
在RDD中，我们认为软件对象具有职责，即对其所作所为的抽象。
UML把职责定义为“类元的契约或义务”。

RDD是思考OO软件设计的一般性隐喻。
把软件对象想象成具有某种职责的人，他要与其他人协作以完成工作。
RDD使我们把OO设计看做是有职责对象进行协作的共同体。

极限编程所提倡的重要测试实践是：首先编写测试。
它还提倡不断的重构代码以改进质量，包括降低冗余，提高清晰度等。

重构是重写或重新构建已有代码的结构化和规律性方法，但不会改变已有代码的外在行为，
而是采用一系列少量转换的步骤，并且每一步都结合了重新执行的测试。
重构的本质是一次实行一小步保留行为的转换。
每次转换之后，要重新执行单元测试，以保证重构不会导致错误。
因此，重构和TDD具有关系——所有的单元测试要支持重构过程。

使用UP的过程成熟标志是，知道何时创建制品能够带来显著价值，或者是当遇到呆板的“完成作业”式的步骤时能够较好的略过。

建模不是过多，而是太少。
开发人员经常会避开任何分析或建模，因为这看起来似乎是低价值和费时间的事。
但是，如果战功了分析和设计的基本原则，适应了这种“语言”（在墙上完成用例，UML或UI原型等），
并且将其应用于敏捷建模的精神中，此时建模是能够带来价值的。

如因素表所做的一样，收集和组织有关的架构性因素，可以称为“架构的科学”。
根据相互依赖情况，优先级，权衡考虑等，做出解决这些因素的决定，可以称为“架构的艺术”。

记录架构选择，决策以及动机。
决定在何处花费精力进行必要的设计，预防将来可能的变化，这是架构设计师的艺术。
架构分析指的是，在功能性需求的语境中识别和解决非功能性需求。

如果开发团队中广泛依赖于某个包X，则他们肯定希望包X是比较稳定的，
因为当包X发生变化时，需要不断的进行版本同步，并且要修改依赖于该包的软件，这样会导致版本过载（version thrashing）。

在一个子系统中，避免直接抛出来自较低层子系统或服务的异常。
应该将较低层的异常转换成在本层次子系统中有意义的异常。
较高层的异常包裹较低层异常并添加一些信息，使得该异常在较高层子系统语境中有意义。

在多个例子中研究模式才有助于消化理解，组建业余学习小组是较常见的学习手段。
参与者在学习小组上分享模式的应用案例，讨论模式书籍中的内容。

在UP设计模型中，除UML包图，类图和交互图之外，软件架构文档（SAD）是另外一个重要制品。
SAD描述有关架构的总体想法，包含架构分析的关键决策。
在实践中，SAD可以帮助开发人员理解系统的基本概念。
从本质上讲，SAD是对架构性决策（例如技术备忘录）的总结以及对N+1架构视图的描述。

拥有架构是一回事，对架构的清晰描述的另外一回事。
架构试图是交流，教育和思考的工具，它可以用文本和UML图表达。
在SAD中，架构设计师将创建被称为逻辑视图的部分，在其中插入这些UML图，并写上有关每个包和层的用途的注释，以及逻辑设计背后的动机。

迭代开发的重要**之一就是根据反馈不断改进，而不是试图详细预测和计划整个项目。

《房间里的大象》PPT内容如下：作者：Niclas Hedhman，翻译：滕菲。
https://www.oschina.net/news/79166/apache-foundation-ceo-decades-views

大家好，我的名字是Niclas Hedhman。我是Apache Software Foundation长期贡献者。
作为一个软件开发人员，我已经工作了32年。多年来，我做了许多观察。
最新的观察是关于一件事，这件事是显而易见，我们却没有注意过它。
“房间里的大象”是英语中的一种表达，指的是那些没有人敢谈论却又很明显的事情。
这个演讲，我想谈谈软件行业里没有人敢谈论的话题，但却能把我们带到另一个层次。

前面提到了我已经做了观察。我们都会观察。
几乎每个人都看到过漂亮的代码。这些代码简洁明了，而且很强大的。这种代码易于理解，易于使用，易于扩展。我们可以很快地完成工作，把事情做好。
然而，如果我们问人们，他们是否在漂亮的代码基础上工作，大多数人说没有。
那么，这个代码是从哪里来的呢？
嗯，很少有开发人员能写出这些漂亮的代码。
另一方面，烂代码随处可见。
我们都见过烂代码。
我们中有些人每天都要和烂代码作斗争，我们都为写出更多的烂代码而内疚。
但是为什么？为什么你要写烂代码？你知道这代码很烂，你还要写。为什么？这是为什么？
我们会听到这样的话，这代码已经很烂了，我没办法改善，因为没法测试，因为代码太复杂，因为做需要的改变太危险了。
我现在很忙。交付期限快到了，等有时间我们会解决这个问题的。现在，我们需要把握重点，把这个问题先搁一搁。
嘿，我觉得这代码也没有很烂。我的队友们都很不高兴，但我认为他们不够聪明，无法欣赏这代码。
我要说，这都是狗屁。那些都是借口，因为不然我们也受不了自己这样。
我们怎么能明知做不好工作，却不感到羞耻，为什么不去换份工作呢？
我的推断是，还有更加深层次的原因，是我们行业存在已久的危机。
我觉得这非常令人不安。

首先，我们来看一些事实。我们的行业正在以一个惊人的速度在发展。几乎每周都有新技术出现，这种情况在过去的三十年中一直如此，我见证了这一切。行业对人们所创造的东西几乎没有限制。需要学习的东西也多到令人震惊。
开源现在是一个公共领域，我们几乎不需要从头开始。我们在已有的平台上工作，以新的方式将已经存在的合起来，再加上自己的创新，就发布了这个产品，其他人可以再在这个基础上创造。这造成了产量以史无前例的速度加速产出。
有没有人能告诉我这是什么？
这是全世界程序员数的增长曲线。具体的数字不重要，尽管据估计人数在50-100万之间。
重要的是，程序员人数在每5年左右就会翻一番。从1950以来，这种增加几乎不间断的。每5年，世界上的程序员的数量增加了一倍。
关于这种指数增长，我们能看出些什么？有两件事。好的是，这种增长不会永远继续下去。因为地球上没有这么多人。坏的是，这些程序员中，有一半都工作经验都不足五年。
实际情况可能更糟，因为还有很多程序员将在未来在10-15年离开这个行业。
所以，我们行业非常缺乏经验，而且一直缺乏经验。
更糟糕的是，由于技术的大环境变化如此迅速，在一项技术过时之前，没有足够的时间来积累经验，然后所有人又开始使用另一个技术了。
这导致同样的错误是一次又一次的循环发生。
大多数程序员不会发明新技术供别人使用。我们使用热门的技术。
我们相信，其他人已经知道何种技术适合我们。我们也不会动脑去思考。
我再说一遍，我们不会批判地思考，并且我们想信仰宗教信条一样，相信别人告诉我该怎么做，我就应该怎么做。

让我们来看看我们的行业的神话。这神话有很多。
由于我们的行为像一个宗教教派，也产生了许多神话，有的是偶然，有的是刻意而为。
神话是由特定的一类人创造和传播的。我们很容易受到我们所尊重的人所说的话的影响。供应商试图向我们出售产品和服务。同样，会议上的发言人，我们阅读书和博客的作者，他们是向我们卖他们的书，网站或服务。在工作中，我们听比我们更资深的人的话，这些人通常是那些有一些成绩的同事。但如果这是一个大公司，那么这些同事的话就会涉及办公室政治，或有为了赢得声望的因素，我们应该对这些人的话产生质疑。

让我们看看业内典型的神话，那些所谓的常识。
神话一 软件很容易修改 我们生活在这样一个概念里，软件是....软的，灵活的。
打几个字，我们就可以改变它，让它做一些完全不同的事。
重新设计的电子产品需要几天的时间，而软件只需要几分钟。
但是，嘿…现实是很残酷。它不是神话，而且会反击。
大多数软件不仅是难以改变，而且一旦用了就往往不能结束。
一旦写好软件，部署好，要想摆脱它，门都没有，无论这软件用起来多么琐碎或一无是处。
这种情况在公司管理中普遍存在。
如果我们需要多花一倍的精力做某件事，我们就多招一倍的程序员。
这肯定行。
《人月神话》（The Mythical Man-Month）是1975年出版的一本书。
40年前，作者Fred Brooks指出，增加人手到一个落后于计划进度的项目里，实际上会使项目进度变得更慢。
最终，花费在沟通所需的时间将比每个人有的时间加在一起还要多。

大公司的经理们的另一个最喜欢的神话就是是，程序员是可互换的零件。
如果一个程序员离开了，我们就从大街上找择一个新的，代替他。
但是那根本行不通。软件知识不在代码里，而存在于写代码人的大脑里。
如果你以前抢修过别人的代码库，而这写代码的这个程序员没有给你任何工作交接，你就知道我在说什么了。
如果写代码库的人离开了，则需要两个新人来代替他，这两人可能需要一年的时间来搞明白这个代码库的作者写的到底是什么，也有可能永远都搞不清楚。
这是我的最爱的神话之一。

如果不是这些抽象概念，我们不会有互联网，也没有网上那些很棒的网站。
如果我们必须为处理器写二进制指令，就有麻烦了。
编程语言，协议，数据格式，框架，还有更多的抽象的概念帮助我们完成工作。
但大多数抽象概念都是在我们写的程序中产生的。
我们创造出的抽象概念只是小聪明，概念不够清晰。
我们也没有很多创造抽象概念的经验，所以我们创造出的是混乱。我们创造的抽象概念往往很糟糕，一片混乱，不利于项目的完成。
很多人兜售各种方法论。
20世纪80年代后期使用的是用例对象方法，然后是理性统一过程和许多其他所谓的计算机辅助软件工程的方法，最后是统一建模语言UML。
Kent Beck介绍了到极限编程方法，这是第一个敏捷方法，是一个反对瀑布式的方法。
近10年间，Scrum，看板和其他方法备受吹捧。所有这些都方法都承诺解决软件这一复杂工作。
我的观察结果是，没有一个方法像宣传的那么好。几乎所有的软件项目都依赖于大神。
能完成项目的人，无论用什么方法，都能完成。对于新的项目，大神们擅长的是开始着手做。
在维护或改进代码库的时候，大神是那些工作中不介意遇到糟糕代码的人。

回到我们的行业。
我们可以以以下方式对我们的行业的程序员进行分类，天才，良好，一般，差和糟糕。
让我们看看每一个的特点。
天才程序员写的代码库很简单，可重复使用，且功能强大。
他们坚持不懈，持续发展，对代码库进行小而有规律的改进，添加新的功能。
他们写了足够多的相关测试。他们往往很谦虚，知识渊博。
他们也不完美，经常要从头开始重写整个库。但他们能写出更好的代码，而不破坏兼容性。

良好开发人员写代码库比较复杂。
通常他们留下了很多未完成的地方。因为他们不会在一个库工作很长时间，很快他们就会开始做另一件新人兴奋的事情了。
他们写的代码库很快变得陈旧，没有人知道如何操作它，而测试它则需要写太多的代码。
良好开发人员对自己和自己的工作感到自豪，但是他们的代码不能重写，因为这些代码写得没那么好，缺乏测试机制。

一般的程序员通常是大公司的维护软件的大神。
他们不计一切代价解决错误，砍掉新功能。如果测试中断，他们只需禁用测试，因为交付代码的时间到了。
他们也不喜欢与那些良好的开发人员工作，因为这些人会留下存在依赖关系的抽象概念和代码库。
这些东西用起来很不方便，而且有很多错误，还没有文件记录。

较差的程序员不关心任何东西。他们只会工作，写代码，回家，然后重复这一过程。
他们永远不会学习，他们不听取别人意见。即使告诉他什么是好的代码，什么事糟糕的代码，他们也不能分辨出来。
他们不应该成为程序员，一般也不会一直做程序员。

糟糕的程序员没有比较差的程序员那么糟糕，因为他们和他们周围的人都知道意识到他们没有经验的，代码写的不是很好。所以他们想学习，渴望成为更好的程序员。他们也往往会过渡成为良好的程序员，但有的也会变成比较差的程序员。糟糕是一个短暂的阶段，没有什么可以担心的。

这给我们带来了下一个神话。
如果我们问程序员，他们属于哪一类。
如果他们没看过这些类别的定义，那么我们将得到这样一个结果，60%的程序员认为自己是属于天才和良好类，只有30%左右的人认为他们是一般的程序员。
但依我的经验，统计数字应该是这样的。
极少数的是天才程序员，有一小部分的良好的程序员，大量的程序员属于一般、较差的程序员。好好思考一下吧。
所以，当天才程序员向我们展示其简单而卓越的杰作，有着漂亮的设计，简洁的抽象，简单易用……
我们就认为“我可以做到”。
在希腊语中，Primus Inter Paris意思是第一名也是平凡人。
这种观点认为真正优秀的人仍然只是我们中的一员，没有什么不同，我们都可以做到。
当我们看到别人写的漂亮代码，觉得很稀松平常。
但我们这些普通人太愚蠢了，看不到自身的局限性。我们知道最漂亮的代码长什么样，知道这是如何使用，但这并不意味着我们可以自己写出这种代码。
虚幻的优越感和达克效应分支理论告诉我们，我们太愚蠢了，却不知道我们是多么愚蠢。
我们对自己的能力有信心，写了那些在正常情况下几乎不能运行的复杂软件，这些软件即使在特殊情况下也无法运行。

我太愚蠢了，我写不出好代码。
所有人，现在，说出来……
这就是房间里的大象。

当然有问题。首先，是经济上的问题。
招更多的程序员，花费是更昂贵的。
招更多的人参与写一个代码库，会使代码库变得混乱。
银行有大量的程序员，只是为了保持程序可以运行。要改变代码库，这个过程是缓慢的。
如果我们看看所谓的互联网公司…这些人在做什么？互联网的效率是减少需要的人的数量。
其次，当前形势有社会影响。
不快乐的程序员倾向于改变工作。
我想说明，大多数情况下，新来的人会使情况变得更糟。
另一个恶性循环，是这种情况像滚雪球越滚越大。我们应该对自己的工作感到满意。当我们去上班时，应该感到高兴。
员工高流动率的另一个方面是，许多程序员为了逃避写代码，去了其他类型的工作岗位，如管理，业务分析师，甚至一些完全无关的专业岗位，因为他们做程序员不快乐。
这导致程序员岗位从业人员经验不足，情况变得更糟。

这个演讲内容非常消极，甚至对许多人来说是个的人身攻击。但是有什么解决办法吗？我想会有解决办法，但是是在遥远的未来。
一些天才会想出软件开发的新模式。我希望它是从根本上不同于我们现在的模式，类似于十八世纪将蒸汽机的引进矿业的发展。
也许人工智能可以用一个完全不同的方法来写软件，从而让我们停止写糟糕代码。谁知道呢？在那发生之前，我想我们都停留在了计算的青铜时代。
用手写代码写出每一个细节，但没有创造出可以传承知识，所以我们无法提高集体技能。

我想给你这个建议。
接吻原理-保持简单，直接（The KISS principle - Keep It Simple, Stupid.）。
当你写代码时，记住这是一件事。不要做额外的抽象。避免概括。避免继承（inheritance）。
不要写你认为你将来可能需要的代码。当没有更多的代码可删除，那么工作就完成了。
即使你正在工作的代码真的很混乱，很糟糕，请不要让这种情况变得更糟。
即使代码很糟糕，如果你改善一点点，就会变好一点点。如果每个人都一点点，最终代码会变好很多。还有，不要让你的队友让把代码搞得更糟糕！。

精益**的关键出发点是价值。
价值只能由最终用户来确定，而价值也只有由特定价格，能在特定时间内满足用户需求的特定产品来表达式时才有意义。

考虑一下下述三个过程：
（1）从概念到投产的设计过程
（2）从最初提出要求到产品送货的信息流动的订货过程
（3）从原材料到用户手上的物质产品的整个生产过程

世界各地的管理人员都爱说，
我们知道如何利用已经买到的材料和设备来生产这种产品。
如果用户不接受，我们可以调整价格，或者增加一些装饰品。

而实际上，他们真正要做的是站在用户的立场上，从根本上重新思考价值。

精益**必须从一种自觉的尝试开始，通过与用户的对话，
为具有特定功能以特定价格提供的产品精确定义价值。
这样做就要暂不考虑现有的资产和技术，而要在把强有力的专职生产团队配备在生产线的基础上重新考虑企业。

知道什么是真正需要做的事，则是必要的。
否则价值的定义几乎肯定会被曲解。

精确的定义价值是精益**关键性的第一步。

价值流是使一个特定产品，通过任何一项商务活动的三项关键性管理任务时，所必须的一组特定活动。
这三项任务是：
（1）从概念设想，通过细节设计与工程，到投产的全过程中解决问题的任务
（2）在从接订单到制定详细进度，到送货的全过程中的信息管理任务
（3）在从原材料成最终产品，送到用户手中的物质转化任务

确定每个产品的全部价值流，是精益**的第二步。

精益**必须超出企业这个世界上公认的划分单位的标准，去查看创造和生产一个特定产品所必须的全部活动。
这些活动包括从概念经过细节设计到实际可用的产品，从开始销售经过接收订单，计划生产到送货，以及从远方生产的原材料到将产品交到用户手中的全部活动。

我们把完成所有这些事情的组织机构，称为精益企业。

要使保留下来的，创造价值的各个步骤流动起来。

所有为设计，订货和提供产品所需要的活动应该在连续的流动中进行。
真正的挑战是在少量生产时创造连续流动。

把一天中生产某一特定产品的生产活动，从按“部门”和“成批”进行改为按连续流动重新安排，
可以使生产率提高两倍，各种错误和废料大大减少。
然而，在这种非常好的方法被发现50年之后，世界上仍然有大量的活动是按部门，按“成批与排队”的方式在进行。

你可以让用户从你那里按需拉动产品，而不是把用户常常不想要的产品硬推给用户。

你越是使劲拉动，阻碍流动的障碍就越会显现出来，从而也就能将它们排除。

事实上，在精益系统中的每个人，从分包商，第一层供应商，组装厂，批发商，用户到员工，
都可以看到所有的事，因而易于发现创造价值的较好方法。

问题在于每家公司只提供一部分产品，经常只从内部看到自己营运的“效益”，而没有人看到用户眼中的完整的产品。
在注意力转变到用户一样能看到整体的那一刻，问题就明显的暴露出来了。

当你开始以用户的眼光看整个事情时，产品（服务）的适当定义就改变了。

真正需要的是对具体产品和服务的整个价值进行管理。

当我们开始思考把完成一项任务所需的基本步骤排列成一个稳定的，连续的流，
其中没有浪费的动作，没有干扰，没有批量，没有排队的方法时，所有以下的事情就变了样。
我们如何共同工作，我们发明的用来协助我们工作的各种工具，
我们创造的用以推进流动的各种组织，我们追求的各种职务，
企业的性质，以及它们之间的联系和它们与社会的联系。

更糟糕的是，没有一个人对开发工作最后负责。
因为会计部门和奖惩系统，在产品的整个生产寿命周期内，永远不会把产品的成功，和最初设计团队的努力联系起来。
因此有过这样的事，一个用户喜欢的，有独创性和极好的技术性能的设计，
却由于成本过高和延误推出时间而未能回收利润。

有一个真正专职的团队存在，严格的应用QFD（质量功能呢展开法）来纠正确定价值，
然后消灭返工和倒流，设计工作就会永远不停的向前，直到完全投产。

这样做的结果是，开发时间减少一半以上，花费的人力总计减少一半以上，
然后却得到一个真正为用户所需要的，“命中率”高的产品。

在精益企业中，销售和生产计划人员是生产团队的核心成员。
他们的责任是在一个产品开发出来时，计划销售宣传活动，并在销售时随时关注生产系统的能力，
从而使订单和产品都可以平缓的从销售流向送货。

由于在生产系统中没有阻碍，产品是按照订单生产的，从原材料加工开始的第一步到制成品出厂的租后一步之间只需要几个小时，
可以在清楚而准确的了解生产系统能力的情况下去寻找和接受订货，
根本不需要加班了。

在成批与排队系统中，总的供货时间常常相当长。

在连续流动的布局中，生产工位是按照顺序排列的，通常是在一个独立工作区中，
产品从一个工位移至下一个，每次一辆自行车。
使用普遍称为“单件流”的一套技术，在工位之间没有在制品作为缓冲。

哪怕有一个残次品，也不能送到下一道工序去。

如果你认为必须花很多钱才能把设备从大批量转为小批量或单件生产，那你就还没有理解精益**。
流动**的最终目标是完全消灭整个生产过程中的停顿，而不是坐等工装设计先消灭停顿再说。

当生产需要加快或减慢时，生产团队的规模可以扩大或缩小，但是实际的生产步幅不变。

丰田的能人在保险杠公司注意到的第一个问题是，大量库存和批量生产。
什么都不流动。

但是，只有下一步拉动时，它们才流动。
这就是说，下料机只有从冲压机处得到信号时才干活，
而冲压设备只有接到焊接车间的指令后才生产。

每一项活动拉动前面一步。

不需要就不做，要做就快做。

传统的管理根本没有领会通过不断改进达到尽善尽美这一概念，
而这一概念正是精益**的基本原则。

如果你用了大笔资金去改进特定的活动，你多半是以错误的方式在追求尽善尽美。

为了在头脑中形成尽善尽美的概念，价值流的管理者们需要应用四个精益原则，
确定价值，识别价值流，流动，拉动。

要观察价值流，要观察价值的流动，要观察被用户拉动的价值。

挑战陈规陋习

在生意场多年，我发现一个现象，
我做事前总问为什么。
可得到答案永远是『我们向来这样做』
没人反思为什么这么做。

生意场上有很多约定俗成的规定，我称为陈规陋习
因为以前这样做，所以就一直这样做下去。
所以，只要你多提问多思考，脚踏实地工作。
你很快就能学会经商，这不是什么难事。

学习编程的意义

编程可以帮助我们完成工作，它没有明确的实用性。
重要的是，我们把它看做思考的镜子，学习如何思考
我认为学习思考最大的价值在于，
所有美国人都应该学习编程，学习一门编程语言
学习编程教你如何思考，就像学习法律一样。
学法律的人未必都成为律师，但法律教你一种思考方式
同样，编程教你另一种思考方式
所以，我把计算机科学看成基础教育
是每个人都应该花一年时间学习的课程

公司的价值

很有趣，我23岁拥有超过100万美元的财产
24岁超过了1000万，
25岁超过了1亿
但这并不重要，我不是冲着钱去的。
钱允许你做想做的事，
钱让你实现那些短期内看不到效益的创意
但钱不是最重要的
重要的是公司，人才，产品，是产品带给客户的价值
所以，我不太看重金钱。

产品与销售

我一直在思考这个问题，
我现在有了清晰的答案。
是这样，就像Sculley一样，
他以前在百事可乐工作，他们的产品可以数十年不变
顶多更换一下可乐瓶子。
所以产品部门的人说话没有份量，
在百事公司谁最有发言权？
是营销部门的人，他们很容易升职从而掌管公司，
对百事来说，这不是件坏事。
问题是垄断科技公司也有这种情况，比如IBM和施乐。
即便IBM和施乐的产品经理能做出更棒的产品，那又怎么样？
这些已经垄断市场的公司很难再提高业绩，
要想提高业绩，还得依靠营销部门。
于是他们逐渐控制公司，而产品部门的人被边缘化，
公司就丧失了打造优秀的产品热情和能力。
产品部门的功臣慢慢被不懂产品的人排挤，
后者通常缺少研发产品的技术和能力，
而且，也并非打心底愿意替客户解决问题。
施乐公司就是这样。

流程与制度

公司规模扩大之后，就会变得因循守旧，
他们觉得只要遵守流程，就能奇迹般的继续成功，
于是开始推行严格的流程制度，
很快员工就把遵守流程和纪律当做工作本身。
IBM就是这样走下坡路的。
IBM的员工是世界上最守纪律的，他们恰恰忽略了产品
苹果也有这个问题，我们有很多擅长管理流程的人才，
但是他们忽略了产品本身。
经验告诉我，优秀人才是那些一心想着产品的人，
虽然这些人很难管理，但是我宁愿和他们一起工作。
光靠流程和制度做不出好产品，
苹果也有这方面的问题。

创意和实现之前的距离

我离开苹果以后，发生了一件几乎毁掉苹果的事，
Sculley有个严重的毛病，我在其他人身上也见到过，
就是盲目乐观，以为光凭创意就能取得成功，
他觉得只要想到绝妙的主意，公司就一定可以实现。
问题在于，优秀的创意与产品之间隔着巨大的鸿沟，
实现创意的过程中，想法会变化甚至变得面目全非，
因为你会发现新东西，思考也更深入。
你不得不一次次权衡利弊，做出让步和调整，
总有些问题是电子设备解决不了的，
是塑料，玻璃材料无法实现的，
或者是工厂和机器人做不到的。
设计一款产品，你得把五千多个问题装进脑子里，
必须仔细梳理，尝试各种组合，才能获得想要的结果。
每天都会发现新问题，也会产生新灵感，
这个过程很重要。
无论开始时有多么绝妙的主意。

才华横溢的团队

我以前在苹果就发现一种现象，
很难表达出来，更像是一种感觉，
生活中多数东西，最好与普通之间的差距不超过两倍，
好比说纽约的出租车司机，
最棒的司机与普通司机之间的差距大概是30%，
最好的与普通之间的差距有多大呢？20%？
最好的CD机与普通CD机的差距有多大？20%？
这种差距很少超过两倍。
但是在软件行业，还有硬件行业，
这种差距有可能超过15倍，甚至100倍，
这种现象很罕见，
能进入这个行业，我感到很幸运。
我成功得益于发现了许多才华横溢，不甘平庸的人才，
而且我发现只要召集到五个这样的人，
他们就会喜欢上彼此合作的感觉，前所未有的感觉，
他们会不愿意再与平庸者合作，只招聘一样优秀的人，
所以，你只要找到几个精英，他们就会自己扩大团队。
Mac团队就是这样，大家才华横溢，都很优秀。

经常性的改变自己

与优秀自信的人合作，不用太在乎他们的自尊，
大家的心思都放在工作上，
每个人负责一块很具体的任务，
如果他们的工作不合格，你要做的无非是提醒他们，
清晰明了的提醒他们恢复工作状态，
同时不能让对方怀疑你的权威性，
要用无可置疑的方式告诉他们工作不合格。
这很不容易，所以我总是采取最直截了当的方式，
有些同事觉得这种方式很好，但有些人接受不了。
我是那种只想成功，不在乎是非的人。
所以，无论我原来的想法多么顽固，
只要反驳的人拿出可信的事实，五分钟内我就会改变观点。
我就是这样，不怕犯错，
我经常承认错误，没什么大不了的。
我只在乎结果。

有效的利用

苹果每年的研发费用数千万，累计已经超过50亿，
有什么效果？我没看到。
他们不懂如何利用新技术，不懂如何创造新产品。
优秀的员工被困在公司里，束手无策。
因为缺少有眼光的管理者。

学习各个领域的优秀成果

你怎么知道哪个方向是正确的？
最终得由你的品味来决定，
你要熟悉人类在各种领域的优秀成果。
尝试把它们运用到你的工作里，
毕加索说过：拙工抄，巧匠盗。
我从来不觉得借鉴别人的创意可耻，
Macintosh团队里有音乐家，
有诗人，艺术家，动物学家，历史学家，
这些人也懂计算机，所以Macintosh才这么出色。
如果没有计算机，它们也会在其他领域创造奇迹。
大家各自贡献自己的专业知识，
Macintosh因此吸收了各个领域的优秀成果，
否则的话，它很可能是一款非常狭隘的产品。

传达情感的媒介

我觉得优秀的同事，都不是为了计算机而工作，
而是因为计算机是传递某种情感的最佳媒介，
他们渴望分享。
如果没有计算机，我们可能会从事其他行业，
是计算机让我们这些从小接触它的人走到了一起，
计算机就是我传达情感的媒介。

可用性实际仅意味着要确保产品工作起来顺畅：
能力和经验处于平均水平（甚至平均水平以下）的人都可以在不会感到无助和挫折的情况下使用该产品完成既定的目的。

可用性，通常关注的是用户使用产品成功完成某任务时的能力，
而用户体验，则着眼于一个更大的视角，强调的是用户与产品之间的所有交互以及对交互结果的想法，情感和感知。

可用性度量，要求被测事物应能代表用户体验的某些方面，并以数字形式表示出来。
比如，一个可用性度量可以说明65%的用户对使用中的某个产品感到满意，或者90%的用户能够在1分钟之内完成一组任务。

可用性度量可揭示用户和物件之间的交互，即可揭示出有效（effectiveness）（是否能完成某个任务），效率（efficiency）（完成任务时所需要付出的努力程度）或满意度（satisfaction）（操作任务时，用户体验满意的程度）。

可用性度量测量的内容，与人及其行为或态度有关。
基于这个原因，我们会讨论置信区间的问题。

可用性度量的最终目标不在于其自身，它们只是一种途径或方法，
可以帮助你获得更多信息，以便做出决策。

---

在进行一个可用性研究时要提前做准备，尤其是在涉及收集数据的环节更应如此。

你需要理解研究的目的有哪些——数据如何在产品开发生命周期中使用。
你需要了解用户的目标——用户使用产品的目的。

了解研究的目标和用户的目标，可以引导我们选择正确的可用性度量。

---

绩效度量：

任务完成，任务时间，错误，效率，易学性。

基于问题的度量：

在确定可用性问题时，需要考虑的一个关键问题是，可用性问题的用途是什么。
最有用的可用性问题应该指出如何对产品进行改进。

你设想的问题，不一定是你最终发现的问题。

不是所有可用性问题都是一样的，有的问题会比其他问题更严重一些。
有些问题会让用户感觉心烦或沮丧，另一些问题则会导致用户做出错误的决定或丢失数据。

严重性评估有助于集中精力解决重要的问题。

当竭力去认定一个问题是不是真问题时，你首先应当问问自己，即，
在用户思考过程和行为背后是不是存在一个与之符合的合理情境。
如果情境是合理的，那么这个问题就可能是真实的。

行为和生理度量：

在典型的可用性测试过程中，大多数参加者不仅需要完成任务和填写调查问卷，还可能有许多其他行为反应。
他们可能大笑，抱怨，大叫，扮鬼脸，坐立不安，漫无目的的四处张望，或者用手指敲击桌子。
这些都是在产品可用性测试中可以被测量到的行为。

---

六西格玛，是一种关注于衡量质量改进的企业研究方法。
西格玛指的是标准差，因此六西格玛值得就是六个标准差。
在生产制造流程中，六个西格玛就相当于每生产一百万个部件就有3.4个次品。

六西格玛的基本目标就是要达到这样的质量水平：
你所处理的任何事情犯错的概率都仅为0.3%或更低。

但很多情况下并不能准确的衡量错误或次品数量。
相反，通常的目标是，在你测量的任何事情上都要达到六个西格玛的改进。

---

一旦关键性的决策者开始看到结果模式一致时，你就无需再花大量的精力使他们相信改变设计的必要性。
汇报中穿插一些小的视频片段，在推销可用性的过程中可以起到完全不同的效果。

从小事做起，努力慢慢做起来。

在开始任何可用性研究之前，确保你有足够多的时间和预算是很关键的。

可用性度量是相对的。
没有绝对的标准来判断什么是“好的可用性”和“坏的可用性”。
正因如此，所以给你的产品确定可用性基线是必要的，在市场研究中经常要这么做。
市场人员总是谈论“改变方针”。

我们要亲眼查看所发生的问题。

在你的结果中标示置信程度，这将会有助于做出明智的决策和提高你的可信度。
不管你的数据表现出来的是什么样子，只要有可能都需要标示置信区间。
这对相对较小的样本（如小于20）来说尤其重要。

不要仅仅通过计算置信区间展示你的置信程度。
我们推荐你计算p值以帮助你决定接受还是拒绝你的假设。

简化你的报告
首先需要了解报告的受众和他们的目标，不同受众群体目标可能不同。
不管你做什么，不要仅仅描述你的数据，这是一个准会使受众睡觉的方式。

给每个主要的点设置一个特定的情节。
报告中你所展现的每个表或图，都给予一个由来或情节。

1. 玩的就是心跳：组织相信忙乱的工作象征着高效的生产率。

优先级总是变化不休，所有事项都是“昨天”就要，总是没有足够的时间交付项目，所有项目都是紧迫项目，紧迫的项目源源不断。
每个人都忙得焦头烂额，永远如此。

这些组织里面的人不会从战略层次上思考问题，只是按照紧迫程度来完成工作。
除非“忙乱指数”非常高，否则它通常都会被忽略——尽管它很有可能会带来显著的长期优势。
人们会一直对其不闻不问，直到它突然（绝对出乎意料的）变得非常紧迫。
“玩的就是心跳”分子相信最好的工作方式不是先谋而后动，而是竭力追赶时间。

这种组织文化认为紧迫性越高的项目，绩效也越高。
那些为了某个短得可笑的期限而加班到深夜的程序员被视为英雄（根本不在乎他们交付的程序质量）。
每个周末，团队的所有成员都照常上班，以保持他们的工作量，这样做的团队比不这样做的团队更受人赞许。

大部分的“玩的就是心跳”型组织满腔热情的拥护客户服务的理念，他们错误的认为对紧迫事件的响应就是值得赞赏的响应。
当客户提出了一个请求，不管是否存在潜在的利润（甚至有效性），该项请求都会立即转化成一个项目，而且通常截止日期都会短得可笑。
很多这一类组织都（错误的）认为这就是敏捷的全部。

紧迫性是唯一的标准，没有人尝试按照重要性或者工作价值来对工作排定优先级。
高层领导，通常是CEO，希望看到组织长久的保持匆忙的状态，因为工作匆忙让人生出一种高生产率的幻觉。

“玩的就是心跳”型组织并不是总会失败，他们当中有一些在多年里一直保持着匆忙的节奏。
但是，它们都不可能构建重大的东西——那需要稳定性和计划。
亢奋型行为不可能扩展——由一些相对较少的人在没有方向，也没有战略指导前提下，光凭借非常，非常忙碌的工作所能达到的效果十分有限。

当然了，任何组织内部都会遇上紧迫的事情，也需要一些角色去关心紧迫任务。
但是，不是所有的事情都是紧迫的，也不是所有角色都要关心紧迫的任务。
除非化紧迫性为优先级和约束，否则，这种“玩的就是心跳”的治愈希望是微乎其微了。

2. 快，赶上：当项目团队决定谁在何时该做什么事情时，呈现出明显的紧迫感，并迫不及待的想立即采取所有必要的行动。

3. 死鱼：自打开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，但却都缄口不言。

很多IT项目的目标可以被扼要的概括为：我们要在截止日期之前，完成这一系列功能，达到这样的准确度，并且保证足够的健壮性。

一个天大的秘密是项目团队中没有一个人相信项目最终能成功。
通常看来，如果其他目标不做修改，截止日期是无法达到的。
不可思议的是，没有人指出失败的阴影正如一只散发恶臭的大死鱼一样把项目变得臭不可闻。

很多组织是如此的汲汲于成功，以至于任何表达疑虑的人不会因为讲出由衷的意见得到任何奖赏。
事实上，如果谁在项目的前期阶段就声称死鱼存在，管理层的第一反应多半如下，
“证明给我们看。给我们证明成功的可能性只是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。用严密的数学证明来告诉我们失败无法避免。”

一旦你提出任何缺乏精确证据的东西，就会被指责为软蛋或者是试图逃避朴实的辛勤工作。
在这样的环境里，“努力”而无法完成比站出来指出目标无法达到更安全。

确实，有时需要勇于承担有挑战性的项目，在认输之前真正的拼搏一番。
非常正确——但区别是，在有确定的截止日期的艰难项目中，没人会捱到最后一刻才声明情况的危急。

4. 欢乐的鼓掌会议：是否表现出高涨的士气成为个人绩效的评价因素。

5. 保姆型项目经理：项目经理拥有的技能与传统的英式保姆有很多共同之处。

6. 牵涉性疼痛：项目治愈了外部的病状，却没有根治内部的病因。

牵涉性疼痛这个术语通常是指疼痛不是表现在病源位置，而是表现在身体的其他部位。

在项目立项的时候，人们往往会解决显式的问题——最明显的，客户疼痛感最强的问题。
但是，如果只盯住牵涉性疼痛，项目交付的产品——一旦交付了——最终就会变成极大的浪费，因为它对于真正的需求几乎没有任何帮助。

我们可能倚重自己所具备的技术，用与我们所熟知的解决方案最契合的方式来看待问题。

是否在处理牵涉性疼痛，一个强烈的信号是临时补丁。
允当目前系统需要做一些修正的时候，这些补丁就会骤然出现。
临时补丁用来修正问题的外部情况，而没有去修正主要的系统。
临时补丁如同创可贴，很少（甚至从不）能帮助解决问题的根本原因。
但是，当一条补丁看上去有效，更多的补丁就会被采用，有时甚至每个补丁上面都是一层又一层的临时补丁。

集中精力研究真正的需求，解决真正的问题，总是能事半功倍。

7. 明日复明日：每个人都有时间窗，提醒自己立即采取行动并持之以恒，直至工作完成。逾出时间窗的交付日期不会导致任何紧迫感，因此也就产生不了行动的动力。

紧迫感是实际行动的催化剂。
如果事情不再紧迫，它在今日待办事宜的列表上就会被排到后面。
其他事情的紧迫性就更为显著，今天就应该处理所有那些需要几天才能完成的事情。

“明日”是这样的一种状态，意识到自己需要负责完成工作，但却没意识到如果期望成功，自己就必须从现在开始。

大规模的项目通过让大多数人保持对时间窗的关注，来避免“明日”的影响。
他们把工作转化成在90天之内——通常在30天内——能够交付的具体任务。

但是，要小心，关键在于每个时间窗都必须产出真正的交付物。
只有进度是远远不够的。

警惕“明日”的另一种特殊变体，耗费大量的时间来准备开始。

项目前期阶段的时间并没有像结束阶段的时间一样被仔细的对待，
使行动开始的最佳方式就是不等“明天”，今天就开始动手。

8. 眼神交流：当任务紧迫而且复杂的时候，组织往往会把项目成员安置在一起工作。

现在，还是痛痛快快的承认吧，如果项目的成败对你性命攸关，你难道会不想把所有的项目成员都安置在一个地方，让他们可以在视线范围之内看到对方？
而且，工作越紧急，团队成员就越有必要在一起。

当所有的全职的，专注的项目成员处在同一个屋檐下工作时，会产生一些很神奇的效果。
他们了解彼此的需要和能力，而且随着了解的增多，他们会调整自己的行为方式，以获得最佳的整合效果。
有一种无形的信息交流使得人际之间的合作变得顺畅，而这依赖于人们在地理位置上的接近度。

类似的，在开发团队里面有一些关键的信息交流对于紧密的合作也非常必要，其中最重要的是信任的给予和获取。
中间横亘着距离，双方很难相互信任。
同样，也很难察觉语言上的微妙之处，信心，某些讽刺和挖苦，真实意图，信服程度，无望感和无能为力感，轻重缓急以及话外之音。
缺乏了这些潜台词，沟通就变得脆弱。

目光接触能提升交流的效果。

9. 情绪戒指管理：经理不是基于摆在项目面前的风险，决策和问题来汇报项目状态，而是基于团队的活动，付出和热情。

10. 忠实信徒：个体把某种**派系作为真理来膜拜，与圣典稍有偏差即被认为是亵渎神灵。

几乎所有流行的软件工程方法学都来源于软件从业者的经验，而不是基础性研究。

与很多业内领先的流程设计者交流之后，我们得知他们中的大部分人承认。
（1）他们的方法来源于一定的领域或者项目大小。
（2）他们的方法从来没有期望如同描述的一样用在所有可能的环境中。

项目上的忠实信徒会让工作止步不前，他们不去专注于内容，反而为方法争执不休。

11. 出租灵魂：从业者愿意放弃长期练就的技能或者技术。

称职的专业人士有一项令人钦佩的地方，在于能够根据待解决问题的实际情况来裁剪解决方案，而不是把问题往个人或者团队久经检验的技能上生搬硬套。
一旦出现了好的新思路，他们能够比较各自的优势，非常明智的决定使用最合适的方法。

要放弃长期坚持甚至精通的技术并不容易，但灵魂的出租者能够忍受暂时的不适。
他们知道相对于问题，现有的技术已经绰绰有余，但他们也清楚某项新技术也许能提供更多的东西。
虽然他们并非追赶最新技术潮流的狂热分子，但他们也愿意放弃现在熟捻于心的工作方式，去考虑其他真正的先进技术的优势。
他们的态度是着眼未来，而非从现状中寻求安慰。

诚然，任何组织都不能任意更改自己选用的技术。
它需要在开发语言，开发方法，技术基础设施，以及其他方面保持一定程度的稳定性。
但我们这里讨论的是态度。
当组织决定对新技术不断研究的时候，它打造了一副金字招牌，吸引着最好的和最聪明的雇员。

新的并不一定就是好的。
当新技术（编程语言，建模技巧，方法学或软件工具）问世，颇具说服力的宣传通常也随之而来。
而且在很多情况下表现为大肆炒作，广告轰炸。

能够把问题本身跟解决方案区分开来是称为灵魂出租者的第一步。
第二步则是要弄明白无论技术多优秀，明天总会有更优秀的出现。

12. 系统开发旅鼠周期：虽然组织流程很明显的需要进行定制，但项目团队依旧盲从于未定制的标准。

如果流程很少照顾到项目的实际需要，照搬流程也许能让项目早点开工，但却无法早点完工。

项目经理不定制流程，就像厨师严格遵循菜谱来烧菜。
那样的话，他永远不会成为一个好的主厨。
当然，即便是好的主厨，也是从学徒工开始，从他们的师傅那里学习菜肴烹饪的基本技能，模仿他们师傅的菜谱。
但一旦他们掌握了基本技能，停止按照标准菜谱烹饪，他们就能脱颖而出，大放异彩。

13. 清空“板凳”：组织变得如此精简，以致于失去任何一个关键人物都会演变成一场灾难。

14. 面对面：分布式团队通过各地之间大量的面对面交流，以建立使远距离团队合作成为可能的熟悉感和可靠感。

在计算机学会会议上，总能听到年轻的程序主管声称他们更喜欢一个小型的，由一流人员组成的尖峰团队，而不是由几百个——同时也意味着平庸的——程序员组成的项目团队。
我们都这样认为。
这才是构建软件的最佳方式。

15. 我给了你凿子，可你为什么不是米开朗基罗：经理购买工具，潜意识里希望它们可以赐予团队技能。

通常都是精明的年轻人来销售软件工具，他们对工具在生产率方面的效果，以及给使用者带来的能力上面夸下海口。
大多数客户都看穿了销售人员的大言不惭，但是有时候IT经理不胜其烦，失去了区分现实与幻象的能力。

这些经理承担了交付的压力，而他们却几乎没有人手来做到这一点。
自动化工具有时看上去就像是一条救生绳。
在某一个绝望的时刻，工具购买者忽视了工具用户必须具备适当技能的观念。

工具的成本不仅仅是工具的价格。

工具出现在桌面上，给人一种开发人员能力很强，生产率很高的感觉。
但是，工具本身并不能改变任何事情，生产率不会自动提升，报告的错误率仍然居高不下，让人郁闷，而士气也依旧十分低下，令人失望。
虽然事与愿违，但生产率瓶颈可以通过开支票购买工具来打破的信念依然顽固。

当然，工具是有用的，它们在合适的人手中能带来令人惊讶的生产率提升，
并且可以完成那些离开了这些工具就不可能完成的事情。
但是正如工具的构造者所告诉你的，拥有恰当的技能去使用工具，这一点才是最关键的。
所谓凿子，在米开朗基罗拿起它之前，只是拥有锋利边缘的铁块而已。

16. 主面板：强团队和弱团队都在使用主面板（dashboard），但普通团队则不然。

最好的团队使用主面板，让大家把精力集中于在正确的时间做出最重要的决定和采取最重要的行动。
弱团队则使用主面板以责备其他人或者转移其他人的责备（通过着重强调好消息）。

团队的前进动力并非缘于对成功的一腔热情，而是对批评心有余悸。

17. 无休止的集体会议：允许无休止的争辩，最终肯定无法达成任何一项决定。

在很多项目团队看来，根本就没有最终决定一说。
表面上服从决定，随后却继续发出反对的声音。

这种行为导致最糟糕的后果是把项目最宝贵的资源——时间——白白挥霍掉了。

其实，无休止的争辩的根源在于团队的领导者。
只要领导者容忍一天，不认同决定的团队成员就会争辩一天。
这取决于领导者是否认识到该在何时结束这种争辩，勇敢的做出决定。

成熟而专业的组织的一项特点就是拥有有效的决策流程，里面包含了决策制订和后续事宜处理的规则。

美国海军陆战队关于军事理论的简明出版物，就包含了一系列被充分理解的决策规则。
在指挥官做出决定之前，每位下级都有责任有义务诚实的提出个人的专业意见——即使这些意见可能会和上级的不一致。
但是，一旦决定做出，每位下级都应该把它当做自身的决定，毫不迟疑的遵守。

服从决定和认同决定二者之间存在区别。
费劲的说服别人去认同自己的看法是没有意义的。
如果人们抱有不同的看法，即使某个人做出了决定，也无法改变他们的看法。
但遵守决定意味着无论认同与否，每个人都应该采取规定好的行动，而不是把精力放在抗议决定上面。

避免无休止的争辩需要有一个适合具体项目的决策流程。

当人们认为只有经过他们同意才能让他们遵守决定的时候，无休止的争辩就产生了。
这时，项目经理应该站出来，建立规范让人们遵守决定。
而且让人们认识到，一旦决定作出，就必须无条件的接受。

18. 幼犬和老狗：拥有很多年轻人（20多岁）的组织比充满老员工的组织更富有生气。

要想组织停止沦为老员工（或者“非常老”员工）之家，最明显的办法是雇佣年轻人。
但这并不是每个人都能做到的，首先，必须有空缺职位，然后，必须愿意在新员工身上投资。
无论如何，招聘一些兼职的大学生总是非常容易的。
况且，还有大量的暑期实习生呢。
更何况还有课后工作的高中生呢。

19. 影评人：影评人是团队成员或者公司内部的旁观者，他们认为自己给项目带来的价值在于指出问题所在或者将会出现问题的地方，却不把解决问题视为自己的职责。

对于如何纠正他所发现的缺陷，他也不提出任何建设性的意见，只是一味的对你们处理事情的方式表示忧虑。

所有影评人都有一个共同的特征，他们相信即使自己所处的项目失败了，他们也能成功。
实际上，他们已经悄悄的与项目团队背道而驰。

20. 单一问责：项目的每件任务都是清晰的映射到仅仅承担单一职责的个体身上。每个人都十分清楚自己承担的职责，以及自己同事承担的职责。

一些项目的运作原则是每一件事的责任都由所有人共同承担。
这样的想法表面看起来非常值得赞叹。
但毫无悬念，这种方法很少奏效。
每个人都需要操心（或干涉）每一件事，却无法把其中任何一件事情做好。

之所以能够进行单一问责，是源于这样的一种自信，即人们清楚的认识到其他人对自己的期望。

21. 苏式风格：交付的产品包含了客户要求的功能，但却不受客户待见，很快就被搁置一边了。

22. 自然权力：能力吸引权力。

知识工作与生产工作极其不同。
在生产环境中，工人们追求一个共同的，简单定义的目标，完成任务所需的技能对于所有人都是一样的。
老板通常是技术精通者，而且对生产线以及生产线工作机制的理解也最深刻。
因此，在需要决策的时候，老板很自然是做出决策的那个人。

知识工作则是另一种情形。
技能是多方面的，从不同角度看问题得到的结论也不同。
如果决策牵涉到一个或多个团队成员的知识领域，那些成员才应该是真正的决策者。
如果决策影响到团队之外的其他人，具备相关领域知识的团队成员至少需要参与到决策制订的过程之中。

在特定领域学识渊博的人被认为是权威，而某人主管某一项工作则被认为是掌权。
权威很可能没有掌权，掌权的人却可能不是权威。
良性的模式是——无论身为权威的人是否手握权力，都应该由他们来做出每一个决策。
同时，可能是由掌权的人负责监督决策的实际执行，而不是决策。

与该模式相反的形式同样显而易见，决策的制订流程遵循组织结构，而不是遵循知识和技巧。
身居更高职位的人负责做出大部分决策，有时甚至都不咨询一下那些对问题有更深刻理解的人。
另一种情形是组织基于价格因素来做出技术的决策，即费用更贵的决策由职位更高的人来制订。

违背自然权利的流动规律，听上去很像是在滥用职权，仿佛全部都是经理的过错。
但在某些情形下，相关领域的专家也应该感到脸红。
经理会放任自流，为所欲为，以致自食其果。
而拥有重要的和必要知识的人们只是坐在一起，闷闷不乐的默许别人在眼前做出错误的决策。
除非被特别要求，否则他们不会提出任何意见。
这是对责任的放弃，因为沉默即同意。
对于错误的决策，沉默的专家与无知的经理们都要负上同样的责任

23. 万籁俱寂的办公室：办公室太安静了，凸显出团队已经失去了活力源泉。

24. 白线：项目团队借用网球场上的“白线”，来界定需求的范围。

很多项目都没有白线。
人们试图借助于特性列表或者目标声明来区分哪些需求属于系统范围之内，哪些需求则不属于。
然而这两种做法都不够精确，无法成为实用的白线。

你是在通过声明需要修改的系统/业务领域与直接交互的外部世界之间的每个接口来定义项目范围。
一旦该工作完成，系统范围就不再有任何的歧义，你已经借助于接口绘出了白线。

25. 沉默即同意：利害相干人无法区分屈服的沉默和同意。

如果组织内部产生了不满，这些不满经常是集中于那些没有达成一致理解的隐式承诺上面。
承诺被误解的情形通常是，一方表达了需求，然后另一方点头示意明白。
前者把这种情形理解成一项承诺，后者则视为痴人说梦。

“沉默即同意”式的承诺对每个人都不利。
双方不可避免的给工作定义出不同的优先级，最终的结果必然是惨淡收场。

要使隐式承诺易于管理，一个行之有效的方法是公开声明少量的重要承诺，把它们写下来，然后共享给所有的相关人士。
承诺书没有必要，短短的承诺列表即可。
上面列出承诺者的姓名，承诺达到的确切结果和确切日期。
在这种情形下，承诺者必然把公开承诺的优先级调的高于自己台面上的其他工作。

26. 稻草人：团队成员很乐于提供“稻草人”解决方案以获得早期的反馈和认识。

客户之所以弄不清楚自己想要什么，是因为他们对自己所能得到的东西一点概念也没有。
最好的分析师从来不会试图去分析了客户的所有问题后，再拿出解决方案。
他们分析得出一些理解，对解决方案的整体或者部分作出最小的投入，然后把解决方案快速交给客户，寻求客户的反馈。

人们天生就是高效的改进者，而只有极少数会愿意从零开始。

最好的稻草人模型可能甚至包括一些有意为之的错误。
分析师故意弄错模型，以保持客户的警惕性，同时释放出一种信号——针对模型畅所欲言的批评都会被完全无保留的接受。

无论人们何时迭代式的寻求解决方案，稻草人建模都是非常有效的。
“稻草人”的哲学是尽早犯错，频繁犯错，这样你将会尽快得到正确的结果。
很多人自认为已经在使用“稻草人”的策略，但是否曾有人指着你的模型大加嘲笑？
那才是“稻草人”。

27. 伪造的紧急性：仅仅是为了遏制成本，项目的截止期限被强行安排得非常紧张。

如果按照慎重的估算得到的时间完成项目，那么多余管理层而言，项目的成本就太高了。
于是，虽然每一个有判断力的参与人员都说项目需要两年时间，但疯狂的管理层还是把计划时间定为一年。

要识别是否属于伪造的紧急性，我们需要仔细查看项目可能产生的收益。
如果收益千真万确，十分可观，那时限一年的计划安排绝对意味着头脑发热的冒险行为，兴许头脑太过于热了。
假如果真能得到如此重要的收益，为什么不多分派一些时间认真的去做这件事呢？

更普遍的现象是，所谓的收益其实只是微不足道的，这也解释了为什么组织没有投入全部的精力。
明显冒进的计划安排实际上只是制约开销的策略。

伪造的紧急性会引发伪造风险。
项目惨淡收场，但这还不是最坏的情况。
最坏的情况是组织没有抓住真正的商业机会去从事高价值的项目，而那些项目的风险都是值得去尝试的。

28. 时间清除了你的手牌：时间是位拙劣的项目经理。

经理在项目初期的决定对项目的影响很大。
当为期10个月的项目刚开始2个月时，增加一个开发人员和一个测试人员也许还有助于准时交付完整的功能。
然而，当项目仅仅剩下2个月时，再增加开发人员和测试人员恐怕就于事无补了。
事实上，这样可能还会给团队带来负作用。

时间也会在“下一个发布版本应该包含哪些特性”的问题上做出短时的决定。
“哪些应该算作核心功能？”这个问题的答案很简单，“迄今为止所有完成的功能都算”。
基于这个结论，你可以得出等式，“完成的功能=核心功能”。
既然该功能已经完成，那它必须包含在此次发布里面。
你不由得啼笑皆非。

29. Lewis与Clark：项目团队在前期投入精力，探索领域并发掘潜能。

它们分配一些预算对问题域进行探索，以判定可能发生的情形，以及针对该问题域启动项目的切实可行性。

项目团队中的探索者从抽象的角度来开展探索工作。
他们不关心谁在处理什么，或者涉及了哪些机器和个人。
相反，他们检查各种条件，看能引发什么点子，产生什么机会，以及该工作未来可能是什么情形。
他们寻求着机会和点子，这些机会和点子一旦被证实，将会给探索的发起机构带来最可观的潜在收益。

30. 短铅笔：连续不断的成本削减开始影响到组织完成任务的能力。

对于组织而言，保持与竞争对手一样低水平的费用开销是至关重要的。
很显然，太多的成本削减会导致组织缺乏竞争力，最终甚至引起成本的增加。

我们需要区分成本削减和组织的贪欲。

31. 节奏：团队通过定期交付，建立起工作的节奏。

作为经理，你应该抑制住操纵节奏或者通过加快节奏以提高生产率的欲望。
团队建立起自己的节奏，驱动着团队进行有规律的交付。
无论艰巨任务还是日常事务，如果能够按照持续的节奏去做，它们都会变得易如反掌。
想想翻越高峰的目标，采取有规律的步调建立起属于你自己的节奏。

32. 加班预兆：经理认为，项目早期的加班表明项目的健康状况非常令人满意。

经理们，特别是年轻的经理们，都很乐意看到手下的人把额外的空闲时间投入到项目上。
他们把这视为一种信号，表明自己在团队鼓舞和个人激励方面做得很好。
每个人正如预期的一样，都是态度坚决的把项目带回家。
但是，这也有可能源于人们在工作中产生的无望感，早期的，持续的加班很可能表示项目团队正处于恐惧之中。

33. 扑克之夜：来自组织各个部门的雇员聚集在一起，参加与工作角色无关联的活动。

对于组织中平时不常打交道的人而言，培养他们之间的私人关系对于组织中的重要工作可以起到润滑剂的作用。

34. 错误的质量关卡：项目中的质量保证工作着眼于格式检查，而这些工作根本不能给真正产品质量带来任何改善。

仅仅是文档通过语法完备性检查并不能说明它就复合了目标。
拥有错误质量关卡的组织关注交付物的语法和形式，却忽视了内容。

如果你使用的是错误的质量关卡，就会发现质检过程传回来的大多数反馈都是关于交付物的形式，而不是交付物的内容含义。
该模式把时间浪费在不具备产出性的步骤上面，而且更为严重的是，与内容相关的缺陷却溜进了最后的产品之中。

35. 测试之前先测试：测试可不仅仅是测试（而且应该在测试之前进行）。

早期测试的目的是给后来阶段的测试提供精准的标准以衡量解决方案。

在测试阶段之前的测试意味着在最开始的项目讨论时期就引入质量控制。
在采用早期测试的项目中，早期的交付物在下一步骤开始之前都会被测试检查，看是否值得继续。
这种早期测试的关键在于尽可能早的揭晓尽可能多的错误概念，误会，冲突，不现实的期望等。

36. 苹果酒屋规则：项目团队成员罔顾或者绕过那些由项目工作无关人士制订的规则。

“苹果酒屋规则”的问题在于制订规则的人并不在苹果酒屋里面居住，也没有任何搬进去住的想法，却反而由她来给住在酒屋里面的人制订规则。

一些开发组织也制订了类似的苹果酒屋规则。
没有参加项目实际工作的人给那些参加项目实际工作的人制订规则。
这样的组织往往存在着一个流程改进部门，或者成为标准组，又或者叫做质量部门，它们的工作就是规定工作的流程或者方法。
这些部门兴许还会为项目选择工具，或者为项目的交付物制订标准。
这些都是由外行来制订规则指导项目团队应该怎样工作，而他们对于工作甚至都没有一点靠谱的理解。

37. 说，然后写下来：项目团队在交谈间得出了决定，然后立刻用书面形式记录下来以供交流。

书写把对话持久化下来，而记忆不可能做到这一点。
用书面方式交流决定，可以为那些没有在场或者忘记细节的人们保存决策制订的对话过程。

38. 项目中贪多求全：组织经常贪多求全就会放慢速度，最终导致净效益降低。但是那种诱惑可能是无法抵抗的。

在这个成本削减和雇员缩减的年代，涌现出了一种舆论，它认为公司并没有全力开发足够多的软件，因而失去了建立真正战略优势的机会。
如果你对这一舆论颇以为然，不妨花几分钟反过来想想，也许IT公司正在开发太多的软件。

在21世纪，似乎所有的事情都应该在昨天完成。

接受超出团队处理范围的工作是管理层怯懦的表现。
为了避免个人遭受指责，却亲手把团队置于不可能成功的境地之中。
最终，团队会饱受超负荷工作之苦，在组织里面受到的尊重度下降，就因为你没有勇气在第一时间说“不”。

怎么做才能逆转这种恶性循环呢？
给工作任务排定优先级，只做你最大能力范围之内的事情。
把低价值的工作放在一边，先完成高价值的工作。

承担超出最大能力范围的工作是变得迟缓的罪魁祸首。
大家无视这个问题解释了为什么如此多的组织因为试图完成大量的工作而让自己慢到几乎停滞。

39. 巨神阿拉斯特：团队领袖（几乎）擅长于一切事情。

作为一个名副其实的领导兼经理，她没有给团队的其他成员安排任何重要的领导或管理工作。
结果自然就是她没有把它们作为领导来培养。

40. 所有人都穿着衣服是由原因的：完全公开的政策让进度慢慢停下来，停下来，最终完全停下来。

信息冗余导致注意力涣散。
当吸引注意力的信息量太多时，我们会处在超负荷的状态之中。
即使信息再多，又有何用？

如果在你的组织里面，所有人都需要知道所有的事情才能完成工作，那你可就前景不妙了。
太多的信息可能是一件坏事，这一点无论如何强调都不过分。
但更大的问题在于首先理解为什么我们让自己承担如此之多。

至于我们给自己加上信息的重枷，一个更常见的原因是信息焦虑——害怕自己不知道别人知道的东西。
知道多少信息是和自己的信息餐碟，不仅仅是一项好的策略，而且是成长的一部分。

41. 同事预审：组织让将来与应聘人共事的员工也参与到招聘过程中来。

42. 浮潜与水肺潜水：不同形式的分析活动贯穿项目的整个生命周期，自上而下，自下而上以及先中间后两边。

在相同的时间内，浮潜潜水员可以游历更宽阔的水域，而水肺潜水员则能潜游得更深入。
成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用，在特定的时刻明智的选择合适的方法，从而有效的利用时间。

浮潜是一项很好的技术，项目团队可以用它来弄清楚需要研究多少领域，以理解问题和达成目标。
当潜水员感觉到一些有趣的东西，陌生的事物或者更深的细节信息需要考察时，他会进行较深的水肺潜水。
深度潜水的发现常常会改变浮潜阶段所作出的假设。

本模式的反例是团队要么沉迷于细节，要么惧怕细节。
并且，人们谈论起“更高层次”和“细节”就好像它们是独立的东西，与正在从事的项目无任何关联。

优秀的开发人员不会画地为牢，它们即可以浮潜，也能水肺潜水。
他们依据自己需要考察的对象来选择技术。
侦察的时候，浅层潜水就已足够，但如果审察，就需要更深的潜水了。

43. 一切都是该死的接口：项目团队成员毫不妥协的强调接口——既在产品里面，也在人与人之间。

康威定律：产品反映了制造该产品的组织结构。
对于接口，这一点尤为正确，项目中复杂的人类接口容易导致复杂的产品接口。

44. 蓝色区域：团队至少有一位成员经常性越职。

绝对服从可能是有害的，某些善意的无序反而是有益的。

45. 消息美化：坏消息在组织里面没有准确的向上传达。

在有些组织里面，坏消息从来不上报。
更为普遍的是，坏消息在一级一级往上传达的过程中被美化了。

消息美化是一种破坏性模式，因为它使决策者得不到所需要的信息，这又可能导致错误的决策，结果反而更糟。
如果信息流动更为有效，那么许多众所周知的错误决策原本可以避免。

当你在项目中观察到这个模式，最典型的症状是出现意外，典型的后果就是延误了一个又一个截止日期，从而达不到期望的结果。
刻意隐瞒坏消息可能使得可解决的问题变成无法解决的问题。
那些原本能对意外的延误有所作为的少数人——控制着资源，给项目设定外部期望的高级经理——得不到采取纠正举措的机会。
如果他们可以在足够早的时候就知道待完成的工作与可用的资源和时间之间的关系不对等，他们就能在足够早的时候提供更多的资源，或者重新调整范围，或者延长计划时间，以避免在最后关头出现延误。

送来坏消息的人会吃到苦头，消息美化就变得不可避免。

团队成员在他们能够证明之前，就知道项目陷于困境。
在有些文化之中，声称达到预定日期有问题的团队成员很有可能会遇上那个臭名昭著的质疑，“你怎么这么肯定你们无法做到？”
由于不想被视为悲泣者或者懦夫，团队成员就此缄口不言，直到灾难已经无可置疑（而且通常也是无可避免）。

经理不能仅仅在口头说希望即时得到坏消息，还得那样去做。
最起码，这意味着把坏消息的反应分成两个部分。
（1）决定如何处理（2）弄清楚它是怎么发生的。
首先关注第一部分，不要马上清查为什么坏事情会发生。
相反，把精力放在督促团队上面，提出“改进”计划，然后落实到行动。

46. 慢慢的道出事实：公司文化迫使人们把令人不安的消息埋在心底。

许多文化都会传达出这种信号，那就是——如果你发现了杂乱不堪的现象，你就得负责清理。
指出问题，却又不立刻提出改进措施——这会被认为是在发牢*。
在很多组织里面，发牢*的职业生涯是有限的。

47. 残局游戏：团队在整个开发过程中定期的使用交付标准检验构建中的产品。

---

83. 不从教训中学习：团队认识到自己的错误，却一次又一次的重蹈覆辙。

对于每个人都承认的失败，如果不想办法去改进，去汲取教训，那么同样的失败会一再发生。
在项目结束的时候召开经验学习会议是朝着正确方向迈出的一步，但它还不够。
很可能即便仔细检视了以往的行为，却依然无法获得回报。

项目结束之后举行回顾会议的项目往往发现自己强调的问题，在严格意义上都不是项目内部的问题。
这些问题根源于外部给项目强加的约束。
因为这些问题都超出了团队的范围，它们的解决方案可能会被认为是僭越了职权。

虽然我们忙得焦头烂额，但是要把完全处于团队范畴之内的变更落实到实处，其实难度很可能非常大。
怪不得回顾有时变成了单纯的抱怨会议，也没有严肃的意愿来改变任何事情。

当经验学习的过程主要是以发泄而结束时，你会发现公布的结果都是人们的观察结果，而不是行动事项。
关键在于坚持为每一个明确的问题（不论是团队权力范围之内还是之外）制订具体的行动方案。
把找出来的每一件没有帮助到团队或者曾经阻碍过团队的事情，与将在下一次迭代或者版本（又或者下一个项目）中付诸实践的某一项行动事项关联在一起。
这样就把经验学习的团队带入了建设性设计的模式。

开这种会时，还有一个操作上的小技巧。
那就是让每个人最少准备关于项目的一件好事情和一件坏事情出席会议。
一个相似的技巧能够帮助团队在回顾时成功激发变更。
坚持至少有一项行动方案完全属于团队范畴之内，并且至少有一项行动方案是部分或者全部属于团队之外。

每一项行动事项都应该指出将如何修改某些方法，任务，人机界面或者强加的约束以避免下一次出现同样的问题。
行动方案必须明确，而且它们必须拥有一个特定的目标指引变化的进行，让变化落实到那个目标。

选择和当下的自己相称的物品

断：行动
（1）购物时要三思而后行
（2）不需要的东西就不接受
（3）只添置必需的物品

舍：行动
（1）收拾没用的破烂儿
（2）卖掉，赠送物品
（3）缩小喜好的范围

离：状态
（1）脱离执念
（2）了解自己，爱上自己
（3）心情愉悦

断舍离：通过收拾物品来了解自己，整理自己内心的混沌，让人生更舒适的行为技术。
通过收拾家里的破烂儿，也整理内心中的破烂儿，让人生变得开心的方法。

断：断绝想要进入自己家的不需要的东西
舍：舍弃家里到处泛滥的破烂儿
离：脱离对物品的执念，处于游刃有余的自在的空间

断舍离的主角并不是物品，而是自己。
你要做到的思考方式并不是“这东西还能使，所以要留下来”，而是“我要用，所以它很必要”。
主语永远都是自己，而时间轴永远都是现在。

现在自己不需要的东西就必须放手，只选择必要的物品。
通过这个过程，你可以从看得见的世界走向看不见的世界，最终实现对自己的深刻，彻底的了解，
并接纳最真实的自己。

并不是心灵改变了行动，而是行动带来了心灵的变化。
只要有所行动，心灵就会跟上脚步。
可以说，断舍离就是一种动禅。

---

收拾就是要扪心自问某件物品与当下的自己是不是确实有关系，进而对物品进行取舍，选择的过程。
只有对当下的自己合适且必需，也确实在用的东西，才会留在你自己的空间里。

所谓时时更新，就是说我们要不断进行更换。
如此一来，只要认真的收拾下去，你就会自然而然的在把东西搬回家之前认真思考一番，
考虑东西现在对自己是不是真的有用，然后做出正确的选择。

在思考的过程中，你逐渐会认清，原来在你的生活里竟然充斥着那么多没用的东西。

---

断舍离并非绝对要以把房间弄干净为目的，而是要通过收拾的过程了解并喜欢上真实的自己，实现自我肯定感。
断舍离的助教不是物品，而是自己，考虑的是“我自己”还需不需要它。
“扔了很可惜，还是留下来吧”这种想法，就是拿物品当主角。

德国诗人，哲学家歌德曾经说过这样一句话：“人类最大的罪是不快活。”
所以，让人变得快活是让一切变好的先决条件。
而且，不是他人快不快活，而是自己。

断舍离的任务就是，取回以往所有被浪费掉的这一切。
在最初阶段，你要先分析自己到底被这些物品夺去了多少能量，然后通过筛选物品的行为，实现自我完善。

好东西都能毫不犹豫的扔掉，可就是对这些廉价的东西恋恋不舍。
当直面自己这种不可理喻的心态后，自己在潜意识里似乎很是畏惧那些高价，高品质的物品，
觉得用便宜的东西就刚刚好，很合适。
这就表示，自己有一个很不好的习惯 —— 自我贬低。

---

说到底，这些东西到底值得我花那么多功夫，时间，金钱和劳力去收拾吗？
当突然察觉到这一点之后，我开始舍得扔东西了。
不过扔了之后就能收拾好了吗？
其实，因为那个时候还没有“断”的想法，所以即便舍得扔东西了，可扔了之后还会再买，买了以后再扔，如此循环往复。

一到换季的时候，很多人都会觉得自己没衣服穿，可衣柜里明明已经塞满了衣服。
这就是典型的“明明是已经不会再穿的衣服，可却因为有感情，所以只能收着”，也就是一种“说是有可却没有，说没有可是却有”的奇怪状态。

以此为契机，我发现了那个一到季节更替就觉得没衣服穿的自己，
也发现了自己到底有多少丢在衣柜里永远不会再穿的衣服。
这其实并不是留恋，而是一种执念。

如何对待自己，就决定了一切。
这种改变最初会体现在物品的世界里。
从家里的衣柜，抽屉开始，进行有意识的改变，慢慢就连你与周围人的关系都跟着改变了。

---

你的家到处都充斥着用不着的破烂儿，就算你把它们收拾的再整齐，也没有任何意义。
实施收纳术，应该从这个阶段之后开始。

不但确保每样物品都在自己的掌控之下，自己能确实用到它，还要和它成为好朋友 —— 和自己喜欢的东西生活在一起。
这样的话，就是达到了“断”。
在买东西的时候会反复思量，让物品物尽其用，并且确保它能把它的功效发挥到极致，一直到用完，这就是断舍离的最终阶段。

让身边的物品保持优胜劣汰的自然循环，要留下适度的量，又确保留下的都是精挑细选过的，
那么就会将物品的丢弃程度降到最低。
以往总是塞东西，把东西堆了又堆，接下来必然就是扔了再扔，这真是让人伤透脑筋。
不过等到了这个全新的阶段，你身边留下的都是精心筛选留下的，适量的物品，性能又高，又美观。
这样一来，你的居住空间里放着的，都是自己最重要的东西了。
这就是不收拾的收拾法的最终形态。

换句话说，这其实是一个连收纳物都不需要的空间，是连收纳术都没有用武之地的世界。

---

断舍离前：对物品的数量与质量没有自觉。
初级：意识到物品的数量与质量判断是否需要，直面对丢弃的迷惘
中级：快速判断物品是否必需，不会拿可惜当借口，习惯了果断与下狠心
大师级：致力于精挑细选，物尽其用，物品能用完。物品的舍弃降低到最小限度，享受清爽和满足感。

多数时候，人都是因为自己吃东西的方式不对才出现问题。
并非物品不好，而是因为自己判断失误才导致物品冗余堆积，导致自己行动困难。

扔掉家里的一件垃圾，这个简单的动作就能磨砺你的内在智慧。

---

物品要用才有价值。
物品在此时，当下，应该出现在需要它的地方。
物品处于恰当的位置，才能展现美感。

说到底，物品会因为所在场合的不同而变得无用或是有用。
所以，首先要通过有意识的选择让物品自然而然的回归到它应该在的地方，回归到需要它的地方。
这就是断舍离要做的。

---

我们会在不知不觉中掉进折扣的陷阱，完全忘记了“东西是不是适合自己的品味”。

如果仔细推敲的话，他们并非扔不掉，而是根本就不想扔。

除掉废物，垃圾，灰尘，就能彻底除掉停滞运与腐败运。

居住环境是凭借一己之力可以改变的环境，要打造出能够款待自己的空间。

---

选择物品的窍门，不是“能不能用”，而是“我要不要用”，这一点必须铭刻在心。

你舍不得扔掉的东西，是不是一年十二个月有十一个半月都派不上用场呢？

扔掉多余的信息，就能尽早从头脑的“便秘”中解脱出来。

希望你不要认为“可惜”是不用扔东西的赦免令，而是对物品的爱惜之情。

物品是一面能映照出真实的自己的镜子，直面物品，就是直面真实的自己。

---

只集中于一点做到完美，就能不知不觉的打开收拾的突破口。

把自己用不着的东西送给有需要的人时，要说“请收下”，不能说“给你”。

通过限制总量，更加严格的筛选出自己喜欢的物品，自然而然的提升了品味。

---

所谓断舍离，就是训练自己成为能够信赖的自己，最终彻底脱离“没法收拾的自己”。

物品是自身的投影，既然如此，物品既棒又新鲜就是最重要的。

凡能采用分工制的工艺，一经采用分工制，便相应地增进劳动的生产力。
各种行业之所以各各分立，似乎也是由于分工有这种好处。
一个国家的产业与劳动生产力的增进程度如果是极高的，则其各种行业的分工一般也都达到极高的程度。

有了分工， 同数劳动者就能完成比过去多得多的工作量， 其原因有三：
第一，劳动者的技巧因业专而日进；
第二，由一种工作转到另一种工作，通常须损失不少时间，有了分工，就可以免除这种损失；
第三，许多简化劳动和缩减劳动的机械的发明，使一个人能够做许多人的工作。

---

引出上述许多利益的分工，原不是人类智慧的结果，尽管人类智慧预见到分工会产生普遍富裕并想利用它来实现普遍富裕。
它是不以这广大效 用为目标的一种人类倾向所缓慢而逐渐造成的结果，这种倾向就是互通有无，物物交换，互相交易。

但人类几乎随时随地都需要同胞的协助，要想仅仅依赖他人的恩惠，那是一定不行的。
他如果能够刺激他们的利己心，使有利于他，并告诉他们，给他作事，是对他们自己有利的，他要达到目的就容易得多了。

不论是谁，如果他要与旁人作买卖，他首先就要这样提议。
请给我以我所要的东西吧，同时，你也可以获得你所要的东西：
这句话是交易的通义。

我们不说自己有需要，而说对他们有利。

这样一来，人人都一定能够把自己消费不了的自己劳动生产物的剩余部分，换得自己所需要的别人劳动生产物的剩余部分。

人们天赋才能的差异，实际上并不象我们所成觉的那么大。
人们壮年时在不同职业上表现出来的极不相同的才能，在多数场合，与其说是分工的原因，倒不如说是分工的结果。

人类如 果没有互通有无、物物交换和互相交易的倾向，各个人都须亲自生产自己生活上一切必需品和便利品，
而一切人的任务和工作全无分别，那末工作差异所产生的才能的巨大差异，就不可能存在了。

---

舍比咨询法则，
咨询第一法则：无论客户和你说什么，问题始终存在。
咨询第二法则：无论问题最初看起来怎样，它始终是人的问题。
咨询第三法则：不要忘记客户是按时间付费，而不是按你的解决问题的程度付费的。

经理人不想承认自己有问题

在管理文化中最糟糕的事莫过于向别人承认你不能凭一己之力解决某个问题。
如果你真的需要帮助，就必须悄悄的向对方透露，而不能在公众面前承认出现了问题。

没有一个正在接受治疗的病人会认为自己很健康，但是咨询第一法则说没有人会承认自己在生病。
因此顾问就面临一个大问题，解决的方法之一是承认客户是称职的，然后询问他是否有需要改进的地方。

很少有人愿意承认自己在生病，但绝大部分人都愿意承认自己需要改进，除非它真的病了。
但是要小心，不要为得到工作而过于热情的给出太多计划，
如果你承诺的太多，反而不会被聘用，因为这样会迫使他们承认遇到了问题。

咨询第一法则的一个推论就是，百分之十承诺法则，
不要承诺会有百分之十以上的改进。

另一个推论就是百分之十解决法则，
如果你不小心取得了超出百分之十的改进，要保证这部分改进不被注意到。
当然，不被注意到的最好方法就是让客户享受到所有的这些荣誉。

经理人总是会用技术问题掩盖自己的问题

经理人往往会把他们遇到的问题称为“技术问题”以避免承认自己的问题，
技术问题往往不被认为是经理的责任，
因为在高科技行业中不可能聘请到所有需要的专家。

即使“真的”是技术问题时，这些问题通常也能追溯为管理活动或是管理懒散。
即使如此，有经验的顾问也不会指出是雇佣了所有技术人员的经理人应对问题负责，
与此同时，顾问应寻找能阻止问题的发生的人，或是在问题出现时能解决问题的人。

咨询第二法则的一个推论是玛威法则，
不论客户在做什么，给他一些其他方面的建议。

问题缠身的人总是愿意重复做那些从第一次开始就没起作用的尝试，
如果这种尝试真能起作用，那他们也就不用聘请咨询顾问了。

经理人并不想解决问题

要想成功，你首先必须要使客户承认他出了问题，
然后那个问题还要足够大，才能证明付给你解决问题的费用是合理的。

咨询第三法则实际上提醒了顾问，如果客户想要解决“问题”，
那么他们早就应该按解决程度来付费了。

深入一点来说，他们只是想能够对他们的上司说，
“看，我们意识到了问题并试图解决它，我们已经请了咨询顾问。”
然而，当顾问离开后，情况就变成了，
“怎么能期待我们去解决问题呢？我们为了一个高新顾问付了三个月的薪水，问题也没能解决。很明显，问题无法解决。”

总而言之，经理人不会花钱买解决方案，那只是给上司的托词。
咨询第三法则的一个推论是赏识规则，
如果你在意谁得到了赏识，你就永远不能完成任何事。

对于顾问来说，要想获得赏识，客户就得承认问题得到了解决，
承认问题得到了解决，就得承认出现了问题，而这是不可想象的。
因此，只有那些看起来似乎什么都没完成的顾问才会再次得到邀请。

雇用顾问的经理人只是想向人证明问题无法解决

经理人和顾问都是凭着自己解决问题的能力赚钱的，
任何一方承认需要对方的帮助将被认为是自己有所不足。
只有最好的经理人和顾问才能伟大到承认他们不能凭一己之力完成任务。

相同的矛盾也可以应用于所有请了咨询顾问的人。
实际上你可以将顾问定义为，
能帮你解决那些本来你认为自己能解决的问题的人。

因此，雇用顾问通常好像是承认个人失败，
而没能够解决问题的顾问可以被解释为客户的个人胜利——除非客户以首席执行官的身份雇佣顾问。
因此，顾问的失败与否还是取决于客户。

这就是导致了我的最后一个法则，
咨询第四法则：如果他们没雇佣你，就不要为他们解决问题。

咨询第四法则告诉你，
千万不要让自己忘记咨询是在他人的请求下去影响他的艺术。
在咨询顾问当中最流行的职业病就是主动提供“帮助”。

渐变

温伯格法则：在绝大多数时间里，在世界上绝大多数地方，不管人们工作的多辛苦，
都不会有什么重大事情发生。

对于这个世界的大多数体系，
对于下一时刻状态的最好的预测就是同前一时刻的状态相同。

温伯格法则告诉他们，大部分的努力的结果会是零，
哪怕他们只是想改变自己而已。

第二糟糕的问题

我这个伟大的建议有个致命的缺陷，我可以把最糟糕的问题拿开，
但是总会把原本是第二糟糕的问题带出来。

我教书的时候经常遇到一些令人头疼的学生，他就是我最糟糕的问题。
如果我劝他降级，我就能清闲一阵，我会想：“现在我最爽了”。

然而我的想法刚一形成，另一个学生就会开始惹祸。
这个新的令人头疼的学生本来是次糟糕的问题，但现在最糟糕的不在了，她就上升到首位了。

鲁迪芜菁甘蓝规则：
一旦你消除了你的头号问题，第二号问题就会升级。

作为顾问，我经常卷入客户的问题之中，以至于我开始相信自己实际上能够永远使客户摆脱问题。
但是根据鲁迪规则，总还会有另外的问题出现。

艰难法则

艰难法则：如果你不能接受失败，你就不能成为顾问。
很艰难法则：一旦消除了你的头号问题，你就会把第二号问题升级上来。

这是否意味着你必须放弃解决问题？
根本不是。
这意味着你必须放弃你能彻底解决问题的错觉。

一旦你放弃了这种错觉，你就能不时的放松自己，让问题自己照顾自己去吧。

最艰难法则：帮自己甚至比帮别人更难。

放弃理性来战胜悖论

顾问处理的是变化，多数人是逻辑性的工作着。
大多数时间他们都不需要顾问。
他们需要顾问的时候通常是在逻辑不起作用的时候，通常是遇到了似是而非，左右为难或相互矛盾的东西。

一句话，他们感到困惑才会请咨询顾问。

如果逻辑总是起作用，就不会再有人需要咨询顾问，
因此，顾问总是要面对矛盾，不要理性，要合理。

认为自己是百事通的人最易被愚弄。
生活是如此重要，所以不必太认真。

最优化的成本

每一种职业都有职业病。
不能拒绝去解决问题只是顾问们的职业病之一。
但是最严重的职业病就是最优化。

每个提供解决方案的人都喜欢最优化。
这是优化申请的正常反应，这部分神经系统会对这样的要求产生反应。
“我们要用最少的成本解决问题”，“用最短的时间解决问题”，“我们必须尽可能的用最好的方式解决”，
对于一个健康的人来讲，优化神经收到这样的要求就会对嘴发出一个脉冲以做出反应，
“你愿意牺牲些什么？”

然而，对一个患病的人来讲，这种神经通道被打断了，
于是嘴里发出一些让人曲解的短语，比如，“好的，老板。我马上办，老板。”

最优化的成本可能是巨大的。

折中处理：你什么也不付出就什么也得不到。
在一个方向上运动，必然会导致在另一个方向上的消耗。

不同的风险

如果我确切的知道将来我需要什么，那么就不会存在折中问题了。

通常来讲，现在多投入一些时间至少能搞清楚将来需要花费的时间。

每一个生物系统都必须面对现在和未来的问题，未来与现在相比总是缺乏确定性。
要想幸存，物种就必须在现在做的更好，但还不能好到阻止明天可能发生的改变。
费舍基本定理：生物体对现在环境的适应性越强，对未来未知环境的适应性就越差。

你越适应，你的可改变能力就越差。
（一个人不可能同时既擅于改变自己，又能坚持自己的想法。）

顾问很少适应现在的环境，因此更具有潜在的适应性。
他们对现在/以后进行折中处理的感觉与那些问题缠身的人不同，
这使得他们成了有价值想法的来源，同时也使人们对他们产生了不信任。

与一个客户一起工作很长一段时间，推荐一些风险低的方案就可以建立信任。
但是时间久了，顾问对环境会更适应，因此就不大可能提供出真正伟大的想法。

橙汁测试

“他们可能会说这是办不到的。”——这种情况说明他们在橙汁测试中不及格。
“但我知道那些说‘没问题’的经理只是想得到这笔生意。”——这种人在橙汁测试中也不及格。

“这真是个问题，我能帮你，……这是所需要的费用。”
能不能支付相应的费用，不是宴会经理所要为我决定的。
这是我的工作，不是他们的工作。

我每天都在用这个测试。
只要我需要服务，我就会告诉他们我想要的，
他们会告诉我从他们那儿获取服务所需的费用，我决定值不值得去获得这项服务。

橙汁测试节约了用于和不合适的人讨价还价数百小时的时间。

错误的问题标签

最难的问题不会是贴着整洁的标签打包送来的，
相反，有时它们的装在贴着错误标签的袋子里。

这就是为什么它们会如此难对付。

医学的秘密

如果系统在自我治疗实践上有悠久的历史，那么顾问就应该倾向于用“无损害”方法。
对能够自我治疗的系统要温柔的处理。

工程第一法则：如果它自己没坏，就不要去修它。

玛威第一大秘密：在所有疾病中，90%会不治自愈——完全不用医生的救治。
玛威第二大秘密：再三治疗一个能自愈的系统将最终产生一个不能进行自愈的系统。
玛威第三大秘密：每一个处方都有两个部分，药物和确保药物正确服用的方法。
玛威第四大秘密：如果他们以前做的没有解决问题，那么告诉他们做些别的试试。
玛威第五大秘密：确保他们付给你足够多的酬金，以让他们能照你所说的去做。咨询中最重要的就是确定正确的酬金。
玛威第六大秘密：知道如何不如知道何时。

情商就是管理情绪的能力。

戈尔曼把情商概括为以下5个方面的能力：
（1）认识自身情绪的能力
（2）妥善管理情绪的能力
（3）自我激励的能力
（4）认识他人情绪的能力
（5）管理人际关系的能力
认识自己，管理自己，激励自己，认识别人，管理别人。

同人打交道的人情商要高，同事情打交道的人智商要高。

医学数据表明，人的疾病75%由情绪引起，经常把持愉悦的心情可以增寿5~7年。

智商高，情商也高的人，春风得意。
智商不高，情商高的人，贵人相助。
智商高，情商不高的人，怀才不遇。
智商不高，情商也不高的人，一事无成。

情商高的人会激励自己，也会激励他人。

任何人都会生气——这很简单。但选择正确的对象，把握正确的程度，在正确的时间，出于正确的目的，通过正确的方式生气。——这却不简单。
——亚里士多德《伦理学》

情绪的力量是巨大的，人的行为由情绪驱动，汽车由马达驱动。
强烈的感性会战胜理性，为朋友两肋插刀，为亲情忍受痛苦。
当人被情绪控制的时候，可能会失去理智。
因此，管理情绪至关重要。

人的情绪直接引起生理反应，情绪可以调动体能。

生活对理性的人来说是喜剧，对感性的人来说是悲剧。——霍勒斯·沃波尔

人脑海马体的功能是负责记忆事实，杏仁核的功能是负责记忆情绪。
海马体让你认出表姐的脸，而杏仁核则会提醒你是否喜欢她。
大脑有两个记忆系统，一个用来记忆普通的事实，另一个用来记忆刻有情绪印记的事实。

高智商的人个人业绩会很优秀，但是如果情商不高，其个人生活就会一团糟。
决定一个人成功的因素，智商占20%，其他因素占80%，其中最重要的是情商。
高智商的人抱怨怀才不遇，是因为情商不够。

在学校里获得高分不一定预示着成功幸福的人生。
擅长处理情绪的人，在人生的任何领域都有优势。
情绪技能出色的人在生活中也更有可能获得满足，由于掌握了提高自身效率的心理习惯而效率更高。
不善于控制情绪的人，常常会经历内心的斗争，其专注工作的清晰思考的能力受到破坏。

孩子所受的教育不应该只是知识和竞争教育，还应该包括素质与合作教育。
情商高有利于一个人在社会中生存和与人共事。

高智商的人为低智商的人工作，说明情商更重要。
高情商的人领导低情商的人。
高情商的人擅长调动别人做事，高智商的人擅长亲自做事。
成为拥有追随者的领导者需要有高情商，领导者是擅长调动别人情绪，让他们与自己共舞的人。

自我意识是对内在心理的持续关注，是自我观察，是跳出自己看自己。
自我意识，指的是在情绪发生时有所意识。

理性和感性共同完成决策。

管理情绪的目的是实现平衡，节制，不做激情的奴隶。

我们的很多活动都是在管理情绪，如休闲娱乐。

悲伤会使心力下降，降低我们对许多事情的兴趣。

大笑可以极大的促进人的智力。
启发一个人思维的一个有效途径是给他讲笑话。
大笑能使人思路更加开阔，联想更加自由，甚至能注意到平时可能忽略的人际关系。

同理心就是了解他人感受的能力。
同情心是指对别人的遭遇感到同情，但并没有体会到和别人一样的感受。
一个人缺乏同理心，就不会感受到别人的痛苦。

调节他人情绪的能力是处理人际关系艺术的核心。

有效人际交流的一个决定因素是人们运用情绪同步性的熟练程度。
如果人们善于与别人的情绪协调一致，或者很容易让别人的情绪跟着自己的走，他们的人际互动在情绪层面就会顺利得多。
成功的领导者和演说家都是善于调用公众情绪的人。

人际智能由四种能力组成：
组织团队——领导者的基本技能，发动并协调团队努力开展工作
协商解决办法——调停的才能，防止冲突或解决突发危机
人际联系——同理心，处理人际关系的艺术
社会分析——能够体察和领悟他人的感受，动机和关切
跟具有这四种技能的人相处会非常愉快，而且这种人具有持续改善的能力。

婚姻忠告对男人：不要回避冲突，妻子发泄不满或者提出分歧，是为了维护婚姻的健康。避免太早提出实际的解决方法，对她的感受产生同理心更重要。
婚姻忠告对女人：可以抱怨他们的行为，但是不要进行人身攻击或者表达轻蔑。

人在压力下会变得愚蠢，在团队中无法控制怒火，对同事的感受麻木不仁，可能产生灾难性的后果。

批评别人的艺术：具体，提供解决办法，当面表达，保持敏感
接受批评的艺术：把批评当做建议，不要自我保护，把批评当做机会

工作的单元是团队而不是个人，情商是促使人们协调一致的技能。
团队完成任务质量的高低取决于群体智商的高低。

人体的免疫系统像人脑一样具有学习能力。

帮助人们更好的调节不安情绪是预防疾病的一种方法。

孩子是异常敏锐的学习者，家庭生活是个体情绪学习最早的学校。
父母情商高，本身就会使孩子受益无穷。

如果父母长期以来用某种特定的模式对待婴儿，到了一定程度，基本的情绪经验就会灌输到婴儿身上。
纯粹的忽视可能比直接虐待更为有害。

基因本身不会决定行为，我们的环境，经验和知识塑造了我们的气质倾向。
情绪智力不是天生的，通过正确的学习可以得到改善。
童年是情绪教育的关键时机。

情绪盲，指管理情绪的知识匮乏，情绪不适应环境，缺乏情绪竞争力。

控制脾气的方法：走开，或数10下。

悲观的看待生活的挫折，感到无助或绝望，是抑郁症的来源。

国家主要的希望在于对青年的正确教育。——伊拉斯谟

避免冲突的办法：要沟通，不要随意猜测，不要急于下结论。

无论是成年人还是学生，在情绪不稳定的时候，都需要一定的帮助才能保持清醒的自我意识。
陷入泥潭不能自拔时，需要别人拉一下。

情绪教育可以帮助儿童胜任人生中的种种角色，整个社会也会因此受益。

你们是否清楚团队的生产率？
要想在将来得到投资，开发团队就必须清楚自己的软件生产率。
如果团队不清楚自己的生产率，那么产品负责人就无法用可靠的发布日期来创建产品路线图。
如果没有可靠的发布日期，公司的产品就可能会失败，投资人的钱就有可能化为乌有。

Scrum和XP都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。
迭代要短，有时间限制，将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。
他们不会花时间用建模来画UML图，编写完美的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。
实际上，Scrum和XP都关注如何把事情做好。
这些团队承认在开发过程中会犯错，但是他们明白，要投入实践中，动手去构建产品，这才是找出错误的最好方式。
不要只是停留在理论层次上对软件进行分析和设计。

Scrum的强大和令人痛苦之处，就在于你不得不根据自己的具体情况来对它进行调整。

产品backlog是Scrum的核心，也是一切的起源。
从根本上说，它就是一个需求，或故事，或特性等组成的列表，按照重要性的级别进行了排序。
它里面包含的是客户想要的东西，并用客户的术语加以描述。
我们叫它故事（story），有时候也叫作backlog条目。
我们的故事包括这样一些字段：ID，名称，重要性，初始估算，如何演示，注解

在sprint计划会议之前，要确保产品backlog井然有序。
产品backlog必须存在。
只能有一个产品backlog和一个产品负责人。
所有重要的backlog条目都已经根据重要性被评分，分数只是比较级，不表示量级。
产品负责人要知道为什么这个故事会在这里。

产品负责人之外的人也可以向产品backlog中添加故事，
但是他们不能说这个故事有多重要，这是产品负责人独有的权利。
他们也不能添加时间估算，这是开发团队独有的权利。

举办sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰的工作，
也是为了让产品负责人能对此有充分的信心。
sprint会议会产出一些实实在在的成果：
sprint目标，团队成员名单，sprint backlog，确定好sprint演示日期，确定好时间地点举行每日scrum会议。

为什么产品负责人必须参加sprint计划会议？
原因在于，每个故事都含有三个变量，范围，重要性，估算，
它们两两之间有强烈的依赖，范围和重要性由产品负责人设置，估算由团队设置。
在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。

不能在质量上让步。
质量可以分为内部质量和外部质量，
外部质量是系统用户可以感知的，运行缓慢，让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。
可维护性包括系统设计的一致性，测试覆盖率，代码可读性和重构等等。

外部质量可看做范围的一部分。
假设产品负责人这样说：
好吧，你们把它估算成6个故事点也行。
但我相信，一定能够找到临时方案，节省一半时间。
你们只要稍稍动下脑子就行。

他想把内部质量当做变量来处理，因为他想让我们缩减故事的估算时间，但不想为缩减范围买单。
临时方案，这个词应当在你的脑中敲响警钟。

经验告诉我，牺牲内部质量是一个糟糕透顶的想法。
现在节省下来的一点时间，接下来的日子里你就要一直为它付出代价。
一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。

碰到这种状况，我就会试着把话题转回到范围上来，
既然你想尽早得到这个特性，那我们能不能把范围缩小一点？这样实现时间就能缩短。
也许我们可以简化错误处理的功能，把“高级错误处理”当做一个单独的故事，放到以后在实现。
或者也可以降低其他故事的优先级，好让我们集中处理这一个。

一旦产品负责人弄清楚内部质量是不可能让步的，他一般都会处理好其他变量。

sprint的长度，时间短有短的好处。
公司会因此而变得敏捷，有利于随机应变。
短的sprint = 短反馈周期 = 更频繁的交付 = 更频繁的客户反馈
= 在错误方向上花的时间更少 = 学习和改进的速度更快

但是长的sprint也不错，
团队可以有更多时间充分准备，解决发生的问题，继续达成sprint目标，
也不会被接二连三的sprint计划会议，演示等等压得不堪重负。

确定了团队喜欢的sprint长度之后，就要在长时间内坚持住。
虽然有的时候回稍微感觉有点长，有的时候感觉有点短。
但保持住这个长度以后，它似乎变成了大家共同的心跳节奏，每个人都感觉很舒服。
这段时间内也无需讨论发布日期之类的事情，因为大家都知道，每过三周都会有一个发布。

确定sprint目标，要用业务术语表达，而不是技术词汇。
sprint目标需要回答这个根本问题，
我们为什么要进行这个sprint，为什么我们不直接放假算了？
要想从产品负责人的口中哄骗出sprint目标，你不妨一字不差的问他这个问题看看。

决定哪些故事需要在这个sprint中完成，是sprint计划会议的一个主要活动。
更具体的说，就是哪些故事需要从产品backlog拷贝到sprint backlog中。
sprint中包含多少故事由团队决定，而不是产品负责人或其他人。

产品负责人如何对sprint放哪些故事产生影响？
他可以重新设置优先级，可以缩小故事范围，还可以拆分故事。

生产率，是对已经完成工作总量的一个衡量方式。
在sprint结束时，要对比估算生产率和实际生产率。
在sprint里面差不多可以完成的故事并不算完成，这是Scrum的要求，
把事情完全做完，达到可以交付的状态，事情只做了一半，它的价值就是0。

我们在估算生产率的时候，
看看团队的历史，看看他们在过去几个sprint里面的生产率是多少，
然后假定在下一个sprint里面生产率差不多不变。
这项技术也被叫做昨日天气。
要想使用该技术，必须满足两个条件：
团队已经完成了几个sprint，
会以几乎完全相同的方式来进行下一个sprint。

我们的估算不应该是物理人天，而应该是理想化的人天，是故事点。
一个理想化的人天是完美，高效，不受打扰的一天，还需要考虑各种影响因素。
我们引入投入程度这个概念，投入程度用来估算团队会在sprint中投入多少精力。
投入程度低，就表示团队估计会受到很大干扰，或者他们觉得自己的时间估算太理想化了。
要想得出一个合理的投入程度，最好的办法就是看看上一个sprint的值，或者取平均值。

假设在上一个sprint，团队工作了45人天，完成了18个故事点。
现在我们要为下一个sprint估算一下生产率，如果下一个sprint一共有50个人天，
那么估算的生产率就是20个故事点。
这表明团队下一个sprint中所能做的故事点数之和不能超过20。

在新团队使用的默认投入程度通常是70%，这是大多数团队都能达到的数值。

如果让整个团队进行估算，通常那个对故事理解最透彻的人会第一个发言。
不幸的是，这会严重影响其他人的估算。
有一项很优秀的技术可以避免这一点，它的名字是计划纸牌。
0 1/2 1 2 3 5 8 13 20 40 100 ?
在估算故事的时候，每个人选出一张卡片作为时间估算，并把它正面朝下扣在桌上，
所有人都完成以后，桌上的纸牌会被同时揭开。
这样每个人都会被迫进行自我思考，而不是依赖其他人估算的结果。
如果在两个估算之间有着巨大差异，团队会就此进行讨论，并试图让大家对故事内容达成共识。

重要的是，我们必须提醒团队成员，他们要对这个故事中所包含的全部工作进行估算。
而不是他们负责的部分工作，测试人员不能只估算测试工作。

故事的大小要合适，
我们常常都力求保证故事的大小在2-8个人天之间。
一个普通团队的生产率大约是40-60，所以大概每个sprint可以完成10个故事。
有时会减少到5个，有时也会多到15个。

任务和故事是不同的，
故事是可以交付的东西，是产品负责人所关心的，
任务是不可交付的东西，产品负责人对它也不关心。

为什么我们坚持所有的sprint都结束于演示？
一次做得不错的演示，即使看上去很一般，也会带来深远影响。
团队的成果得到认可，他们会感觉很好。
其他人可以了解你的团队在做些什么。
演示可以吸引相关干系人的注意，并得到重要反馈。
演示是一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作，这很有意义。
做演示会迫使团队真正完成一些工作，进行发布。
如果没有演示我们就会总是得到些99%完成的工作。
有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。
这比得到一堆貌似完成的工作要好很多，而且后者还会污染下一个sprint。
团队知道这次无论如何他们也要进行演示，一些真正有用的东西被演示出来的机会就会大很多。

不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。
把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。
节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。
可能的话，让观众自己试一下产品。
不要花太多时间，不用很好看，只要能传递信息就行。

在有关回顾的种种一切中，最重要的就是确保回顾能够进行。
由于某些原因，团队常常都不太愿意做回顾。
如果不给他们点温柔的刺激，我们的大多数团队都会跳过回顾，直接进行下一个sprint。
我认为回顾是Scrum中第二重要的事件，最重要的是sprint计划会议。
因为，回顾是做改进的最佳时机。
当然，你不需要在回顾会议上得到什么好点子，在家里的浴盆里就能做到。
如果没有回顾，你就会发现团队在不断重犯同样的错误。

我们发现，很多时候，只要能清楚的指出问题所在，到了下一个sprint，问题也许就自行解决了。
把sprint回顾结果贴在团队房间的墙上，会更有效。
在sprint中引入的每一点变化，都会让团队付出相应的代价，
在引入变化之前，可以先考虑什么都别做，寄希望于问题自动消失或变小。
如果每次有人发几句牢*，你就引入新的变化，那人们就不愿意再说小问题了，这就大为不妙。

Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践。
组合使用Scrum和XP会有显著收获。

结对编程可以提高代码质量。
结对编程可以让团队的精力更加集中，不去做与当前sprint无关的东西。
很多强烈抵制结对编程的开发人员根本就没有尝试过，而一旦尝试之后就会迅速喜欢上它。
结对编程令人精疲力竭，不能全天都这样做。
常常更换结对是有好处的。
结对编程可以增进团队间的知识传播，速度快到令人难以想象。
有些人就是不习惯结对编程。
可以把代码审查作为结对编程的替代方案。
不用键盘的家伙应该自己也有一台机器，不是用来开发，而是在需要的时候稍稍做一些探索尝试，或者遇到困难的时候查看文档等等。
不要强制大家使用结对编程，鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。

对我来说，TDD比Scrum和XP还要重要。
你可以拿走我的房子，我的电视还有我的狗，但不要试着让我停止使用TDD。
如果你不喜欢TDD，那就别让我进入你的地盘，不然我一定会想方设法来偷摸着干的。

下面是有关TDD的一个10秒钟总结：
测试驱动开发意味着你要先写一个自动测试，然后编写恰好能够用的代码，让它通过这个测试，
接着对代码进行重构，主要是提高它的可读性和消除重复。
整理一下，然后继续。

TDD很难，开发人员需要花一定时间才能掌握。
实际上，往往问题并不在于你用了多少精力去教学，辅导和演示。
多数情况下，开发人员掌握它的唯一方式就是跟一个熟悉TDD的人一起结对编程，
一旦掌握以后，他就会受到彻底的影响，从此再也不想使用其他方式工作。

TDD会把开发-构建-测试这三者构成的循环变得奇快无比，同时还可以充当一张安全网，
让开发人员有足够的信心频繁重构，伴随着系统的增长，设计依然可以保持整洁和简单。

TDD是很难，但是在一开始没有用TDD进行构建的代码库上实施TDD，则是难上加难。
如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧。
首先还是应该想办法简化手工回归测试，然后再考虑将真正的测试变成自动化执行。

增量设计。
这表示一开始就应该保持设计简单化，然后不断进行改进。
而不是一开始努力保证它的正确性，然后就冻结它，不再改变。

很多有关敏捷软件开发的书都声称：加班工作在软件开发中会降低生产率。
经过几次不情愿的试验之后，我完全拥护这种说法。
大约一年以前，我们中有一个团队在疯狂加班。
现存代码库的质量惨不忍睹，他们不得不投入绝大多数时间来救火。
测试团队根本没时间来认真做质量保证工作。
几个月后，我们成功的把大家的工作时间缩短到了适当的范围。
他们正常上下班，除了有时候在项目关键期要加班以外。
令人惊异的是，生产率和质量都取得了显著提高。

别把最慢的一环逼得太紧。
假设验收测试是你最慢的一环，测试人员稀缺，或者低劣的代码质量造成了过长的验收测试周期。
假设你的验收测试团队每星期最多测试3个特性，而开发人员每星期能够开发6个特性。
经理或者产品负责人，甚至团队会觉得不妨安排每周开发6个特性。
千万不要。你最终一定会认识到现实的残酷，可那时伤害业已造成。
实际上，应该每周只完成3各特性，多余的时间用来攻克测试的瓶颈。
例如，让一些开发人员去做测试人员的工作。
实现一些工具或脚本，用来简化测试工作。
增加更多的自动化测试代码。
延长sprint长度，把验收测试放到sprint里面来。
雇佣更多的测试人员。

回顾可以帮助我们更好的识别出最慢的一环。

宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的小团队强。
要想拆分小团队，必须确保他们彼此之间不会产生互相干扰。

如果注意观察，仔细聆听，也许你会注意到虚拟团队的存在。
你选择了使用大团队，不过观察一下sprint中的交流方式，你就能发现事实上这个大团队自动分成了两个子团队。
你选择了使用三个小团队的方式，不过观察一下sprint中的交流方式，你就会发现团队1和团队2一直在交流，而团队3比较孤立。

从到目前为止观察到的情况来看，3-8个人是最佳的团队尺寸。
假设你有一个10人的Scrum团队，那么就考虑一下把最差的两个人踢出去吧。

曾经有那么一次，在一个大型产品的开发过程中，我们实施不了Scrum，因为团队成员花了太多时间来救火，
拼命忙着修复早起版本的Bug。
这是个恶性循环，影响很坏，他们花了太多时间救火，最后根本没有时间进行前瞻性的工作来防火。
改进设计，自动化测试，创建监控工具和警报工具。

按时交付优秀软件是世界上最艰难的事情。

按时交付优秀的软件是尘世间最难得的喜事，
这需要对客户有透彻的理解，需要配备必需的团队，
需要与客户融合到一起并以客户为中心，需要有完善的产品定义，
准确的抓住市场热点，需要开发过程完美无瑕，
然后，产品才能一举成功，在发布会上闪亮登场，引来惊呼一片。

软件是一种知识产权，软件生产主要是一种智力活动。

大多数软件开发经理或领导者，并没有站在全局角度看待所承担的义务，
他们认为自己的工作要么是设计，要么是编码，要么是测试，要么是写文档，要么是营销软件，
要么是以某种方式“管理”软件开发过程。

让人们开始思考，人们应该思考些什么，以及如何让人们更有效的思考。

---

判断一个人是否在思考，最简单的方法，是看他是否注意倾听他人的观点和批评意见。
认真思考的人听到了可能比自己更好的想法时，会克制住争强好胜的念头。
他们会要求自己以谨慎的态度，公平正确的评估新得到的，可能很有价值的信息。

他们能够听出哪些话不够客观，是对方自我意识太强的反映，
因为他们完全理解了人性的本质，并运用这种理解对原始信息进行提炼。

软件表达了创建它的团队的心声。
在任何时刻，分析团队的言行，得到的结果可能会让你觉得十分困惑，但软件不会撒谎。

软件会揭示团队的一切。
他们具有的每一个优点和缺点，天赋和缺陷，下意识和小毛病和绝顶聪明之处。

创建软件的过程，就是十足的自我表达的过程。
软件从不说谎。

这个**是软件开发管理理论的基础。

在产品的设计之初，你就必须考虑到客户的期望。
然后，你必须在各种产品宣传材料中传达对产品的这种内在期望。
期望是一种情感状态，是对快乐的预期，是希望需求得到满足那种青涩的喜悦。

客户的最低期望，是你能了解他们在使用产品时的痛苦经历。

客户害怕新技术，在这方面，开发人员与用户并无两样。

伟大的软件首先是在适当的时机向市场推出适当的产品。
这意味着你必须知道如何交付产品，并了解客户最深层的需求。
软件满足的需求越深入，软件就越伟大。

---

软件研发的本质是信息加工和流动的过程，精益看板方法让团队利用可视化方法观察信息流动过程，
让团队学会利用这些信息来自主决策，逐步改善拥堵，加速流动。

精益软件开发七大原则：
（1）消除浪费
（2）增强学习
（3）尽量延迟决策
（4）尽快交付
（5）授权团队
（6）嵌入完整性
（7）着眼整体

1. 消除浪费
   何谓浪费？凡是对客户或产品不具备提升任何价值的行为，基本上都是一种浪费。

千万不要在没有做适度的拆解问题下进行时程的预估，因为那完全是在猜猜看。
猜是人类最糟糕的预估了，最少也要有参考依据，但是必须经过拆解成为较小的工作单元，参考才足以成立。

	制造业七大浪费	软件业七大浪费
1	库存	半成品，部分完成的工作
2	额外过程	额外过程
3	生产过剩	多余功能
4	运输	任务调换
5	等待	等待
6	移动	移动
7	缺陷	缺陷

软件开发是一种学习的过程。
也就是说，开发人员学的越快，写的程序才可能越正确，对客户也越有利。
因此程序设计人员从一开始就要下定决心把事情学好，然后再运用学会的专业知识来辅助写出正确的程序。

尽量延迟决策。
对流程而言：等到真正需要做改变的时候再做决策，提前的变更只会增加无形的成本。
对人而言：等到做决策所需要的信息较充分后，再来做判断会比较正确。

其实客户需要的不是软件，他们要的是解决他们的问题。

---

看板的本质是一个很单纯的想法，那就是半成品（work-in-progress，WIP）必须加以限制。

想要产品有好的质量怎么办呢？
“重视它”是提升质量的最有效的办法。
是的，就只是重视它，质量就会开始变好，这正是所谓的霍桑效应。

霍桑效应，指的是由于受到额外的关注，而引起努力或绩效上升的情况。

---

看板之父安德森曾经说过，优秀的团队坚持使用实体的看板。

看板方法背后有两条基础性原则：
（1）一条是限制WIP的数量
（2）另一条是仅当前面的工作字段有空位时，才可以通过拉动系统拉入新的工作项目。

设定WIP限额，不要一次做不能立刻完成（造成别人等待）的事情。

---

传统的时间管理观念是，只要提高工作效率，你便能掌控生活，从而内心感觉平和，而且会有成就感。
但是，效能并不能为你换来满足感的，人生也不见得会因产能的增加而变得更美好。

人们花太多时间，试图找到执行平凡目标的方法。

项目来不及时，应该先坐下来把原因弄清楚，
先找出造成项目来不及的变异性在哪里，这才是正确的措施。
增加人手只会先增加开发的时程，因为新人需要学习才能上手，而学习必须要有人教才行，把人力资源拿出来做教学，
当然只会让开发工作变得更慢。

---

阻塞不等于瓶颈。
瓶颈可能是资源受限于产能，或是非实时可用性资源出了问题。
阻塞，可能是什么特殊原因或变异造成的流程阻塞。

Clean Architecture

One of the goals of this book is to cut through all that confusion and to define, once and for all, what design and architecture are. For starters, I’ll assert that there is no difference between them. None at all.

The word “architecture” is often used in the context of something at a high level that is divorced from the lower-level details, whereas “design” more often seems to imply structures and decisions at a lower level.

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

The measure of design quality is simply the measure of the effort required to meet the needs of the customer. If that effort is low, and stays low throughout the lifetime of the system, the design is good. If that effort grows with each new release, the design is bad. It’s as simple as that.

---

Every software system provides two different values to the stakeholders: behavior and structure.

If you give me a program that works perfectly but is impossible to change, then it won’t work when the requirements change, and I won’t be able to make it work. Therefore the program will become useless.
If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change. Therefore the program will remain continually useful.

---

Notice the pattern that I’ve quite deliberately set up in introducing these three programming paradigms: Each of the paradigms removes capabilities from the programmer. None of them adds new capabilities. Each imposes some kind of extra discipline that is negative in its intent. The paradigms tell us what not to do, more than they tell us what to do.

Another way to look at this issue is to recognize that each paradigm takes something away from us. The three paradigms together remove goto statements, function pointers, and assignment. Is there anything left to take away?

---

The problem that Dijkstra recognized, early on, was that programming is hard, and that programmers don’t do it very well. A program of any complexity contains too many details for a human brain to manage without help. Overlooking just one small detail results in programs that may seem to work, but fail in surprising ways.

Dijkstra’s solution was to apply the mathematical discipline of proof. His vision was the construction of a Euclidian hierarchy of postulates, theorems, corollaries, and lemmas. Dijkstra thought that programmers could use that hierarchy the way mathematicians do. In other words, programmers would use proven structures, and tie them together with code that they would then prove correct themselves.

But the proofs never came. The Euclidean hierarchy of theorems was never built. And programmers at large never saw the benefits of working through the laborious process of formally proving each and every little function correct. In the end, Dijkstra’s dream faded and died. Few of today’s programmers believe that formal proofs are an appropriate way to produce high-quality software.

Of course, formal, Euclidian style, mathematical proofs are not the only strategy for proving something correct. Another highly successful strategy is the scientific method.

---

Science is fundamentally different from mathematics, in that scientific theories and laws cannot be proven correct.

That is the nature of scientific theories and laws: They are falsifiable but not provable.

Science does not work by proving statements true, but rather by proving statements false.

Dijkstra once said, “Testing shows the presence, not the absence, of bugs.” In other words, a program can be proven incorrect by a test, but it cannot be proven correct. All that tests can do, after sufficient testing effort, is allow us to deem a program to be correct enough for our purposes.

The implications of this fact are stunning. Software development is not a mathematical endeavor, even though it seems to manipulate mathematical constructs. Rather, software is like a science. We show correctness by failing to prove incorrectness, despite our best efforts.

Software architects strive to define modules, components, and services that are easily falsifiable (testable). To do so, they employ restrictive disciplines similar to structured programming, albeit at a much higher level.

---

The fact that OO languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted.

In short, when the source code in a component changes, only that component needs to be redeployed. This is independent deployability.

If the modules in your system can be deployed independently, then they can be developed independently by different teams. That’s independent developability.

What is OO? There are many opinions and many answers to this question. To the software architect, however, the answer is clear: OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies.

---

Why would an architect be concerned with the mutability of variables? The answer is absurdly simple: All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables.

Architects would be wise to push as much processing as possible into the immutable components, and to drive as much code as possible out of those components that must allow mutation.

To summarize:
• Structured programming is discipline imposed upon direct transfer of control.
• Object-oriented programming is discipline imposed upon indirect transfer of control.
• Functional programming is discipline imposed upon variable assignment.

What we have learned over the last half-century is what not to do.

---

Good software systems begin with clean code.

The goal of the principles is the creation of mid-level software structures that:
• Tolerate change,
• Are easy to understand, and
• Are the basis of components that can be used in many software systems.

• SRP: The Single Responsibility Principle
An active corollary to Conway’s law: The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change.
• OCP: The Open-Closed Principle
Bertrand Meyer made this principle famous in the 1980s. The gist is that for software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.
• LSP: The Liskov Substitution Principle
Barbara Liskov’s famous definition of subtypes, from 1988. In short, this principle says that to build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another.
• ISP: The Interface Segregation Principle
This principle advises software designers to avoid depending on things that they don’t use.
• DIP: The Dependency Inversion Principle
The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.

---

Components are the units of deployment. They are the smallest entities that can be deployed as part of a system. In Java, they are jar files. In Ruby, they are gem files. In .Net, they are DLLs. In compiled languages, they are aggregations of binary files. In interpreted languages, they are aggregations of source files. In all languages, they are the granule of deployment.

---

• REP: The Reuse/Release Equivalence Principle
The granule of reuse is the granule of release.
This is not simply because, without release numbers, there would be no way to ensure that all the reused components are compatible with each other.

• CCP: The Common Closure Principle
Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons.
This is the Single Responsibility Principle restated for components. Just as the SRP says that a class should not contain multiples reasons to change, so the Common Closure Principle (CCP) says that a component should not have multiple reasons to change.
The SRP tells us to separate methods into different classes, if they change for different reasons. The CCP tells us to separate classes into different components, if they change for different reasons.

• CRP: The Common Reuse Principle
Don’t force users of a component to depend on things they don’t need.
The ISP advises us not to depend on classes that have methods we don’t use. The CRP advises us not to depend on components that have classes we don’t use.
Don’t depend on things you don’t need.

---

Allow no cycles in the component dependency graph.

The component structure cannot be designed from the top down. It is not one of the first things about the system that is designed, but rather evolves as the system grows and changes.

Depend in the direction of stability.

One sure way to make a software component difficult to change, is to make lots of other software components depend on it. A component with lots of incoming dependencies is very stable because it requires a great deal of work to reconcile any changes with all the dependent components.

• Fan-in: Incoming dependencies. This metric identifies the number of classes outside this component that depend on classes within the component.
• Fan-out: Outgoing depenencies. This metric identifies the number of classes inside this component that depend on classes outside the component.
• I: Instability: I = Fan-out , (Fan-in + Fan-out). This metric has the range [0, 1]. I = 0 indicates a maximally stable component. I = 1 indicates a maximally unstable component.

A component should be as abstract as it is stable.

Thus, if a component is to be stable, it should consist of interfaces and abstract classes so that it can be extended.

Thus dependencies run in the direction of abstraction.

---

And the longer you wait to make those decisions, the more information you have with which to make them properly.

A good architect maximizes the number of decisions not made.

Good architects design the policy so that decisions about the details can be delayed and deferred for as long as possible.

---

Conway’s law says:
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

Architects often fall into a trap—a trap that hinges on their fear of duplication.

Duplication is generally a bad thing in software. We don’t like duplicated code. When code is truly duplicated, we are honor-bound as professionals to reduce and eliminate it.

But there are different kinds of duplication. There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance. Then there is false or accidental duplication. If two apparently duplicated sections of code evolve along different paths—if they change at different rates, and for different reasons—then they are not true duplicates. Return to them in a few years, and you’ll find that they are very different from each other.

---

Software architecture is the art of drawing lines that I call boundaries. Those boundaries separate software elements from one another, and restrict those on one side from knowing about those on the other.

---

Communications between components in a monolith are very fast and inexpensive. They are typically just function calls. Consequently, communications across source-level decoupled boundaries can be very chatty.

---

Software systems are statements of policy. Indeed, at its core, that’s all a computer program actually is. A computer program is a detailed description of the policy by which inputs are transformed into outputs.

A strict definition of “level” is “the distance from the inputs and outputs.” The farther a policy is from both the inputs and the outputs of the system, the higher its level.

---

Strictly speaking, business rules are rules or procedures that make or save the business money. Very strictly speaking, these rules would make or save the business money, irrespective of whether they were implemented on a computer. They would make or save money even if they were executed manually.

Business rules are the reason a software system exists.

---

Architectures are not (or should not be) about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.

Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and environments.

A good software architecture allows decisions about frameworks, databases, web servers, and other environmental issues and tools to be deferred and delayed. Frameworks are options to be left open. A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat, or MySQL, until much later in the project.

Frameworks are tools, not ways of life.

Your architecture should tell readers about the system, not about the frameworks you used in your system.

---

The overriding rule that makes this architecture work is the Dependency Rule:
Source code dependencies must point only inward, toward higher-level policies.

---

Tests are not outside the system; rather, they are parts of the system that must be well designed if they are to provide the desired benefits of stability and regression. Tests that are not designed as part of the system tend to be fragile and difficult to maintain. Such tests often wind up on the maintenance room floor—discarded because they are too difficult to maintain.

---

The organizational structure of data, the data model, is architecturally significant.

The data is significant. The database is a detail.

『技术』不能让一个企业运转起来，而『关系』能。
成功公式的一个最重要因素就是要明白如何与人相处。
如果你想让某个人与你为敌，只要告诉他『是你错了』。这个办法屡试不爽。
交谈的真正艺术在于不仅在正确的地方说出正确的事情，还在于冲动的时候不要说出错误的事情。

沟通，与他人有效交互的能力。
协商，将事情办成的能力。
领导力，施加影响来将事情办成。
政治，在政治场合与别人交互。

对人品的真正考验并非是我们知道怎么做，而是当我们不知道怎么做时如何做。
调动所有人积极性的最好办法之一是你在任何环境中都举止文雅，专业。
学习变得文雅专业的首页原则就是，注重关系甚于争执孰对孰错。
最大的利益在于学会建立关系，选择注重关系而非正确性。
经营关系的一部分就是文雅的接受反馈。

如果哪个人惹人讨厌，他（她）是不是有才能都几乎没区别，因为人们不愿意和他公事。
对照起来，倘若某个家伙人见人爱，他的同事就会想方设法的找出他哪怕一丁点才能。

记住这个黄金法则：『你怎样对待别人，别人就会怎样对待你』。

我感觉到要说什么并不重要，重要的是怎样以一种适当的途径来给对方传递信息。
许多成功的权利人士都有个共同点，就是他们有基于谁在场来动态切换语境的能力。

听得好是一种沟通与影响他人的有力手段，与说得好同样重要。
行业人士至少应听得与他们需要说的一样多，太多人没有意识到真正的沟通其实是双向的过程。
你可以有非常不错的主意，但如果你不能让别人听明白，这些主意就不可能让你有所成就。
学习有效沟通是一个终身的过程——永远都有改善的余地。

多说『是』，少说『不是』。
作为架构师，我们要寻求说『是』的方法。
学会把消极的负面回复，转化成积极的正面答复。

作为架构师，你就是在推销东西。
你需要准备即便是出现问题，也要将解决方案推销出去。
人们提出问题时，可能看上去在与你在作对，而实际上，人们询问是为了确认此解决方案，或者他们要了解此解决方案。
他们提出问题，是因为他们随后也可能要向他们所在的单位推销这些提及的解决方案。

先寻求理解别人，在寻求被人理解。
通过倾听并复述所说过的话，来理清自己的理解。

在商业活动中，你不是得到你应得的，而是得到你谈判得来的。
不要想着马上解决问题，要让别人尽可能多的说话，从而获取尽可能多的语境信息。
有效协商可以将一些想法和项目扼杀在早期阶段——在没有花费可观的资源之前。

管理是将事情做对，而领导力则是做对的事情。
领导力是一种艺术，从而让他人心甘情愿的为你想完成之事而奋斗。
你不能靠敲击别人的脑袋来领导，那是人身侵犯，不是领导。

通过影响而不是要求别人顺从，来发挥你的领导力。
建立信任关系，建立共识，建立战略伙伴关系，要身体力行，感知风险，评估影响，做出行动。
谨慎的选择卓尔不群。

不要告诉别人怎么做，告诉他们要做什么，他们会做出你意想不到的结果。

从政治角度，你需要确保你的个人目标与公司目标保持一致。
尽早处理别人关注的问题。
生活是反身的，你传达的东西会发射回你。
你希望这个世界怎样对待你，你就怎样对待这个世界。

任何时候，你能做得最好的就是表现自然真诚。
承认自己的弱点，承认你的实力和兴趣。
架构师把透明化和清晰性带到许多领域。

如果你工作只是为了钱，你永远不可能挣太多的钱。
但如果你热爱你做的事，并把客户置于第一位，你早晚会成功的。

好的灵感并没有价值，你需要的是由它得到金钱。
架构师的部分工作不仅是获取商务知识，还要在更大范围内共享技术知识。

领导者与跟随者的区别就在于创新。
创新就是把变化看成是机会而非威胁的能力。

创新分为4种类型，产品创新，过程创新，位置创新，范式创新。
想要创新，你得做好所有人都说你是疯子的心理准备。
创新的一个基本部分就是不怕失败。
你不能只问客户他们想要什么，然后试着给他们这些东西。在你把这些东西做好后，他们又会索要新的东西。
最成功的人都是那些善于进行B计划的人。

当你的想法与周围的人完全不同时，你要是说『我是对的，别人都不对』，你就会处于非常惹人讨厌的位置。
这样可以过过嘴瘾，但同时也会招惹别人的攻击。
我并没有什么特别的才能，我就是有非常强烈的求知欲。
只有组织促进创造性的不满足情绪，才会达到优秀的成就。

战术技能与战略结合，就是真正的杀手级组合。缺乏战术激励的战略注定会失败。
未来属于那些在事物大行其道之前就看到其可能性的人。
认知就是察觉不可见事物的艺术。
没有执行的认知是空想。
如果你做小事时有大思维，那么做这些小事就是按正确方向来的。
你有认知时，它会影响你的态度。你的态度就会变乐观而不是悲观。
对于指导自己要去哪儿的人来说，整个世界都会给他让路。

“有效性”只是“知识工作者”的一种特殊技能，而知识工作者直到最近才逐渐增多。
对“体力工作”而言，我们所重视的只是“效率”。
所谓效率，可以说是“把事情做对”（to do things right）的能力，而不是“做对的事情”（to get the right things done）的能力。

体力工作的成果，通常可以用数量和质量来衡量。
近一百年来，对如何衡量体力工作的效率和质量，我们已有相当的研究，现在我们已经能够运用测定体力工作效率的方法，来促使工作者的产出大为增加。
关于体力工作，我们已有一套完整的衡量方法和制度，从工程设计到质量控制，但是这种衡量方法和制度，并不能适用于知识工作。
如果所设计的是一项错误的产品，则尽管工程部门能迅速绘制出精美的蓝图，其结果也是极其可悲的。

惟有从事“对”的工作，才能使工作有效，而这一点，却是无法用衡量体力工作的方法来衡量的。
我们无法对知识工作者进行严密和细致的督导，我们只能协助它们。
知识工作者本人必须自己管理自己，自觉地完成任务，自觉地做出贡献，自觉地追求工作效益。

的确，谁也不知道一位知识工作者在想些什么。
然而，思考却正是他的本分，他既然是在思考，他就是在工作。

知识工作者的工作动力，取决于他是否具有有效性，及他在工作中是否能有所成就。
如果他的工作缺少有效性，那么他对做好工作和做出贡献的热情很快就会消退，他将成为朝九晚五在办公室消磨时间的人。

知识工作者并不生产本身具有效用的产品。他生产的是知识，创意和信息。
这样的产品本身并无用途，只有通过另一位知识工作者，把他的产品当做投入，并转化为另一种产出，它们才具有实际的意义。
再伟大的智慧，如果不能应用在行动上，也将只是毫无意义的资料。

因此，知识工作者必须做到一些体力工作者不需要做的事，他必须具有有效性。
而且，他不能只顾到他的产品本身的效用。

知识工作不能用数量来衡量，也不能用成本来衡量。
衡量只是工作主要应看其结果，而不是看机构的规模有多大或管理工作的繁简。

管理者所面临的一连串工作却很少告诉他任何情况，更不能向他提示真正的问题所在。
对医生来说，病人的主诉便是重心，因为那是病人认为的重心。
而一位管理者所关切的，却是更复杂的世界。
哪些事情是重要的，是管理者必须去做的，哪些事情只会分散他的注意力，这并不是一目了然的，也不能像病人叙述症状那样为医生提供线索。

知识工作者彼此之间最难协调，其原因正是由于他们是知识工作者。
每一位知识工作者都各有所长，各自的志趣。
他们每个人都需要使用别人的成果。

对管理者的有效性而言，最重要的人物，往往并不是管理者直接控制的下属，而是其他部门的人，即所谓“旁系人士”，或者管理者本人的上司。
一位管理者如果不能与这些人主动接触，不能使这些人利用他的贡献，他本身就没有有效性而言。

在组织内部，不会有成果出现，一切成果都存在于组织之外。
举例来说，企业机构的成果，是通过顾客产生的，企业付出的成本和努力，必须通过顾客购买其产品或服务，才能转变为收入和利润。
同样的道理，医院的成果肯定表现在病人身上。当病人并不是医院组织中的一份子。

在组织内部所发生的，只有人工和成本。
一个组织要产生一项既定成果，其工作量越少，表示其成绩越好。

一个组织不能像生物一样，以自身的生存为目的，如果能延续后代就算成功了。
组织是社会的器官，只有能为外部环境做出自己的贡献，才能算有所成就。

对于外部的情况，真正重要的不是趋势，而是趋势的转变。
趋势的转变才是决定一个机构及其努力的成败关键。
对于这种转变，必须要有所觉察，转变是无法计量，无法界定，无法分类的。

有效性是一种后天的习惯，是一种实践的综合。
既然是一种习惯，便是可以学会的。

---

下列五项是要成为一个卓有成效的管理者，必须在**上养成的习惯：
（1）有效的管理者知道他们的时间用在什么地方。
他们所能控制的时间非常有限，他们会有系统的工作，来善用这有限的时间。

（2）有效的管理者重视对外界的贡献。
他们并非为工作而工作，而是为成果而工作。
他们不会一接到工作就一头钻进去，更不会一开头就探究工作的技术和手段，他们会首先自问：“别人期望我做出什么成果？”

（3）有效的管理者善于利用长处，包括自己的长处、上司的长处、同事的长处和下属的长处。
他们还是善于抓住有利形势，做他们想做的事。
他们不会把工作建立在自己的短处上，也绝不会去做自己做不了的事。

（4）有效的管理者集中精力于少数重要的领域。
在这少数重要的领域中，如果能有优秀的绩效就可以产生卓越的成果。
他们会按照工作的轻重缓急设定优先次序，而且坚守优先次序。
他们知道：要事第一。
重要的事情先做，不重要的事情放一放，除此之外也没有其他办法，否则反倒一事无成。

（5）有效的管理者必须善于做出有效的决策。
他们知道有效的决策事关处事的条理和秩序问题，也就是如何按正确的次序采取正确的步骤。
他们知道一项有效的决策，总是在“不同意见讨论”的基础上做出的判断，它绝不会是“一致意见”的产物。
他们知道快速的决策多为错误的决策，真正不可或缺的决策数量并不多，但一定是根本性的决策。
他们需要的是正确的战略，而不是令人眼花缭乱的战术。

---

当你发现自己站在了大多数人一边，你就该停下来反思了。——马克·吐温
任何一个还在为温饱而努力的人，一定缺乏想象力。——安斯卡·王尔德

生活不必如此艰辛，确实不必如此。
大多数人，也包括过去的我，花费太多时间说服自己相信生活本来就是艰难的，
为了换得间或的休闲周末和偶尔的（甚至还要冒着被解雇的风险）短暂假期，
不得不忍受朝九晚五的劳苦。

人们并不渴望成为百万富翁——他们只是渴望体验百万美元才能买到的享受。

所谓专家，就是在极小领域内犯过所有能犯的错误的人。——尼尔斯·威尔

先找到市场，再生产产品远比反过来要聪明的多。

现实不过是幻象——非常持久的幻象。——阿尔伯特·爱因斯坦

就像我们说自己『发烧』实际上却被『发烧』所控制一样，这些声称自己『富有』的人实际上是被『富有』所支配的。——塞内加

我也记得那些看上去富有实际上却极其匮乏的人。
他们积攒了大量无用之物，却不懂得如何利用，也不懂得如何舍弃，
最终将自己陷入金银的桎梏之中。——亨利·大卫·梭罗

新贵和普通大众的目标不同，而这种不同的目标反映出截然不同的思考层次和生活哲学。

让别人为自己工作。
不为工作而工作，花最小的代价取得最大的效果（最小有效工作量）
定期分配一生的休整期和冒险期（即迷你退休）。意识到完全的休息并不是目标，做令人兴奋的事情才是真正的目标。
既不想当老板也不做员工，只做拥有者。就好比拥有一辆火车并雇请别人来确保火车的按时运营。
目标宏远但确保每天稳定的进账：现金流第一，日进斗金其次。

首要原则是不要欺骗自己，而你自己是最容易被欺骗的人。——理查德·P·费曼

如果搭错车，请立即下车。

钱赚够了就收手。
不要像旅鼠一样无方向。
盲目的追求金钱是愚蠢的举动。

我曾包下私人飞机翱翔在安第斯山脉的上空，
曾在世界一流的滑雪跑道上尽情享受世界上最棒的葡萄酒，
也曾懒洋洋的躺在私人别墅的巨型游泳池里，
过着国王一般奢侈的生活。
有一个我很少提及的小秘密：所有这些都比美国的房租还便宜。
如果能自由支配时间和空间，你的钱将自动升值3-10倍。

拥有很多金钱和能够像百万富翁一样真正享受生活根本就是两码事。

拥有选择机会——具备选择的能力——才是真正的力量。
你可以用现有一般的工作量赚取更多的钱——多得多的钱。

选择是无限的，但是每一种选择都始于相同的第一步：抛弃成见。

我给不出一个万无一失的成功法则，但我能告诉你一个失败法则：永远在尽力取悦所有的人。——赫伯特·贝亚德·斯沃普

只有在带来更大效率和乐趣的情况下，与众不同才是不错的选择。

如果每一个人都以同一个方法来看待和解决同一个问题，而结果总是让人不满意，
这时，我们该问自己，是不是可以换一个角度来做？
不要总是遵循错误的模式。
方法错误，本事再大也没用。

少做并不意味着懒惰。
少做些无意义的工作，就能够集中精力做对个人而言更重要的事情，这并不是懒惰。
对大多数人来讲，这好像不太能接受，因为我们的文化更重视个人牺牲而不是个人的产出能力。
很少有人会去（或者有能力去）了解自己工作的成效，继而及时评测出自己的贡献。
更多的工作时间，就意味着更多的自我价值，意味着来自上司和周围同事的支持和肯定。
可是，新贵花很少的时间呆在办公室里，却能够比十几个非新贵取得更有意义的成果。

关键是高效，而不是忙碌。

对于所有的重大事情，可以的安排通常会搞砸。
万事万物不会都和你作对，淡然也不会都顺你的意。
各种环境条件永远不可能达到完美。
如果对你来说很重要，而且『最终』你会这么做，那么现在就做吧，边做边调整。

寻求宽恕，而不是寻求许可。
如果事情并不至于毁掉你周围的一切，那么就试着去做，然后证明它是正确的。
大多数人习惯在你动手做之前就来劝阻，但是一旦你开始做了，他们的阻挠就变得犹豫了。
要学会做一个麻烦的制造者，真正搞砸的时候也要学会说对不起。

要强调优势，而不是弥补弱势。
大多数人通常只擅长小部分事情，而在其他大部分事情上做得非常糟糕。
利用强项的倍增效应，而不是持续改进弱项，后者最多也不过是达到中等水平。

做你想做的事，而不是被迫做不想做的事。

光靠钱是不能解决所有问题的。
拥有更多的金钱，并不是我们想要的答案。
而之所以产生这种答案，部分原因就是我们头脑懒惰。
在我们需要深刻自我反省的时候，或者为了现在而不是将来创造快乐生活做必要决定的时候，
一句『要是我有更多的钱』往往成了最简单的借口。

相对收入比绝对收入更重要。
最顶尖的新贵牛人每小时至少能赚5000美元。
而我刚出校门时，只有每小时5美元的报酬。

不欢迎任何批评的人，必定会失败。
我们需要避免的是那种毁灭性的批评，而不是所有的批评。

停顿就是错误的第一步。

行动未必一定带来快乐，但没有行动就一定不会有快乐。——本杰明·迪斯雷利

我为什么不确切描述一下我的恶梦究竟会是什么样呢？
如果我去旅行，最坏的结果是什么？
有趣的事情发生了，在不断自我折磨时，我偶然开始了反向思维。
通过定义噩梦，定义最坏情况，我一下子就停止了茫然的不安和模糊的焦虑，
也不像以前那样担心旅行的问题了。
突然间，我开始思考哪些可能采取的简单步骤能挽救我余下的资源，
也开始考虑如果所有不幸都发生，我该如何回到正轨。
我意识到，要回到过去的生活并么有那么困难，
更不用说生存下去。

我认为大多数人和大多数所谓的『哦，天哪，我的人生完了』之类的灾难也不过如此。

我所冒的风险是不太可能发生的，而我所换来的改变是可能发生的。
几乎不存在任何风险，有的只是极可能发生的巨大人生变化，而我也不需要比现在更努力，就能回到过去的生活。

花几天时间，用最俭省的费用生活，穿最粗糙的衣服，然后问自己：『这就是我所害怕的生活吗？』——塞内加

悲观主义者说：『哦，没希望了，也不要再努力了。』
而乐观主义者说：『不要再努力了，事情总会变好的。』
两者一样，因为什么也不会发生。
——伊冯·乔伊纳德

如果生活没有变得更好，说明一切并不会自行改善。
如果你只是在自欺欺人，那么，你该停下来，计划做一下改变了。

我是一个老人，听说过相当多的磨难，但是大多数都没有发生。——马克·吐温

『请告诉，我应该从这里往哪走？』
『那可得取决于您想去哪里？』猫说道，
『去哪里我都无所谓……』爱丽丝说，
『那么您走哪条路都行。』猫说
——刘易斯·卡罗尔

理性的人让自己适应世界，非理性的人坚持让世界适应自己。所以，所有的进步都靠非理性的人。——萧伯纳

世界上99%的人都认为自己不可能取得伟大的成就，于是他们的目标就很现实——中庸。

如果你有不安全感，会怎样呢？
世界上其他人也有同样的感受。
不要总是高估对手而低估自己，你比自己所想象的要强。

做大事，都要从正确的提问开始。
首先，换一个更好的问题。

快乐的反义词是什么？悲伤？不是。应该是无趣才对。
你要问的问题不是『我想要什么』，而是『什么让我富有激情』。

无趣才是真正的敌人，而不是所谓的抽象的『失败』。

如果你不会失败，你会做什么？
如果你比世界上其他人聪明10倍，你会做什么？
要成为『想成为的人』需要做些什么？

最重要的行动永远不会令人舒适。
幸运的是，你可以通过自我调整来应对并克服这种不适感。

提出解决办法而不是去问别人，
主动引导对方给出自己想要的反应而不是被动的等待，
坚持自己的主张又不去得罪所有人。

要想拥有一种不寻常的生活方式，你就得培养为自己和他人做决策的不寻常的习惯。

不是积聚而是精简。不是每天增加而是每天减少。
文明程度总是向着更简单的方向变化。
——布鲁斯·李

完美不是指再没有东西能增加上去了，而是指再也不能拿走一样东西了。——安托万·圣埃克苏佩里

对于可以用不多的精力就能完成的事情，过多的投入就是愚蠢。——奥卡姆的威廉

你不应该每天都想着去做更多，也不应该让每一秒钟都充满了工作的烦恼。
我自己花了很长时间才领会到这点。我也曾非常热衷于那种以数量定绩效的方式。

不重要的工作做得再好，也不会变得重要。
耗时的工作，并不等同于重要的工作。

做些什么当然比如何去做更为重要，
有效益当然很重要，但是如果不是用在正确的事情上，有效益也就是徒劳的。

计算过的事情，才能成功。——彼得·德鲁克

80%的产出来自20%的投入。——帕雷托法则

我看到一家银行写着『24小时营业』，但是我可没有那么多时间。——史蒂文·赖特

如果你是一名员工，把时间花在无意义的事情上，在某种程度上，不是你的错。
没有一定的利益，一般人是没有动力去好好利用时间的。
这个世界已经习惯在上午9点到下午5点的时间段里工作，既然你在该时间段里受雇佣必须呆在办公室里，
你就不得不找各种事情来打发这段时间。

最好的员工才有最大的谈判砝码。

怎么可能全世界所有人都正好需要8小时来完成工作？不可能。
朝九晚五只是随意制定出来的规矩而已。

你没必要为了成了一位真正的百万富翁而每天工作8小时，
更不用说只要活得像个百万富翁了。
我知道你怎么想，我自己有很长一段时间也这么想：一天的时间真的不够多。

如果给你24小时去完成一项任务，时间的压力促使你集中精力去执行，
别无选择只能做最重要的部分。
因为精力更高度集中，短时限内做出的最终产品，通常不比长时限内做出来的差，甚至质量更高。

只做重要的事情，以减少工作时间。
减少工作时间，来做最重要的事情。

最好的解决办法是，两个一起用：确定几件影响收入的重要事情，用非常短和清楚的时限来计划它们。
如果还没有正确的选定目标重要的任务，就莽撞的开始和结束，那些不重要的事情就会摇身变成重要的事情。
即使你知道什么才是重要的事情，但如果没有设定完成任务的时限，
那些强加到身上的（或突发的）次要事情就会不断的出现，不断占有你的时间，
一天下来你会一事无成。

大部分的投入都是无用功，浪费的时间与得到的时间成正比。
只有对高负荷工作量的有效限制，才会迎来优异的效率和时间的自由。

喜欢忙碌并不是勤奋。——塞内加

我现在有成效吗，还是只是很忙碌而已？
我不停的找事来做，是不是错过了重要的事情？

压力是我们自己造成的，因为我们感觉不得不这样做。不得不做。我再也没有那样的感觉了。——奥普拉·问弗瑞

要有更多的时间，就要少做一些事情。

如果你有心脏病，每天只能工作2小时，你会做什么？
如果你第二次心脏病发，只能一周工作2小时，你会做什么？
如果有一把枪指着你，要求你停止4/5的耗时工作，你会去掉哪一些工作？
如果这件事是我今天唯一完成的事情，我会对今天满意吗？
不要同时做几件事情。
学会建议。不再向别人寻求解决办法，开始自己提出解决方案。不要再来回拉锯，做一个决定。

任何一个阅读太多而动脑太少的人都会养成懒于思考的习惯。

聪明人往往有很多不想知道的东西。——拉尔夫·沃尔多·艾默生

学会视而不见，是获得内心平静的重要途径之一。——罗伯特·索耶

练习不完成的技能，开始某件事情，并不意味着一定要去完成它。
如果正在读的文章实在看不下去，就放下它，再也不要重新拾起。

独立思考。做下棋的人，而不是棋子。——拉尔夫·沙瑞尔

开会是一种令人上瘾并沉浸其中的活动，无论公司还是其他组织都习惯于开会，只是因为他们自己不能独立解决问题。
——戴夫·巴里

最好的防御就是进攻。——丹·盖博

计划可以防止混乱和冲动。——安妮·狄勒德

目的就是授权给员工，把所有相关信息给他们，让他们比过去做得更多。——比尔·盖茨
对员工而言，目标是拥有充分接触所需信息的机会，以及能尽可能独立做决策的权力。
对企业老板而言，目标是尽可能的把信息和独立决策权下放给员工或者责任人。

人们以为做超级天才一定很有趣，但他们不知道要容忍全世界的白痴是多么困难。——小男孩凯文

学会说不。
『不』是你对所有要求的缺省回答。不要特意说谎。
『我真的不能——不好意思，我现在手头上的事情太多』就是一个万能回答。

一个人能放弃的东西越多，他就越富有。——亨利·大卫·梭罗

没有人能给你自由，也没有人能给你平等或者公正或者任何其他东西，
如果你是一个真正的人，那就自己去获取。——马尔科姆·艾克斯

我对那些自认为主宰我的人从桌边丢来的同情面包屑没兴趣。
我希望拥有点单的权利。——图图主教

清晰的表达，清晰的安排，有源于清晰的思考。

事情定好就不要放在心上了。——罗恩·波拜尔

一开始就要明确终点。

天才不过是能看到别人看不到的东西。——约翰·罗斯金

主要获益应该可以用一句话表达。
产品的主要获益应该可以用一句话或者一个词来解释。它有什么与众不同之处？我为什么要买它？
简洁，如果还不能让大家清楚明白，就不要继续往前走。

我不仅要用上自己所有的脑力，还要用上所有能外借到的脑力。——伍德罗·威尔逊

与拥有相比，创造是更好的自我表达方式。人生正是通过创造而不是拥有来展示的。——维达·D·史谷德

如果你并不是一名专家，也不要着急。
该除去专家身上的神圣光圈了，让专业界指责我吧。
在4周内成为顶尖专家。

首先，被看成专家和是专家是有区别的。

很多理论，只有被某些重要实验揭示了错误时才会消失……
因此实验主义者是任何科学领域的侍卫，是他们保证了理论家的诚实。——加来道雄

未来的工厂只需要两个员工，一个人和一只狗。
人是用来喂狗的。
狗是用来防止人去碰机器的。——沃伦·本尼斯

公司做错了决策或者做了过多的决策，都可能导致公司倒闭。
后者还会使事情更为复杂。——迈克·梅普斯

非理性的思考还不够。思考是被动的。要习惯非理性的行动。

自由状态下犯错，远比戴着枷锁做正确的事情要好得多。——托马斯·亨利·赫胥黎

每天勤勤恳恳工作8小时，最终可能成为一个每天工作12小时的老板。——罗伯特·弗罗斯特

在这条路上，只有第一步最重要。——维安尼

我人生30年都没有旅行过——所以为什么不去呢？
这正是每个人都应该问自己的问题——为什么不呢？

最近，有人问我会不会解雇一名造成公司60万美元损失的员工。
我回答说，不会，我会用这60万美元来培训他。——托马斯·J·沃森

自由意味着责任。这也是为什么大多数人害怕它的原因。——萧伯纳

如果你心脏病发作，假设你的老板对此深表同情，你该如何进行4周的远程工作？
设身处地从老板的角度想一想，基于你的工作历时记录，你相信自己能离开办公室工作吗？
量化自己的工作成效。
先创造一个机会证明远程工作的成效，再要求得到宽松的政策。
在建议之前练习应对『拒绝』的艺术。
让老板开始习惯远程工作的方式——建议周一或者周五在家

不要低估公司对你的需要。
认真工作然后要求得到自己想要的。
如果一直得不到自己想要的，那就离开。
世界很大，没有必要把大部分生命浪费在一个小空间里面。

可以因为野心而犯错，却不能因为懒惰而犯错。要培养自己勇敢行动的力量，而不是忍受折磨的力量。——马基雅维里

有些工作的确无药可救。

如果要玩这个游戏，一开始就要清楚三件事情：游戏规则，奖励和惩罚，结束时间。

花费精力或消耗时间的事情，并不就是带来成效或者值得去做的事情。
因为5年，10年或者20年之前的错误决策，而一直在承受后果的你会觉得，
承认决策错误的事实令人难堪，但这并不意味着你现在不能做正确的决策。

对成功者而言，能够抛弃无用的东西是必须具备的能力。
事先没有思考清楚就去做某项工程或工作，会使得本来有益的事情变成浪费精力。
这就如同预先不设定赌注的上限就进赌场一样：危险又愚蠢

不要把复杂和困难混为一谈。
大多数的处境都是简单的——只是情感上难以接受。

问题和解决办法都是简单且显而易见的。
你并非不知道如何去做。
你当然知道。
只不过你担心最终会弄得比现在还要糟。
现在，我告诉你：如果你已处于这种情境，就不会比现在更糟糕。

只有睡着的人才不会犯错误。——英格瓦·坎普拉德

每天，成千上万的人离开他们的工作岗位，其中大多数都未必有你能干。
这并不令人奇怪，也没有那么悲惨。

在旅游业发展之前，旅游被看成是一种学习，其益处就是陶冶情操并且帮助价值观的形成。——保罗·福赛尔

从长远来看，即兴表达的简单冲动比研究更重要。——罗尔夫·波茨

人生不是通过加速就可以体味到更多的。——莫罕达斯·甘地

一个人的完美之处就在于找到自己的不完美之处。——圣·奥古斯丁

只有放弃许多原本平常却被过高估价的东西，才有可能得到自由、快乐和成功。——罗伯特·亨莱

不可能有足够的时间让我们去做所有想做的无聊事情。——比尔·沃特森

人，生来就如此，一种工作的放松只有在另一种工作中得到。——阿那托尔·法郎士

都说人一直在为人生寻找意义。我认为并不是这样。我们一直寻找的是活着的经历。——约瑟夫·坎伯

如果你不能明确定义问题，或者无法采取应对行动，就忘掉这个问题。

磨砺你的逻辑性和实践性精神工具，并不意味着要你做无神论者或者无宗教主义者。
也不是让你变得愚钝和肤浅。而是让你变聪明，把精力都用在关键有效的地方。

人真正需要的不是没有压力的生活状态，而是为了自己自由选择的，值得的目标，努力和奋斗的状态。——维克多·弗兰克尔

我相信，生命就是用来享受的，自己感到快乐就是最重要的事情。
我认为有两点非常重要：持续学习和服务。

道德不过是我们对个人不喜欢的人所采取的态度。——奥斯卡·王尔德

因为自己没有主意，所以成年人总是问孩子们长大后想当什么。——宝拉·庞德斯通

如果你没有犯错，那是因为你处理的问题不够难。而这就是一个大错。——弗兰克·威尔茨克

错误只是过程的一部分。
迷失了梦想，陷入为工作而工作的思路。
事事亲为。
自己处理可以由外包工作者或者同事处理的事情。
帮助外包工作者或者同事多次处理同一个问题，或者处理非紧急问题。
在自己生活、睡觉或者应该休息的地方工作。
没有以2-4周为周期，对自己的工作和个人生活做一个全面的二八法则分析。
无论是个人生活还是职业生活，都不停的追求无尽的完美，而不是只要达到不错或者良好。
夸大琐事和小问题的重要性和比例，作为工作的借口。
把非紧急的事情变得紧急起来，从而证明工作的意义。

忙碌的人忙于任何事情，除了生活。——塞内加

我所知道的能够避免陷入失落与担心的最好方法是：假设死亡即将到来。——史蒂夫·乔布斯

如果你对人生感到困惑，你并不孤单。
当你意识到人生并不是一个有待解决问题，也不是一个需要赢取的比赛，这自然就不再成为一个问题。
如果你一心要解开这个根本不存在的谜，你就会错过所有真正的乐趣。
当你明白那些规定和限制是我们自己为自己制定的时候，不断追求成功的沉重就可以由偶然发现的轻松所替代。
因此，勇敢起来，不要担心其他人的看法。毕竟他们并不经常这样做。

人们总是抱怨管理者们没有抽出足够的事件来思考企业的未来，或对未来未予以足够的重视。
对此，我们是司空见惯的。

这种怨言不是空穴来风。
管理者们应多花一点时间考虑企业的未来，并对未来予以更高大的重视。
它们还应在许多其他事情上付出更多的时间和努力，例如他们对社会和社区肩负的责任。

如不重视未来，他们及他们的企业会付出惨重的代价。

可是，抱怨管理者在明天的工作上投入的时间太少是徒劳无益的，对未来的漠视只是表面现象。
管理者处理不完今天的事情，因此也无法关注明天。
这也只是表面现象。
缺乏处理企业的经济任务所需的任何知识基础和系统基础才是真正的根源所在。

在管理者可以考虑处理未来的问题前，他必须能够用更短的时间应付今天的挑战。
因此，它他需要系统化的处理今天的工作。

（1）成果或资源不是来源于企业内部，它们来源于企业外部。
对于任何经营活动来说，无论是设计，销售，制造，还是会计，我们唯一可以确定的是这些经营活动需要企业付出努力，因此产生成本。
决定企业付出的努力能够转化为经济成果，或是否会落得竹篮打水一场空的总是外部的人。

只有在知识上，企业才会与众不同，因此才会产出在市场上有价值的东西。
然而，知识不是经营资源，它是普遍分布的社会资源。
在任何时间段内，它不会永久的成为秘密。
实际上，经营可以被定义为一个将外部资源（知识）转化为外部成果（经济价值）的过程。

（2）成果的取得是靠挖掘机会，而不是靠解决问题。
在解决问题的过程中，我们唯一有希望得到的是恢复正常秩序。
我们有希望看到的，最多是帮助企业摆脱对其取得成果的能力的限制。
成果本身必须来源于对机会的挖掘。

（3）要创造成果，资源必须被分配给机会，而不是分配给问题。
机会最大化，是对企业经营工作的有意义的定义，而且实际上是准确的定义。
它暗示企业需要的是有效性，而不是效率。
如何把事情做好，不是企业应该提出的问题，而是，如何找到正确的事情做，并集中资源和力量做好这些事情。

（4）只有保持领先，企业才能创造出经济成果，而仅有能力是不行的。
企业在有意义的领域做出了独一无二的贡献，或者至少做出了截然不同的贡献，它获得的回报就是利润。
而且什么是有意义的事情是由市场和顾客决定的。
只有提供顾客认为有价值的，并愿意掏腰包购买的东西，企业才能赚取到利润。

大不等于领先。
在许多行业，规模最大的公司绝不是利润最高的公司，这时因为它在产品系列的发展，市场的供应链技术的应用上无法做到与众不同，更不用说独一无二了。
第二位或甚至第三位通常更有优势，这时因为企业可以集中精力应付某一个细分市场，某一类顾客，某一种技术应用，而真正的领先者常常源于这些方面。
许多公司认为它们可以或者应该可以在它们涉足的市场或行业内在所有方面都居于领先地位，事实上，这是妨碍它们取得领先地位的主要障碍。

想创造出经济成果的公司，必须在某些为顾客或市场带来真正价值的方面取得领先地位。

（5）任何领先地位都是短暂的，而且很可能是昙花一现的。
企业的经营成果一开始是创造利润，最后最多是赚取与能力相当的报酬。

那么，管理者的任务就是扭转司空见惯的下滑趋势。
他的职责是把企业经营的中心放在机会上并远离问题，重新带来领先优势并阻止迈向平庸的趋势，用新的活力和新的方向取代迟钝和惰性。

（6）企业的现状是逐渐变老。
恢复正常状态始终是徒劳无益的，正常状态，只符合昨天的现实。
管理者的责任不是在已经发生变化的今天强行使用昨天的标准，而是改变企业及其行为，态度，希望，产品，市场和分销渠道，使它们符合新的现实。

（7）企业的现状可能是资源的不合理配置。
在企业付出的努力，成本，资源和成果上，企业倾向于不由自主的扩散能量。
因此，企业需要不断的重新评估和校正方向，在最想不到的方面，企业最需要重新评估和校正方向。
让现在的企业有效的经营。

不注重设计明天的款式，而不断的修补昨天的衣服，是非常危险的倾向。
缝缝补补的方法是不够的。

（8）集中是经济成果的关键。
经济成果要求管理者集中的应付尽可能少的产品，产品系列，服务，顾客，市场，分销渠道，最终用户等，它们带来的收入越多越好。
要创造出经济成果，雇员就需要专心处理少数几项能够带来相当大经济成果的活动。

我们的人员编制庞大，然而我们没有集中的在任何一个领域付出足够的努力。

---

企业现状分析，
管理者需要找出是不是“正确的答案”，而是“正确的问题”。

定义产品，
每一个经验丰富的管理者，至少都知道和了解有关产品定义的问题，尽管这些问题不是简单的问题。
单单这一点使得产品分析成为最好的出发点。
几乎所有企业都提供某些根本不是真正产品而是其他产品一部分的“产品”，如附件或促销品。
企业应按对真正产品的影响评价它们，例如，按提升销售额的能力。

市场与分销渠道常常比产品更重要。

要取得领先地位，产品必须与市场和顾客的一个或多个真正需要最匹配。
顾客必须愿意为它付钱。

知识和资金资源的问题远比将它们分配到成本区复杂得多。
但是，我们首先必须了解清楚资源实际上在哪里，以及它们与企业的成果有什么关系。

---

人们认为投入的资源越多，产品的前景就越光明，这是最自欺欺人的想法。
如果你一开始没有取得成功，再试一次，然后试试别的。
在不懈努力的过程中，每一次努力取得成功的可能性不是越来越大，反而是越来越小。

每一个新产品要做到不负众望，时间必须是有限的。
只有在取得较大进展的情况下，时间才能延长。
如果即使时间延长了，它仍旧无法取得成功，它就不应再有下一次机会。
否则，企业就会被管理层自以为是的实施的投资项目捆住手脚，它们消耗关键性资源，过多的占用管理层的时间——可是未曾出现任何转机。

---

重要的不是成本的绝对水平，而是付出的努力与成果之比。
无论付出的努力有多么省钱或有效率，如果没有成果，它不是成本，而是浪费。
如果它自始至终都不能产生成果，它从一开始就是不合理的浪费。

因此，机会的最大化是提高付出的努力与成果的比值的重要途径，从而实现对成本的控制和获得低成本。
机会的最大化必须摆在第一位，其他成本控制的措施发挥的是补充作用，而不是中心作用。

在降低成本上，唯一真正有效的方法是完全砍掉某一项活动。
企图削减成本的方法很少是有效的，企图少花钱做根本不应做的事情是没有什么意义的。

然而，在降低成本运动的开始阶段，管理者一般都会宣布不放弃任何活动或部门。
这等于宣告整个活动是毫无效果的行动。
最后的结果，只能是损害必不可少的活动，并让人相信，不不要的活动的成本在几个月内就会完全恢复到最初的水平。

有效的成本控制要求我们必须着眼于整个企业，否则，某一个方面的成本的降低，完全是靠增加其他方面的成本实现的。

顾客买的不是商品，他买的是满意和他因此得到的用途。
因此，真正符合经济学的成本应包括顾客为了得到他所购买的商品的全部用途而需要付出的一切，如维护，维修和运营费用等。

---

企业是一个过程，在此过程中将资源转化为给市场带来经济价值的行为。
企业的目的是创造顾客。
企业的目的是向独立的外来者提供后者愿意用他的购买力交换的东西，而这种外来者拥有选择不购买的权利。

在企业内部，人们很难知道企业为什么能赚到钱，我们需要从外部有组织的考察自己的企业。

企业内部的人认为他们了解顾客和市场，他们的这种想法与其说是正确的，不如说是错误的。
只有一个人真正了解顾客，即顾客自己。
企业只有询问顾客，观察顾客，试图了解顾客的行为，才能知道他是谁，他是做什么的，他如何购买，如何使用他购买的产品，他有什么希望，他认为什么是重要的等。

顾客很少购买企业想卖给他的东西。
制造企业很少能充分的认识到真正与其竞争的是什么和是谁。
生产企业或供应商认为某个产品所具有的最重要的特性，对于顾客来说可能完全相对无关紧要。
要生产这种产品，企业很可能要付出艰苦努力，面临各种困难和付出巨大代价。
但顾客丝毫不会被制造企业遭遇的各种烦恼所打动，他唯一的难问题是，而且应该是，“它能为我做什么呢？”

各种广告一个接一个的强调生产这个或那个产品有多么复杂和艰辛。
如果这能给顾客留下任何印象，那很可能是原意的反面意思，
如果做到令人满意这么难，那它可能不是很有效。

顾客不是付钱的人，而是做出购买决策的人。

如果要尝试了解顾客表面上不合理的行为，生产企业就被迫从市场营销的角度看问题，而不是仅仅停留在口头上。
此外，这种尝试迫使生产企业根据市场的逻辑采取行动，而不是以供应商的逻辑为出发点。
如果它不能让顾客的行为向有利于它的方向发展，它就必须适应顾客的行为。
否则，它就不得不接受更艰巨的挑战，即改变顾客的习惯和想法。

无论什么样的行为，只要不符合顾客自身的最大利益，生产企业最终会付出沉重的代价。

---

认真处理本企业的知识的最佳方式是，了解企业擅长做什么和不擅长做什么。
因此，第一个问题是，我们擅长做什么，且不费吹灰之力，而其他企业在做同样的事情上做的很失败？
随后，我们还要问，我们不擅长做什么，而其他企业似乎在这方面没有遇到什么麻烦？

企业当然不需要与其他企业进行比较。
企业还可以比较自己的失败与自己的成功，并问，我们为什么会取得这样的成果？

最后，向企业的忠实顾客问以下问题始终都是一个好主意，
在哪些方面，我们为你所做的是其他企业所做不到的？
不是因为顾客总是知道答案，而是因为他们的答案尽管杂乱无章，但很可能揭示出一个告诉我们在哪里寻找答案的模式。

---

如果把今天的行动与承诺建立在对未来事件的预测的基础上，那么任何这种企图都是徒劳无益的。
我们能做的最多是预测已经发生和不能改变的事件在未来能产生什么样的影响。

创造未来的努力不是为了确定我们明天应做什么，而是为了确定我们今天应做什么，才能拥有明天。

要让未来称为现实，人们不需要具有创造性和想象力。
人们需要是付出努力，而不是具有天赋，因此在某种程度上，每一个人都可以做到。
拥有创造性和想象力的人当然拥有更有想象力的创意。
但是，越具有想象力的创意实际上不一定会取得更大的成功。
平凡的想法有时也会取得成功。

要让未来成为现实，人们必须愿意尝试新东西。
人们必须乐于问，我们真正希望看到哪些与今天完全不同的事情发生？
人们必须乐于说，作为企业的未来，这正好是需要成为现实的事情，我们将设法让它成为现实。

你需要有发现问题的智慧

在针对企业的经营课题进行咨询或解决问题的训练时，在思考解决方案之前，时常会遇到“对问题的认识太浅”，“对问题的认识有所错误”或“即使解决了仍不断有无法处理的问题产生”之类的状况。
简而言之，就是“无法确实且具体的发现问题”。

急着决定解决方案，可能会适得其反

与其怀疑问题本身，一般人通常会满脑子只想着要找出解决方案。
毕竟只要找到解决方案，就没事了。
因此，人们会为了一些没有必要解决的问题，花了太多的时间寻求解决方案而浪费时间，或者让自己陷入拼命想处理根本解决不了的琐碎问题的情况。
而另一方面，只去解决容易处理的问题的情形也很多。

在发生错误的时候如果提议要追究原因的话，会令人觉得好像要“否定某人的人格”。
问题，立场，人格，全部都被一体化，无法切割。
分析出造成问题的原因，思考为了防止重蹈覆辙的解决方案时，彻底思考“为什么”实在不该牵连到否定犯错者的人格啊。

那位实习医师坦承自己犯错，在反省那是“身为医师不该有的行为”之外，并且提出了“为什么自己会犯错”，“原因在于实习医师36小时的工作”的问题，并建议医院的体制应该进行改革。
思考事件发生的原因，虽然本人的资质可能也有问题，但“医院36小时工作的体制”也有问题，完全不提体制的部分，是无法解决问题的。

正视现状，才是发现问题的开始。

先思考：什么是“问题”？
许多谈问题解决的书也和考试用的参考书一样，从“问题浏览”开始，而解决的步骤则是专注在如何解决所接收到的问题，所以欠缺解决问题根本的前提，也就是“怀疑问题本身”的这个步骤。

---

发现问题的能力，将决定你解决方案的品质
好的解决方案来自于正确的问题设定

所谓问题就是“应有的景象”与“现状”之间的“落差”，所谓“解决方案”就是填补“落差”的处方签。
问题 = 应有的景象 - 现状

因此，与现状没有落差的目标不会产生问题。
或者，不可能达成的目标与现状之间的落差，会成为理论上不可能解决的问题。

所谓发现问题，可以说是从掌握“应有的景象”与“现状”之间“落差”的结构开始。
总而言之，找出产生“落差”的原因，逼近其本质，就可以看见通往解决方案的路径。

因为有可能达成“应有的景象”与“现状”之间的落差，才会有“问题”

因为看不见“应有的景象”，所以无法发现问题
我在接受他人咨询时，常会发现他们举出各式各样的问题点，同时会提到他们自己想的解决方案或执行解决方案时遇到的障碍。
但是听了他长篇大论之后，一旦问他“那么，你想怎么办呢？”，很多人就忽然辞穷而回答不出来了。
想这种情形大多是因为当事人迷失了“应有的景象”。
因此，我建议他首先去思考作为目标的“应有的景象”，因为只集中于思考目标，其他的阻碍原因就会被赶到一旁。
当他心中的“应有的景象”越来越清楚，就可以看见与“现状”的“落差”了。
于是，自然就可以看见解决的办法。

领导人如果只盯着已经发生，已显现的现状问题，而不谋求对症下药解决问题，那么这样的领导人将无法领导今后的企业。
大胆规划企业将来希望成为什么样的“应有的景象”，将它与“现状”的“落差”视为问题并谋求解决，才是商业领导人确切的使命。

现在需要的是会思考“什么是今后应该处理的重要问题”，这种对未来设定新问题的能力。
换句话说，今后商业领导人所需的重要资质不是对现场的解决方案下达琐碎的“know how”指示，而是可以订出为什么，以及今后什么会成为问题/课题的卓越的“know why”能力。
这正是发现问题的能力。

这对于在现场的商业人士也是相同的。
要跳出以往在既定框架内执行上司交办的已成过去式的“know how”，为达成目标而发现改善型的问题，具备与未来相关的新问题设定能力是很重要的。
优秀的经营者是问题解决者，同时也是优秀的问题发现者。

---

无法发现问题的4个原因
（1）无法确实描述作为问题前提的“应有的景象”：无法想象“应有的景象”，或是所构思出来的“应有的景象”是错误的。
（2）对“现状”的认识，分析力不够，未能正确掌握现状：欠缺正视“现状”的问题意识，欠缺掌握“现状”的分析技巧
（3）无法理清“落差”的结构，而将问题的本质具体化并排定先后顺序：在成为问题的落差还属于模糊不清的状态下就想解决问题，问题的原因各式各样而无法定出先后顺序，又全部都想解决
（4）从可执行的“解决方案”倒回来想问题，所以看不到可能性：眼镜只朝可以执行的方向看，将会把自己推向离问题的本质越来越远

---

走向构思“应有的景象”的时代
被赋予应有的景象的时代 -> 自己构思应有的景象的时代

策略性问题发现：随着“应有的景象”的不同，问题本身差异很大。
操作性问题发现：由于“应有的景象”是被赋予的，只要分析与“现状”的落差就好。

策略性问题发现的构思力是领导人的必要条件
现在大多数商业领导人所需要的是自己构思“应有的景象”的策略性问题发现能力。
以往擅长于操作性问题发现/解决的过去式商业领导人，不见得能成为今后优秀的具策略性问题发现能力的策略家。

以客观性与逻辑性为基础，以主观与感性为核心，来构思“应有的景象”。

随着问题发现的主题视点的改变，“应有的景象”也大相径庭。
无论企业经营如何科学化，问题发现的主体终究是人，“应有的景象”与问题的掌握方式都会随着这个主体的视点转变而大不相同。

所谓“问题发现的4P”，是指一下4项，
（1）purpose，目的轴：究竟“为了什么”？
（2）position，立场轴：究竟“对谁而言”是问题？
（3）perspective，空间轴：俯瞰问题，大局观
（4）period，时间轴：以“什么时间点”的问题为问题

经理人必须有同事处理数件事情的能耐，此外，还得知道何时该转移注意力，把精力放在当时最能促进整个组织产出的活动上。
有一个极有效的收集信息的方法经常被经理人忽略——不时地在公司中走动走动。
管理的艺术便在于如何在那么多看来都很重要的活动中，挑出一两个甚至三个最重要的，然后全心全意的去做。

所谓的“工作成熟度”（task-relavant maturity）是指其对特定项目的经验或熟悉度，而非对一般事情而言。
有效率的管理是根据部署对工作的熟悉度，而施予不同程度的掌控。
上司应该是个协调者，让下属能畅言他的工作状况或者有什么不顺的情形。这个上司集学生和教练两个角色于一身。
经理人在会议中最主要的角色是协调者，负责控制会议的进度和化解纷争。

一定要确定你已在讨论中收集到足够的相关信息，而非只是泛泛之言。
如果决策参与人好不容易达成了共识，但却被“决策终结者”给否决，这种情况一定令人沮丧，甚至会影响士气及工作效率。
当你将计划落实为白纸黑字时，看起来最抽象笼统的总结即为你的战略，而你用来实行战略的行动即为战术。

我们必须培养出何时说“是”和说“不”的判断力和胆识。
斯隆总结他在通用汽车数十年的经验时说：“好的经营管理，是**集权和地方分权的折中产品。”

管理是一种团队活动，不管教练再怎么强，仍然得看队员们的努力。
一旦一个人的动力来源是在自我实现层次，他便需要某些标准来衡量进展如何。最重要的一种衡量尺度是对他工作绩效的回馈。
将办公室化为竞技场能让部署有运动员精神：求胜但不怕输，并随时向自己的极限挑战——这是一个团队能不断前进的主要动力。

随着工作成熟度的改变，管理风格也必须随之改变。
绩效评估的结果将会对部署产生一定的影响且会持续一阵子——可能正面也可能负面，因此绩效评估便成为经理人最具高管理杠杆率的活动。
记住！你所要谈的事情越复杂，沟通的效果通常也越差。

变现不佳的员工常常会忽视他自己的问题。因此，身为上司的你必须找到证据来证明你不是信口开河。
让部署从忽视问题的存在转变为担负责任是经理人的责任，但双方应该一起寻求解决问题的方法。
主管必须不惜任何代价来保持其判断的完整性。为保证评估过程的完整，主管无论如何都得自己做部署的评估。

不要担心问题太单刀直入——这样的问题才容易得到直接的答案。
从长远来看，如果每个主管都能抛开本位主义尽力留住人才，大家都会有好处。

软件发布应该是一个快速且可重复的过程。

从“决定做某种修改”到“该修改结果正式上线”的这段时间称为周期时间（cycle time）。
对任何项目而言，它都是一个极为重要的度量标准。

---

作为软件从业人员，我们面临的最重要的问题就是，如果有人想到了一个好点子，
我们如何以最快的速度将它交付给用户？

我们并不认为软件开发方法不重要，如果没有对软件生命周期中其他方面的关注，
只把它们作为全部问题的次要因素草率对待的话，就不可能实现可靠，迅速且低风险的软件发布，无法以高效的方式将我们的劳动成果交到用户手中。

现在有很多软件开发方法，它们主要关注于需求管理及其对开发工作的影响。
市面上也有很多优秀的书，它们详细讨论了在软件设计，开发和测试方面各种各样的方法，
但它们都仅仅讲述了将软件交付给作为客户的人或组织这一完整价值流的一部分。

本书的中心模式是部署流水线。
部署流水线以持续集成过程为其理论基石，从本质上讲，它是采纳持续集成原理后的自然结果。

部署流水线的目标有三个：
（1）它让软件构建，部署，测试和发布过程对所有人可见，促进了合作。
（2）它改善了反馈，以便在整个过程中，我们能够更早的发现并解决问题。
（3）它使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本。

在许多软件项目中，软件发布是一个需要很多手工操作的过程。
发布当天紧张的原因应该比较清楚了，在这个过程中有太多步骤可能出错。
假如其中有一步没有完美的执行，应用程序就无法正确的运行。
一旦发生这种情况，我们很难一下子说清楚哪里出了错，或到底是哪一步出了错。

每次提交都对应用程序进行构建并测试，这称作持续集成。
什么是反馈流程？它是指完全以自动化方式尽可能的测试每一次变更。
快读反馈的关键是自动化。

人力资源是昂贵且非常有价值的，所以我们应该集中人力来生产用户所需要的新功能，
尽可能快速的交付这些新功能，而不是做枯燥且易出错的工作。

参与软件交付过程的所有人（包括开发人员，测试人员和运维人员，数据库管理员，基础设施的专家以及管理者）都应该参与到这个反馈流程中，这是至关重要的。
如果这些人无法做到每天都在一起工作（尽管我们认为团队应该是全功能团队），就一定要常常碰头并一起探讨如何改进软件交付的流程。
对于快速交付高质量的软件来说，基于持续改进的过程是非常关键的。

想要能够根据反馈来调整行动，就要对信息进行广播。
使用一个大且可视的仪表盘，或者其他通知机制对于确保反馈送达到每一个人是极为重要的。

当然，如果最后没有引发什么改进行动，反馈也就没有什么用了。
因此，这就要求纪律性和计划性。
当需要采取行动时，整个团队有责任停下他们手中的事情，来决定接下来采取哪些行动。
在完成此事之后，团队才能继续自己的工作。

你会注意到，书中很多东西都来自于精益**和哲学。
精益制造的目标是确保快速的交付高质量的产品，它聚焦于消除浪费，减少成本。
多个行业的实践已经证明，精益制造可以节省大量成本和资源，带来高质量的产品，缩短产品上市时间。

部署流水线的一个关键点是，它是一个“拉动”（pull）系统。

如果在软件开发中的某个任务令你非常痛苦，那么解决痛苦的方法只有更频繁的去做，而不是回避。
因此，我们应该频繁做集成，事实上应该在每次提交修改后都做集成。

越早发现缺陷，修复它们的成本越低。
因此，交付团队必须执行铁一般的纪律，一旦发现缺陷，就要马上着手修复。
假如每个人都对火警信号听而不闻，视而不见的话，火警信号就没有意义了。

实际上，我们认为，一个特性只有交到用户手中才能算“DONE”。
这是持续部署实践背后的动机之一。
对于一些敏捷交付团队来说，“DONE”意味着软件已经部署到生产环境上。

应用程序的首次发布只是其生命周期中的第一个阶段。
随着应用程序的演进，更多的发布会接踵而来。
更重要的是，你的交付过程应该随之不断演进。

戴明环：计划（plan），做（do），研究（study），行动（act）。

---

配置管理是指一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一定义，修改，存储和检索。
配置管理策略将决定如何管理项目中发生的一切变化。
因此，它记录了你的系统以及应用程序的演进过程。
另外，它也是对团队成员协作方式的管理。

决定使用一个版本控制工具仅仅是制定配置管理策略的第一步而已。

使用版本控制
（1）对所有内容进行版本控制
（2）频繁提交代码到主干
（3）使用意义明显的提交注释

依赖管理
（1）外部库文件管理
（2）组件管理

每个人都希望使用的软件非常灵活，为什么不呢？
可是，灵活性也是有代价的。

就像一个平衡游标，一端是只有单一用途的软件，而且工作得很好，但很难或根本无法改变它的行为。
然而另一端则是编程语言，你可以用它编写游戏，应用服务器或股票管理系统，这就是灵活性。
显然，大多数软件都在两点之间，而不是这两端点中的任何一个。
这些软件被设计用于完成某些特定目的，但在能够完成这些目的的前提下，通常在一定程度内可以通过某些方法改变它们的行为。

任何改变应用程序的行为，无论修改了什么，都算是编程，即使只是修改一行配置信息。
你进行修改所使用的语言可能或多或少的受到限制，但此时仍是在编程。
根据我们的经验，“修改配置信息的风险要比修改代码的风险低”这句话就是个错觉。

就拿“停止一个正在运行的应用系统”这个需求来说，通过修改代码或修改配置都很容易办到。
如果使用修改源代码的方式，可以有多种方式来保证质量，比如编译器会帮我们查语法错误，自动化测试可以拦截很多其他方面的错误。
然而，大多数配置信息是没有格式检查，且未经测试的。
大多数系统只有在运行时，才能发现错误的配置信息。

可配置的软件并不总是像它看起来那么便宜。
更好的方法几乎总是先专注于提供具有高价值且可配置程度较低的功能，
然后在真正需要时再添加可配置选项。

不要误解我们的意思，配置并非天生邪恶，但需要采取谨慎的态度来一致的管理它们。
现代计算机语言已经采用各种各样的特性和技术来帮助减少错误。
在大多数情况下，配置信息却无法使用它们，甚至这些配置的正确性在测试环境和生产环境中也根本无法得到验证。
我们认为，对部署活动的冒烟测试就是一种缓解配置验证问题的方法，我们应始终使用它。

---

积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你，才是最好的履历。
信誉远胜过时髦的编程技巧和流行的范式。
掌握最新的技术趋势，与时俱进固然重要，但不能让客户为此买单。

Simplify essential complexity, diminish accidental complexity.
简化根本复杂性，消除偶发复杂性。
根本复杂性，指的是问题与生俱来的，无法避免的困难。
偶发复杂性，是人们解决根本复杂性的过程中衍生的。
系统设计的初衷是解决根本复杂性，但是解决方案本身带来了新的问题。
许多软件框架和厂商提供的“解决方案”都表现出偶发复杂性和症状。
解决特定问题的框架很管用，但设计过度的框架增加的复杂性反而超过了它应该缓解的复杂性。
在大型软件项目中，关注根本复杂性，消除偶发复杂性，抽丝剥茧制订解决方案，才是真正的挑战。
应该尽可能选择源自实际项目的框架，警惕那些象牙塔里的产品；
分析方案中有多少代码直接用来解决业务问题，有多少只是用来实现用户与应用之间的交互；
谨慎使用软件厂商在幕后推动的方案，它们并非一无是处，但往往包含偶发复杂性；
要量体裁衣，为问题制订“合身”的解决方案。
架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。

Seek the value in requested capabilities.
分析客户需求背后的意义。
顾客和最终用户提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径。
架构师可以通过询问客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好，成本更低的解决方案。
通过关注问题的真正含义，理顺需求的轻重缓急，把最优价值的需求摆在第一位。

One line of working code is worth 500 of specification.
一行可运行的代码比五百行架构说明更有价值。
架构师往往容易被抽象的架构所吸引，沉迷于设计过程。
架构师必须时刻关注目标，牢记设计只是达成目标的手段，不是目标。
我们的目标是可工作的代码，对软件项目而言，忽略这一点就是灾难。
没有天生完美的设计，所有的设计都要在实现的过程中逐步完善。

提前关注性能问题。
在项目周期的最后阶段才关注新能问题，会导致我们错失大量历史信息，这些信息包含性能变化的细节。
如果性能是架构设计的重要指标，就应该尽早展开性能测试。
当系统出现性能问题时，你只须检查最近的变化，而不用全盘考虑整个架构。

Business drives
业务目标至上。
按照通常的业务惯例，在启动一个软件项目之前，应当制定计划，明确对投资回报率的预期。
架构师必须把握这个预期，并估计该项目的商业价值，避免作出错误的技术决策，造成经费超支。
架构师必须通过沟通协调，既保护软件架构，又坚持业务目标，既允许开发人员制定微观（技术）决策，又设法避免他们参与制定业务决策。
如果技术决策脱离了业务目标和现实条件的约束，则无异于用宝贵的稀缺资源进行高风险的投机。
用业务目标驱动项目开发，才能保证软件开发团队的长远利益。

Simplicity before generality, use before reuse.
先确保方案简单可用，再考虑通用性和复用性。
通过经验提炼的简单方案，远胜不切实际的通用性。
并非所有人都需要通用性，愿意为它掏钱，具体情况要具体分析，有针对性的解决方案才有价值。

导致项目失败的原因很多，最常见的是中途临时调整进度。
当然，调整也可能指延长项目期限，或者增加项目资源，那就没什么好操心的了。
最怕的是时间不变，任务量增加；或者任务不变，截止日期提前。
一般人有一种错误的观念，认为加快进度可以降低成本，提高交付速度。
实际上，改变计划会引发产品质量问题，而解决产品质量问题的代价更高。
最后的结果是成本不降反升，通常项目就是这样失败的。
首先通过协商尽量维持原定进度，保证产品质量；如果必须加快进度，可以尝试去掉一些不重要的功能，留待后续版本发布。
显然这需要提前做好准备，包括谈判策略和说服他人的技巧。

妄想实现所有需求，只会产生脆弱的，一无是处的架构。

Use uncertainty as a driver.——Kevlin Henney
重视不确定性。
当你面对两种可能性时，应该仔细考虑设计中存在的不确定性。
不确定性可以促使你推迟决定，收集更多的信息；促使你用分隔和抽象的方式来降低设计决策对系统的影响程度。
架构属于设计范畴，但并非所有的设计都属于架构之列。
架构代表了那些形成系统的重要设计决策。
其重要性由变更决策的代价来衡量。
优良的架构能够从整体上降低设计决策对系统的影响程度，糟糕的架构则会突出它。
设计决策对系统的影响程度，用变更设计决策需要付出的代价来衡量。
了解出现两个合理选择之外还存在其他选择，比决策结果本身更有价值。
当你积极的与同事在白板前争论不同的可能性时，当你对着代码反复琢磨而无法决定采用哪种实现方式时，
当新的需求或对需求的新解释质疑现有的实现方式时，说明你碰到不容易确定的情况了。
这时要设法利用分离或封装将决策和最终依赖于决策的代码隔离开。
做不到这一点，代码就会杂乱无章，仿佛一个紧张的应聘者，试图用模棱两可，含糊其辞的方式回答没有把握的问题。
当你在不同的系统开发路线之间举棋不定时，不要急于做出决策。
推迟决策，直到掌握更详实的信息，以便做出更可靠的决策。
但也别太迟，要赶在这些信息失效前利用它们。
架构和过程相互交织，所以架构师应该在开发周期中促成那些注重实证的架构方法，并设法引出反馈。

不要轻易放过不起眼的问题。
组织团队一起来想办法管理风险。
不要轻易放过“不妥”的感觉。
多和客户交流，经常与团队沟通，看看你是不是真的了解他们的想法。
自己的盲点自己难以觉察。忠言虽然逆耳，却是你最宝贵的财富。

Reuse is about people and education, not just architect.
有这样一种观点，认为设计优良的框架，细致考虑并精巧实现的架构自然会被人们重复利用。
事实上，即便是最精美，最优雅的框架，可复用性最高的系统，也必须满足下面的条件才可能被复用。
大家知道它们存在。
大家知道如何使用它们。
大家认识到利用已有资源好过自己动手。
如果大家找不到可复用的资源，或者不知道如何使用这些资源，人的天性就会发挥作用。
他们会自己动手实现，到头来吃亏的还是架构师。

Try before choosing.
先尝试后决策。
平庸的架构师可能会收集手边的信息，斟酌酝酿一番，然后从象牙塔里颁布解决方案让开发人员实现。
架构师应该持续关注那些马上要制订的决策。
架构师只需组织协调制订决策的过程即可，不必自己做出决策。

缺乏业务领域知识的架构师不能顺利的理解业务问题，无法把握业务目标和业务需求，也就难以设计有效的架构来满足需求。
架构师的角色任务在于理解业务问题，业务目标，业务需求，并设计技术架构来满足它们。
掌握业务领域知识将有助于架构师选择合适的架构模式，更好的制订对未来的扩展计划，适应不断变化的产业趋势。
理解具体的业务目标也有助于你设计有用的架构。
作为架构师，你要始终理解公司的业务目标，并确保架构支持这些目标。

如果把编写代码看成设计行为，而不是生产行为，我们就能采用一些已经被证明有效的管理方式。
这些方法过于用于管理具有不可预测性的创新工作。
如果软件行业希望从这些方法中获益，我们必须记住，程序设计属于设计范畴，而不是生成范畴。

越复杂的架构越难成功实现，缩小项目规模通常会降低架构的复杂性，这是架构师提高成功几率最有效的途径。
抓住真正需求。
分而治之。
设置优先级。
尽快交付。

Context is king.
具体情境决定一切，根据它设计尽量简单的解决方案。
架构是在具体情境下作出的一系列决策，用以实现一组通常相互制约的需求。
由于需求常常相互制约，所以设计架构的关键不是贡献新内容，而是忽略那些不必要的需求。
设计架构的过程其实就是做出明智决策的过程。
别让团队成员被各种设计理念束缚住，鼓励大家具体情况具体分析，努力找出最简单的解决方案。

架构师安排任务时，应该时刻考虑所有开发人员的性格特点。
从这个角度来看，架构是一个指南，为不同性格的团队成员安排合适的任务，让大家在工作过程中相互学习。
如果大家有机会充分磨合，相互适应，就能轻松化解各种难题。

有多少软件架构师还把自己的工作看成单纯的技术工作？
难道我们不曾周旋于各种利益集团之间，充当和解人，中间人，甚至仲裁者的角色？
有多少人对待工作时，还是一副清高的知识分子态度，不愿正视这份工作必须和人打交道？
要想成为伟大的建筑师，优雅丰富的心灵远比聪明才智重要。
哪种架构师更容易脱颖而出？
是那些天资聪明，对技术烂熟于心的人，还是那些宽容，文雅，高尚的人？你更愿意与谁共事？
维护自己设计的系统远比“修剪爬山虎”麻烦。
你有勇气删掉有缺陷的代码吗？还是假装没看见？最近你推翻过自己的设计吗？
最后一次见到让你赞不绝口的架构是什么时候？你是否立志要让自己的程序给别人带去愉悦？
建筑师首先应该是伟大的雕塑家，或者伟大的画家，否则他不过是个建筑工人。
你的架构是否蕴含适当的艺术的成分？用组件搭建的系统，有没有借鉴绘画的造型和质感？
有没有从雕塑的姿势和平衡中汲取灵感？是否考虑了适当留白的重要性？

别忘了，真正决定程序流程的不是调用栈，而是用户需求。
向令人怀念的调用栈架构告别吧，忘掉那些程序员绝对程序流程的日子，准备好应付随时出现的乱序事件，不断根据具体情境调整策略。
别再抱怨现实世界带来了麻烦，不妨从中寻找解决问题的灵感。

保护好开发人员，不要让他们卷入到不那么重要的工作中。
无论使用的是何种过程，要确保它们的设计目的是消除障碍，而不是增加障碍。

记录软件架构决策理由的文档，长期有用，又无须为之付出过多维护精力，具有很高的投资回报价值。
定义软件架构，就是要在质量属性，成本，时间以及其他各种因素之间，做出正确的权衡。
此份文档应能向你自己，经理人员，开发人员及软件的其他利益相关者，清楚阐明选择某种解决方案，而非另外一种的原因，包括其中做出的权衡。
无论使用何种形式和格式，此文档都应回答以下基本问题：“我们做了什么决策？”“为什么这样决策？”
“我们还考虑过哪些解决方案？为什么没有采用？”
它逼着你明确说出理由，有助于确保基础是扎实稳固的。
如果相关条件发生变化，需要对决策重新评估，它可以作为一个起点。

Assumpation is the mother of all screw-ups.
臆断是把事情搞砸的根源。
软件架构的最佳实践表明，应该记录下每个决策背后的理由，当这一决策包括权衡时尤须如此。
在更为正式的方法中，记录下每个决策的上下文是很常见的做法，这些上下文包含了促成最终决策的各项“因素”。
这种做法颇有价值，因为列出这些因素有助于强调架构师所持的假设，这些假设会影响到软件设计中的重要决策。
事实和假设是构建软件的两大支柱，务必确保软件的基石坚实可靠。

如果发现自己试图把最喜欢的模式硬套在不适用的问题空间上，那么你也许是模式病患者。
不要让你对模式的喜欢变成了迷恋，进而引入超出实际所需的过于复杂的解决方案。
设计模式不是魔法，在解决方案中使用它并不能确保获得好的设计，它们只是对常见问题的可重用的解决方案。
人们记录发现的模式，是为了避免后来重新发明车轮。
当问题出现时，我们能识别出来，并恰当的应用设计模式，这才是我们的任务。
应当保持对系统的洞察力，提供切实有效的商业解决方案，使用模式解决适用的问题才是最重要的。

应用程序的支持和维护都不应该是事后才考虑的事情。
由于应用程序超过80%的生命周期都是在维护上，在设计时就应该多多关注支持和维护的问题。

CAP定理，在分布式系统中通常期望的3个特性，一致性，可用性和分区容错性是无法同时获得的。
相反我们应该问，为什么必须要持有这些特性？这样做可以获得什么好处？何时才期望拥有这些特性？如何才能打破系统成规以达成更佳的效果？
永远不要放弃质疑，因为架构设计的教条往往从根基上削弱了交付能力。

Make sure the simple stuff is simple.
确保简单问题有简单解。
软件架构师解决了很多非常困难的问题，但也会去解决一些相对容易的问题。
对于简单的问题，不要使用复杂的解决方案，这个建议听上去显而易见，但要遵循却并不容易。
架构师展示才华的机会多的是，只要有真正的难题出现，总有这样的机会。
在往前做出超越系统实际需求的架构决策时，不妨自问，照此实现之后，如果再退回去会多么困难。

作为架构师，主要目标应该是创建可行，可维护的解决方案，当然，也一定要能够解决当前的问题。
其中，要知道解决方案中什么是可行的，就要求架构师拥有相关知识，能够实际参与到解决方案的开发活动中去。
因此我建议，如果是你做的系统设计，你也应该能够编程实现自己给出的设计。

我们对项目所做的每一个决策——无论是与技术，过程还是与人相关——都可以看做一种投资形式。
投资是和成本联系在一起的，成本并非单纯只有货币一种形式。
之所以进行投资，是相信它们最终能带来回报。
老板发员工薪水，是期望此项投资将会对他们的事业产生积极的影响。
开发团队决定遵循某种专门的开发方法学，是期望它能够给团队带来更高的生产力。
选择投入一个月的时间重新设计应用程序的物理架构，是相信这将有利于长期运维。
回报率，也成为投资回报率（ROI，Return On Investment），是衡量投资是否成功的指标之一。
虽然不必用经济收益来衡量一切事物，但投资总应该产生增值。
将架构决策视为投资，并将相关的回报率也一并考虑在内。
在判断每个决策选项是否务实或恰当时，这种方法很有用。

一切软件系统都是遗留系统。
即使系统十分前沿，采用了最新的技术开发而成，但对接手它的下一个人而言，它也会是遗留系统。
在今天，软件很快便会过时，这已经成为软件的天然属性。
如果系统能够作为产品存活下来，哪怕只有数月时间，都必须承认，负责维护工作的开发人员肯定要对软件进行缺陷修复，这是不可避免的。
假设有另外不同的团队打开了代码库，他们很容易便可了解到当前在做什么，这是优秀架构的基础。
无需对架构进行过度的简化或为之准备面面俱到的记录文档，好的设计会以多种方式说明自身。
依赖关系十分丑陋的架构，其行为往往看起来就像是笼中的困兽，到处受限。

If there is only one solution, get a second opinion.
起码要有两个可选的解决方案。
对于某个问题，如果只考虑了一个解决方案，那你就有麻烦了。
如果对手头的问题只有一个解决方案，这意味着将没有进行折衷权衡的余地。
如果事实确实如此，别费力气，赶紧让更有经验的架构师助你一臂之力。

Understand the impact of change.
理解变化的影响。
优秀的架构师能够深刻理解变化带来的影响，这种影响不仅限于彼此隔离的软件模块之间，而且包括人与人之间，以及系统与系统之间。
管理变化并非架构师的职责，但架构师要确保变化是可控的。
架构师必须评估变化对项目范围，时间和预算各个方面产生的影响，并准备好花较多时间在那些受影响最大的区域。

Shortcuts now are paid back with interest later.
现在走捷径，将来付利息。
在项目开发初期走捷径，可能会以日后付出高昂的维护费用为代价。
除了避免在开发初期走捷径，发现有不当的设计决策时就要尽快修正，这点也很重要。
设计不当的特征可能会成为后续特征的基础，将来需要花费很高的成本来更正。
作为架构师，一定要坚持成本还很低廉时就动手，搁置越久，为之付出的利息也将越高。

If you design it, you should be able to code it.
架构师要以自己的编程能力为依托。
不要在设计里使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架，不要使用自己没有亲自配置过的服务器。

Stable problems get high-quality solutions.
稳定的问题才能产生高质量的解决方案。
现实世界中的编程，并不是要去解决别人给你的问题。
最好的架构师不是要去解决难题，而是要围绕难题开展工作。
架构师要能够将四处弥漫的软件问题圈起来，并画出其中的各种边界，确保问题有稳定的，完整的认识。
如果问题是稳定的，那么问题解决之后，就永远不会再来烦恼你。

Don't be clever.
弃聪明，求质朴。
不要追求聪明，尽量用最浅显易懂的质朴方法，恰如其分的进行设计。
小聪明会诱导我们在软件开发中使用奇技淫巧。

你的客户并不是你的客户，客户的客户才是你的客户。
如果你的客户的客户赢了，你的客户也就赢了，这意味着，你也赢了。
如果发现你的客户疏忽了他们的客户的需求，你要指出来，并说明原因。
如果你的客户有意无意的忽视他们的客户所看重的重要事项——这种情况常有发生——那么，请考虑放弃这个项目。
明知是糟糕的主意，但你如果竟然也同意接手，这无异于在谋杀客户的客户。
需求收集会议不是项目实现讨论会议，只要牢牢关注你的客户的客户的需求即可。
这样你才能产出客户真正需要的东西，而不只是他们声称自己所需要的东西。
我们也不配称得上真正关爱我们的客户，如果不能更为关爱他们的客户。

设计是一个不断发现的过程。
设计是在不断变化的世界中持续进行探索试验的过程，只有接受这点，我们才能明白，设计过程也必须保持灵活性和连续性。
事物发展总会出人意料。

Choose frameworks that play well with others.
选择彼此间可协调工作的框架。
软件框架是系统的基础，在选择时，不仅要考虑每个框架自身的质量和特性，也要关注共同构成系统的各个框架之间是否能和谐共处。
另外还要关注，随着系统不断演化，是否能方便的向其中加入新的软件框架。
即，必须选择彼此之间没有重叠，而且开放，简洁，精专的框架。
每个框架或者第三方库，如果既能专注解决某个独立的逻辑域或关注面，又不会侵入其他必需框架的领域或关注面，那是最好不过了。
系统应该由多个相互独立的框架组成，其中每个框架都精专与各自的领域，但同时又非常简洁，包容和灵活。
尽量不要使用“无所不能”型的框架，它们依靠的是囊括一切，独霸天下的理念，这样会大大增加框架间重叠的概率。

着重强调项目的商业价值。

Don't be a problem solver.
不要急于求解。
有时候，没有解决方案才是最好的解决方案。
有许多软件问题根本就不需要解决。
它们之所以看似问题，是因为我们只关注它们的表面症状。
由于架构师往往习惯于迅速进入问题解决模式，我们常常忘记，或者根本就不知道，改如何去审视问题本身。
我们应该学会像长焦镜头一样，不断的拉近放远，以确保正确的锁定问题，而不是只一味的接受别人给出的问题。
在需求面前，我们不应该成为被动的储存罐，像糖果盒一样时刻准备着掏出各色各样的聪明点子。
不要立即着手去解决摆在面前的问题，而要看看自己是否可以改变问题。
问问自己，如果没有这个问题，系统架构会是怎样的？
有时业务问题确实需要得到解决，但有时，或许并非那么迫在眉睫。
还是先想想，如果根本不存在这个问题，这个世界又将会怎样。

我们是工具的制造者，我们制造的系统，一定要能够帮助人们——通常是其他人——做事，否则就失去存在的意义，我们也将无法从中获得报酬。
人们使用工具来达到目标，工具只不过是达到目的的一种手段。
好的工具会让用户感到很“上手”，具有“轻巧便利”的特性。

找到并留住富有激情的问题解决者。
我们要找的，是那种具备解决问题的能力和激情的开发人员。
工作中使用的工具肯定会改变，真正所需的，是那种无论技术如何变化，都善于攻克各种难题的人才。
即便能背出某个API的全部方法，也不能说明此人具备解决问题的才能和激情。
好的开发人员对工作充满激情。

业务和软件都是活生生，会变化的实体。
业务需求可能会因新近收购的业务伙伴和营销战略而迅速变化。
应该领悟到我们构建的产品是柔韧的，并且围绕产品的需求很可能会发生变化。
对软件而言，更多的需要以“对工作进行计划，不断调整计划”的方式处理。

没有永不过时的解决方案。
Today's solution is tomorrow's problem.
今天的解决方案会成为明天的问题。
今天做出的选择，在未来很大程度上会是错误的。
如果今天做出的任何选择，在未来会是糟糕的选择，那就不要操心将来要怎样的东西——只要选择能满足当前需求的最佳解决方案就行了。
“分析瘫痪”是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜测对未来而言最好的技术。
为当前选择一项好技术已属困难，要选择在未来也切合可用的好技术只会徒劳无功。
仔细查看目前业务所需为何，以及当前技术市场提供的东西。
从中选择能够满足当前需求的最好解决方案，因为别的东西，不仅对明天是错误的选择，而且，对今天就已是错误的选择。

For the end user, the interface is the system.
对最终用户而言，界面就是系统。
如果产品的用户交互体验质量让人无法忍受，那么无论产品在技术上如何先进或具有开创性，都会造成让人无法忍受的印象。
用户界面是架构的重要组成部分，但往往也是被忽视的部分。
在早期阶段就让用户界面专家参与其中并贯穿整个产品开发阶段，能确保用户界面和产品浑然一体，使最终产品整洁优美。
当产品还在beta阶段时，架构师应仔细观察由真实的最终用户完成的用户交互测试，并将他们的反馈纳入最终产品中。
随着时间变迁，技术会发生变革，产品特性也会不断增加，产品的用法也会因此经常发生变化。
架构师应确保，随着架构变化而变的用户界面也要能够反映用户的期望。
用户交互应是整个产品架构的目标之一。

Great software is not built, it is grown.
优秀软件不是构建出来的，而是培育出来的。
环境和需求的变化不可避免，你和你的系统都要学会适应变化。
设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。

2001年美国营销学会评选有史以来对美国营销影响最大的观念，
结果不是劳斯·瑞夫斯的USP、大卫·奥格威的品牌形象，
也不是菲利浦·科特勒所架构的营销管理及消费者“让渡”价值理论，
不是迈克尔·波物的竞争价值链理论，
而是艾·里斯与杰克·特劳特提出的“定位”理论。

	独特的销售主张	品牌形象论	定位论
产品时间	50年代	60年代	70年代以来
核心理论，主张	强调产品具体的特殊功效和利益	塑造形象长远投资	创造心理位置强调第一
方法和证据	实证	精神和心理的满足	类的独特性
沟通的着眼点	物	艺术，视觉的效果	心理上的认识

应强调指出的是，“缺发适当定位”至今是许多本地企业及赢利组织在市场竞争中的“瓶颈”，是营销中突出的问题点。

---

“我们这儿的问题是缺乏交流。”
你经常听到这句让人听烦了的话吗？
问题发生之后，“缺乏交流”是唯一最常见、最普通的解释。

商界、政府、劳资关系和婚姻都会出问题。
人们认为，要是大家都拿出一点时间来，交流一下感情，做一点解释，这世界上的许多问题自然就会消失。
人们似乎相信，只要当事各方坐下来交谈，任何问题都能解决。

真是这样吗？未必。
如今，交流本身也成了问题，我们所在的社会有史以来头一回变成了传播过度的社会，年复一年，我们说的太多，听的太少。

本书旨在讨论一种新的传播方法，叫做“定位法（Positioning）”。

定位是一个改变了广告本质的概念。
这个概念简单到了使人难以理解其威力的地步。

定位要从一个产品开始。
那产品可能是一种商品、一项服务、一个机构甚至是一个人，也许就是你自己。
但是，定位不是你对产品要做的事，定位是你对预期客户要做的事。
换句话说，你要在预期客户的头脑里给产品定位。

所以说，把这个概念称作“产品定位”是不正确的，好像你在对产品本身做些什么似的。
定位并不是不包含变化在内。它也要变。
不过，那只是名称上的变化，产品的价格和包装事实上都丝毫未变。

变化基本上是表面的，旨在确保产品在预期客户头脑里占据一个真正有价值的地位。
在我们这个传播过度的社会里，想要解决说话有人听的问题，定位同样也是首选的思路。

---

如今，要想成功就得脚踏实地，而真正值得考虑的现实就是预期客户头脑里已有的想法。

定位的基本方法不是创造出新的、不同的东西，而是改变人们头脑里早已存在的东西，把那些早已存在的联系重新连接到一起。
现在的市场对过去管用的战略不再有所反应了，因为市场上的产品、公司和叫卖声太多了。
人们间的最多的问题是：为什么。
我们为什么需要新方法来开展广告宣传和营销？

我们的社会已经变成一个传播过度的社会。

在这个传播过度的丛林里，获得大成功的唯一希望是要有选择性，缩小目标，分门别类。
简言之，就是“定位”。

普通人的大脑已经是一块满得滴水的海绵，只有挤掉已有的内容才能吸收新的信息。
然而，我们却还是往那块过分饱和的海绵里灌输更多的内容，并且为无法使人接受我们的信息而感到失望。

面对眼前大量的信息，人们的普遍对策是收紧人口，对唾手可得的信息接受得越来越少。
传播本身就是传播的问题。

阻碍你的信息发生作用的敌人是传播量，只有在认识到这个问题的本质之后，你才能明白如何去解决它。

不要在产品里，甚至不要在你自己的脑子里寻找解决问题的方法。
要在预期客户的头脑里寻找解决问题的方法。
换句话说，既然用什么办法都不能使别人接受你的信息，那就别去管传播这一头了，把注意方向放在接受方身上，集中研究一下预期客户的观念。
而不是产品的现实情况。

改变一下方法，把注意力放在预期客户而不是产品身上，简化你的选择过程。
定位思维的精髓在于，把观念当作现实来接受，然后重构这些观念，以达到你所希望的境地。

---

在我们这个传播过度的社会里面有一个悖论，那就是什么东西也没有传播信息重要。
有 了信息，什么事都有可能做到，没有信息，什么事也不可能做成。

无论你有多大的天分和雄 心壮志，都无济于事。
所谓运气，通常是从成功和信息交流中产生的。
要在合适的时候对合适的人说合适的话，要找到休斯顿国家航空天局（NASA）的人所 谓的发射空间之窗。

定位就是帮助在人们的大脑中找到窗的一个有组织的体系。
它的基本概念是，传播只有 在合适的环境中和合适的时间里才能实现。

你要想在情场或生意场上获得成功，就必须认识到在对方大脑里捷足先登的重要性。

你如果不是第一个进入预期客户头脑的（无论是作为个人、政客还是商家），就会遇到 定位问题。

（1）产品时代
（2）形象时代
（3）定位时代

你尝到的就是你想尝到的。

任何广告的首要目标都是提高人们的期望值，造成一种假象，即该产品或服务会产生你期望看到的奇迹。
而且，转眼之间奇迹就出现了。

新的、不同的东西必须与原有的东西相关，否则在人们的头脑里没有立足之地。
这就解释了这样一个现象，你有了全新的产品之后，告诉预期客户该产品不是什么，往往要比告诉他们该产品是什么还管用。

要想找到一个独特的位置，你必须放弃传统的逻辑思维。
传统逻辑认为，你要在你自身或你的产品当中找到你的观念。
不对。你必须做的是，到预期客户的脑子里去找。

最为重要的是，成功的定位需要始终如一，必须坚持数年如一日。
然而，每当一家公司打赢了一场漂亮的定位战后，它往往会掉进我们所谓的FWMTS陷阱：“忘记了使他们成功的根本。”Forgetwhatmadethemsuccessful.）

你如果想现在成功，就不能忽视竞争对手的地位，也不可离开自己的位置。

失败者往往认为问题的关键是应再加努力。
一家处于败势的公司即使再努力也不会有多大收效。
问题不在于其实质，而在于时机。

要想通过额外的努力去获得较大的收效，就应当早一点把劲使在确立产品优势上，这才是可贵的东西。

---

定位行动的最终目的应当是在某个产品类别里取得领导地位。
一旦有了这种领先地位， 公司就可以在今后的许多年里放心地享用领先带来的果实了。

---

你是什么样的人？
人和产品都犯一个毛病：认为自己能为所有的人干所有的事。

这里面的问题在于预期客户的头脑。
人们很难把一个概念同每一种产品联系起来如果是两个、三个甚至更多的概念，就更不可能了。

定位工作中最难的一点是，选定某个具体的概念，把它与自己联系起来。
你如果想打破预期客户对你漠不关心的壁垒，就必须这么做。

你是什么样的人？你在生活中的位置是什么？
你能用一个概念来概括你自己的位置吗？
要是能的话，你能通过自己的职业来确立这个位置并加以利用吗？
大多数人没有足够的信心为自己确立一个概念。
他们犹豫不决，指望别人来给自己下定义。

有些雄心勃勃、头脑聪明的人在发现自己身陷一个前景暗淡的处境时通常会怎么办？
他们会更加努力。
他们想用工作更长的时间、投入更多的精力来加以扭转。
成功的秘诀是，一刻不停地拼命干，把工作做得比别人好，名望和财富自然会来到你身边，对吧？

不对。
更加努力地工作很少会成为通往成功之路，干得更加聪明才是更好的办法。
这又是“勤能补拙”的那一套老话。管理人员往往不懂得如何干自己的工作。

他们推销自己的战略往往建立在一个天真的假设上．即能力和努力才是最重要的。
于是，他们更加埋头苦干，等待哪一天有人会把魔棒点在他们的肩膀上。

可是，那一天很少会来到。
事实是，通往名望和财富的道路很少能从自己身上找到。
唯一有把握获得成功的方法是，为你自己找匹马骑。
你内心可能很难接受这一点，但人生的成功更多是要靠别人为你做些什么，而不是你能为自己做些什么。

肯尼迪说的不对（他的原话是：不要问国家能为你做什么，要问你能为国家做什么——译注）。
别问自己能为公司做什么，要问公司能为你做什么。
所以；你如果想最大限度地利用你的职业为你提供的机会，就得睁大双眼，找一匹马替你出力。

（1）第一匹马是你所在的公司。
（2）第二匹马是你的上司。
（3）第三匹马是朋友。
（4）第四匹马是好点子。
（5）第五匹马是信心。
（6）第六匹马是你自己。

要记住，获胜次数最多的未必是体重最轻、脑子最聪明或体质最棒的骑师。最好的骑师赢不了比赛。
赢得比赛的通常是骑着最好的马的那位。
所以，要给你自己找匹马骑，并且让它拼命地跑。

完美的设计不是包罗万象无所不有，而是完整自洽不可精简。
软件工程的目的在于控制复杂度，而不是增加复杂度。
架构一词起源于建筑工程，现在已被用于描述规划、设计并实现软件密集型系统的艺术。
在软件领域中，架构就是指为客户构建系统。

UML类图可以用来表示类之间的关系，
用例图可以用来表示使用场景，
组件图可以用来说明系统中的可重用部分（即组件），并更易于看出它与二进制文件之间的对应关系。

墨菲定律根本内容是：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。

所有的模型都不甚完备，有些模型却有些用处。
若想设计一个系统——任何领域中的任何系统，都需要首先对其进行抽象。
抽象就是指建立一个模型，对系统在视图、结构、行为、参与的实体和流程等方面提供概念上的描述。

UML基于一系列的图形化标记，特别适合在面向对象场景中建模。
不过若使用其他编程理念，例如，函数式或关系型等，UML或许不是最佳选择，
但UML的确非常适合描述面向对象系统。

UML图表：
活动图，类图，通信图，组件图，组合结构图，部署图，交互概述图，
对象图，包图，顺序图，状态机图，时间图，用例图

常用：用例图，类图，顺序图

用例是指系统和其中某个参与者之间的一次交互过程。
用例可以表示哪些参与者要做些什么。
参与者可以是一个用户，或者是外部系统等需要与系统产生交互的对象。
参与者无法被系统控制，参与者定义在系统之外。

类图用来表示系统的静态结构，静态结构是由类型及其关系构成的，
类图中的类型和接口自然由开发团队是实现。

顺序图能够给出实现了某个场景的一系列对象的交互顺序。
顺序图主要用来描述系统中某个流程的详细步骤。
有了顺序图，任何人都可以清楚的了解系统实现某个用例的方法。

UML是一种通用的语言，这意味着它适合描述任何领域，但仅限于大体上的描述，即UML并不能够精确的描述某个领域。
而在我们生活的这个非完美的现实世界中，却不存在通用的语言可以在同等代价下解决所有类型的问题。
而领域特定语言专门为特定的领域和场景设计，它是一种定制的、直击要害的专门语言。
领域特定语言中的元素来自于领域本身，而不是一些固定下来的元模型。

有经验的设计者显然知道一些缺乏经验的设计者不知道的事情。这些事情是什么呢？
写出可以正常工作的的代码是一回事，而写出可以正常工作的良好代码则是另一回事。
若目标是“写出可以正常工作的良好代码”，就需要用更加全面的眼光来看待系统。
一个设计精良的系统并不是一系列指令和修补的堆砌，里面还有很多与设计直接或间接相关的东西。

“写出可以正常工作的良好代码”需要我们更加重视代码的可维护性。
之所以选择这个特性，并不是因为其他特性（例如，可扩展性和可伸缩性）与可维护性相比不重要，
而是因为保持良好可维护的代价比较高，且容易让开发者忽视，最终造成严重后果。
一个良好的代码体系可以容易找到Bug所在，也可以轻易的修复Bug，还可以在任何时候进行任何程度的改进，包括可扩展性和可伸缩性。
考虑到这些，可维护性就成为了设计系统时最应该关注的问题。

从高处着眼，业界普遍认同的是两种软件模式：设计模式和架构模式。
在设计、编写代码时，我们会使用设计模式。
而在概括的规划系统的整体设计时，我们会使用架构模式。

若想设计出好的软件，普通的设计原则就够了。
你并不特别需要模式，不过若某个问题恰好可以由某个模式解决，那么该模式将成为解决问题的捷径。
时至今日，重复发明轮子绝对谈不上是什么好事。

模式并不一定是某个问题的终极解决方案，使用模式也不会让你的代码更好，或执行速度更快。
正确应用模式只能够保证解决问题，对待模式要有一颗平常心，不要花费很大的力气去让设计符合某个模式。

首先解决问题，随后编写代码。——John B. Johnson

若问题领域需要数百个实体来表示，数千个业务规则要满足，那么久需要一些规范来约束组件的设计。
这些规范分为两类：设计模式和架构模式。
设计模式就是针对某种重复出现的软件设计问题提供的通用解决方案。
而架构模式则是更大规模的模式，用来描述系统的组织结构，并制定每个子系统的职责。

从单纯的技术角度来看，很多号称复杂的系统实际上并没有遇到技术难题。
之所以给人复杂的感觉，是因为系统所处的领域天生就比较复杂。
通常难点在于为业务创建合适的软件模型，而不是具体的实现过程。
若有了良好设计的模型，那么基本上就可以随意的用合理的代价处理任何程度的复杂性。

业务逻辑通常是一系列的if-then-else语句，一把会手工映射到业务对象的方法上，
其产物通常叫做领域逻辑或业务逻辑。
一个真实系统中，我们经常会面对数以千计的业务规则映射到数百个业务对象上。

真正的敌人是重复，而不仅仅是代码重复。
一个良好设计的系统不会在多个地方（包括代码，文档，单元测试或用例）重复同一个功能。

实现领域模型的一个主要障碍是对象和关系模型数据库之前的不匹配。
领域模型是一个面向对象的设计，和数据库或其他应用程序的约束完全无关，
而今受限于其建模的业务流程，这意味着同样的领域建模可以重用于其他需要同样逻辑的任意场景中。
模型是和业务相关的，且仅和业务相关。
或早或晚，系统将要开始实现，数据也需要持久化，因此你需要将模型映射至一个活多个数据库系统中。
从应用程序角度来看，领域模型就是逻辑上的数据库（为各种数据存档），不过这个“数据库”仅仅是个对象模型，并没有提供关系型接口。
但创建这个关系型接口是必不可少的，且创建代价非常高。

业务逻辑是系统的核心，不过并不是整个系统。
每种做法都有其优势和劣势，各种模式的取舍并不像每个人都能看懂的菜谱或算法那样简单，这也正是架构师存在的意义。

在非技术的上下文中，我们将服务定义成一个业务相关的操作，应用程序中的每个客户都可以重复的执行，
这些客户包括用户、程序中的其他服务以及业务逻辑中的其他部分等。

高层次的思考，必须借助高层次的语言。——Aristophanes

分层系统中中间层的设计有两个选择，应用程序的数据可以通过强类型DataSet等表格状容器保存，也可以选用更加抽象的对象模型。
无论何种做法，最终都需要将数据持久化至关系型数据库中保存，也就难免造成阻抗失调情况。
领域驱动设计，随之而来的就是需要需要以更加概念的方式操作数据，数据库的角色也不可避免的降低成了一个持久化工具。
我们曾经使用多年的、作为存储过程简化封装的数据访问层很快过时并被替代，数据访问层正在不停的向着O/R映射层演化。

用户会嘲弄般的笑道：“太酷了，这跟我们以前说的一模一样，不过不是我们现在想要的。”
行为驱动开发让开发者关注于用户的真实需要，也能帮助用户更快的找到他们的真实需要。

设计软件有两种方式：一种是让其足够简单，从而避免错误。另一种是让其足够复杂，借此掩盖错误。——C.A.R. Hoare
悲观者抱怨风，乐观者期待风的结束，现实主义者却借风杨帆远航。——William Arthur Ward

继承是为了多态，而不是重用。
不要仅为了重用而使用继承，最好是编写一个新的类来满足需求，而不是继承某个原本不是完成此工作的现有类。

Donald Knuth曾说过，过早的优化是所有软件罪恶的根源。
我们将改说法更进一步——不要优化系统，而是让其尽可能的灵活面对改进和扩展，仅在系统完成之后，再关注纯粹的优化。

若你很在乎某个系统特性，那么在设计开始前就应考虑它，安全性和可测试性也是如此。

一些墨菲法则：
1.
为一个赶不上进度的软件项目增加人手，只能让其更加落后于进度。
程序的复杂性一直增加，直到负责维护的程序员力不从心为止。
若建筑师按照程序员写程序那样造房子，那么史上出现的第一只啄木鸟也许会毁掉整个文明。
2.
真正的程序员从不添加注释。若代码难以编写，那么也会难以阅读。
程序员90%的错误来自于其他程序员提供的数据。
编写符合需求的程序和在水面行走一样简单，前提是需求已确定，水面已结冰。
3.
软件可以正常工作的概率与其所需要的代码行数成反比。
Bug出现的几率与正在查看该软件的人数及这些人的重要程度成正比。
专家就是那些最后一刻赶到，陪众人一起挨骂的人。
4.
一个可以工作的复杂系统一定是始于一个可以工作的简单系统。
人们会一直增加软件的可靠性，直到提高的成本已经大于处理错误的代价为止。
在理论上，理论和实践之间没有差别；不过在实践中，二者截然不同。
5.
提供了接口说明文档的软件模块中仍有一些未在文档中提到的功能。
足够好并不是足够好，除非项目有明确的期限。
仅观察铁轨永远都不能告诉你火车行驶的方向。
6.
唯一完美确定的科学就是事后诸葛。
在将某事放在内存（记忆）中时，不要忘了存放的位置。
你永远没时间正确的做一件事，但总是有时间去重做。
7.
不怕用户没有想法，就怕用户的想法错误且不切实际。
若让软件处理了所有可能的愚蠢错误，那么也会同时造就出更加愚蠢的用户。
若想编写出一个连傻瓜都能用的软件，那么也就只有傻瓜才想使用了。

业务层：事务脚本模式，表模块模式，活动记录模式，领域模型模式
服务层：远程门面模式，数据迁移对象模式，适配器模式，面向服务架构
数据访问层：插件模式，控制反转模式
表现层：模型-视图-控制器模式，模型-视图-展示器模式，Presentation Model模式，选择用户界面模式