编写背景：

看到第 2 篇的时候，心里有一些烦躁，没有看第 1 篇时那么的激动我也不知道是为什么，感兴趣的朋友可以看看我在这一篇里都有哪些记录，不感兴趣的朋友建议就不要看了，节省时间啊！！！！！！！

这篇的前言部分有这么一句话：“质量管理要求你管理好你自己，但仅仅如此还是不够的。为了建立和维护大规模信息系统，你还必须在管理你和别人之间的关系上取得成功。”

 

第 6 章 分析管理者的工作内容

 

一个管理者要负责以下内容：

Ø         决定做什么并且指派某人去做。 ---- 决定和指派

Ø         倾听究竟为什么要做，为什么应该让另一个人做，或者，为什么应该用另一种方法，而不是你指示的方法去做。 ---- 倾听

Ø         跟踪工作是否正确完成，如果还未完成，就要准备倾听世界上最差劲的借口。 --- 追踪

Ø         再次跟踪工作是否完成，只是为了发现错误，但是最终还是决定满足现状，因为情况已经如你所希望的那样好了。 ---- 评估质量

Ø         考虑是否应该辞掉那个看起来不能正确完成工作的人，但最终发现那些成功者可能和他们一样差劲，甚至更坏。 ---- 个人决定

Ø         考虑一下如果你自己亲自做这项工作会有多快和多好；仔细想想如果你自己做，这项工作会在 30 分钟内完成，但是你要花 3 天的时间作决策。既然如此，为什么还有人用了两个星期，并且还做错了呢。 ---- 管理

 

协调的管理者怎么做

领导能力是一种创造环境的能力，在这种环境下，每个人都能够有创造力地贡献和解决问题。

我们的管理者对我们的成功有如下贡献：

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.     还有，有时候能明智地雇用和解雇下属

 

有益的提示与建议

对管理来说，你的个人经验永远都是不够的。在你的一生中不可能经历那么多不同的项目。在你二十几年的职业生涯中能经历多少历时 5 年的项目？所以，为了成为一个大项目的高效管理者，你必须学习别人。如果你学不好，就要学习如何学习。

 

小结

Ø         在高效的软件组织里，管理者的工作是让更多的人参与进来，而且还要参与到决定将要做的和正在做的事情之中。

Ø         为了解决危机，管理者必须动员在船舷上的人扔掉行李，以保证船不沉。

Ø         当组织深陷危机时，高水平的人就要肩负重荷。管理者对此不知不觉地起了决定作用，但是本情况可以通过协调的管理行为来调整。

Ø         软件工程管理者的主要任务是在所有为项目努力的员工中间发展一种开诚布公和相互信任的环境。

Ø         协调的管理者不会陷入指责的怪圈，部分原因是他们知道自己不是员工的、老板的，或者软件质量变化的被动牺牲品。相反，他们会聪明地利用这些资源。

Ø         领导能力是一种创造环境的能力，在这种环境下，每个人都能够有创造力地贡献和解决问题。在这种模型下，管理者的工作只能用一种标准来评价：人们被管理得是否成功。

 

第 7 章 了解不同的喜好

 

世界上有两种真理，一种指引道路，另一种暖人心怀。前者是科学，后者是艺术。但他们都不能脱离对方而存在，更难分孰轻孰重。没有艺术的科学就如同管道工手中的镊子一般派不上用场；同样，没有科学为伴的艺术只能是粗俗的传说或者是宅心仁厚的庸医。艺术之中的真理使得科学不会对人性视而不见，而科学的真理则让艺术不会变得滑稽可笑。

 

从工作的角度来看，一个没有判断者的团队永远不会完成任何一件事；而一个没有观望者的团队总会发现：他们并没有真正干完某事，因为有的信息被漏掉了。

 

Ø         低效的管理者在对待员工的差异时假装其不存在。高效的管理者则承认差异并知道如何协调的对待这些差异。

Ø         对待每个人都一样并不意味着平等。敏锐的管理者能够察觉人们之间的不同并懂得如何利用它以增进管理效率 --- 平等，而非不公。

Ø         尽管我乐于相信软件工程中的所有行为都是逻辑的，但实际工作中许多人的确是在感情用事。最平常然而最重要的情感之一就是偏好。

 

第 8 章 不同的秉性

 

Ø         研发的控制过程中经常用到 4 种控制手段：智力控制，物理控制，紧急情况控制，以及感情控制。我们可以把这些控制和秉性联系起来。

Ø         软件领域内的大部分创新都是智力控制的结果，至少它们受到了广泛关注。

Ø         在软件控制过程中引入物理控制时为了处理纯智力模型研发中出现的脱轨行为。通常的办法包括预防、侦错与修正。

Ø         当我们通过固定的流程来处理物理和智力问题时，我们发现管理好坏并不取决于对常规问题的处理，而是取决于对意外 --- 非常规情况的处理。

Ø         展望者总是想法多多。催化剂一心帮助别人发展，而且不愿意任何人受苦。组织者喜欢秩序。麻烦解决者喜欢把事情尽快完成。因为不同软件文化模式偏爱不同类型的控制，所以不同秉性的人对这些模式的反应各不相同。如果不加以阻止，任其按自己的方式发展，每种秉性都可能滥用。

 

第 9 章 把差异当作资产

 

为什么说差异是资产

复杂的软件业务，不可能通过一个管理者向整个团队分派所有任务的方法来进行控制，而是必须让每个人都参与控制。这样做，通常需要人们之间的差异。因此管理者们经常会问两个问题：“哪种人最适合这个任务？”以及“哪种差异会影响实际表现？”

 

差异元素有：文化、男和女、感观特征、能力、身体能力、年龄。

 

每个年龄都有他们各自的优势。年轻人精力充沛，年长者经验丰富。 30 年后，我发现自己已经很难熬夜编程了，但是我学会了怎样在一个正常的工作日内如何高质高量地编程。经验当然是最好的老师，但最好的老师不是必须倾囊相授。同样，尽管年轻人精力充沛，看起来他们似乎也不应该通过任意消耗体力来编写高质量的代码。

每个年龄层都给管理者带来他们所不愿意看到的危险。 20 岁的小伙子可能整天和女同事眉来眼去。一个 30 岁的男人会因为被己婚或未婚妇女在职位上超越自己而感到焦虑。 40 岁的男人会沉浸在中年危机的情绪中，因而整天做着逃到富士山去写一部伟大小说，或者穿着法兰绒外衣在丛林中生活的白日梦。

但是一个不协调的管理者可能会比一个不能应付年龄问题的员工更加灰心丧气。

 

许多从事软件开发的人坚信应该分别对待能力不同的人，但是他们不知道如何去识别能力。他们也相信有区别地对待具有不同优势的人是错误的，但是他们很难应用那些可以源自他人的优点。最后，年龄歧视（不管是喜欢年老还是年轻）成为软件生产组织中的普遍现象，尽管不被注意，但却使组织无法从年龄差异种获益了。

 

第 10 章 不协调的模式

 

为什么我们总是缺乏足够的时间把事情做好，却总是有足够的时间重做？

 

安抚模式

为了满足时间和进度上的要求，管理者会做出所有他们能做到的有害的事。为了安抚顾客，他们允许程序员做偷工减料这种与所有正确行为标准相冲突的事。程序员自己也可能祈祷被允许忽略技术评审、测试和其他质检程序，而且管理者们无一例外地通过屈服来安抚他们。

安抚当然不是一个有意识的选择，它来自于管理者在面对客户和程序员时的那种自卑感。然而，简单地变成有意识的安抚以及这样做之后的有害效果并不能根除安抚模式。

当一个项目进度轻微落后时，迫于顾客和程序员的双重压力，管理者可能转而寻找迅速但却留有隐患的方案。技术评审不但看起来价值不高，而且会使进度更慢。这种思想会诱使管理者允许程序员们省略首次评审或首次评审未通过所导致的二次评审，特别是因为大家都在找一个越快越好的捷径。于是项目看上去又回到进度中来，“安抚有效”的想法更加坚定了。然而，长此下去，越来越多的错误将会出现，而且非常难被找到何解决，因此项目进度反而更加落后了。

起初，跳过技术评审的主意不那么具有诱惑力，因为管理者尚有理智。但是随着一个又一个的“成功”，这个主意就变得更难抗拒了，同时，每次这么做又使管理者的自我评价降低。最终，技术评审要么被完全扔到一边，要么就是名存实亡。没有有效的评审系统，项目错误都在项目后期，以最耗费时间成本和最影响进度的方式出现。管理者用这次的耽搁作为取消下一评审或测试的理由，循环往复，他们对自己的评价越来越低。

 

指责链

当员工或小组犯错，或者未达到进度要求时，管理者有许多额外的问题要解决。屈从于指责犯错误者的诱惑，迅速导致许多被指责者努力逃脱指责。另一方面，员工可能会积怨渐深。他们会采用更多不负责任的方法，甚至颠覆这位经理，从而导致项目出现更多的失败。

开始的时候，指责的冲动并不强，或许因为管理者并不十分信任指责的成效。伴随着一个又一个的“成功”，对指责的信任膨胀以至滥用的诱惑就越来难以抗拒了。最终，每个人都会无端地受到指责，甚至有时是因为别人犯错，自己却被迁怒。生产效率可能在开始的时候会上升，但最终，随着越来越多的人处在滥用的火力之下，生产效率降低了。一旦开始恶性循环，效率随着管理者不断的怒气冲冲而持续走低，最终完全失效。

 

小结

Ø         在很多组织中，管理者感到时间不够用的原因，是他们缺乏协调地处理其他人的不协调的能力。不同的文化模式有他们各自的不协调的特征，因此给予管理者不同的负担。

Ø         无效行为总是留下没解决的问题，以至于不协调的后果之一就是这类问题数量的增加，让其他人来解决，而不是造成问题的人。因此，更多的不协调意味着更多的解决问题和“灭火”的时间。

Ø         软件工程管理者的一个主要的任务就是帮助员工发展社会沟通技巧，不仅仅因为人们会相处得更好，更因为社会技巧作为技术技巧的基础变得越来越重要。

Ø         组织要么把自己锁在不协调模式上，要么是协调模式上。造成这种不同的原因是管理者的决定影响他们的行为，并且为他人所效仿。

Ø         当感到在质量和进度之间很难选择时，软件经理经常牺牲员工间的交流互动，从而很快在质量和进度两方面都付出代价。

Ø         安抚模式在反复无常型组织中尤为普遍，这很好地解释了为什么它们被称为“反复无常型”文化。例如，一个未经过技术评审的项目经常在最后关头付出大量的时间成本，因而对进度造成最致命的影响。管理者们用这种耽搁作为更多地省略技术评审和测试的理由。

Ø         在指责文化中，特别是在例行公事型组织中，屈从于惩罚犯错者的习惯很快将导致员工额外努力，以逃脱指责。另一方面，员工们积怨日深，并且使用更多不负责任的方法，甚至造反，这一切都会导致项目中更多的失败。

 

第 11 章 人类行为技术

 

Ø         当你要试图解释一种令人迷惑的交互关系时，可以像你在编程的过程中解决问题那样处理。从输出开始，然后回溯；或者从隐藏着的顶部开始，然后向下一直到根部。

Ø         你在探索交互关系的过程中，别忘了，自我轻视一定是不协调行为的根。但是不要混淆自我认同和自大。自大的行为 --- 比如坚持保留特权，在规定好开始时间的会议上让其他人等待，甚至在最后一分钟取消会议，或者拒绝参加领导能力培训，由于“我知道全部资料” --- 这就是自我轻视的征兆。这是指责者常用的伪装之一 ---- 我是最重要的，你什么也不是 ----- 这绝对是为了掩盖个人没有价值的感觉。

Ø         为了在实用水平上与人们一同工作，基层管理者需要有一个能够指导日常工作的模型，用来实现更加协调的管理。

Ø         人类行为的技术要比软件技术复杂无数倍。当我能看透更深的层次时，我就能实现完全的和谐，并且用小的能量和破坏性来管理人们（我自己和别人）。成为一个熟练的人类行为技术专家就意味着能达到这个结果。