善工利器
这是一本系统阐述在面对容易失控的软件开发团队时，如何管理、建设和赋能团队，以及成功交付开发成果的书。
直到今天，这仍然是困扰软件工程的一大难题：建立和维护软件开发团队，对内和对外的良好的沟通交流渠道。
甚至，我们可以稍微夸张一点的讲，正是围绕 “如何解决沟通交流” 这一核心问题，人们才孜孜不倦的探索和创造了一个又一个的软件工程方法、模型、方法论。
当我们作为程序员的管理者开始管理程序员的时候，为求得工作任务的进展和质量，我们又经常越俎代庖将某个员工手头的工作接过来自己做好 —— “我来干，你看着”；
不然，等你学会的时间，我早都干好了；而不是耐心、细致、周到、将心比心指导小伙伴们自己做好，不惜用一时的工作效率或者单个工作产品的质量来换取小伙伴们的长远发展。
程序员为何难以管理
从零开始编写新程序，更像是在写小说。
尽管可以将程序员组织成团队，但是，有效管理他们的关键是，管理者要充分认识到每一个程序员都是独立的个体。
程序员之间的个体差异巨大，管理者必须竭尽全力让每个人的长处得到充分发挥，同时尽力弥补每个人的短板，至少要能够有效化解短板引发的问题。
这条原则适用于任何领域的管理工作，不过在管理程序员时尤为重要。
即使软件实践和开发过程十分顺利，但是，当项目的工作产品本身难以捉摸的时候，你该如何做才能对项目的进展状况了如指掌呢？
在几乎所有的软件中，程序本身的实际有形成果（如打印的报告、输出的数据或用户界面）与程序的真实进展都是不匹配的。
坦率的讲，程序员的许多工作（也许是大部分工作）就是对现有的程序进行修改，而这些程序多半是别人编写的。
即使程序是他们自己编写的，恐怕也是半年前的事情了。
而根据 伊格尔森定律（Eagleson's Law）：即使是自己编写的代码，如果有半年时间没有看过，那与别人写的代码没有什么区别了。
这句话的意思是说，代码看起来会很混乱，难以理解，并且由于缺乏有效的进度度量指标，项目何时才能圆满完成也难以预估。
如果程序员的内驱力主要来自时间计划表、管理层压力或者报酬，那么他们就不能成为一名卓越的程序员。
事实上，对于大多数卓越的程序员而言，他们的内驱力来源于更高层次的目标：做出对人们生活切实有用的程序，做出改变世界的杰出产品。
了解程序员
程序员与程序员之间在很多方面存在着巨大的差异，只有充分了解程序员才能完全理解这一点。
大多数公司的高层管理者对所有程序员的管理，都是等量齐观的，这是一个可怕的错误。
历经多年的程序员管理工作之后，我们仍然惊叹于程序员个体之间的巨大差异，这种差异要求管理者在处理问题时对症下药，在激励个体时也需要因人而异。
而对我们而言，有一点是毋庸置疑的：要想成功管好程序员，首先必须要真正的了解每个程序员。
根据我们招聘和管理成百上千位程序员所积累的经验，程序员之间的个体差异，主要来自于个人内在因素，而非外在属性。
沟通的效果，在国内，与距离的平方成反比；如果跨域了国界，那么就与距离的立方成反比。
寻找并延揽出类拔萃的程序员
和普通工程师相比，那些出类拔萃的工程师往往更能顾全大局，他们偏爱行动，具有强烈的使命感；
他们展示和表达出坚定的信念，在管理中充分发挥积极主动的作用，能够给予其他工程师无私的援助。
在同样拥有两年工作经验和接受过类似培训的程序员当中，最好的程序员的生产力水平比最差的要高出 10 倍。
初始编码时间的差异是 20:1，代码规模的差异是 5:1，而调试时间的差异则是 25:1。
20 年后，Barry Boehm 所做出的研究指出，最高效的软件开发人员和最低效的软件开发人员之间的效率差距拉大到了 25:1，而他们产生的 bug 数量的差距高达 10:1。
在 2000 年，Boehm 与其他合著者深化了他们的研究，将研究对象聚焦为团队，得出结论：由经验丰富的顶级程序员组成的团队，其开发效率比缺乏经验的初级程序员所组成的团队高出 5.3 倍。
根据 “个体差异” 研究，优秀的程序员最高可以比平庸的程序员高出 30 倍的工作效率。
考虑到前者从来拿不到应有的报酬，所以可以说他们是软件领域中最廉价的劳动力了。
程序设计经理最重要的工作就是延揽出类拔萃的人。
一流人才招聘一流人才，二流人才招聘三流人才。
具体做事的时候，架构师要少一些，砖瓦匠要多一些。
你的内部岗位描述只是编写外部招聘公告的起点，你需要增补材料，让它看起来更吸引人。
千万别把一次招聘看作是一次性的挑战，我们要把招聘看成是持续进行的人际关系经营过程，这样，短期内你能迅速拓展自己的人脉，长期上也能为公司的招聘工作保驾护航。
所以，你应当让招聘工作一直在路上。
如果你现在的员工都很快乐，他们就会推荐其他杰出的程序员给你。
所以，请营造一个让员工感到关怀备至的工作环境，包括专门为程序员设计的办公室，以及其他一些福利。
我希望招聘文笔流畅的人才，因为在我们的工作中，有很多时间都被用来完成电子邮件、文档、计划、规格书、说明书等一系列文案工作。
所以，我希望我的团队成员都可以把文档写得条理清晰，尽管这是一项很难掌握的技能。
我实际上更希望看到主修英语的人士来从事程序设计工作，而不是主修数学。
我努力寻觅的是那些会自动自发完成很多本职工作以外任务的人士。
他们并不桎梏于学校项目或者他们之前的雇主要求他们完成的工作，他们总是充满激情，以完成了某个业余项目为乐事。
我关心的是，他们是如何维护业余项目的？他们是否在其中倾注了极大精力，还是浅尝辄止之后很快就放弃了？
（面试时采用）类似 IQ 之类的测验是非常愚蠢的。
那些自命不凡的人，我不会聘用他们。曾经，有一位候选人告诉我，他每周只需要工作两天，因为在这 16 个小时内他就能完成其他人 40 个小时才能完成的事情。
哦，你不用来了，谢谢。
一定要要求候选人现场编写代码，并回答有关编码的问题，这一点不容置疑。
我一般会请候选人展示一段他最引以为豪的代码，并向我们做出讲解。这样做是为了判断他的表达能力，也就是他有效沟通的能力，这是我在招聘中最看重的技能之一。
请候选人带上他们编写的源代码来参加面试。查看他们的代码，你就会知道他们是否优秀。
接着要求候选人展示一个他所编写的应用程序，评估一下这个应用程序的用户体验如何。
在面试时进行半个小时的结对编程，可以节省所有人的时间。
我总是发现，让候选人详细谈论他们做过的项目能够带来最精准的信息：
他们的沟通是否顺畅，他们在项目过程中实际扮演了什么角色，他们能够把握全局，他们是否真正理解技术细节。
如果你有些犹豫不决，那就不要聘用他。
永远不要满足于只和候选人提供的证明人想谈。如果它们是候选人的朋友，往往不会提及他的缺点，但其实每个人都有缺点。
寻找一个独立的来源 —— 你认识的和候选人共事过或者曾经管理过他的人。
每个程序员的内心动力都不一样。
迅速帮助新员工入职
入职是非常重要的。除了提供培训、确定导师等常规操作，我通常会让新员工迅速完成一些小任务以获得成就感。
如果不这么做，即使是经验丰富的人也会因为挫败感而早早陷入倦怠状态。
而如果我这么做了，新员工会感觉自信满满，并且迅速在团队其他成员那里建立起自己的影响力。
在最初的试用期要处处留心。第一天，最初的几天，第一周，第一个月……
帮他们组队，阅读他们的代码；最重要的，是尊重他们。
新员工接受录用通知之后并不意味着招聘工作已然结束。
聪明的管理者会继续跟进，精心呵护他们的新员工，直到他们入职，以避免发生新员工 “下单后悔” 的事故。
他们也会预料到新员工的前经理会尝试 “挽救” 他们，从而采取相应行动，保障新员工顺利加入团队。
成为高效的程序设计经理：向下管理
多年服务于技术组织的经验告诉我们，那些不愿意深入理解程序员的程序设计经理们，在尝试对开发团队或项目进行管理、指导或者下达命令时，通常会把事情搞得一塌糊涂。
有效管理程序员最重要，最关键的因素（没有之一），就是获取你管理的下属和同僚来自技术层面的尊重。
如果没有获得这种尊重，那么你的每一次管理行动都会遭遇直接拒绝或者消极怠工。
也正是因为这个原因，哪些不懂得程序员的经理（没有在其职业生涯的某个时期做过程序员），才会觉得有效管理程序员是极端困难的。
要想赢得技术层面的尊重，关键因素包括：
- 理解计算机程序设计的艺术
- 拥有良好的工作履历
- 做出过值得称道的技术贡献
- 追逐技术潮流的最前沿
- 成为一个技术社区或者专业组织的活跃成员
- 展现出不菲的个人价值
当你考虑从外部 “空降” 管理程序员设计团队的人才时，一定要确保候选人拥有一系列 “信用证明”（也就是在软件开发行业中拥有良好的、而且是被证明真实可靠的履历），如此才可确保团队对他萌生足够的尊重。
有很多种方法可以构建出令人信服的 “信用证明”，其中最简单易行的莫过于将组织内一位众望所归的杰出程序员或技术主管提拔为经理。
这么做最燃也会面临一些挑战，但是杰出的程序员本身已经受人敬仰，赢得了他的同僚或未来治下的团队成员的尊重，有助于他去培养一种基于尊重的优秀的团队文化。
锦上添花的是，杰出的程序员能够深入理解技术以及与其他经理们非常熟络，本身就是一大优势，因此他可以把这种理解传递给团队。
另一种厚植声望从而赢得技术层面尊重的方法，就是管理者本人曾经开发或管理过一些自己管理的程序员们熟悉的项目或产品。
不论通过以上何种方式厚植你的技术声望，一定要确保团队成员对此深入了解。
一定要在简历上展示出你的技术实力，并在招聘过程中确保技术人员知晓你的技术实力。
不要害羞，要想方设法的让你的成就家喻户晓，广为人知。
这些方法都是赢得来自未来下属的技术层面的尊重，而做出的霸气外露的尝试。
这些行动确实能让你平添威望。你不仅需要竭尽全力赢得这种尊重，而且还要在于下属日常交流中不断强化这种尊重。
在对前沿技术的认知和理解上比你的下属和同僚保持领先一步的优势，也是建立和维护他们对你的技术层面的尊重的一种重要方法。
身为技术团队的管理者，一定要竭尽所能成为一名能够赢得下属尊重的技术带头人，不仅要在技术上保持领先，还要展现出强有力的个人魅力，让你的下属发自内心的尊重你。
出类拔萃的技术人员总是惺惺相惜的。
如果能够延请到出类拔萃的程序员，那么其他部分的工作都会变得轻而易举。
如果请来的程序员都不如人意，那么通常你也就没有时间去处理其他的工作了，因为这些不省心的程序员总是惹出层出不穷的麻烦，让你应接不暇，分身乏术。
很多团队实质上全都是由资质平平的程序员组成的 —— 他们做事本分得体，能够胜任本质工作，但是并不出众。
无论你当前的工作重心是否是为团队增添精英成员，你都需要时刻思考如何强化团队的战斗力 —— 如何有效推动团队的持续改进工作，如何提升团队的能力。
多年的经验使我们确信每一位程序员的个性都是独特的，从管理方式上对不同类型的程序员区别对待，真正做到因人制宜，因人施 “管”，这会让你的管理工作更加成功。
管理者的一个重要工作就是引导各项目工作走向正规，这就意味着管理者需要随时随地保证团队成员之间，以及团队与团队之间沟通顺畅。
这还意味着管理者需要尽早发现前进道路上的阻碍，找到移除阻碍的办法：通常是让一个程序员开始或者结束一个任务。
引导的目的在于让事情完成，而并不在于如何完成。
有些管理者喜欢事无巨细、越俎代庖，此举偶然为之无可厚非。
但是，管理者要想最大化利用好自己的时间，发挥自己的技能，就要引导程序员自己做出正确的决定，而不应该替他做决定。
这样既可以帮助下属培养技能、积累经验、建立自信，还能获得那些具体执行决定的员工的认同。
如果你发现自己经常需要下达具体的命令，那就说明你还没能充分利用好你的管理技能，或者没能赋予下属足够的权力。
作为管理者，你必须指出大方向，然后做好充分的检查，以确保下属做出正确的决定并能实现目标。
你要及早检查下属做出的重要决定，否则在你想要插手接入或者中途修正的时候，下属很可能已经做了很多无用功。
普通的管理者能够在目标无法达到时，发现阻碍目标达成的障碍并且想方设法的消除它们。
优秀的管理者则技高一筹，他们能够提前预知障碍，并且在它们产生实质性危害，从而导致目标无法实现之前就消除它们。
杰出的管理者则在整个处理过程中，表现的举重若轻。
程序设计经理必须要学会的最重要的一课，就是如何保护好自己的团队成员，使其免受组织中每日泛滥不绝的各种问题、争议和所谓 “机会” 的干扰。
做一个抑制噪声的消声器。
只有少数重要的事项会占据优先级排列顺序的顶端，而其他的事项则不那么重要。
请对那些顶级优先级的事项多加关注。
随着时间的流逝，你必须学会分辨哪些事项才是真正重要的，这样你才能妥善处理好这些事项，而不是把精力浪费在其他细枝末节的事项上。
你还需要让你的员工知晓，为了保护好他们，使他们免于淹没在繁杂的琐碎事情之中，你都做出了怎样的努力。
你对团队的另一重保护是，要避免他们受来自组织内其他部门或个人的不当沟通方式的困扰。
你还必须要对团队提供第三重保护：保障他们免于遭受开发部门之外的同时或者部门的抨击。
管理者最重要的职责之一就是，给员工的绩效做出反馈，并且持续提升员工的绩效。
成为卓越的代名词。很多人其实并不能适应需要卓越素质的环境。
设立有一个改善个人绩效的简单易行的方法，而且几乎对每个人都奏效：与你的员工达成共识，设定一系列必须达到的目标、必须完成的任务，并且指定完成的时间；接下来定期审查这些任务的进展状况。
目标可以设立得泛泛一些，但如果想要绩效改进更为明显，那就需要将其设计得更为量化。目标的可测性越高，管理者和团队成员在评估进展状况的时候就越轻松。
确保团队理解你并不只是评估他们 “做了哪些事情”，你还要评估他们 “是如何完成的” …… 这里所说的 “如何”，包括工作透明度高、代码简洁有效、重视文档化工作以及尊重他人。
小心！把员工的绩效目标和奖金关联起来并不一定是个好主意。有关激励理论的研究表明，和通行的想法相反，在软件开发团队这样需要创造性劳动的环境里，奖金会降低员工的工作效率。
自 20 世纪 70 年代以来，涉及成人和儿童的研究都表明，条件性奖励（如果你能做到这些，就能得到某个奖励）会衰减员工工作的乐趣，因而会耗散掉员工工作的内在动力。
奖金额度越大，员工的表现就越差。不仅如此，奖金会让员工的视野变得狭窄，往往只适用于那些机械化的劳作，而对于那些启发式、复杂度高、概念性的工作是没有效果的，而且奖金导致的短视效应，反倒会拖长寻找解决方案的时间。
自我驱动的人们，通常要比那些寻求奖金的人们成就更大。
当人们只能被奖金驱动时，那就是他们最缺乏驱动力的时刻。
需要尽力限制使用条件性奖励的次数，更多的使用意料之外的奖励。
管理者需要尽力帮助团队，让他们找到适合自己的自我驱动力。
为员工设立清晰的绩效目标，可以催生明确的绩效评估方法，当你向领导汇报或者与公司其他人员沟通时，你就可以更加清晰、有条理。
几乎每一位程序员都渴望看到管理者对他们绩效的反馈。
管理者对他们的表现进行反馈的最简单易行的办法，莫过于每天在办公室里走上一圈，或每周与下属来一次面对面的交流，让团队成员知道你在对他们最近完成的工作的看法。
对下属的绩效定期进行评估并反馈给下属，这是程序设计经理仅次于招聘到合适的人选的重要职责。
我的工作不是对人们宽容，而是要让他们变得更为优秀。
管理者必须要对组织和所有下属负责，不能无原则的迁就那些在重要工作中表现得很差的个人，否则就是姑息养奸。
没有什么方式能够替代面对面的沟通，当项目处于关键时间节点上时尤为如此。
团队成员之间相隔越远，沟通方式就应该更为正式、更为明确。
大型团队（29 人）产生的代码缺陷大约是小型团队（3 个人）的 6 倍，这显然会浪费大量成本。
同时，为了达成同样效果的交付成果，大型团队大约平均只比小型团队少用了 12 天时间。
小型团队比大型团队更高效 …… 完成同样大小的项目，5~7 人的团队所花费的时间最短。
没有杰出的团队，就做不出杰出的软件，而大多数开发团队都像一个支离破碎的家庭。
成为高效的程序设计经理：向上管理、对外管理以及自我管理
成功并不只在于你做了什么，更需考虑别人会如何看待你所取得的成果：现实中，外在认知往往比实际的行动更为重要。
向上管理始于了解你的领导，了解他们是哪种类型的人：技术型、销售或市场型、财务型，抑或是其他类型？
是关注大局型还是注重细节型？什么样的问题最令他们敏感？
如何向上管理取决于你能否正确了解你的领导，以及其他你可能间接或隐式汇报的高层管理者。
你的领导级别越高，你的报告就要越发精简，更加注重大局 —— 更少细节，更大格局；更少文字，更多项目符号。
更为关键的是，你需要清醒审慎的评估如何高效的与你的领导进行沟通。
你应当（而且必须）一直采用迭代方式不断优化沟通效果，不断调整沟通的信息量。
有的事情需要长篇大论才能有效澄清，而又的事情浓缩为寥寥数语才是上上之选。
你不必喜欢或者崇拜你的领导，也不必憎恨他。
但你必须管理他，让他成为你事业进步、职业发展与个人成功的助力源泉。
透彻了解你领导的个性特征，可以帮助你决定如何采取某些行动。
没有什么能比定期汇报，更能够赢得领导对你的信心了。
请注意，其他人可能会查看你沟通的信息，所以你要始终如一的保证汇报的专业度，避免汇报内容有任何负面的评论。
因为负面评论总会通过某种方式，传到你并不希望听到它的人耳中。
有时候，口头沟通比书面报告效果更好。
沟通的另一个重要方面是精心设计和完美展示 PPT 文档。
请一定要设法掌握设计精美 PPT 文档的艺术。
高效的程序设计经理必须能够进行高效的沟通，在如今这个时代，能够做出精彩纷呈的 PPT 文档是一项宝贵的技能。
你一定要沉下心来仔细构思，精心设计出令人过目不忘的 PPT 文档。
用来准备 PPT 的时间，应当与观看它的观众（直接观看或者间接观看）的职位高低成正比。
要想获得成功，不能只做好自己的本职工作，还要帮助你的领导获得成功。
人类的本性要求我们要回报那些帮助我们完成任务的人，所以，你应该了解如何才能帮助你的领导获得成功。
为此，你需要了解你领导的领导是如何评判你的领导的。
如此，你才能知晓你需要做些什么才能帮助你的领导获得成功。
你要找到那些对他至关重要的事情，然后你就可以主动尝试选择其中的一至数件来尽情施展自己的才华。
问问你的领导，你怎样做才能给予他帮助，或者自己先采取一些试探性的行动，观察一下领导的反应，如果能够获得领导的鼓励，那就继续行动以扩大战果。
通常，在你采取主动的行动之后，总能得到一些反馈 —— 领导会指导你如何做好下一步工作。
注意，在没有得到这种鼓励之前，不要表现得过于鲁莽，否则你的行为会招致领导的反感，并在未来受到某种程度的回击 —— 让领导误以为你在谋求提升或是谋求将他取而代之，这肯定是你最不愿留给领导的印象。
领导什么时候想要听你的汇报？在每周例会之前为他提供及时有效的信息是至关重要的，而会议结束一天之后，才提供的信息可能就是 “明日黄花” 了。
同样，在预算周期切换之前提供及时的反馈，可以让你的领导（以及你自己）来来年（或下一个预算周期）更轻松自如一些。
审慎思考时机问题，恰当的时机几乎和好运气一样重要。
请记住，电影工作室之所以一定要挑选特定的时间发布新电影，原因一定是非常合理的：一部电影发布的时机，甚至决定了它能否获得奥斯卡金像奖。
同样，请仔细考量沟通时间，以及何时才是交付成果、完成原型或者做好演示的最佳时机。
你要明确公司召开重要会议的时间点，以及公司做出重要决策的时间点。
下面是几条成为模范员工的秘诀，至少在你的直属领导眼里，这些秘诀应该很有效。
-
第一，要维持 “免维护” 状态，也就是说，不要把每一个问题都带到你的领导那里寻求解决方案。你要仔细甄别你的问题，只把那些真正重要的问题拿去寻求领导的帮助。当然，尽可能自己解决问题永远都是上善之选。另外，你还要摒弃只给领导带去问题的做法，向他提交问题的同时，你最好配附几套备选的解决方案。即使你没有特别妥帖的解决方案（或者没有找到最好的），也会让领导觉得你已经做好了自己的功课，找他只是为了寻求他的建议和忠告，而不是直接把问题抛给他。
-
第二，要勇于承担责任，不要把责任推给别人，特别是你的团队成员。
-
第三，毛遂自荐，主动施以援手。有些时候，你的领导会被各种各样的棘手问题困扰，这时候如果你有能力，不妨主动提出 “我帮你对付那一个（或者那几个）问题吧”。
-
第四，要学会给人带来惊喜与欢乐。你可以了解哪些事情与你的领导利害相关，并找到办法超水平的解决这些问题、完成这些任务，甚至超过领导的预期，令他对你刮目相看。有时候做到这一点其实并不需要付出太多。
你可以卓有成效的管理好你的团队，成功的交付项目，但如果没有领导为你保驾护航，你的职业前途必定坎坷。
也许看起来并不那么显而易见，然而你的薪水、奖金、期权、津贴的多寡，乃至于晋升机会的大小，其实都是由一系列管理层闭门会议决定的，有时甚至就是你的领导自己决定的。
所以你一定要主动做好向上管理，这样你才可能得到更多的职业回报。
当你努力做好向上管理时，其实就是以 “润物细无声” 的方式努力巩固与高层领导的关系。
其中的某位领导可能会成为你的好友，并在你今后的职业生涯中一直陪伴你、支持你。
融洽的部门内合作氛围，能够让你领导的工作更为轻松，因为你能自行解决很多部门内部事务，而不必惊动你的领导。
和谐的部门内部合作，还能够消弭很多问题和争论，加速项目的进度，团队也不必经受锱铢必较、互相攻讦之苦。
融洽的部门内部合作还能将你和你的同级同事紧密联系在一起，你们之间可以坦诚探讨问题、分享解决方案、相互安慰、相互鼓励。
融洽的合作氛围可以表现为团队成员互相帮助，不遗余力的对同伴遭受的问题提供支持、共享资源和培训、守望相助。
团队成员都视彼此为最亲密的伙伴、最可靠的帮手，他们愿意帮助对方获得成功。
当你被延请或提拔成为程序设计经理时，请仔细研究公司的组织结构图，找到各个职能部门的主管，想办法让自己逐一了解他们以及了解其他各部门中与你同级的经理。
请他们吃午饭，或者偶尔停下来与他们聊聊天。提前维系好跨部门的纽带关系是很有必要的，当你需要向他们发出求助时，你会更加容易获得他们的积极响应。
尽力知晓公司里每个人的名字，在小规模的组织中做到这一点很容易，但随着公司规模的扩大，在超过 100 人的公司里想要做到这一点就是一项挑战了。
总有一个时刻你会无法跟上公司规模扩大的速度，但还是要努力认识更多的人，争取比其他任何人都认识得多。
要想卓有成效的管理自己，首先就要实事求是的评估自己的行为习惯和行事风格，然后找出那些你想要改进的方面，最后切实履行你的改善计划。
你需要真实客观的评价自己的如下几个方面：
- 个人风格
- 时间管理能力（优先级管理）
- 沟通管理能力
- 管理实践
- 跟踪管理能力
- 虚心好学、处处请教的能力
如果你看起来邋遢懒散，那么你就必须刻意采取更多措施，去克服你的领导以及其他高层管理者与你互动时产生的负面看法。
要以身作则，成为团队表率。永远不要要求团队去做连你自己都不愿意做的事。
找机会了解你的员工，记住他们初入公司的日期；了解他们来自哪里，何时回乡探望家人；探知他们配偶或者伴侣的名字，他们有几个孩子；知道他们开什么样的车，他们想要哪种车；
了解他们想去度假的地方，有什么爱好……
这些事情是你应该弄清楚的，能够帮助你更透彻的了解你的员工。你对他们了解得越透彻，他们对你也就会越坦诚，越愿意对你敞开心扉谈论任何事情。
重要的是，你要有意识的去思考自己的管理风格是什么，你想要培养出怎样的管理风格。
想做到这一点，当然需要锲而不舍、水滴石穿，但是做到之后，它对于帮助你成为成功的程序设计经理是至关重要的。
你最重要的资产就是时间。
你要珍惜时间，同时，要慷慨给予那些真正需要关注的人或时时间。找对方法来管理好时间，你的生活才会过得舒心惬意。
你要坚持按时参加会议、出席约会；确保准时结束会议；不向任何拖沓冗长的会议风格妥协。
每多用一个小时来制订计划，就能少浪费一天的时间和精力。
设置待办事项优先级的关键是
- 找出那些既不紧急也不重要的事项，把它们从列表中划去
- 找到那些既紧急又重要的事项，优先处理，然后再去做剩下的那些或紧急或重要的事项
优先处理既紧急又重要的事项是关键：我们常常把紧急的事项看作是重要的，反而耽误了解决重要的事项。
大多数成功人士都坚持列出待办事项列表。这件事应该成为你生活中不可分割的一部分。
你会发现，每天管理你的待办事项列表，能够让你活力满满、成就感满满。
要想成为一名高效的管理者，你必须创建有效的机制来合理管控如洪水般涌来的各种信息，不能让它反噬你。
想要成为一名高效的管理者，你必须首先成为一个高效的沟通者。高效的沟通者往往都是优秀的倾听者。
人们一般都想要被人倾听，你的员工也是如此。
如果你不听他们在说什么，那么毫无疑问，他们不会开心。
智慧就是你此生从聆听而非说话中所得到的奖赏。
令人惊奇的是，很少有人真正遵循这个简单的实践。放下你的手机或平板电脑，停止处理电子邮件，坐下来凝视说话的人。
用眼神交流，仔细聆听对方在说什么（并思考他们呈现的信息）。
注意，信息并不局限于他们的话语，还包括他们的姿势、身体语言、情感或专注的程度。
留意上述一切信息，语言之外的这些线索往往最能说明问题。
沟通中最大的问题，就是误以为自己已经在沟通。
在倾听完对方所说的内容之后，重述或者重释你听到的内容，以确定你的理解正确。
「外向型程序员和内向型程序员有什么区别？当你和外向型程序员谈话时，他会盯着你的鞋子，而内向型程序员只会盯着自己的鞋子。」
许多人认为管理是自上而下的，管理者具有权威的地位，也就是说，他们处在金字塔的顶端，成为 “一山之王”。
与此相反，我们建议你把自己看做金字塔的底部，而你的员工在顶端。
你的员工和他们做的工作，才是真正重要的。
欲先民，必以身后之。
想要领导民众前进，必须要把民众的利益摆在自己的前面。
看似他们为你工作，实则你为他们工作。
你要确保自己总是在做真正重要的、长远来看会产生重大影响的事情，而不仅仅局限于短期的事情。
今时今地你要做的事情越来越多，你必须要遴选和着力解决重要的事情。
你要有意识的选择重要的事情，并把不重要的事情放到一边。
你应当把招聘这样的事项设置为首要任务，并且每天都要花一些时间在这上面。
没有记录的会议，就是一个从没有召开过的会议。
人们往往也是在做完了所有的管理工作之后，才会把注意力转向自己的职业发展和个人自律。
花些时间和精力实施有效的自我管理，可以让你从日常工作中获得巨大的汇报。
花些时间去做好自我管理吧；每周推拒一次约会，留出一小时给自己，后者可以与导师一起，积极致力于改善自己的风格，改善自己的时间管理、优先级管理和沟通方式，养成时刻跟进的习惯。
这可能是你在一周中花费的最为划算的一小时。
经验法则与至理名言
“往返 3 次法则”：在一次讨论当中，双方交换意见/见解的次数被限定在 3 次。使用 “往返 3 次法则” 可以避免没完没了的争论。
有这样的一个现象，它对所有团队管理者而言可谓是家喻户晓，那就是两位技术专家总会陷入唇枪舌战的争论之中，而且没完没了。
如下做法有效的阻止了这类现象的蔓延 —— 仔细观察只有两人参与的讨论，当他们每个人都讲过 3 次之后就终止他们的对话，让第三个人接着讲。
如果你是一名担负有管理员工责任的经理，那么你的员工比你手头正在做的任何事情都重要得多。
如果一名团队成员在你不太方便的时间来找你谈话，那请先把手头的工作放下，专心跟他交流，因为他可能想要鼓足勇气告诉你一件大事。
我发现，如果这位 “不速之客” 平常不善言辞，那他尤其可能会有大事向你汇报。
如果你的团队成员知道自己来访的时候能得到你最高优先级待遇，那么当遇到很棘手、很麻烦的事情时，他们都来找你倾诉的可能性就更大了。
够用就行。完美是优秀的敌人。
程序员往往容易走向两种极端：要么很快 “完成” 任务，然后把包袱甩给其他人；要么不停的完善、完善、再完善，但总是做不完。
如果管理者总是通过主导谈话内容来达成共识，那么他最终得到的不是一个团队，而只是一群受胁迫的人。
大多数团队都不是真正的团队，而仅仅是每个人与领导的个人关系的集合。每个人都在与其他人争夺权力、荣誉和地位。
行为总是围绕着度量指标转。
受到表彰的消防员会随身带着火柴。
要想控制疾病不扩散，就不要表彰携带病毒的人。我们应该找到那些能够未雨绸缪、预防风险、执行力突出，能够冷静有效的从挫折中恢复而不张扬、不炫耀的人。
人们常常觉得自己的工作充满挑战和艰辛，但却不能理解其他团队为什么不能完成他们自己的任务，因为别人的任务看起来总是比自己的任务简单得多。
我的职责是竭尽所能为员工支付更高的工资，而不是搜肠刮肚去琢磨怎样才能少付工资。
薪酬是一个复杂的函数，它不仅仅由工资组成，还包括一些重要的内容，如工作内容、工作伙伴、是否会用到一些新技术、是否有助于改变世界等。
薪酬 = i×工资 + j×股票期权 + k×福利 + l×与谁共事 + m×工作地点 + n×做什么 + ……
每一个变量（即工资、股票期权、福利 等）前面都有一个与其关联的系数，系数的取值影响着计算的结果。
每个人都应该考虑对自己来说哪些因素比较重要、有多重要，然后在 0 和 1 之间为系数取值。
制定下属的工资表时，要假想它是可以贴到办公室门外来公示的。
一流的招聘人员少之又少，所以要视你的招聘团队为无价之宝。
如果你现有的员工都很快乐，他们一定会推荐杰出的人才给你。所以，请营造一个让员工感到满意舒心的工作环境 —— 包括专门为程序员设计的办公室，优秀的领导力，以及其他一些额外的福利待遇。
招聘两个 “还不错” 的员工，效果远远不如招聘一个杰出的员工。
一流人才招聘一流人才，二流人才招聘三流人才。
我经常寻找那些会自动、自发完成大量除本职工作以外的工作的人。上学时，他们并不只是做老师要求的项目；工作后，他们不仅完成雇主要求他们做好的事情。他们对某种东西充满激情，利用业余时间完成一些兼职项目。
请允许我来抛砖引玉：不要面试那些做不到善始善终的人，永远不要。
证书和学位算不上是成就，完成一项拥有真实用户的真正项目才算。
招聘那种纯粹为了好玩，而用自己的时间开发东西的人。
招聘多名谦逊踏实、能融入团队、寻求稳定职业发展的开发人员，远远好过招聘一名在面试中表现得野心勃勃，又有浓重防备心理的所谓 “明星” 开发人员。
下面这个面试问题很重要，尽管它与技术没有直接关系，但它适用于每位候选人：工作之余你会做哪些好玩的事情？
在面试中要向每一位候选人提这个问题，他认为这样有助于发掘蕴含在候选人内心的各式各样的激情。
当他发现程序员对生活的某些方面充满激情时，他的习惯是将他们的激情转移到对产品的精益求精和对程序的精雕细琢上。
他渴望自己的团队对工作充满激情。
让应聘者告诉你，你的公司可以在哪些方面做得比现在更好。
优秀的主管要拥有足够的判断力，会挑选出能达成自己目标的优秀人选；要拥有足够的自制力，在下属沉浸在工作当中时不会瞎指挥。
只要可能，就要在聘用合同里面加上 3 个月的 “试用期”。这样你就不会被迫接受不合适的人了。
在最初的试用期要处处留心。第一天，最初的几天，第一周，第一个月 …… 帮他们组队，阅读他们的代码；最重要的，是尊重他们。
应对复杂问题最重要的因素，并非程序员所使用的工具和技术，而是程序员自身的职业素养。
问题的复杂度每增加 10%，软件解决方案的复杂度就会相应的增加 100%。这不是一个可以通过努力改变的条件（尽管想方设法降低复杂度总是我们期待的），而是一个基本事实。
距离越远，沟通就应越正式。
团队成员之间的相隔越远，沟通就应越正式、越直截了当。
在电话会议开始时先随便聊聊本地新闻，这是个好习惯。带有地方特色的信息（政治、体育、天气）可以让电话两端的人都觉得自己的生活范围更为宽广。
永远不要低估近距离沟通的价值。
没有什么方式能够替代面对面的沟通，当项目处于关键时间节点上时尤为如此。
Scrum 开发模式实际上可以帮助地理上分散的团队，取得与集中办公团队相近的绩效。
全球化开发的最佳实践 —— 我们发现了许多能够有效改善沟通的实践，其中包括：
- 相比于本地同事的请求，要更积极的响应外地同事的请求，此举有助于建立位于不同工作场所之间员工们的互信
- 在每个工作场所都设置联络员，有效增进各地之间的沟通
- 确立回复电子邮件和语音邮件消息的规范
- 及早安排工作场所之间的差旅 —— 只有不同工作场所的员工会面之后，一切才会运转良好
信任，但不放弃验证工作。
造成延迟和混乱的最主要的原因之一，就是允许一个主管直接管理过多的下属。
Graicunas 建议一个管理者最多管理 5 名直接下属，最好是 4 名。
一对一沟通：这是最有效的管理工具，没有之一。
管理者的任务是充分发挥员工的长处，同时限制员工的缺点，使其不至于影响工作。这也完全适用于管理者的上级和下级。
团队要用到的工具，团队自己去选择。
人类都热衷于提升事务的复杂度，程序员尤其如此。
每个人都可以被传授雕刻技艺：但对米开朗基罗来说，能教给他的是怎样能够不去雕刻。杰出的程序员也是如此。
程序员宁愿站在别人的脚趾上，也不愿站在别人的肩膀上。
我们有两只耳朵、一张嘴，请按这个比例来使用它们。
保持简单 —— 不要把事情过度复杂化。
认真倾听，多提问题。
对自己从事的工作保持一份自豪感。
客观看待一切事物。
反复进行沟通 —— 组织中出现的最大问题之一就是缺少沟通。
学会合作。
学会有效辩论、理性沟通 —— 不论输赢，找出正确途径才是正解。
如果放任不管，员工很快就会偏离项目目标。好的项目领导几乎每天都和员工交谈：“你做了什么？为什么？有效吗？”
你愿意为此而赌上自己的职业前途吗？
这是 Claudia Brenner 在 IBM 时学会提出的一个关键问题。她说，“通过这个问题，你能判断出程序员是否真正相信，他刚与你说过的话”。
你可以不遵循标准，但必须知道为什么要有标准，而且能明确说明标准。
判断你的设计是否已臻完美的标准，不是不能再增加任何东西，而是不能再删减任何东西。
设计第一，编码第二。
编写代码的时候不能 “各人自扫门前雪”。
小心 “闭门造车” 型的软件开发人员。
Conway 定律：如果你让 4 个小组去做同一个编译器，你会得到一个 4 通道的编译器。
Lunde 定律：无论何时，如果你用新团队去替换项目中的资深开发人员，新团队最终都会找到一个令人信服的理由去重写全部代码。注意，新团队的这一做法是错误的。
软件就是创造它的团队的真实写照。无论你想了解一个团队的哪类信息，都可以通过研究他们开发的软件来获得。
我强调这个思想，是因为我觉得这是软件开发管理的基础。团队的语言和行为总是难以捉摸，但软件不会说谎。
软件必然会展现出团队的一切弱点和实力、每个人的天分和缺陷、团队成员的毛病和灵光乍现的智慧。
有疑问，看软件。要达到这个境界，你必须善于翻译，善于理解软件中的种种迹象是怎么产生的。
如果团队和团队开发的软件给你的信息是一致的，那么你在开展下一步工作时就会比较有信心了。
既要聪明的工作，也要勤奋的工作。
我认为在代码走查上花上一个小时的时间，抵得上两周的测试。代码走查是一种真正有效的消除错误的方法 …… 现在我觉得，代码阅读应该贯穿项目的整个生命周期，一旦你沉浸在代码阅读的环境里，你会感觉非常自在。
我使用员工做出的贡献，与他造成的损失之间的差值，作为绩效考核的指标。
如果你能在中午之前给我一份状态报告，那我就取消状态会议。
这是一个能够及时收到状态报告的聪明办法。
没有会议纪要的会议，就是一个从没有召开过的会议。
在项目状态会议上每多花一个工时，真正用于工作的时间就会损失 3 个工时。
所有被测量的东西，都会被暗中操纵。
使用代码行数来测量软件生产力，就好比使用重量来衡量研发飞机的进展状况。
我们的产出价值，应该使用 “代码总量” 乘以 “代码运行的频率” 来衡量。
不要写没人打算运行的代码。
大多数软件工具对效率和质量的提高幅度仅为 5% ~ 35%，但总有人反复说提高幅度是 “数量级”（10 倍以上）的；浮夸是软件公司的通病。
最初学习新的工具或技术的时候，实际上程序员的生产力和交付产品的质量都会降低。只有克服了学习曲线之后，你才能获得预期的收益。
这正是白板几乎成为软件开发团队办公地点的标志性物品的原因之一：白板提供了一块画布，可以演示复杂程序的抽象过程，还允许人们在讨论时指着它讲述。
如果我能够有机会再教育我的孩子一次，我一定会做出一个改变：在餐厅的墙上挂一块白板，与孩子分享可视化的想法，而不是单纯的进行交谈。
一支践行 “集体负责制” 的团队能写出更为整洁的代码（Bug 更少）。
即使 100% 的测试覆盖是可以实现的，但对于测试来说仍然不够。大约 35% 的软件缺陷来自逻辑路径的遗漏，另有 40% 来自特定组合的逻辑路径的执行。它们都不能通过 100% 的测试覆盖发现。（也就是说，100% 的测试覆盖也许只能检测出 25% 的错误！）
得到优秀的运动员容易，让他们配合起来难。
大多数人都真的希望能把工作做好。如果他们做得不好，通常是管理方面出了问题。
每个程序员的内心动力都不一样。了解每个程序员的动机是高效管理的关键。
与我们通常所相信的观点相反 …… 最美好的时刻并非那些被动的、接受性的、放松的时刻 —— 尽管它们是我们通过努力获得的，我们很享受。
最美好的时刻通常发生在一个人为了解决一些难题，为了完成有价值的任务的过程中，身体或精神达到极限的时刻。
我们通常也把这种 “心流” 状态称为 “专心致志” —— 完全沉浸在当前的挑战之中的一种状态，时间不知不觉的流逝掉了。
提拔通常不是对过去表现的奖赏。管理层提拔的都是那些有潜力解决更大、更难问题的人。
我的任务不是激励球员，相反是他们为我们的球队带来了非凡的动力。我的任务是不使他们丧失动力。
如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们对广阔无垠的大海满怀憧憬。
你喜欢并尊重为你工作的人。你关心他们。他们的问题就是你的问题，他们的忧虑就是你的忧虑。
你的心胸像火车一样宽广，大家对此有目共睹。你能在一个人做出可信的东西之前就表现出对他的信任。
你使他们都觉得，你已经把他们当成家人了。这就是他们跟着你的原因。
Novell 刚刚新增了一个头衔：杰出工程师。杰出工程师必须由同事推选产生，其选拔标准要比管理层来选拔的标准严苛得多。
这一标准还能够鼓励大家争当技术团队中的优秀成员，有助于强化每个人的良好行为。
如果你不希望 “技术极客” 流失，那就要想办法提拔他们，但不要让他们当管理者。
他们多数都不太合适从事管理工作 —— 事实上，他们中的大多数可能会变成可怕的管理者。
但你需要给他们提供向上发展的途径，需要给予他们认可，需要给他们发更多的工资。
让员工参与目标设定。
没有哪个杰出的程序员会坐在那里说 “我打算赚一大笔钱” 或者 “我打算卖出 10 万份副本”，因为这样的想法不会促进问题的解决。
对编程人员来说，最糟糕的事情莫过于看不到自己的工作成果交付。
员工离开的不是公司，而是他们的经理。
谨记：当项目团队进行最后冲刺时，团队成员的配偶和家庭也能感受到他们所承受的压力。体贴的项目经历会主动去了解员工的配偶是否需要出租车服务来接送孩子，或者公司中是否有人可以在回家的路上给困在家中照顾患病孩子的员工配偶捎一些东西。
不管团队成员是否有加班费，最大错误都是不对加班进行记录。不能因为团队成员没有加班费就认为那是 “免费的”。对于财务部门来说这种认识可能没有问题，但从项目经理的角度来说，加班不是免费的。
项目经理必须当心的一种危险情况是，狂热而又年轻的软件工程师过多的自愿加班。
管理团队、顺利交付
你们不是来编写代码的；你们是来输出产品的。
侯世达（Hofstadter）定律：做事所花费的时间总是比你预期的要长，就算你已经充分考虑到了侯世达定律的影响。
在保障 “项目进度” 的重压之下，程序员们需要长时间持续工作，除非被其他事情打断。叫外卖能让程序设计团队持续工作。
如果让他们外出就餐，他们持续工作的意志就会减弱，加班的意愿也会降低许多。
做项目就应该像跑马拉松一样。你必须设定好一个恰当的节奏，然后才有希望在接近终点线处发起冲刺，从而一举赢得比赛。
程序员总是能够找到借口说他们实在 “磨刀不误砍柴工”，而且还会千方百计的证明 “这确实是必要的”。有时候情况的确如此，但有时候得需要经理来决定什么情况下这种 “磨刀” 的功夫已经脱离了项目的初始目标，然后让程序员从他们开心的 “工具保养” 工作中回归到真正的首要任务上。
我的经验法则以问题的形式呈现。
- 第一条也是最重要的一条：**我们为什么要做这个？**它提醒我要经常审视自己的团队，观察团队是否聚焦在产品或战略及战术上最优先的事情上。我们常常把弥足珍贵的工作浪费在无足轻重的事情上。
- 第二条：**我们正在试图解决的问题是什么？**它提醒我要把营销部门心心念念的那些华而不实的东西忽略掉，把精力聚焦在真正需要解决的客户问题上，并且积极的寻找解决方案。
这两条经验法则看起来理所应当，具体做事时也确实应该如此，然而它们呢总是被遗忘。
有一半的项目并非在执行项目的过程中就出了问题，它们一开始就错了。因此，一定要保证项目开始的 6 个星期执行正确。
一旦错过市场窗口，商业价值就会变成零。
当你制订战术层面的解决方案时，需要确保在战略层面上已经有了妥善的计划。
危机能使人们团结一致，要善加利用。
要想制订出完美的项目计划，首先要列出所有的未知问题。
每项任务都必须指定唯一一位负责人，如果指定了两位负责人，那这事就没有人负责了。
项目经理的职责是确保每项任务制定 唯一负责人 —— 识别每项任务，确保为每项任务指定一位负责人，推进任务执行，而不是亲自去完成任务。
项目经历还要同唯一负责人一起定期回顾和检查以下 3 个问题：你是否清楚项目的整体目标？你是否清楚你的任务对实现整体目标将会做出怎样的贡献？对于你所负责的那部分工作，有哪些东西会妨碍你达成目标？
病态组织的一个症状是，精简项目人员反而会增大风险。
Rosenberg 定律：软件并不难写，除非你需要用它完成新的工作。
推论：唯一值得编写的软件就是能完成新的工作的软件。
要从小型项目做起，把细节考虑周全，不要盲目憧憬过于华丽、过于缥缈的设计。
如果项目不能解决一些当前急迫的需求，那么它十有八九就是被过度设计了。
其实，使用何种软件开发方法无关紧要；真正重要的是，你必须始终如一的对项目的需求保持清醒的认识。
离开了需求或设计，程序设计就成了一门在空白文本中塞 bug 的艺术。
（对于软件需求而言）我们总是习惯性的以为人们知道自己想要什么，然而实际上，我们的经验更多的倾向于 “人们并不清楚自己想要什么，但在看到实物的时候他们能分辨出不想要什么”。
迭代的过程至关重要：客户是不知道他们想要什么的，直到他们看到实物。
规格说明书中模棱两可的表述，乃是系统的干系人之间悬而未决的冲突的体现。
相比于缺少某些功能特性，糟糕的质量更容易引起客户的不满。
客户可以炒掉公司里的任何一个人，上自董事长下到员工 —— 他们只需把钱付给其他公司即可。
软件很像香肠：享用最终产品时，人们真心不想知道其中都加入了什么。
在实践中，Frederick Brooks 发现，几乎所有的项目都只有 1/6 的时间花在编码上，而有整整一半的时间用在测试和修正缺陷上。
始终雇佣那些比你更聪明的人，但永远不要传递那些你都不理解的东西。
如果它（软件系统）在我的机器上无法工作，那它到哪儿也工作不了。
成功的自动化测试工作的成本都很高。
若不实施自动化测试，成本还要再多上 10 倍。
如果你不容许过程中出现任何错误，那么结果一定会失败。
出色的过程管理是我们的战略。我们通过让普通人管理出色的过程，来获得精彩绝伦的结果。
同时我们也看到，竞争对手们常常使用杰出人才来管理蹩脚的过程，最终成果差强人意（或一塌糊涂）。
我们的工作内容中并不存在 “快速修正错误” 这么一回事。根本不存在可以在短期内改善产品的办法 …… 你唯一能改变的就是有效工作的时间比例 …… 所以你需要在避免浪费时间这一点上全身心投入。
迷恋上原型是危险的，原型只可以达到产品可用程度的 10%。
前 90% 的代码会花费在前 90% 的项目开发时间，剩下 10% 的代码还要再花费 90% 的项目开发时间。
永远不要用一个糟糕的时间点，去交换另一个同样糟糕的时间点。
要给 “完成” 下一个确切的定义。若你的团队并没有对 “完成” 的定义达成共识，自然就很难为工作的圆满完成而感到欢欣鼓舞。
当任务因顺序上的限制不可再分时，添加人手对加快进度毫无帮助。
这就好比无论指派多少个妇女，孕育一个生命都需要 9 个月。许多软件任务都具备这样的特征，这是由调试工作的时序性本质引起的。
好的组织要学会将 “估算” 和 “承诺” 二者区分开来。
如果你是 Scrum Master，如果此时所有人都盯着你看，这就意味着你的做法有问题。
因为 Scrum 团队成员应当彼此互相关注。
当团队没能在估算的时间段内完成事先估计好的任务时，应当削减下一个时间段的时长。
节奏均匀能使团队受益。
为何压力仅仅能使程序员至多提升 6% 的生产率？
我的回答是：压力并不能促使人们的思维变得更敏捷。
组建团队就好似烤蛋糕：调料搭配不当，口味肯定不佳；一旦调料搭配得当，就会十分香甜。
（管理者）应当表现的想一名星探。
应当把有凝聚力（时刻准备迎接新挑战）的团队视为项目交付内容的一部分。
你在项目开始的头一个星期之内所要求的代码质量，将会决定之后每周你所得到的代码质量。
新系统的设计者不仅要做系统的实现者，和第一个大规模使用者，还应当编写首份用户手册。
如果我没有全身心的投入这些活动，我就无法实现数以百计的改进，因为没有亲自参与，就想不到要做哪些改进，或是无法意识到这些改进的重要性。
“学习编程” 与 “设计交互式软件” 之间的关系，就像 “学习打字指法” 与 “写诗” 之间一样，彼此关联甚少。
好的设计能让价值增长速度胜过成本消耗速度。
激励程序员
如果你善于激励，那么即使对本书其他部分涉及的能力大多感到心有余而力不足，你依然可能成为杰出的软件经理。
反过来，如果你不善于激励程序员，那你就很难成为成功的软件经理。
- 马斯洛的需求层次理论
- 麦格雷戈的 X-Y 理论
- 赫茨伯格的激励因素和保健因素理论
马斯洛认为，人的需求可以划分为若干层次，从低层次的需求（生理需求）直到最高层次的需求（自我实现）。
他还坚信，在低层次需求尚未满足之前，更高层次的激励没有多少用武之地。
- 生理需求：基本的生活需要 —— 空气、食物、水、居所、温暖、性、睡眠等
- 安全需求：保护、安全、秩序、法律、约束、稳定等
- 隶属与爱的需求：家庭、感情、关系、工作组等
- 尊严需求：成就、地位、责任、名誉
- 自我实现：个人成长与实现
马斯洛围绕需求层次理论所提出的观点，今天依然在促使我们不断改善工作环境，鼓励员工充分发展，自我实现。
你可能花了几个月甚至几年的时间哄着团队走向自我实现，但当每个人都在担心自己和家人的基本食物和住房需求得不到保障时，团队瞬间就崩溃了。
你必须再次从最基本的层次开始，培养最基本的团队合作氛围。
麦格雷戈的 X-Y 理论：
- X 理论：独裁式、压制的风格、严格控制、没有发展。产生狭隘的压制文化。
- Y 理论：自助式、解放和发展。通过授权、增加自主性及赋予责任，来获得控制、成就及持续的发展。
赫茨伯格的激励因素和保健因素理论：对工作的满意与不满意情绪，几乎总是源自不同的因素，而非之前人们一直认为的是对相同因素的不同反应。
一组因素（激励因素）能真正的起到激励作用，而另一组因素（保健因素）则会导致不满意。
- 激励因素：成长机遇、发展、责任、工作本身、认可、成就
- 保健因素：地位、工作保障、与下属的关系、私生活、与同事的关系、工资、工作条件、与上司的关系、公司政策和管理、监督
人们会努力争取实现 “保健” 需求，如果没有争取到那就会导致不满，而一旦需求得到满足，其作用又很有限，难以持久。
管理不善的组织不知道，人们不是通过解决保健需求来得到激励的。只有当激励因素得到实现和满足时，人们才能得到真正的激励。
保健因素是承载基础的 “木桩”，一旦受到破坏或侵蚀，基础就会不牢，但是保健因素本身无法实现激励。
赫茨伯格的激励因素与保健因素理论，帮助我们更好的理解了员工的动机。
适用于程序员的激励因素：
- 改变世界
- 学习与成长
- 工具和技术
- 认可与称赞
- 趣味性
- 利益
缺乏会导致不满的因素依次是：
- 赢得员工的尊重
- 趣味性
- 学习与成长
- 良好的工作条件
- 合理的公司政策和管理
- 合乎职业道德的管理
- 合理的薪酬
在我所有参与过管理的团队当中，我是第一个认识到导致不满的因素和产生激励的因素并不相同的人。
此时，我突然感悟到：首先要确保员工对一组基础性因素感到满意，然后才能进一步利用另一组不同的因素进行激励。
条件性奖励在多数情况下，反而会导致项目的进度比没有奖励承诺时拖得还要长。
研究表明，奖励会导致员工的关注范围变窄，对于计件工作来说这一点恰好有利于激励，但对于创造性工作来说会适得其反。
另外，激励容易使人上瘾，并容易会催生消极短视的想法。
当人们只能用奖金进行激励的时候，恰恰也是他们最消极的时候。
他并非建议降薪，恰恰相反，他说：公平合理的薪酬至关重要，原因之一是它能使员工无须担心钱的问题，这样他们才能心无旁骛的工作。
他也并不反对非条件性奖励，只要这些奖励不完全在员工的预料之中，不足以使之成为预期即可。
根据我们的经验，项目完成后，对表现出色的员工给予让他们意外的奖励，有助于激励他们加倍努力、精益求精。
内在激励驱动的人所取得的成就，通常要比追求奖励的人所取得的成就更多。
如果你是一名担负有管理员工责任的经理，那么你的员工比你手头正在做的任何事情都重要得多。
作为管理者，你的工作是绝不忽视你的人，始终坚持以人为本。
如果你期待员工努力工作，那么一个很重要的做法是允许他们在办公场所玩耍。
如果你认为玩是 “不专业” 的表现，那么有必要请你重新考虑。
在办公室外玩耍应该成为一种你常用的激励措施，这类活动会产生一些积极的影响。
- 增进友情
- 参与者之间进行非正式的交流
- 锻炼身体、保持健康
管理者的级别越高，办公桌上的玩具就应该更多、更优质。
在我的团队中，每个人都在学习。我对待团队中的每个人都向对待成年人一样。程序员们真心乐意为我工作。
如果你现有的员工都很快乐，他们一定会推荐杰出的人才给你。
所以，请营造一个让员工感到满意舒心的工作环境 —— 包括专门为程序员设计的办公室，优秀的领导力，以及其他一些额外的福利待遇。
“管理” 是让人们做需要做的事，而 “领导” 是让人们想做需要做的事。
永远不要怀疑少数乐于思考、甘于献身的公民可以改变世界。事实就是如此。
如果你不对自己做出改变，那么你将混迹在人群中 “泯然众人”。
如果有什么事儿没做好，那是我的责任。如果有什么事儿做得办好不坏，那是我们共同的责任。如果有什么事儿做得非常好，那是你们的功劳。
这就是让球队赢得橄榄球比赛冠军的关键。
大声赞许；轻声责备。
庆祝你的成功，在失败中寻找幽默。别太把自己当回事儿。你放松，你周围的人才能放松。享受乐趣，并始终保持激情。
建立成功的程序设计文化
卓越的程序设计经理这一角色中的关键要素是创建和培育一种成功的程序设计文化。
对我们中的大多数人来说，这种文化应当支持和鼓励按时按预算交付高质量的软件，应当让团队中的开发人员对成为团队的忠诚成员而感到骄傲和自豪。
你要想方设法打造团队内外追求卓越的期望，逐步建立你和团队能够成功交付软件的信心。
成功的程序设计文化能够以任何针对个人的激励方式都无法望其项背的方式，去驱动团队高效的工作。
建立强有力的程序设计文化，需要创建：
- 一个良好的工作环境：良好的工作环境有利于开发出高品质软件，有利于按时交付符合目标和客户导向的软件
- 充满尊重和公平的支持团队合作和协作的氛围：这可以让员工一直保持在最高工作效率的状态
- 可以不断迸发出饱满工作激情的环境：可以轻松培养出恪守承诺作风的氛围
- 针对产品、项目以及可交付物的度量标准：用意衡量团队的努力程度，用于团队持续改进
在软件公司，为了建立你所需要的程序设计文化，有必要先理解你所在公司的文化。
想要理解公司文化，那就要听听 CEO 的说法。
在程序设计团队中，驱动决策的力量，最终来源于两个因素的平衡：一是关注创新，二是关注对客户和市场的响应。
赞美你想要看到的更多的事物。
- 要鼓励创新，你必须鼓励风险
- 要鼓励风险，你必须容忍失败
- 要容忍失败，你必须充满耐心
- 要传达对创新的鼓励，你必须要奖励奉献，而不仅仅是奖励成功
汽车之所以有刹车，是为了跑得更快，而不是为了跑得更慢。
标准和规范还可以应用于：需求、编码、代码质量、文档自动生成、开发流程、编译流程、测试用例跟踪、可追溯性、代码提交、源码控制、开源代码的使用、知识产权。
几乎每个程序设计组织都需要一种关注 “交付” 的文化。无论是软件上市还是服务上线，按时交付的要求都需要得到广泛重视。
不要告诉别人 “如何” 做事。告诉他们做 “什么” 事，他们会以自己的创造力还你一个惊喜。
我只检查自己所要求的东西。
信任但要核实。
依照其本来面目看待一个人，他只会变得更糟。但是，依照其潜在可能去看待他，他会变得更好。
你应当不惜一切代价去避免针对个人英雄主义的过度奖励。
软件开发团队应当是一个学习型组织。
不要奢望程序员能够开发出完美的代码，这种事情根本不存在。代码是永远也写不完的。
相反的，程序员需要学会在适当的时候放下。
有些程序员不知道 “完成” 是什么意思，他们会说，核心内部函数可以展示的时候，就算是完成了一些工作，而没有考虑需要有流畅用户界面并符合实际需求。
要使程序员达到最高的生产效率，
- 需要为其配置一间安静的私人办公室
- 一台性能卓越的计算机
- 无限量供应的饮料
- 20~22℃ 的室温
- 没有炫光的显示器
- 一把舒适得让人感觉不到的椅子
- 一位能帮他们取信、订阅手册和购买图书的管理员
- 一位能确保因特网畅通自如的系统管理员
- 一位能发现他们发现不了 bug 的测试人员
- 一位能使他们的程序界面好看的美工
- 一支能找到目标客户的市场团队
- 一支能确保目标客户购买产品的销售团队
- 一批富有耐心、帮助客户配置好产品、能帮程序员理解哪些问题引发客户拨打技术支持电话的技术支持人员
- 以及一系列其他的支持和管理职能部门
通常，所有的开销加起来，约占公司总支出的 80%。
成功管理软件交付过程
大多数程序设计经理发现，当领导在评价他们工作绩效的时，往往是以成败论英雄，即他们能否在预算范围之内交付符合客户需求的软件。
即使是在敏捷组织与自组织团队盛行的当今，绝大多数程序设计经理还是需要一力担当软件交付的职责。
而作为一名程序设计经理，你的组织几乎肯定希望你在交付过程中发挥重要作用。
如果你的组织是真正的的敏捷组织，那么你的团队就会担当起软件交付的职责，而作为管理者，你本人很可能被衡量 “能否为团队创造准时交付的软件的各项条件”。
组织期待你可以创造出一派蒸蒸日上的良好开发氛围，一个基于团队合作、团队稳定、顺畅沟通的欢乐祥和而又积极向上的团队文化氛围。
在不同的组织中，管理者的交付责任几乎是各不相相同的。
问问你自己：我的组织是如何衡量我，如何测量我的团队的交付能力的。
真正的敏捷组织少之又少，在更多的情况下，衡量你是否成功交付的标准，依然是经典的预算、时间、范围 和 质量 这四大要素组成的某种组合。
无论你是否喜欢衡量你的各项指标，你都需要清楚理解它们是什么，这一点极其重要。
你还需要知道是否有合作伙伴可以与你分担交付责任。
传统意义上，有许多干系人都会与你分担交付责任。
如果没有，你除了需要学习有关开发管理方面的知识，还要学习项目管理的常规工作。
项目经理的职责是协调团队、预算 和 进度。
当项目规模庞大到需要跨团队时，项目经理通常负责管理多个团队间的依赖关系。
Scrum Master 负责保障敏捷组织的健康运行。
在产品规范方面，你应该有一个产品经理或产品负责人，他的职责是构想你的程序员正在构建的产品，并将其分解为市场实验、最小可行的产品、最小可市场化功能 和 用户故事。
程序员负责正确的构建产品，而产品经理则负责构建正确的产品。
产品交付始于项目或者产品启动会，在该会议上，你将扮演一个推动并确保澄清项目及其目标的角色。
你的角色与产品经理的角色一样，就是去激励你的团队。
你和你的商业伙伴（BP）们要抓住机会，奠定正确的基调。
如果不是具备一定的重要性，你也不会去承接哪怕是最次要的项目，而这正给你提供了讲述这个故事的机会。
如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们要对广阔无垠的大海满怀憧憬。
每一个团队成员，都应该在项目启动后了解何为项目成功的标准，从而使成员都能在同一个方向上共同推动项目的发展。
即使已经有了非常好的项目名称 和 项目 T 恤，项目的愿景也仍然会应为技术性的短视而模糊。
程序员很容易把注意力转向算法、组件模块 和 代码本身，而忽视了客户的需求和想法，以及客户的希望和梦想。
优秀的程序设计经理能够激励团队将重心始终集中到客户身上，专注于交付项目成果。
千万别低估向团队寻求反馈的价值。
团队会议是一个很好的机会，通过一起讨论项目的价值、选择最佳的方案，你可以极大的激励团队成员为追求卓越而努力。
不仅如此，大家一起分享、评估项目的过程，也能厚植同袍之谊，提高团队士气。
产品负责人的职责包括最终验收的标准，以及定义什么是 “成功”。
其关键是要让各个干系人就 “项目的成功标准是什么” 达成一致，并为此提供答案。
产品负责人应当在项目启动时，就上述问题为团队提供各个干系人共同认可的答案。
程序员最讨厌的事情之一就是当他们费尽千辛万苦做出产品时，却发现因为时间太迟、需求不对 或者 产品研发所遵循的需求规格并非客户的现实需要 等诸多原因，而导致产品反响不佳。
所以，你一定要弄清楚干系人对产品的预期，追求的是速度、功能、质量、上市时间，还是某些特定功能、集成度、易用性，抑或其他因素 —— 包括确定衡量这些因素的关键指标。
身为管理者，你代表着你的团队，你有责任了解项目在哪项/哪些预期上可以进行弹性调整。
项目管理中有一条经验法则，叫做 “铁三角”，三角形的三边分别是 范围、进度 和 人员。
这个规则是，范围、进度 和 人员，只能任选其中两项。
例如，如果你要增加功能，那么你要么删除一批总体规模相近的功能，以满足进度的要求；要么延期进度方面的要求，给予你的团队更多的时间；抑或在项目中投入更多的人员。
这是一条显而易见的基本法则。
当然，到底选择 “铁三角” 的哪两边，这可能不是由你来决定的，这可能是产品管理部门的责任。
但你要代表你的团队，确保每个人都明白铁三角的哪条边是可以被调整的。
有时，质量是 “铁三角” 中可调整的参数之一。
过度追求质量，也可能是在玩火自焚。
作为程序设计经理，我们需要从 BP 们那里获取到清晰的功能优先级说明。
为了项目能够成功，我们能交付的 15% 最好是最重要的、能够提高最高客户价值的那部分。
Scrum 流程把优先级顺序规范化定义到 Sprint 循环中。
团队真正需要知道的是，哪些功能项提供的价值最大，然后把这些功能项用作第一个冲刺阶段的候选功能项，并对剩下的最重要的那些功能项做优先级区分。
随着待办项的重要程度的降低，优先级区分可以做得更加粗略笼统。
产品负责人，需要对下一个冲刺阶段的功能项做相同的优先级区分，并在团队中达成共识，确保开发团队总是在做价值最高的开发工作。
一旦错过市场窗期，商业价值就会变成零。
在 “那个日期” 没得商量的情况下，你必须迅速弄清楚 “这个功能” 到底是什么，功能有多少是可以调整的，以及如何为这些功能设定优先级。
意识到交付日期不可更改，那么正确的功能优先级排序，就将成为制订项目计划的重要部分。
Scrum 特别适合范围部分确定的项目，因为 Scrum 可以确保产品待办事项列表 始终按照客户最关心的东西来排序，产品始终是已构建和可构建的。
虽然项目奖励通常都是在项目交付之后发放，但是程序设计经理可以在项目的计划阶段，以及项目的关键节点上为团队争取特别奖励。
在通知团队进入 “加力燃烧” 工作模式之前，他先去找 CFO 交涉：接下来我打算让团队进入高强度加班工作模式。如果他们真能搞定这个项目，你应当给他们颁发一定的特殊奖励。
如果是在项目成功之后再去交涉，CFO 就不会那么容易答应了。
控制预算的人，不论是你还是你的精力，在要求团队付出全部努力，打破常规奋力拼搏之前，一定要预先分配好用于奖励的预算。
项目开始于愿景，但必须通过 需求、假设、预期、风险、里程碑 和 最终交付 的流程，才能成功交付。
开发软件产品是一件非常困难的任务，其中最明显的一点，就是产品经理很难清晰的用文字，表达出程序设计团队到底需要做出什么样的产品。
雪上加霜的是，我们经常能从程序设计经理或程序员那里听到抱怨：他们还不知道到底希望做出什么样的产品，就已经给我们指定了一个必须完成的日期。
当你需要自己推想需求的时候，很难做出满足客户需求的产品。
臆测从来都不能为获知 “需要构建怎样的产品” 打下坚实的基础。
各项研究一再表明，按照模棱两可的需求，或者说按照错误的需求来构建产品，是软件开发中代价最大的错误之一，也是项目失败的首要原因之一。
更糟糕的是，组织往往因为不了解其后果，而对需求沟通不畅的情况一再姑息。
其实，使用何种软件开发方法无关紧要；真正重要的是，你必须始终如一的对项目的需求保持清醒的认识。
业务团队与程序设计团队之间失败的、不完整的 或者 模糊的 需求沟通，是造成这个问题的关键原因。
并且，这个问题拖得越久，修复它的代价就越大。
在软件开发过程中，需求在编码之前就完美无瑕是不现实的，要实现需求清晰化并不容易。
构建程序的很多本质工作，实际上就是不断调整需求规格。
当时每个人都想反抗那种冗长的文风，所以大家一起推动了这次变革。
我们仅仅增加了一个简单的需求标准，要求每个功能都必须包含编号和优先级。
此举让我们的执行能力提升了至少两倍。
单独的需求从产品需求文档、开发到 QA 阶段都有迹可循，程序员不再需要深钻研读产品需求文档，QA 也终于有了可以标记测试的功能项。
而产品经理本人一旦习惯了新的文风，也会发现编写产品需求文档更加容易了。
不论使用哪种开发方法，程序设计经理都需要警惕开发过程中遇到的有歧义的需求。
这种需求会导致程序员遇到不确定的程序逻辑，他们常常会继续编码，填上自说自话的逻辑。
这时候，实际上是程序员自己在确定需求细节。
然而，在定义需求的时候，很有会有程序员比产品经理更理解产品（除非产品的目标客户是其他程序员），因为产品经理的职责才是（或者应该是）理解客户。
解决需求有歧义或不完整的问题，有几种方案。
一种解决方案是使用专门的工具，现在市场上已经有商业工具可以读入产品需求文档，使用自然语言理解功能来定位和显示有歧义的地方。
另一种解决方案是，加强需求提供者与程序员之间的沟通。
如果上述两种解决方案都不可行，程序设计经理就需要介入并为需求提供者和程序员建立沟通桥梁，
并促进双方的内部沟通，以提高程序员理解需求的可能性，
确保他们在遇到需求歧义的时候去询问清楚，而不是按照自己的理解补充需求。
你的工作职责不仅仅是确保需求清晰，还要确保这些需求具有正确的优先级排序，以及确保每个人对这些需求的假设、预期和风险 均有清晰的认知。
无论是将它叫做需求协作，还是需求澄清，它的目的都是了解客户想要什么，做什么可以让客户满意，这是实现需求清晰化的根本。
需求优先级排序对项目成功至关重要。
如果需求没有排序，开发人员将会根据自己的研发偏好，去实现那些最简单的功能，或者一些看起来酷炫、很新颖、很有趣 的功能。
这样，在面对复杂到令人生畏的功能时，开发人员可能会简单粗暴的从他们已知的功能着手，并希望通过对已知功能的开发，带领他们去理解那些未知的功能。
正确进行优先级排序的好处显而易见：以那些最能让你从竞争中脱颖而出的、市场与客户最关注的功能 为开发起点，这样就可以确保在需求的时候，这些功能随时都可以被交付。
敏捷开发方法论正是基于如下原则：经常性交付（每次迭代/冲刺都需要有交付物），这些交付物必须是当前客户价值最高的功能需求，而后剩余的功能也进行重新排序，以确保正确的优先级。
无论使用何种方法论，优先完成高优先级的功能，都可以促使客户为我们提供反馈。
通故这些反馈，我们就能发现各个需求在功能列表中的优先级，它们可能并不像我们开始理解的那样，可能还会发掘出新的功能需求。
这些功能原本不在功能列表中，但显然比大家认为下一步要完成的工作优先级更高。
所谓市场化功能，意味着这些功能可以给客户带来价值。
需求优先级排序，是产品经理或者产品负责人所拥有的权力，但是客户价值并不是优先级排序的唯一标准。
我们需要确保开发人员的想法也要包含在排序的过程中。
通过协作，产品经理与开发人员可以找到如何切分最小可市场化功能的方法。
进行排序时，开发人员需要考虑需求之间的依赖关系。敏捷开发人员需要估算开发任务的相对大小，借此作为量化的依据，并提供给产品负责人用以计算投资回报率（ROI）。
Scrum 将产品负责人的职责规定为 “以故事的形式（用户故事）交付客户需求”，这些用户故事并非只在项目之处进行排序，而是在每次冲刺开始前都需要重新排序。
但是 Scrum 并没有规定必须是产品负责人编写用户故事，仅仅是要有人写就行了。
有经验的管理者会识别项目风险，并作出合理降低或者消除风险的行为，这与交付最高客户价值的功能需求同等重要。
其中一个关键的不确定性领域是用户界面：没有人敢保证可以提交一份用户一定会接受的界面。
所以，在没有将用户界面放到用户面前之前，一切不过仅是猜想罢了。
同时，你也无法预测需要经过多少迭代才能确保用户界面被用户所接受，所以你应该尽早开始着手与这部分相关的工作。
用更早且更频繁的方式交付代码，我们就可以通过频繁的检查点来核实你对需求的理解程度，避免需求出错的情况发生。
当风险太高时，你需要坚持自己的观点。
想方设法得到正确的需求，了解客户真正想要什么、需要什么，那么接下来的项目进展就会顺利许多。
把需求限制在 “做什么” 而不是 “如何做”
程序设计经理还需要警惕，在产品需求文档中指定如何实现的情况。
好的产品需求文档描述的是，客户所需要的解决方案以及它给客户带来的价值，即 “做什么”。
而如果产品需求文档中还附加了选择哪种技术 和 实现路径，则会因为错失了好的程序设计团队的专业知识、研究分析技能以及创造力可能带来的贡献，从而不能交付合格的产品解决方案。
如果你不让你的工程师编写代码，你就失去了他们一半的价值。
如果你发现产品需求文档中指定了 “如何做”，原因可能是你的 BP 们并不相信你，或者你的团队，能做出优质的关于实现方面的决策。
这时候，最好的解决方法是把你们的技术决策过程公布出来，把每一个设计阶段的决策思考都分享给 BP 们，慢慢增强他们对你们的信心。
此外，其原因还有可能是你的 BP 们是在某次行业会议上，看到了竞争对手的演示，因此才会指定 “如何做”；或者也可能是因为指定 “如何做” 更容易描述 —— 比起实际表述出软件所应当完成的功能来说，直接指定使用某种技术更加轻松简单。
有时候，产品经理是在读到某种技术的底层实现方法时，一时兴起而想到的项目创意，因此他们写下需求时可能认为那是唯一的实现方案，而没有想过总结出真正需求的愿景，然后再去拜托技术伙伴们思考是否有更强大的技术用于实现。
优秀的程序设计经理，与普通程序设计经理的区别在于，前者并不仅仅满足于完成接收到的需求，即并不只是开发客户所要求的软件，而是追求去真正理解 BP 们所要完成的目标，交付真正能满足需要的产品。
取悦客户的能力，可以使优秀的管理者及其团队脱颖而出。
苹果公司 iPad 的实例证明，客户无法提出他们想象不到的需求 —— 从来没有人认为自己会需要 iPad。
当然，你很少有机会去制作 iPad 这样完全颠覆客户想象的产品。但大多数项目都可以通过一些细微的差别，满足客户真正需要却没有想到的需求。
引导你的团队去打磨他们自己的、基于团队的 DoD（Definition of Done，完成的定义）。
通过 10 年来对敏捷团队的管理、辅导，以及领导敏捷转型，Ron 相信，在进行正式编码之前想清楚并为团队与项目定义 “完成”，这种做法可能是最有用的敏捷实践。
2016 年版的《产品团队绩效研究》显示，能够自行定义 “完成” 标准的团队与绩效最高的团队之间存在相关性。
我们看到过很多团队时常对他们的 DoD 进行回顾，并更新他们的定义，使之更有有效。
无论你正在构建的是什么东西，都有以前从未被构建过的内容，这一点几乎毫无例外 —— 要么是开发方式，要么是开发工具，或者是平台，又或者是所需要的经验，反正至少有一样是你的团队前所未见的。
估算在项目运行过程中应随机应变。
当你自己都不知道自己在说什么的时候，说得再精确也没有意义。
估算面临的一个挑战是，在项目进行的过程中，需求会变得比一开始看到的更复杂。
前 90% 的代码会花费前 90% 的项目开发时间，剩下 10% 的代码还要再花费 90% 的项目开发时间。
在估算时，程序员们也很少考虑到实际工作以外的因素，高估了他们可以持续工作的时间和可承受的工作强度。
一个非常保守的行业经验法则是，程序员通常花在编码上的时间不超过 55%。
只有当一项任务可以在很多工作者之间分配，并且这些工作者之间完全不需要对此进行沟通交流的情况下，“人”（资源）和 “月”（时间）才可以互换。
我们的公司确实需要在某种程度上了解我们可以在什么时候完成哪些事情，而我们的产品经理也需要了解哪些功能更有成本效益。
你工作的一部分内容就是，引入能使软件开发更可预测的实践。
并且，请永远不要让高层管理者（或者你的产品经理）将相对估算和承诺混为一谈。
在实践中，Brooks 发现，基本上所有的软件项目都只需要用 1/6 的计划时间来编写代码，与此同时需要用一半的时间来进行测试与 Bug 修复工作。
完美是优秀的敌人。
好的设计增加价值比增加成本更快。
要求有人写出设计文档，即使之前我们是在白板上分享，这一行为也会迫使设计具体化。
而设计文档能让团队其他成员接受设计，并迫使他们批判设计。
如果设计只占了整个项目的 1% 的时间，那它肯定太少了；但如果设计占用了整个项目超过一半的时间，那它肯定太多了。
如果你不确定你在构建什么，概念验证（Proofs of Concepts），或 PoCs，对于帮助你的设计师和程序员保证他们了解如何解决问题、在早期冲掉风险、并确定你需要做什么才能成功，是非常有用的。
频繁交付是一种敏捷机制，以确保建立紧密的客户反馈循环。
请记住，QA 的工作是从评审你的设计开始的。你应让设计人员将他们的设计展示给其他同事。
无论你是在做大型设计还是在做即时（JIT）设计，你都应该鼓励或者要求实施设计评审，以尽早排除设计缺陷，找出被忽视的复杂问题和发现没有预料到的交互环节，并识别各种类型的缺陷。
设计评审还有一个隐性的好处 —— 帮助整个团队提高设计能力。
设计评审是一个向年轻的团队成员传授设计能力（不仅是设计原理，还有具体的设计流程）的好机会，而且可以帮助团队建立最佳的设计实践，并不断的提高团队整体的设计质量水平。
一旦建立了稳固的设计评审机制，你就可以把组件设计分发给初级或者中级程序员，而不用担心他们会失败，因为设计评审可以让你或者你的组织为他们提供良好的保障机制。
这样你的资深程序员就有时间把他们的经验扩散到多个组件设计之中，并负责它们的整体设计了，而这两点是你赖以成功的关键。
当技术债务上升时，对客户的响应能力就会下降。
在高技术债务的应用中，估算几乎是不可能的。
重大项目的管理必须像跑马拉松一样。设置良好的节奏，做好足够的准备，保证开发团队能够坚持到最后的冲刺阶段。
你可以要求开发团队偶尔进行冲刺，也可以要求他们在终点线前拼尽全力的奔跑，但不能要求他们在长期项目中一直保持冲刺状态。
在我们看来，很不幸的是，Scrum 把它的迭代成为 “冲刺”，特别是考虑到那些真正实施敏捷方法的团队，是基于历史上马拉松般的速度来规划的。
不现实的项目时间表，肯定会燃尽他们的精力，把团队带向不可避免的失败。
中期里程碑是项目节奏的关键。
敏捷方法可能不会为中期里程碑命名，因为根据敏捷的定义，产品在每一次迭代期或冲刺结束时，都应当是可发布的，所以每次迭代或冲刺都是一个里程碑。
程序员如果彼此不沟通，常常会变得冷漠无声，对什么事都漠不关心，对项目会带来破坏性的影响。
通过在冲刺计划会议上的通力合作，程序员经常互相分享各自的计划、任务 和 步骤，他们能够互相获得反馈。
程序员总是能够找到借口说他们是在 “磨刀不误砍柴工”，而且还会千方百计的证明 “这确实是必要的”。
有时候情况的确如此，但有时候得需要经理来决定什么情况下这种 “磨刀” 的功夫已经脱离了项目的初始目标，然后让程序员从他们开心的 “工具保养” 工作中回归到真正的首要任务上。
不管是否声明，你都有一个关键的职责：让项目愿景保持清晰。
程序员本身的特质（处理细节的能力、平衡各种想法并发散思考的能力），也常常让他们陷入各种细节之中。
你还会发现常常需要在功能、质量、时间之间进行权衡。
你需要问这样的问题：如果我们要实现这个功能，那么在之前的功能列表中，销售部门或市场部门愿意放弃哪一条，才能让我们仍然按时完成项目？
无论你是通过与你的团队成员一对一的谈话，还是通过小道消息，或者从问题上报的过程中发现障碍，你都不能为障碍的存在找借口。
相比于缺少某些功能特性，糟糕的质量更容易引起客户的不满。
你需要 “深入的倾听”，听到人们话外的意思，这样才能听懂他们真正需要什么。
对于真正的 Bug，你的反应最好不是诉诸惩罚，而是专注于如何在未来避免出现类似的问题。
你的任务不是挑错误，而是改善流程：更好的冒烟测试，更好的测试框架，持续的构建流程，确保活跃的代码分支不变得不可编译或不可运行，让正确的人及时做好设计与代码审查，恰好够用的编码指南（以及推荐与施行它的流程），完善的源代码控制系统，支持开发流程的工具，编码最佳实践与查错最佳实践的培训，及时的 QA 反馈，分配最好的程序员和查错人员去指导最缺乏经验的新人等。
先思考测试而不是代码，是一种微妙的改变。这样的改变会带来额外的好处，能够确保你完全理解需求。
于是 编码/测试 循环变为 测试/编码 循环，一旦形成新的习惯，你会发现 TDD 并不会带来多少额外的开发成本，只会带来更好的质量。
有证据表明，做 TDD 要比不做 TDD 多花 15% 的时间。但也有证据表明，TDD 能使 Bug 更少。（微软的两项研究显示，使用 TDD 后，Bug 的数目分别减少了 24% 和 38%。）
有时候，团队远远没有建立起足够的对质量的责任感，这就需要中间过程的帮助。
在检入代码时，程序员需要写一两段简短的说明文字，解释他们将如何测试代码，这样可以使他们慢慢建立起对质量的责任感。
知道其他人会检查自己的代码，会让程序更加小心，以免犯下愚蠢的错误。
解释自己的代码的行为，早已被证明可以帮助程序员，发现他们在其他情况下难以发现的错误。
而且所有的研究都表明，在程序员对代码记忆犹新的时候就发现并修复错误，比起后来在 QA 或者客户发现问题的时候再修复要容易。
不仅如此，代码审查人员还可以教年轻的程序员，如何更好的进行程序设计。
最好让代码所有人在审查前一周左右，按照模板或者 wiki 页面填写好需要被审查的代码段的说明。
最好有一个表格可以让审查人员填写他们的审查结果，指出他们的评论所对应的代码行号，以及提出更好的修正建议，或者仅仅只是提出思考。
一旦建立起代码审查的文化，你就可以建立起一个由资深程序员，对同级或更年轻程序员的代码进行审查的循环。
整个环节在最后冲向终点线的过程中发生了变化。
交付、最终版、发布、上线、完成 —— 不管你怎么称呼，完成软件开发都是一件很困难的事情。
修复不重要的东西，会给发布带来不必要的风险。
从现在开始千万不要再增加新的功能；现在要做的是不断改善质量。
软件永远无法达到尽善尽美。
挑战在于，如何知道何时它已经 “足够好”，该放手结束工作。“有时候，你需要 ‘架枪’ 逼迫程序员，他们才愿意交付产品”。
因此，你（或者产品经理，甚至是高层管理者）需要决定项目何时交付。
有时候，你需要重新定义什么是成功，甚至需要做出非常大的改变，才能让产品更早到达用户手中。
项目宣布成功之后，你应当尽早开展实实在在的庆祝活动。
这是一个让大家放下项目交付的重大压力，聚集到一起放松的很好的机会。
一个项目交付之后，你可能需要给团队片刻的时间来喘口气。
但在他们开始忙于下一个项目之前，你需要召开一个回顾总结会议，让大家一起反思在刚刚完成的项目中，学到了哪些东西。
避免心理防御是关键。
无论我们揭示了什么，我们必须理解并真正相信：考虑到当时的已知情况、每个人的技能和能力、可用资源和情境，每个人都做到了最好。
将期望集中放在下一个项目上，即在你们完成了上一个项目之后，整个团队如何在构建下一个项目时做到更好、更快、更高效。
着眼于未来，可以减轻大家认为你正在寻找上一个项目所犯的错误的感觉。
问问你自己，你的团队做出的贡献和学到的经验中，有哪些可以给公司的其他人带来价值。
下一个项目没准备好，不代表你的团队会失去活力。
闲暇时间往往是程序员重构混乱代码、编写完善文档、补救当初为了及时交付而赶工欠下的各种 Bug 的最佳时机。
交付软件之后，团队成员很容易觉得自己已经成功，但大部分情况下，交付后最关键的任务是倾听客户的反馈。
敏捷团队中的管理者
很多管理者都被项目缠身，没有时间去做好一个管理者。
真正的敏捷组织是让团队自己负责交付，而不是让管理者来负责交付。
麦格雷戈 X-Y 理论：
- X 理论：专制，作风压抑，严格管控，毫无发展。产生限制性的、压抑的文化。
- Y 理论：自由与发展型。通过赋能、授权等方式来获得管控、成就以及持续改进，并且产生责任感。
当我们转向敏捷时，通常会从技能型团队转向跨职能团队。
Scrum 告诉我们，一个团队最理想的人数是 7 人（上下浮动不超过 2 人），也就是 5~9 个团队成员（包括 开发人员、测试人员、设计人员、技术撰稿人），再加上一个 Scrum Master 和一个 PO。
团队的规模各不相同，但其关键是，每个团队不再是围绕专业技能来组织的。
相反，每个团队的配置是跨职能的，能够提供客户觉得有价值并能看到的功能。
每个团队都配置了足够多的来自每个专业的程序员，能够自给自足的完成相应的功能。
每个团队都有一个 PO 来对团队进行指导和支持。PO 专注于定义团队需要完成的功能，并对功能进行排序，以便团队始终为客户提供最大的价值。
团队是完成工作的地方。
管理者在敏捷团队中的职责，并不是专注于交付，交付的职责是被赋予团队的。
团队不向管理者汇报工作，他们是自组织的。
与之对应的，管理者是专注于技术能力和实践这些技术能力的人，专注于雇用合适的人。
除此之外，管理者还要专注于指导、辅导和支持员工做出好成绩。
作为一名管理者，你可以使敏捷文化得以实现，也可以阻碍敏捷文化的发展。
服务型领导关注的是领导，而不是管理。
他是为客户、用户、股东、管理层和员工创造文化，并将重点放在满足客户、用户、股东、管理层和员工等干系人的需求上。
管理者为团队划出了需要完成的事情的界限，并对团队说，我相信你能找到完成工作的方法。
一个 Scrum 团队的工作，就是在管理者划出的界限内，围绕着管理者提出的挑战进行自组织。
管理者的工作是提出适当的挑战，并消除自组织团队的障碍。
管理者所面临的挑战就是要相信成员和团队。
信任但要核实。
我只检查自己所要求的东西。
为个人和团队设定预期目标；如果需要，就对他们进行辅导；检查他们的工作结果；逐步提升对他们所需的辅导的理解。
敏捷管理就是关于，如何改善那些可以对卓越的工作提供支持的流程、环境和具体实践。
当团队自组织的时候，管理者还有很多事情要做，管理者的工作是对团队进行工程化管理，使团队能够全力以赴的完成工作。
如果你是 Scrum Master 且大家都在看你，那你的做法就错了。
既然你的目标是支持团队自我激励和自组织，那么真正重要的是每一个团队的成员都拥有自己的看法和观点。
这意味着你要相信他们，并辅导团队成员相互信任。
这种信任体现在 分享、沟通和协作、建立并重视团队合作，并创造一种 “所有人参与其中” 的团队意识。
从根本上来说，敏捷所强调的是，软件开发是一项团队活动。
研究显示，心理安全是高绩效团队的重要特质，团队成员在团队内部有一种安全感，有机会说出自己的意见。
管理者必须愿意甚至渴望被打断。
我们不仅要欢迎他们来打扰，还要主动邀请我们的员工在任何时候，有任何问题都来随时打扰我们。
在开始的时候，每个人都会谈论范围、预算和时间表，但到最后，就没有人真正关心这些东西了。
他们唯一关心的是人们喜不喜欢你的软件。
这是你唯一真正需要管控的标准。
我们还需要认识到，代码质量的好坏与程序员能不能屏蔽掉杂念、进入心无旁骛的工作状态直接相关。
作为管理者，我们的工作之一就是保护我们的团队，使其远离可能导致质量问题的干扰和多任务的影响。
归根结底，管理者需要设定质量预期，屏蔽噪音，然后检查结果。
重要的不是你的流程，重要的是你改进流程的过程。
曾经有人对我们提出了让人惊讶的建议：如果你没有在规定的时间内把所有的事情都处理好，请先试着缩短时间。
有效的设置时间盒，有助于工作的聚焦与高效。
善工利器
这是一本系统阐述在面对容易失控的软件开发团队时，如何管理、建设和赋能团队，以及成功交付开发成果的书。
直到今天，这仍然是困扰软件工程的一大难题：建立和维护软件开发团队，对内和对外的良好的沟通交流渠道。
甚至，我们可以稍微夸张一点的讲，正是围绕 “如何解决沟通交流” 这一核心问题，人们才孜孜不倦的探索和创造了一个又一个的软件工程方法、模型、方法论。
当我们作为程序员的管理者开始管理程序员的时候，为求得工作任务的进展和质量，我们又经常越俎代庖将某个员工手头的工作接过来自己做好 —— “我来干，你看着”；
不然，等你学会的时间，我早都干好了；而不是耐心、细致、周到、将心比心指导小伙伴们自己做好，不惜用一时的工作效率或者单个工作产品的质量来换取小伙伴们的长远发展。
程序员为何难以管理
从零开始编写新程序，更像是在写小说。
尽管可以将程序员组织成团队，但是，有效管理他们的关键是，管理者要充分认识到每一个程序员都是独立的个体。
程序员之间的个体差异巨大，管理者必须竭尽全力让每个人的长处得到充分发挥，同时尽力弥补每个人的短板，至少要能够有效化解短板引发的问题。
这条原则适用于任何领域的管理工作，不过在管理程序员时尤为重要。
即使软件实践和开发过程十分顺利，但是，当项目的工作产品本身难以捉摸的时候，你该如何做才能对项目的进展状况了如指掌呢？
在几乎所有的软件中，程序本身的实际有形成果（如打印的报告、输出的数据或用户界面）与程序的真实进展都是不匹配的。
坦率的讲，程序员的许多工作（也许是大部分工作）就是对现有的程序进行修改，而这些程序多半是别人编写的。
即使程序是他们自己编写的，恐怕也是半年前的事情了。
而根据 伊格尔森定律（Eagleson's Law）：即使是自己编写的代码，如果有半年时间没有看过，那与别人写的代码没有什么区别了。
这句话的意思是说，代码看起来会很混乱，难以理解，并且由于缺乏有效的进度度量指标，项目何时才能圆满完成也难以预估。
如果程序员的内驱力主要来自时间计划表、管理层压力或者报酬，那么他们就不能成为一名卓越的程序员。
事实上，对于大多数卓越的程序员而言，他们的内驱力来源于更高层次的目标：做出对人们生活切实有用的程序，做出改变世界的杰出产品。
了解程序员
程序员与程序员之间在很多方面存在着巨大的差异，只有充分了解程序员才能完全理解这一点。
大多数公司的高层管理者对所有程序员的管理，都是等量齐观的，这是一个可怕的错误。
历经多年的程序员管理工作之后，我们仍然惊叹于程序员个体之间的巨大差异，这种差异要求管理者在处理问题时对症下药，在激励个体时也需要因人而异。
而对我们而言，有一点是毋庸置疑的：要想成功管好程序员，首先必须要真正的了解每个程序员。
根据我们招聘和管理成百上千位程序员所积累的经验，程序员之间的个体差异，主要来自于个人内在因素，而非外在属性。
沟通的效果，在国内，与距离的平方成反比；如果跨域了国界，那么就与距离的立方成反比。
寻找并延揽出类拔萃的程序员
和普通工程师相比，那些出类拔萃的工程师往往更能顾全大局，他们偏爱行动，具有强烈的使命感；
他们展示和表达出坚定的信念，在管理中充分发挥积极主动的作用，能够给予其他工程师无私的援助。
在同样拥有两年工作经验和接受过类似培训的程序员当中，最好的程序员的生产力水平比最差的要高出 10 倍。
初始编码时间的差异是 20:1，代码规模的差异是 5:1，而调试时间的差异则是 25:1。
20 年后，Barry Boehm 所做出的研究指出，最高效的软件开发人员和最低效的软件开发人员之间的效率差距拉大到了 25:1，而他们产生的 bug 数量的差距高达 10:1。
在 2000 年，Boehm 与其他合著者深化了他们的研究，将研究对象聚焦为团队，得出结论：由经验丰富的顶级程序员组成的团队，其开发效率比缺乏经验的初级程序员所组成的团队高出 5.3 倍。
根据 “个体差异” 研究，优秀的程序员最高可以比平庸的程序员高出 30 倍的工作效率。
考虑到前者从来拿不到应有的报酬，所以可以说他们是软件领域中最廉价的劳动力了。
程序设计经理最重要的工作就是延揽出类拔萃的人。
一流人才招聘一流人才，二流人才招聘三流人才。
具体做事的时候，架构师要少一些，砖瓦匠要多一些。
你的内部岗位描述只是编写外部招聘公告的起点，你需要增补材料，让它看起来更吸引人。
千万别把一次招聘看作是一次性的挑战，我们要把招聘看成是持续进行的人际关系经营过程，这样，短期内你能迅速拓展自己的人脉，长期上也能为公司的招聘工作保驾护航。
所以，你应当让招聘工作一直在路上。
如果你现在的员工都很快乐，他们就会推荐其他杰出的程序员给你。
所以，请营造一个让员工感到关怀备至的工作环境，包括专门为程序员设计的办公室，以及其他一些福利。
我希望招聘文笔流畅的人才，因为在我们的工作中，有很多时间都被用来完成电子邮件、文档、计划、规格书、说明书等一系列文案工作。
所以，我希望我的团队成员都可以把文档写得条理清晰，尽管这是一项很难掌握的技能。
我实际上更希望看到主修英语的人士来从事程序设计工作，而不是主修数学。
我努力寻觅的是那些会自动自发完成很多本职工作以外任务的人士。
他们并不桎梏于学校项目或者他们之前的雇主要求他们完成的工作，他们总是充满激情，以完成了某个业余项目为乐事。
我关心的是，他们是如何维护业余项目的？他们是否在其中倾注了极大精力，还是浅尝辄止之后很快就放弃了？
（面试时采用）类似 IQ 之类的测验是非常愚蠢的。
那些自命不凡的人，我不会聘用他们。曾经，有一位候选人告诉我，他每周只需要工作两天，因为在这 16 个小时内他就能完成其他人 40 个小时才能完成的事情。
哦，你不用来了，谢谢。
一定要要求候选人现场编写代码，并回答有关编码的问题，这一点不容置疑。
我一般会请候选人展示一段他最引以为豪的代码，并向我们做出讲解。这样做是为了判断他的表达能力，也就是他有效沟通的能力，这是我在招聘中最看重的技能之一。
请候选人带上他们编写的源代码来参加面试。查看他们的代码，你就会知道他们是否优秀。
接着要求候选人展示一个他所编写的应用程序，评估一下这个应用程序的用户体验如何。
在面试时进行半个小时的结对编程，可以节省所有人的时间。
我总是发现，让候选人详细谈论他们做过的项目能够带来最精准的信息：
他们的沟通是否顺畅，他们在项目过程中实际扮演了什么角色，他们能够把握全局，他们是否真正理解技术细节。
如果你有些犹豫不决，那就不要聘用他。
永远不要满足于只和候选人提供的证明人想谈。如果它们是候选人的朋友，往往不会提及他的缺点，但其实每个人都有缺点。
寻找一个独立的来源 —— 你认识的和候选人共事过或者曾经管理过他的人。
每个程序员的内心动力都不一样。
迅速帮助新员工入职
入职是非常重要的。除了提供培训、确定导师等常规操作，我通常会让新员工迅速完成一些小任务以获得成就感。
如果不这么做，即使是经验丰富的人也会因为挫败感而早早陷入倦怠状态。
而如果我这么做了，新员工会感觉自信满满，并且迅速在团队其他成员那里建立起自己的影响力。
在最初的试用期要处处留心。第一天，最初的几天，第一周，第一个月……
帮他们组队，阅读他们的代码；最重要的，是尊重他们。
新员工接受录用通知之后并不意味着招聘工作已然结束。
聪明的管理者会继续跟进，精心呵护他们的新员工，直到他们入职，以避免发生新员工 “下单后悔” 的事故。
他们也会预料到新员工的前经理会尝试 “挽救” 他们，从而采取相应行动，保障新员工顺利加入团队。
成为高效的程序设计经理：向下管理
多年服务于技术组织的经验告诉我们，那些不愿意深入理解程序员的程序设计经理们，在尝试对开发团队或项目进行管理、指导或者下达命令时，通常会把事情搞得一塌糊涂。
有效管理程序员最重要，最关键的因素（没有之一），就是获取你管理的下属和同僚来自技术层面的尊重。
如果没有获得这种尊重，那么你的每一次管理行动都会遭遇直接拒绝或者消极怠工。
也正是因为这个原因，哪些不懂得程序员的经理（没有在其职业生涯的某个时期做过程序员），才会觉得有效管理程序员是极端困难的。
要想赢得技术层面的尊重，关键因素包括：
当你考虑从外部 “空降” 管理程序员设计团队的人才时，一定要确保候选人拥有一系列 “信用证明”（也就是在软件开发行业中拥有良好的、而且是被证明真实可靠的履历），如此才可确保团队对他萌生足够的尊重。
有很多种方法可以构建出令人信服的 “信用证明”，其中最简单易行的莫过于将组织内一位众望所归的杰出程序员或技术主管提拔为经理。
这么做最燃也会面临一些挑战，但是杰出的程序员本身已经受人敬仰，赢得了他的同僚或未来治下的团队成员的尊重，有助于他去培养一种基于尊重的优秀的团队文化。
锦上添花的是，杰出的程序员能够深入理解技术以及与其他经理们非常熟络，本身就是一大优势，因此他可以把这种理解传递给团队。
另一种厚植声望从而赢得技术层面尊重的方法，就是管理者本人曾经开发或管理过一些自己管理的程序员们熟悉的项目或产品。
不论通过以上何种方式厚植你的技术声望，一定要确保团队成员对此深入了解。
一定要在简历上展示出你的技术实力，并在招聘过程中确保技术人员知晓你的技术实力。
不要害羞，要想方设法的让你的成就家喻户晓，广为人知。
这些方法都是赢得来自未来下属的技术层面的尊重，而做出的霸气外露的尝试。
这些行动确实能让你平添威望。你不仅需要竭尽全力赢得这种尊重，而且还要在于下属日常交流中不断强化这种尊重。
在对前沿技术的认知和理解上比你的下属和同僚保持领先一步的优势，也是建立和维护他们对你的技术层面的尊重的一种重要方法。
身为技术团队的管理者，一定要竭尽所能成为一名能够赢得下属尊重的技术带头人，不仅要在技术上保持领先，还要展现出强有力的个人魅力，让你的下属发自内心的尊重你。
出类拔萃的技术人员总是惺惺相惜的。
如果能够延请到出类拔萃的程序员，那么其他部分的工作都会变得轻而易举。
如果请来的程序员都不如人意，那么通常你也就没有时间去处理其他的工作了，因为这些不省心的程序员总是惹出层出不穷的麻烦，让你应接不暇，分身乏术。
很多团队实质上全都是由资质平平的程序员组成的 —— 他们做事本分得体，能够胜任本质工作，但是并不出众。
无论你当前的工作重心是否是为团队增添精英成员，你都需要时刻思考如何强化团队的战斗力 —— 如何有效推动团队的持续改进工作，如何提升团队的能力。
多年的经验使我们确信每一位程序员的个性都是独特的，从管理方式上对不同类型的程序员区别对待，真正做到因人制宜，因人施 “管”，这会让你的管理工作更加成功。
管理者的一个重要工作就是引导各项目工作走向正规，这就意味着管理者需要随时随地保证团队成员之间，以及团队与团队之间沟通顺畅。
这还意味着管理者需要尽早发现前进道路上的阻碍，找到移除阻碍的办法：通常是让一个程序员开始或者结束一个任务。
引导的目的在于让事情完成，而并不在于如何完成。
有些管理者喜欢事无巨细、越俎代庖，此举偶然为之无可厚非。
但是，管理者要想最大化利用好自己的时间，发挥自己的技能，就要引导程序员自己做出正确的决定，而不应该替他做决定。
这样既可以帮助下属培养技能、积累经验、建立自信，还能获得那些具体执行决定的员工的认同。
如果你发现自己经常需要下达具体的命令，那就说明你还没能充分利用好你的管理技能，或者没能赋予下属足够的权力。
作为管理者，你必须指出大方向，然后做好充分的检查，以确保下属做出正确的决定并能实现目标。
你要及早检查下属做出的重要决定，否则在你想要插手接入或者中途修正的时候，下属很可能已经做了很多无用功。
普通的管理者能够在目标无法达到时，发现阻碍目标达成的障碍并且想方设法的消除它们。
优秀的管理者则技高一筹，他们能够提前预知障碍，并且在它们产生实质性危害，从而导致目标无法实现之前就消除它们。
杰出的管理者则在整个处理过程中，表现的举重若轻。
程序设计经理必须要学会的最重要的一课，就是如何保护好自己的团队成员，使其免受组织中每日泛滥不绝的各种问题、争议和所谓 “机会” 的干扰。
做一个抑制噪声的消声器。
只有少数重要的事项会占据优先级排列顺序的顶端，而其他的事项则不那么重要。
请对那些顶级优先级的事项多加关注。
随着时间的流逝，你必须学会分辨哪些事项才是真正重要的，这样你才能妥善处理好这些事项，而不是把精力浪费在其他细枝末节的事项上。
你还需要让你的员工知晓，为了保护好他们，使他们免于淹没在繁杂的琐碎事情之中，你都做出了怎样的努力。
你对团队的另一重保护是，要避免他们受来自组织内其他部门或个人的不当沟通方式的困扰。
你还必须要对团队提供第三重保护：保障他们免于遭受开发部门之外的同时或者部门的抨击。
管理者最重要的职责之一就是，给员工的绩效做出反馈，并且持续提升员工的绩效。
成为卓越的代名词。很多人其实并不能适应需要卓越素质的环境。
设立有一个改善个人绩效的简单易行的方法，而且几乎对每个人都奏效：与你的员工达成共识，设定一系列必须达到的目标、必须完成的任务，并且指定完成的时间；接下来定期审查这些任务的进展状况。
目标可以设立得泛泛一些，但如果想要绩效改进更为明显，那就需要将其设计得更为量化。目标的可测性越高，管理者和团队成员在评估进展状况的时候就越轻松。
确保团队理解你并不只是评估他们 “做了哪些事情”，你还要评估他们 “是如何完成的” …… 这里所说的 “如何”，包括工作透明度高、代码简洁有效、重视文档化工作以及尊重他人。
小心！把员工的绩效目标和奖金关联起来并不一定是个好主意。有关激励理论的研究表明，和通行的想法相反，在软件开发团队这样需要创造性劳动的环境里，奖金会降低员工的工作效率。
自 20 世纪 70 年代以来，涉及成人和儿童的研究都表明，条件性奖励（如果你能做到这些，就能得到某个奖励）会衰减员工工作的乐趣，因而会耗散掉员工工作的内在动力。
奖金额度越大，员工的表现就越差。不仅如此，奖金会让员工的视野变得狭窄，往往只适用于那些机械化的劳作，而对于那些启发式、复杂度高、概念性的工作是没有效果的，而且奖金导致的短视效应，反倒会拖长寻找解决方案的时间。
自我驱动的人们，通常要比那些寻求奖金的人们成就更大。
当人们只能被奖金驱动时，那就是他们最缺乏驱动力的时刻。
需要尽力限制使用条件性奖励的次数，更多的使用意料之外的奖励。
管理者需要尽力帮助团队，让他们找到适合自己的自我驱动力。
为员工设立清晰的绩效目标，可以催生明确的绩效评估方法，当你向领导汇报或者与公司其他人员沟通时，你就可以更加清晰、有条理。
几乎每一位程序员都渴望看到管理者对他们绩效的反馈。
管理者对他们的表现进行反馈的最简单易行的办法，莫过于每天在办公室里走上一圈，或每周与下属来一次面对面的交流，让团队成员知道你在对他们最近完成的工作的看法。
对下属的绩效定期进行评估并反馈给下属，这是程序设计经理仅次于招聘到合适的人选的重要职责。
我的工作不是对人们宽容，而是要让他们变得更为优秀。
管理者必须要对组织和所有下属负责，不能无原则的迁就那些在重要工作中表现得很差的个人，否则就是姑息养奸。
没有什么方式能够替代面对面的沟通，当项目处于关键时间节点上时尤为如此。
团队成员之间相隔越远，沟通方式就应该更为正式、更为明确。
大型团队（29 人）产生的代码缺陷大约是小型团队（3 个人）的 6 倍，这显然会浪费大量成本。
同时，为了达成同样效果的交付成果，大型团队大约平均只比小型团队少用了 12 天时间。
小型团队比大型团队更高效 …… 完成同样大小的项目，5~7 人的团队所花费的时间最短。
没有杰出的团队，就做不出杰出的软件，而大多数开发团队都像一个支离破碎的家庭。
成为高效的程序设计经理：向上管理、对外管理以及自我管理
成功并不只在于你做了什么，更需考虑别人会如何看待你所取得的成果：现实中，外在认知往往比实际的行动更为重要。
向上管理始于了解你的领导，了解他们是哪种类型的人：技术型、销售或市场型、财务型，抑或是其他类型？
是关注大局型还是注重细节型？什么样的问题最令他们敏感？
如何向上管理取决于你能否正确了解你的领导，以及其他你可能间接或隐式汇报的高层管理者。
你的领导级别越高，你的报告就要越发精简，更加注重大局 —— 更少细节，更大格局；更少文字，更多项目符号。
更为关键的是，你需要清醒审慎的评估如何高效的与你的领导进行沟通。
你应当（而且必须）一直采用迭代方式不断优化沟通效果，不断调整沟通的信息量。
有的事情需要长篇大论才能有效澄清，而又的事情浓缩为寥寥数语才是上上之选。
你不必喜欢或者崇拜你的领导，也不必憎恨他。
但你必须管理他，让他成为你事业进步、职业发展与个人成功的助力源泉。
透彻了解你领导的个性特征，可以帮助你决定如何采取某些行动。
没有什么能比定期汇报，更能够赢得领导对你的信心了。
请注意，其他人可能会查看你沟通的信息，所以你要始终如一的保证汇报的专业度，避免汇报内容有任何负面的评论。
因为负面评论总会通过某种方式，传到你并不希望听到它的人耳中。
有时候，口头沟通比书面报告效果更好。
沟通的另一个重要方面是精心设计和完美展示 PPT 文档。
请一定要设法掌握设计精美 PPT 文档的艺术。
高效的程序设计经理必须能够进行高效的沟通，在如今这个时代，能够做出精彩纷呈的 PPT 文档是一项宝贵的技能。
你一定要沉下心来仔细构思，精心设计出令人过目不忘的 PPT 文档。
用来准备 PPT 的时间，应当与观看它的观众（直接观看或者间接观看）的职位高低成正比。
要想获得成功，不能只做好自己的本职工作，还要帮助你的领导获得成功。
人类的本性要求我们要回报那些帮助我们完成任务的人，所以，你应该了解如何才能帮助你的领导获得成功。
为此，你需要了解你领导的领导是如何评判你的领导的。
如此，你才能知晓你需要做些什么才能帮助你的领导获得成功。
你要找到那些对他至关重要的事情，然后你就可以主动尝试选择其中的一至数件来尽情施展自己的才华。
问问你的领导，你怎样做才能给予他帮助，或者自己先采取一些试探性的行动，观察一下领导的反应，如果能够获得领导的鼓励，那就继续行动以扩大战果。
通常，在你采取主动的行动之后，总能得到一些反馈 —— 领导会指导你如何做好下一步工作。
注意，在没有得到这种鼓励之前，不要表现得过于鲁莽，否则你的行为会招致领导的反感，并在未来受到某种程度的回击 —— 让领导误以为你在谋求提升或是谋求将他取而代之，这肯定是你最不愿留给领导的印象。
领导什么时候想要听你的汇报？在每周例会之前为他提供及时有效的信息是至关重要的，而会议结束一天之后，才提供的信息可能就是 “明日黄花” 了。
同样，在预算周期切换之前提供及时的反馈，可以让你的领导（以及你自己）来来年（或下一个预算周期）更轻松自如一些。
审慎思考时机问题，恰当的时机几乎和好运气一样重要。
请记住，电影工作室之所以一定要挑选特定的时间发布新电影，原因一定是非常合理的：一部电影发布的时机，甚至决定了它能否获得奥斯卡金像奖。
同样，请仔细考量沟通时间，以及何时才是交付成果、完成原型或者做好演示的最佳时机。
你要明确公司召开重要会议的时间点，以及公司做出重要决策的时间点。
下面是几条成为模范员工的秘诀，至少在你的直属领导眼里，这些秘诀应该很有效。
第一，要维持 “免维护” 状态，也就是说，不要把每一个问题都带到你的领导那里寻求解决方案。你要仔细甄别你的问题，只把那些真正重要的问题拿去寻求领导的帮助。当然，尽可能自己解决问题永远都是上善之选。另外，你还要摒弃只给领导带去问题的做法，向他提交问题的同时，你最好配附几套备选的解决方案。即使你没有特别妥帖的解决方案（或者没有找到最好的），也会让领导觉得你已经做好了自己的功课，找他只是为了寻求他的建议和忠告，而不是直接把问题抛给他。
第二，要勇于承担责任，不要把责任推给别人，特别是你的团队成员。
第三，毛遂自荐，主动施以援手。有些时候，你的领导会被各种各样的棘手问题困扰，这时候如果你有能力，不妨主动提出 “我帮你对付那一个（或者那几个）问题吧”。
第四，要学会给人带来惊喜与欢乐。你可以了解哪些事情与你的领导利害相关，并找到办法超水平的解决这些问题、完成这些任务，甚至超过领导的预期，令他对你刮目相看。有时候做到这一点其实并不需要付出太多。
你可以卓有成效的管理好你的团队，成功的交付项目，但如果没有领导为你保驾护航，你的职业前途必定坎坷。
也许看起来并不那么显而易见，然而你的薪水、奖金、期权、津贴的多寡，乃至于晋升机会的大小，其实都是由一系列管理层闭门会议决定的，有时甚至就是你的领导自己决定的。
所以你一定要主动做好向上管理，这样你才可能得到更多的职业回报。
当你努力做好向上管理时，其实就是以 “润物细无声” 的方式努力巩固与高层领导的关系。
其中的某位领导可能会成为你的好友，并在你今后的职业生涯中一直陪伴你、支持你。
融洽的部门内合作氛围，能够让你领导的工作更为轻松，因为你能自行解决很多部门内部事务，而不必惊动你的领导。
和谐的部门内部合作，还能够消弭很多问题和争论，加速项目的进度，团队也不必经受锱铢必较、互相攻讦之苦。
融洽的部门内部合作还能将你和你的同级同事紧密联系在一起，你们之间可以坦诚探讨问题、分享解决方案、相互安慰、相互鼓励。
融洽的合作氛围可以表现为团队成员互相帮助，不遗余力的对同伴遭受的问题提供支持、共享资源和培训、守望相助。
团队成员都视彼此为最亲密的伙伴、最可靠的帮手，他们愿意帮助对方获得成功。
当你被延请或提拔成为程序设计经理时，请仔细研究公司的组织结构图，找到各个职能部门的主管，想办法让自己逐一了解他们以及了解其他各部门中与你同级的经理。
请他们吃午饭，或者偶尔停下来与他们聊聊天。提前维系好跨部门的纽带关系是很有必要的，当你需要向他们发出求助时，你会更加容易获得他们的积极响应。
尽力知晓公司里每个人的名字，在小规模的组织中做到这一点很容易，但随着公司规模的扩大，在超过 100 人的公司里想要做到这一点就是一项挑战了。
总有一个时刻你会无法跟上公司规模扩大的速度，但还是要努力认识更多的人，争取比其他任何人都认识得多。
要想卓有成效的管理自己，首先就要实事求是的评估自己的行为习惯和行事风格，然后找出那些你想要改进的方面，最后切实履行你的改善计划。
你需要真实客观的评价自己的如下几个方面：
如果你看起来邋遢懒散，那么你就必须刻意采取更多措施，去克服你的领导以及其他高层管理者与你互动时产生的负面看法。
要以身作则，成为团队表率。永远不要要求团队去做连你自己都不愿意做的事。
找机会了解你的员工，记住他们初入公司的日期；了解他们来自哪里，何时回乡探望家人；探知他们配偶或者伴侣的名字，他们有几个孩子；知道他们开什么样的车，他们想要哪种车；
了解他们想去度假的地方，有什么爱好……
这些事情是你应该弄清楚的，能够帮助你更透彻的了解你的员工。你对他们了解得越透彻，他们对你也就会越坦诚，越愿意对你敞开心扉谈论任何事情。
重要的是，你要有意识的去思考自己的管理风格是什么，你想要培养出怎样的管理风格。
想做到这一点，当然需要锲而不舍、水滴石穿，但是做到之后，它对于帮助你成为成功的程序设计经理是至关重要的。
你最重要的资产就是时间。
你要珍惜时间，同时，要慷慨给予那些真正需要关注的人或时时间。找对方法来管理好时间，你的生活才会过得舒心惬意。
你要坚持按时参加会议、出席约会；确保准时结束会议；不向任何拖沓冗长的会议风格妥协。
每多用一个小时来制订计划，就能少浪费一天的时间和精力。
设置待办事项优先级的关键是
优先处理既紧急又重要的事项是关键：我们常常把紧急的事项看作是重要的，反而耽误了解决重要的事项。
大多数成功人士都坚持列出待办事项列表。这件事应该成为你生活中不可分割的一部分。
你会发现，每天管理你的待办事项列表，能够让你活力满满、成就感满满。
要想成为一名高效的管理者，你必须创建有效的机制来合理管控如洪水般涌来的各种信息，不能让它反噬你。
想要成为一名高效的管理者，你必须首先成为一个高效的沟通者。高效的沟通者往往都是优秀的倾听者。
人们一般都想要被人倾听，你的员工也是如此。
如果你不听他们在说什么，那么毫无疑问，他们不会开心。
智慧就是你此生从聆听而非说话中所得到的奖赏。
令人惊奇的是，很少有人真正遵循这个简单的实践。放下你的手机或平板电脑，停止处理电子邮件，坐下来凝视说话的人。
用眼神交流，仔细聆听对方在说什么（并思考他们呈现的信息）。
注意，信息并不局限于他们的话语，还包括他们的姿势、身体语言、情感或专注的程度。
留意上述一切信息，语言之外的这些线索往往最能说明问题。
沟通中最大的问题，就是误以为自己已经在沟通。
在倾听完对方所说的内容之后，重述或者重释你听到的内容，以确定你的理解正确。
「外向型程序员和内向型程序员有什么区别？当你和外向型程序员谈话时，他会盯着你的鞋子，而内向型程序员只会盯着自己的鞋子。」
许多人认为管理是自上而下的，管理者具有权威的地位，也就是说，他们处在金字塔的顶端，成为 “一山之王”。
与此相反，我们建议你把自己看做金字塔的底部，而你的员工在顶端。
你的员工和他们做的工作，才是真正重要的。
欲先民，必以身后之。
想要领导民众前进，必须要把民众的利益摆在自己的前面。
看似他们为你工作，实则你为他们工作。
你要确保自己总是在做真正重要的、长远来看会产生重大影响的事情，而不仅仅局限于短期的事情。
今时今地你要做的事情越来越多，你必须要遴选和着力解决重要的事情。
你要有意识的选择重要的事情，并把不重要的事情放到一边。
你应当把招聘这样的事项设置为首要任务，并且每天都要花一些时间在这上面。
没有记录的会议，就是一个从没有召开过的会议。
人们往往也是在做完了所有的管理工作之后，才会把注意力转向自己的职业发展和个人自律。
花些时间和精力实施有效的自我管理，可以让你从日常工作中获得巨大的汇报。
花些时间去做好自我管理吧；每周推拒一次约会，留出一小时给自己，后者可以与导师一起，积极致力于改善自己的风格，改善自己的时间管理、优先级管理和沟通方式，养成时刻跟进的习惯。
这可能是你在一周中花费的最为划算的一小时。
经验法则与至理名言
“往返 3 次法则”：在一次讨论当中，双方交换意见/见解的次数被限定在 3 次。使用 “往返 3 次法则” 可以避免没完没了的争论。
有这样的一个现象，它对所有团队管理者而言可谓是家喻户晓，那就是两位技术专家总会陷入唇枪舌战的争论之中，而且没完没了。
如下做法有效的阻止了这类现象的蔓延 —— 仔细观察只有两人参与的讨论，当他们每个人都讲过 3 次之后就终止他们的对话，让第三个人接着讲。
如果你是一名担负有管理员工责任的经理，那么你的员工比你手头正在做的任何事情都重要得多。
如果一名团队成员在你不太方便的时间来找你谈话，那请先把手头的工作放下，专心跟他交流，因为他可能想要鼓足勇气告诉你一件大事。
我发现，如果这位 “不速之客” 平常不善言辞，那他尤其可能会有大事向你汇报。
如果你的团队成员知道自己来访的时候能得到你最高优先级待遇，那么当遇到很棘手、很麻烦的事情时，他们都来找你倾诉的可能性就更大了。
够用就行。完美是优秀的敌人。
程序员往往容易走向两种极端：要么很快 “完成” 任务，然后把包袱甩给其他人；要么不停的完善、完善、再完善，但总是做不完。
如果管理者总是通过主导谈话内容来达成共识，那么他最终得到的不是一个团队，而只是一群受胁迫的人。
大多数团队都不是真正的团队，而仅仅是每个人与领导的个人关系的集合。每个人都在与其他人争夺权力、荣誉和地位。
行为总是围绕着度量指标转。
受到表彰的消防员会随身带着火柴。
要想控制疾病不扩散，就不要表彰携带病毒的人。我们应该找到那些能够未雨绸缪、预防风险、执行力突出，能够冷静有效的从挫折中恢复而不张扬、不炫耀的人。
人们常常觉得自己的工作充满挑战和艰辛，但却不能理解其他团队为什么不能完成他们自己的任务，因为别人的任务看起来总是比自己的任务简单得多。
我的职责是竭尽所能为员工支付更高的工资，而不是搜肠刮肚去琢磨怎样才能少付工资。
薪酬是一个复杂的函数，它不仅仅由工资组成，还包括一些重要的内容，如工作内容、工作伙伴、是否会用到一些新技术、是否有助于改变世界等。
薪酬 = i×工资 + j×股票期权 + k×福利 + l×与谁共事 + m×工作地点 + n×做什么 + ……
每一个变量（即工资、股票期权、福利 等）前面都有一个与其关联的系数，系数的取值影响着计算的结果。
每个人都应该考虑对自己来说哪些因素比较重要、有多重要，然后在 0 和 1 之间为系数取值。
制定下属的工资表时，要假想它是可以贴到办公室门外来公示的。
一流的招聘人员少之又少，所以要视你的招聘团队为无价之宝。
如果你现有的员工都很快乐，他们一定会推荐杰出的人才给你。所以，请营造一个让员工感到满意舒心的工作环境 —— 包括专门为程序员设计的办公室，优秀的领导力，以及其他一些额外的福利待遇。
招聘两个 “还不错” 的员工，效果远远不如招聘一个杰出的员工。
一流人才招聘一流人才，二流人才招聘三流人才。
我经常寻找那些会自动、自发完成大量除本职工作以外的工作的人。上学时，他们并不只是做老师要求的项目；工作后，他们不仅完成雇主要求他们做好的事情。他们对某种东西充满激情，利用业余时间完成一些兼职项目。
请允许我来抛砖引玉：不要面试那些做不到善始善终的人，永远不要。
证书和学位算不上是成就，完成一项拥有真实用户的真正项目才算。
招聘那种纯粹为了好玩，而用自己的时间开发东西的人。
招聘多名谦逊踏实、能融入团队、寻求稳定职业发展的开发人员，远远好过招聘一名在面试中表现得野心勃勃，又有浓重防备心理的所谓 “明星” 开发人员。
下面这个面试问题很重要，尽管它与技术没有直接关系，但它适用于每位候选人：工作之余你会做哪些好玩的事情？
在面试中要向每一位候选人提这个问题，他认为这样有助于发掘蕴含在候选人内心的各式各样的激情。
当他发现程序员对生活的某些方面充满激情时，他的习惯是将他们的激情转移到对产品的精益求精和对程序的精雕细琢上。
他渴望自己的团队对工作充满激情。
让应聘者告诉你，你的公司可以在哪些方面做得比现在更好。
优秀的主管要拥有足够的判断力，会挑选出能达成自己目标的优秀人选；要拥有足够的自制力，在下属沉浸在工作当中时不会瞎指挥。
只要可能，就要在聘用合同里面加上 3 个月的 “试用期”。这样你就不会被迫接受不合适的人了。
在最初的试用期要处处留心。第一天，最初的几天，第一周，第一个月 …… 帮他们组队，阅读他们的代码；最重要的，是尊重他们。
应对复杂问题最重要的因素，并非程序员所使用的工具和技术，而是程序员自身的职业素养。
问题的复杂度每增加 10%，软件解决方案的复杂度就会相应的增加 100%。这不是一个可以通过努力改变的条件（尽管想方设法降低复杂度总是我们期待的），而是一个基本事实。
距离越远，沟通就应越正式。
团队成员之间的相隔越远，沟通就应越正式、越直截了当。
在电话会议开始时先随便聊聊本地新闻，这是个好习惯。带有地方特色的信息（政治、体育、天气）可以让电话两端的人都觉得自己的生活范围更为宽广。
永远不要低估近距离沟通的价值。
没有什么方式能够替代面对面的沟通，当项目处于关键时间节点上时尤为如此。
Scrum 开发模式实际上可以帮助地理上分散的团队，取得与集中办公团队相近的绩效。
全球化开发的最佳实践 —— 我们发现了许多能够有效改善沟通的实践，其中包括：
信任，但不放弃验证工作。
造成延迟和混乱的最主要的原因之一，就是允许一个主管直接管理过多的下属。
Graicunas 建议一个管理者最多管理 5 名直接下属，最好是 4 名。
一对一沟通：这是最有效的管理工具，没有之一。
管理者的任务是充分发挥员工的长处，同时限制员工的缺点，使其不至于影响工作。这也完全适用于管理者的上级和下级。
团队要用到的工具，团队自己去选择。
人类都热衷于提升事务的复杂度，程序员尤其如此。
每个人都可以被传授雕刻技艺：但对米开朗基罗来说，能教给他的是怎样能够不去雕刻。杰出的程序员也是如此。
程序员宁愿站在别人的脚趾上，也不愿站在别人的肩膀上。
我们有两只耳朵、一张嘴，请按这个比例来使用它们。
保持简单 —— 不要把事情过度复杂化。
认真倾听，多提问题。
对自己从事的工作保持一份自豪感。
客观看待一切事物。
反复进行沟通 —— 组织中出现的最大问题之一就是缺少沟通。
学会合作。
学会有效辩论、理性沟通 —— 不论输赢，找出正确途径才是正解。
如果放任不管，员工很快就会偏离项目目标。好的项目领导几乎每天都和员工交谈：“你做了什么？为什么？有效吗？”
你愿意为此而赌上自己的职业前途吗？
这是 Claudia Brenner 在 IBM 时学会提出的一个关键问题。她说，“通过这个问题，你能判断出程序员是否真正相信，他刚与你说过的话”。
你可以不遵循标准，但必须知道为什么要有标准，而且能明确说明标准。
判断你的设计是否已臻完美的标准，不是不能再增加任何东西，而是不能再删减任何东西。
设计第一，编码第二。
编写代码的时候不能 “各人自扫门前雪”。
小心 “闭门造车” 型的软件开发人员。
Conway 定律：如果你让 4 个小组去做同一个编译器，你会得到一个 4 通道的编译器。
Lunde 定律：无论何时，如果你用新团队去替换项目中的资深开发人员，新团队最终都会找到一个令人信服的理由去重写全部代码。注意，新团队的这一做法是错误的。
软件就是创造它的团队的真实写照。无论你想了解一个团队的哪类信息，都可以通过研究他们开发的软件来获得。
我强调这个思想，是因为我觉得这是软件开发管理的基础。团队的语言和行为总是难以捉摸，但软件不会说谎。
软件必然会展现出团队的一切弱点和实力、每个人的天分和缺陷、团队成员的毛病和灵光乍现的智慧。
有疑问，看软件。要达到这个境界，你必须善于翻译，善于理解软件中的种种迹象是怎么产生的。
如果团队和团队开发的软件给你的信息是一致的，那么你在开展下一步工作时就会比较有信心了。
既要聪明的工作，也要勤奋的工作。
我认为在代码走查上花上一个小时的时间，抵得上两周的测试。代码走查是一种真正有效的消除错误的方法 …… 现在我觉得，代码阅读应该贯穿项目的整个生命周期，一旦你沉浸在代码阅读的环境里，你会感觉非常自在。
我使用员工做出的贡献，与他造成的损失之间的差值，作为绩效考核的指标。
如果你能在中午之前给我一份状态报告，那我就取消状态会议。
这是一个能够及时收到状态报告的聪明办法。
没有会议纪要的会议，就是一个从没有召开过的会议。
在项目状态会议上每多花一个工时，真正用于工作的时间就会损失 3 个工时。
所有被测量的东西，都会被暗中操纵。
使用代码行数来测量软件生产力，就好比使用重量来衡量研发飞机的进展状况。
我们的产出价值，应该使用 “代码总量” 乘以 “代码运行的频率” 来衡量。
不要写没人打算运行的代码。
大多数软件工具对效率和质量的提高幅度仅为 5% ~ 35%，但总有人反复说提高幅度是 “数量级”（10 倍以上）的；浮夸是软件公司的通病。
最初学习新的工具或技术的时候，实际上程序员的生产力和交付产品的质量都会降低。只有克服了学习曲线之后，你才能获得预期的收益。
这正是白板几乎成为软件开发团队办公地点的标志性物品的原因之一：白板提供了一块画布，可以演示复杂程序的抽象过程，还允许人们在讨论时指着它讲述。
如果我能够有机会再教育我的孩子一次，我一定会做出一个改变：在餐厅的墙上挂一块白板，与孩子分享可视化的想法，而不是单纯的进行交谈。
一支践行 “集体负责制” 的团队能写出更为整洁的代码（Bug 更少）。
即使 100% 的测试覆盖是可以实现的，但对于测试来说仍然不够。大约 35% 的软件缺陷来自逻辑路径的遗漏，另有 40% 来自特定组合的逻辑路径的执行。它们都不能通过 100% 的测试覆盖发现。（也就是说，100% 的测试覆盖也许只能检测出 25% 的错误！）
得到优秀的运动员容易，让他们配合起来难。
大多数人都真的希望能把工作做好。如果他们做得不好，通常是管理方面出了问题。
每个程序员的内心动力都不一样。了解每个程序员的动机是高效管理的关键。
与我们通常所相信的观点相反 …… 最美好的时刻并非那些被动的、接受性的、放松的时刻 —— 尽管它们是我们通过努力获得的，我们很享受。
最美好的时刻通常发生在一个人为了解决一些难题，为了完成有价值的任务的过程中，身体或精神达到极限的时刻。
我们通常也把这种 “心流” 状态称为 “专心致志” —— 完全沉浸在当前的挑战之中的一种状态，时间不知不觉的流逝掉了。
提拔通常不是对过去表现的奖赏。管理层提拔的都是那些有潜力解决更大、更难问题的人。
我的任务不是激励球员，相反是他们为我们的球队带来了非凡的动力。我的任务是不使他们丧失动力。
如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们对广阔无垠的大海满怀憧憬。
你喜欢并尊重为你工作的人。你关心他们。他们的问题就是你的问题，他们的忧虑就是你的忧虑。
你的心胸像火车一样宽广，大家对此有目共睹。你能在一个人做出可信的东西之前就表现出对他的信任。
你使他们都觉得，你已经把他们当成家人了。这就是他们跟着你的原因。
Novell 刚刚新增了一个头衔：杰出工程师。杰出工程师必须由同事推选产生，其选拔标准要比管理层来选拔的标准严苛得多。
这一标准还能够鼓励大家争当技术团队中的优秀成员，有助于强化每个人的良好行为。
如果你不希望 “技术极客” 流失，那就要想办法提拔他们，但不要让他们当管理者。
他们多数都不太合适从事管理工作 —— 事实上，他们中的大多数可能会变成可怕的管理者。
但你需要给他们提供向上发展的途径，需要给予他们认可，需要给他们发更多的工资。
让员工参与目标设定。
没有哪个杰出的程序员会坐在那里说 “我打算赚一大笔钱” 或者 “我打算卖出 10 万份副本”，因为这样的想法不会促进问题的解决。
对编程人员来说，最糟糕的事情莫过于看不到自己的工作成果交付。
员工离开的不是公司，而是他们的经理。
谨记：当项目团队进行最后冲刺时，团队成员的配偶和家庭也能感受到他们所承受的压力。体贴的项目经历会主动去了解员工的配偶是否需要出租车服务来接送孩子，或者公司中是否有人可以在回家的路上给困在家中照顾患病孩子的员工配偶捎一些东西。
不管团队成员是否有加班费，最大错误都是不对加班进行记录。不能因为团队成员没有加班费就认为那是 “免费的”。对于财务部门来说这种认识可能没有问题，但从项目经理的角度来说，加班不是免费的。
项目经理必须当心的一种危险情况是，狂热而又年轻的软件工程师过多的自愿加班。
管理团队、顺利交付
你们不是来编写代码的；你们是来输出产品的。
侯世达（Hofstadter）定律：做事所花费的时间总是比你预期的要长，就算你已经充分考虑到了侯世达定律的影响。
在保障 “项目进度” 的重压之下，程序员们需要长时间持续工作，除非被其他事情打断。叫外卖能让程序设计团队持续工作。
如果让他们外出就餐，他们持续工作的意志就会减弱，加班的意愿也会降低许多。
做项目就应该像跑马拉松一样。你必须设定好一个恰当的节奏，然后才有希望在接近终点线处发起冲刺，从而一举赢得比赛。
程序员总是能够找到借口说他们实在 “磨刀不误砍柴工”，而且还会千方百计的证明 “这确实是必要的”。有时候情况的确如此，但有时候得需要经理来决定什么情况下这种 “磨刀” 的功夫已经脱离了项目的初始目标，然后让程序员从他们开心的 “工具保养” 工作中回归到真正的首要任务上。
我的经验法则以问题的形式呈现。
这两条经验法则看起来理所应当，具体做事时也确实应该如此，然而它们呢总是被遗忘。
有一半的项目并非在执行项目的过程中就出了问题，它们一开始就错了。因此，一定要保证项目开始的 6 个星期执行正确。
一旦错过市场窗口，商业价值就会变成零。
当你制订战术层面的解决方案时，需要确保在战略层面上已经有了妥善的计划。
危机能使人们团结一致，要善加利用。
要想制订出完美的项目计划，首先要列出所有的未知问题。
每项任务都必须指定唯一一位负责人，如果指定了两位负责人，那这事就没有人负责了。
项目经理的职责是确保每项任务制定 唯一负责人 —— 识别每项任务，确保为每项任务指定一位负责人，推进任务执行，而不是亲自去完成任务。
项目经历还要同唯一负责人一起定期回顾和检查以下 3 个问题：你是否清楚项目的整体目标？你是否清楚你的任务对实现整体目标将会做出怎样的贡献？对于你所负责的那部分工作，有哪些东西会妨碍你达成目标？
病态组织的一个症状是，精简项目人员反而会增大风险。
Rosenberg 定律：软件并不难写，除非你需要用它完成新的工作。
推论：唯一值得编写的软件就是能完成新的工作的软件。
要从小型项目做起，把细节考虑周全，不要盲目憧憬过于华丽、过于缥缈的设计。
如果项目不能解决一些当前急迫的需求，那么它十有八九就是被过度设计了。
其实，使用何种软件开发方法无关紧要；真正重要的是，你必须始终如一的对项目的需求保持清醒的认识。
离开了需求或设计，程序设计就成了一门在空白文本中塞 bug 的艺术。
（对于软件需求而言）我们总是习惯性的以为人们知道自己想要什么，然而实际上，我们的经验更多的倾向于 “人们并不清楚自己想要什么，但在看到实物的时候他们能分辨出不想要什么”。
迭代的过程至关重要：客户是不知道他们想要什么的，直到他们看到实物。
规格说明书中模棱两可的表述，乃是系统的干系人之间悬而未决的冲突的体现。
相比于缺少某些功能特性，糟糕的质量更容易引起客户的不满。
客户可以炒掉公司里的任何一个人，上自董事长下到员工 —— 他们只需把钱付给其他公司即可。
软件很像香肠：享用最终产品时，人们真心不想知道其中都加入了什么。
在实践中，Frederick Brooks 发现，几乎所有的项目都只有 1/6 的时间花在编码上，而有整整一半的时间用在测试和修正缺陷上。
始终雇佣那些比你更聪明的人，但永远不要传递那些你都不理解的东西。
如果它（软件系统）在我的机器上无法工作，那它到哪儿也工作不了。
成功的自动化测试工作的成本都很高。
若不实施自动化测试，成本还要再多上 10 倍。
如果你不容许过程中出现任何错误，那么结果一定会失败。
出色的过程管理是我们的战略。我们通过让普通人管理出色的过程，来获得精彩绝伦的结果。
同时我们也看到，竞争对手们常常使用杰出人才来管理蹩脚的过程，最终成果差强人意（或一塌糊涂）。
我们的工作内容中并不存在 “快速修正错误” 这么一回事。根本不存在可以在短期内改善产品的办法 …… 你唯一能改变的就是有效工作的时间比例 …… 所以你需要在避免浪费时间这一点上全身心投入。
迷恋上原型是危险的，原型只可以达到产品可用程度的 10%。
前 90% 的代码会花费在前 90% 的项目开发时间，剩下 10% 的代码还要再花费 90% 的项目开发时间。
永远不要用一个糟糕的时间点，去交换另一个同样糟糕的时间点。
要给 “完成” 下一个确切的定义。若你的团队并没有对 “完成” 的定义达成共识，自然就很难为工作的圆满完成而感到欢欣鼓舞。
当任务因顺序上的限制不可再分时，添加人手对加快进度毫无帮助。
这就好比无论指派多少个妇女，孕育一个生命都需要 9 个月。许多软件任务都具备这样的特征，这是由调试工作的时序性本质引起的。
好的组织要学会将 “估算” 和 “承诺” 二者区分开来。
如果你是 Scrum Master，如果此时所有人都盯着你看，这就意味着你的做法有问题。
因为 Scrum 团队成员应当彼此互相关注。
当团队没能在估算的时间段内完成事先估计好的任务时，应当削减下一个时间段的时长。
节奏均匀能使团队受益。
为何压力仅仅能使程序员至多提升 6% 的生产率？
我的回答是：压力并不能促使人们的思维变得更敏捷。
组建团队就好似烤蛋糕：调料搭配不当，口味肯定不佳；一旦调料搭配得当，就会十分香甜。
（管理者）应当表现的想一名星探。
应当把有凝聚力（时刻准备迎接新挑战）的团队视为项目交付内容的一部分。
你在项目开始的头一个星期之内所要求的代码质量，将会决定之后每周你所得到的代码质量。
新系统的设计者不仅要做系统的实现者，和第一个大规模使用者，还应当编写首份用户手册。
如果我没有全身心的投入这些活动，我就无法实现数以百计的改进，因为没有亲自参与，就想不到要做哪些改进，或是无法意识到这些改进的重要性。
“学习编程” 与 “设计交互式软件” 之间的关系，就像 “学习打字指法” 与 “写诗” 之间一样，彼此关联甚少。
好的设计能让价值增长速度胜过成本消耗速度。
激励程序员
如果你善于激励，那么即使对本书其他部分涉及的能力大多感到心有余而力不足，你依然可能成为杰出的软件经理。
反过来，如果你不善于激励程序员，那你就很难成为成功的软件经理。
马斯洛认为，人的需求可以划分为若干层次，从低层次的需求（生理需求）直到最高层次的需求（自我实现）。
他还坚信，在低层次需求尚未满足之前，更高层次的激励没有多少用武之地。
马斯洛围绕需求层次理论所提出的观点，今天依然在促使我们不断改善工作环境，鼓励员工充分发展，自我实现。
你可能花了几个月甚至几年的时间哄着团队走向自我实现，但当每个人都在担心自己和家人的基本食物和住房需求得不到保障时，团队瞬间就崩溃了。
你必须再次从最基本的层次开始，培养最基本的团队合作氛围。
麦格雷戈的 X-Y 理论：
赫茨伯格的激励因素和保健因素理论：对工作的满意与不满意情绪，几乎总是源自不同的因素，而非之前人们一直认为的是对相同因素的不同反应。
一组因素（激励因素）能真正的起到激励作用，而另一组因素（保健因素）则会导致不满意。
人们会努力争取实现 “保健” 需求，如果没有争取到那就会导致不满，而一旦需求得到满足，其作用又很有限，难以持久。
管理不善的组织不知道，人们不是通过解决保健需求来得到激励的。只有当激励因素得到实现和满足时，人们才能得到真正的激励。
保健因素是承载基础的 “木桩”，一旦受到破坏或侵蚀，基础就会不牢，但是保健因素本身无法实现激励。
赫茨伯格的激励因素与保健因素理论，帮助我们更好的理解了员工的动机。
适用于程序员的激励因素：
缺乏会导致不满的因素依次是：
在我所有参与过管理的团队当中，我是第一个认识到导致不满的因素和产生激励的因素并不相同的人。
此时，我突然感悟到：首先要确保员工对一组基础性因素感到满意，然后才能进一步利用另一组不同的因素进行激励。
条件性奖励在多数情况下，反而会导致项目的进度比没有奖励承诺时拖得还要长。
研究表明，奖励会导致员工的关注范围变窄，对于计件工作来说这一点恰好有利于激励，但对于创造性工作来说会适得其反。
另外，激励容易使人上瘾，并容易会催生消极短视的想法。
当人们只能用奖金进行激励的时候，恰恰也是他们最消极的时候。
他并非建议降薪，恰恰相反，他说：公平合理的薪酬至关重要，原因之一是它能使员工无须担心钱的问题，这样他们才能心无旁骛的工作。
他也并不反对非条件性奖励，只要这些奖励不完全在员工的预料之中，不足以使之成为预期即可。
根据我们的经验，项目完成后，对表现出色的员工给予让他们意外的奖励，有助于激励他们加倍努力、精益求精。
内在激励驱动的人所取得的成就，通常要比追求奖励的人所取得的成就更多。
如果你是一名担负有管理员工责任的经理，那么你的员工比你手头正在做的任何事情都重要得多。
作为管理者，你的工作是绝不忽视你的人，始终坚持以人为本。
如果你期待员工努力工作，那么一个很重要的做法是允许他们在办公场所玩耍。
如果你认为玩是 “不专业” 的表现，那么有必要请你重新考虑。
在办公室外玩耍应该成为一种你常用的激励措施，这类活动会产生一些积极的影响。
管理者的级别越高，办公桌上的玩具就应该更多、更优质。
在我的团队中，每个人都在学习。我对待团队中的每个人都向对待成年人一样。程序员们真心乐意为我工作。
如果你现有的员工都很快乐，他们一定会推荐杰出的人才给你。
所以，请营造一个让员工感到满意舒心的工作环境 —— 包括专门为程序员设计的办公室，优秀的领导力，以及其他一些额外的福利待遇。
“管理” 是让人们做需要做的事，而 “领导” 是让人们想做需要做的事。
永远不要怀疑少数乐于思考、甘于献身的公民可以改变世界。事实就是如此。
如果你不对自己做出改变，那么你将混迹在人群中 “泯然众人”。
如果有什么事儿没做好，那是我的责任。如果有什么事儿做得办好不坏，那是我们共同的责任。如果有什么事儿做得非常好，那是你们的功劳。
这就是让球队赢得橄榄球比赛冠军的关键。
大声赞许；轻声责备。
庆祝你的成功，在失败中寻找幽默。别太把自己当回事儿。你放松，你周围的人才能放松。享受乐趣，并始终保持激情。
建立成功的程序设计文化
卓越的程序设计经理这一角色中的关键要素是创建和培育一种成功的程序设计文化。
对我们中的大多数人来说，这种文化应当支持和鼓励按时按预算交付高质量的软件，应当让团队中的开发人员对成为团队的忠诚成员而感到骄傲和自豪。
你要想方设法打造团队内外追求卓越的期望，逐步建立你和团队能够成功交付软件的信心。
成功的程序设计文化能够以任何针对个人的激励方式都无法望其项背的方式，去驱动团队高效的工作。
建立强有力的程序设计文化，需要创建：
在软件公司，为了建立你所需要的程序设计文化，有必要先理解你所在公司的文化。
想要理解公司文化，那就要听听 CEO 的说法。
在程序设计团队中，驱动决策的力量，最终来源于两个因素的平衡：一是关注创新，二是关注对客户和市场的响应。
赞美你想要看到的更多的事物。
汽车之所以有刹车，是为了跑得更快，而不是为了跑得更慢。
标准和规范还可以应用于：需求、编码、代码质量、文档自动生成、开发流程、编译流程、测试用例跟踪、可追溯性、代码提交、源码控制、开源代码的使用、知识产权。
几乎每个程序设计组织都需要一种关注 “交付” 的文化。无论是软件上市还是服务上线，按时交付的要求都需要得到广泛重视。
不要告诉别人 “如何” 做事。告诉他们做 “什么” 事，他们会以自己的创造力还你一个惊喜。
我只检查自己所要求的东西。
信任但要核实。
依照其本来面目看待一个人，他只会变得更糟。但是，依照其潜在可能去看待他，他会变得更好。
你应当不惜一切代价去避免针对个人英雄主义的过度奖励。
软件开发团队应当是一个学习型组织。
不要奢望程序员能够开发出完美的代码，这种事情根本不存在。代码是永远也写不完的。
相反的，程序员需要学会在适当的时候放下。
有些程序员不知道 “完成” 是什么意思，他们会说，核心内部函数可以展示的时候，就算是完成了一些工作，而没有考虑需要有流畅用户界面并符合实际需求。
要使程序员达到最高的生产效率，
通常，所有的开销加起来，约占公司总支出的 80%。
成功管理软件交付过程
大多数程序设计经理发现，当领导在评价他们工作绩效的时，往往是以成败论英雄，即他们能否在预算范围之内交付符合客户需求的软件。
即使是在敏捷组织与自组织团队盛行的当今，绝大多数程序设计经理还是需要一力担当软件交付的职责。
而作为一名程序设计经理，你的组织几乎肯定希望你在交付过程中发挥重要作用。
如果你的组织是真正的的敏捷组织，那么你的团队就会担当起软件交付的职责，而作为管理者，你本人很可能被衡量 “能否为团队创造准时交付的软件的各项条件”。
组织期待你可以创造出一派蒸蒸日上的良好开发氛围，一个基于团队合作、团队稳定、顺畅沟通的欢乐祥和而又积极向上的团队文化氛围。
在不同的组织中，管理者的交付责任几乎是各不相相同的。
问问你自己：我的组织是如何衡量我，如何测量我的团队的交付能力的。
真正的敏捷组织少之又少，在更多的情况下，衡量你是否成功交付的标准，依然是经典的预算、时间、范围 和 质量 这四大要素组成的某种组合。
无论你是否喜欢衡量你的各项指标，你都需要清楚理解它们是什么，这一点极其重要。
你还需要知道是否有合作伙伴可以与你分担交付责任。
传统意义上，有许多干系人都会与你分担交付责任。
如果没有，你除了需要学习有关开发管理方面的知识，还要学习项目管理的常规工作。
项目经理的职责是协调团队、预算 和 进度。
当项目规模庞大到需要跨团队时，项目经理通常负责管理多个团队间的依赖关系。
Scrum Master 负责保障敏捷组织的健康运行。
在产品规范方面，你应该有一个产品经理或产品负责人，他的职责是构想你的程序员正在构建的产品，并将其分解为市场实验、最小可行的产品、最小可市场化功能 和 用户故事。
程序员负责正确的构建产品，而产品经理则负责构建正确的产品。
产品交付始于项目或者产品启动会，在该会议上，你将扮演一个推动并确保澄清项目及其目标的角色。
你的角色与产品经理的角色一样，就是去激励你的团队。
你和你的商业伙伴（BP）们要抓住机会，奠定正确的基调。
如果不是具备一定的重要性，你也不会去承接哪怕是最次要的项目，而这正给你提供了讲述这个故事的机会。
如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们要对广阔无垠的大海满怀憧憬。
每一个团队成员，都应该在项目启动后了解何为项目成功的标准，从而使成员都能在同一个方向上共同推动项目的发展。
即使已经有了非常好的项目名称 和 项目 T 恤，项目的愿景也仍然会应为技术性的短视而模糊。
程序员很容易把注意力转向算法、组件模块 和 代码本身，而忽视了客户的需求和想法，以及客户的希望和梦想。
优秀的程序设计经理能够激励团队将重心始终集中到客户身上，专注于交付项目成果。
千万别低估向团队寻求反馈的价值。
团队会议是一个很好的机会，通过一起讨论项目的价值、选择最佳的方案，你可以极大的激励团队成员为追求卓越而努力。
不仅如此，大家一起分享、评估项目的过程，也能厚植同袍之谊，提高团队士气。
产品负责人的职责包括最终验收的标准，以及定义什么是 “成功”。
其关键是要让各个干系人就 “项目的成功标准是什么” 达成一致，并为此提供答案。
产品负责人应当在项目启动时，就上述问题为团队提供各个干系人共同认可的答案。
程序员最讨厌的事情之一就是当他们费尽千辛万苦做出产品时，却发现因为时间太迟、需求不对 或者 产品研发所遵循的需求规格并非客户的现实需要 等诸多原因，而导致产品反响不佳。
所以，你一定要弄清楚干系人对产品的预期，追求的是速度、功能、质量、上市时间，还是某些特定功能、集成度、易用性，抑或其他因素 —— 包括确定衡量这些因素的关键指标。
身为管理者，你代表着你的团队，你有责任了解项目在哪项/哪些预期上可以进行弹性调整。
项目管理中有一条经验法则，叫做 “铁三角”，三角形的三边分别是 范围、进度 和 人员。
这个规则是，范围、进度 和 人员，只能任选其中两项。
例如，如果你要增加功能，那么你要么删除一批总体规模相近的功能，以满足进度的要求；要么延期进度方面的要求，给予你的团队更多的时间；抑或在项目中投入更多的人员。
这是一条显而易见的基本法则。
当然，到底选择 “铁三角” 的哪两边，这可能不是由你来决定的，这可能是产品管理部门的责任。
但你要代表你的团队，确保每个人都明白铁三角的哪条边是可以被调整的。
有时，质量是 “铁三角” 中可调整的参数之一。
过度追求质量，也可能是在玩火自焚。
作为程序设计经理，我们需要从 BP 们那里获取到清晰的功能优先级说明。
为了项目能够成功，我们能交付的 15% 最好是最重要的、能够提高最高客户价值的那部分。
Scrum 流程把优先级顺序规范化定义到 Sprint 循环中。
团队真正需要知道的是，哪些功能项提供的价值最大，然后把这些功能项用作第一个冲刺阶段的候选功能项，并对剩下的最重要的那些功能项做优先级区分。
随着待办项的重要程度的降低，优先级区分可以做得更加粗略笼统。
产品负责人，需要对下一个冲刺阶段的功能项做相同的优先级区分，并在团队中达成共识，确保开发团队总是在做价值最高的开发工作。
一旦错过市场窗期，商业价值就会变成零。
在 “那个日期” 没得商量的情况下，你必须迅速弄清楚 “这个功能” 到底是什么，功能有多少是可以调整的，以及如何为这些功能设定优先级。
意识到交付日期不可更改，那么正确的功能优先级排序，就将成为制订项目计划的重要部分。
Scrum 特别适合范围部分确定的项目，因为 Scrum 可以确保产品待办事项列表 始终按照客户最关心的东西来排序，产品始终是已构建和可构建的。
虽然项目奖励通常都是在项目交付之后发放，但是程序设计经理可以在项目的计划阶段，以及项目的关键节点上为团队争取特别奖励。
在通知团队进入 “加力燃烧” 工作模式之前，他先去找 CFO 交涉：接下来我打算让团队进入高强度加班工作模式。如果他们真能搞定这个项目，你应当给他们颁发一定的特殊奖励。
如果是在项目成功之后再去交涉，CFO 就不会那么容易答应了。
控制预算的人，不论是你还是你的精力，在要求团队付出全部努力，打破常规奋力拼搏之前，一定要预先分配好用于奖励的预算。
项目开始于愿景，但必须通过 需求、假设、预期、风险、里程碑 和 最终交付 的流程，才能成功交付。
开发软件产品是一件非常困难的任务，其中最明显的一点，就是产品经理很难清晰的用文字，表达出程序设计团队到底需要做出什么样的产品。
雪上加霜的是，我们经常能从程序设计经理或程序员那里听到抱怨：他们还不知道到底希望做出什么样的产品，就已经给我们指定了一个必须完成的日期。
当你需要自己推想需求的时候，很难做出满足客户需求的产品。
臆测从来都不能为获知 “需要构建怎样的产品” 打下坚实的基础。
各项研究一再表明，按照模棱两可的需求，或者说按照错误的需求来构建产品，是软件开发中代价最大的错误之一，也是项目失败的首要原因之一。
更糟糕的是，组织往往因为不了解其后果，而对需求沟通不畅的情况一再姑息。
其实，使用何种软件开发方法无关紧要；真正重要的是，你必须始终如一的对项目的需求保持清醒的认识。
业务团队与程序设计团队之间失败的、不完整的 或者 模糊的 需求沟通，是造成这个问题的关键原因。
并且，这个问题拖得越久，修复它的代价就越大。
在软件开发过程中，需求在编码之前就完美无瑕是不现实的，要实现需求清晰化并不容易。
构建程序的很多本质工作，实际上就是不断调整需求规格。
当时每个人都想反抗那种冗长的文风，所以大家一起推动了这次变革。
我们仅仅增加了一个简单的需求标准，要求每个功能都必须包含编号和优先级。
此举让我们的执行能力提升了至少两倍。
单独的需求从产品需求文档、开发到 QA 阶段都有迹可循，程序员不再需要深钻研读产品需求文档，QA 也终于有了可以标记测试的功能项。
而产品经理本人一旦习惯了新的文风，也会发现编写产品需求文档更加容易了。
不论使用哪种开发方法，程序设计经理都需要警惕开发过程中遇到的有歧义的需求。
这种需求会导致程序员遇到不确定的程序逻辑，他们常常会继续编码，填上自说自话的逻辑。
这时候，实际上是程序员自己在确定需求细节。
然而，在定义需求的时候，很有会有程序员比产品经理更理解产品（除非产品的目标客户是其他程序员），因为产品经理的职责才是（或者应该是）理解客户。
解决需求有歧义或不完整的问题，有几种方案。
一种解决方案是使用专门的工具，现在市场上已经有商业工具可以读入产品需求文档，使用自然语言理解功能来定位和显示有歧义的地方。
另一种解决方案是，加强需求提供者与程序员之间的沟通。
如果上述两种解决方案都不可行，程序设计经理就需要介入并为需求提供者和程序员建立沟通桥梁，
并促进双方的内部沟通，以提高程序员理解需求的可能性，
确保他们在遇到需求歧义的时候去询问清楚，而不是按照自己的理解补充需求。
你的工作职责不仅仅是确保需求清晰，还要确保这些需求具有正确的优先级排序，以及确保每个人对这些需求的假设、预期和风险 均有清晰的认知。
无论是将它叫做需求协作，还是需求澄清，它的目的都是了解客户想要什么，做什么可以让客户满意，这是实现需求清晰化的根本。
需求优先级排序对项目成功至关重要。
如果需求没有排序，开发人员将会根据自己的研发偏好，去实现那些最简单的功能，或者一些看起来酷炫、很新颖、很有趣 的功能。
这样，在面对复杂到令人生畏的功能时，开发人员可能会简单粗暴的从他们已知的功能着手，并希望通过对已知功能的开发，带领他们去理解那些未知的功能。
正确进行优先级排序的好处显而易见：以那些最能让你从竞争中脱颖而出的、市场与客户最关注的功能 为开发起点，这样就可以确保在需求的时候，这些功能随时都可以被交付。
敏捷开发方法论正是基于如下原则：经常性交付（每次迭代/冲刺都需要有交付物），这些交付物必须是当前客户价值最高的功能需求，而后剩余的功能也进行重新排序，以确保正确的优先级。
无论使用何种方法论，优先完成高优先级的功能，都可以促使客户为我们提供反馈。
通故这些反馈，我们就能发现各个需求在功能列表中的优先级，它们可能并不像我们开始理解的那样，可能还会发掘出新的功能需求。
这些功能原本不在功能列表中，但显然比大家认为下一步要完成的工作优先级更高。
所谓市场化功能，意味着这些功能可以给客户带来价值。
需求优先级排序，是产品经理或者产品负责人所拥有的权力，但是客户价值并不是优先级排序的唯一标准。
我们需要确保开发人员的想法也要包含在排序的过程中。
通过协作，产品经理与开发人员可以找到如何切分最小可市场化功能的方法。
进行排序时，开发人员需要考虑需求之间的依赖关系。敏捷开发人员需要估算开发任务的相对大小，借此作为量化的依据，并提供给产品负责人用以计算投资回报率（ROI）。
Scrum 将产品负责人的职责规定为 “以故事的形式（用户故事）交付客户需求”，这些用户故事并非只在项目之处进行排序，而是在每次冲刺开始前都需要重新排序。
但是 Scrum 并没有规定必须是产品负责人编写用户故事，仅仅是要有人写就行了。
有经验的管理者会识别项目风险，并作出合理降低或者消除风险的行为，这与交付最高客户价值的功能需求同等重要。
其中一个关键的不确定性领域是用户界面：没有人敢保证可以提交一份用户一定会接受的界面。
所以，在没有将用户界面放到用户面前之前，一切不过仅是猜想罢了。
同时，你也无法预测需要经过多少迭代才能确保用户界面被用户所接受，所以你应该尽早开始着手与这部分相关的工作。
用更早且更频繁的方式交付代码，我们就可以通过频繁的检查点来核实你对需求的理解程度，避免需求出错的情况发生。
当风险太高时，你需要坚持自己的观点。
想方设法得到正确的需求，了解客户真正想要什么、需要什么，那么接下来的项目进展就会顺利许多。
把需求限制在 “做什么” 而不是 “如何做”
程序设计经理还需要警惕，在产品需求文档中指定如何实现的情况。
好的产品需求文档描述的是，客户所需要的解决方案以及它给客户带来的价值，即 “做什么”。
而如果产品需求文档中还附加了选择哪种技术 和 实现路径，则会因为错失了好的程序设计团队的专业知识、研究分析技能以及创造力可能带来的贡献，从而不能交付合格的产品解决方案。
如果你不让你的工程师编写代码，你就失去了他们一半的价值。
如果你发现产品需求文档中指定了 “如何做”，原因可能是你的 BP 们并不相信你，或者你的团队，能做出优质的关于实现方面的决策。
这时候，最好的解决方法是把你们的技术决策过程公布出来，把每一个设计阶段的决策思考都分享给 BP 们，慢慢增强他们对你们的信心。
此外，其原因还有可能是你的 BP 们是在某次行业会议上，看到了竞争对手的演示，因此才会指定 “如何做”；或者也可能是因为指定 “如何做” 更容易描述 —— 比起实际表述出软件所应当完成的功能来说，直接指定使用某种技术更加轻松简单。
有时候，产品经理是在读到某种技术的底层实现方法时，一时兴起而想到的项目创意，因此他们写下需求时可能认为那是唯一的实现方案，而没有想过总结出真正需求的愿景，然后再去拜托技术伙伴们思考是否有更强大的技术用于实现。
优秀的程序设计经理，与普通程序设计经理的区别在于，前者并不仅仅满足于完成接收到的需求，即并不只是开发客户所要求的软件，而是追求去真正理解 BP 们所要完成的目标，交付真正能满足需要的产品。
取悦客户的能力，可以使优秀的管理者及其团队脱颖而出。
苹果公司 iPad 的实例证明，客户无法提出他们想象不到的需求 —— 从来没有人认为自己会需要 iPad。
当然，你很少有机会去制作 iPad 这样完全颠覆客户想象的产品。但大多数项目都可以通过一些细微的差别，满足客户真正需要却没有想到的需求。
引导你的团队去打磨他们自己的、基于团队的 DoD（Definition of Done，完成的定义）。
通过 10 年来对敏捷团队的管理、辅导，以及领导敏捷转型，Ron 相信，在进行正式编码之前想清楚并为团队与项目定义 “完成”，这种做法可能是最有用的敏捷实践。
2016 年版的《产品团队绩效研究》显示，能够自行定义 “完成” 标准的团队与绩效最高的团队之间存在相关性。
我们看到过很多团队时常对他们的 DoD 进行回顾，并更新他们的定义，使之更有有效。
无论你正在构建的是什么东西，都有以前从未被构建过的内容，这一点几乎毫无例外 —— 要么是开发方式，要么是开发工具，或者是平台，又或者是所需要的经验，反正至少有一样是你的团队前所未见的。
估算在项目运行过程中应随机应变。
当你自己都不知道自己在说什么的时候，说得再精确也没有意义。
估算面临的一个挑战是，在项目进行的过程中，需求会变得比一开始看到的更复杂。
前 90% 的代码会花费前 90% 的项目开发时间，剩下 10% 的代码还要再花费 90% 的项目开发时间。
在估算时，程序员们也很少考虑到实际工作以外的因素，高估了他们可以持续工作的时间和可承受的工作强度。
一个非常保守的行业经验法则是，程序员通常花在编码上的时间不超过 55%。
只有当一项任务可以在很多工作者之间分配，并且这些工作者之间完全不需要对此进行沟通交流的情况下，“人”（资源）和 “月”（时间）才可以互换。
我们的公司确实需要在某种程度上了解我们可以在什么时候完成哪些事情，而我们的产品经理也需要了解哪些功能更有成本效益。
你工作的一部分内容就是，引入能使软件开发更可预测的实践。
并且，请永远不要让高层管理者（或者你的产品经理）将相对估算和承诺混为一谈。
在实践中，Brooks 发现，基本上所有的软件项目都只需要用 1/6 的计划时间来编写代码，与此同时需要用一半的时间来进行测试与 Bug 修复工作。
完美是优秀的敌人。
好的设计增加价值比增加成本更快。
要求有人写出设计文档，即使之前我们是在白板上分享，这一行为也会迫使设计具体化。
而设计文档能让团队其他成员接受设计，并迫使他们批判设计。
如果设计只占了整个项目的 1% 的时间，那它肯定太少了；但如果设计占用了整个项目超过一半的时间，那它肯定太多了。
如果你不确定你在构建什么，概念验证（Proofs of Concepts），或 PoCs，对于帮助你的设计师和程序员保证他们了解如何解决问题、在早期冲掉风险、并确定你需要做什么才能成功，是非常有用的。
频繁交付是一种敏捷机制，以确保建立紧密的客户反馈循环。
请记住，QA 的工作是从评审你的设计开始的。你应让设计人员将他们的设计展示给其他同事。
无论你是在做大型设计还是在做即时（JIT）设计，你都应该鼓励或者要求实施设计评审，以尽早排除设计缺陷，找出被忽视的复杂问题和发现没有预料到的交互环节，并识别各种类型的缺陷。
设计评审还有一个隐性的好处 —— 帮助整个团队提高设计能力。
设计评审是一个向年轻的团队成员传授设计能力（不仅是设计原理，还有具体的设计流程）的好机会，而且可以帮助团队建立最佳的设计实践，并不断的提高团队整体的设计质量水平。
一旦建立了稳固的设计评审机制，你就可以把组件设计分发给初级或者中级程序员，而不用担心他们会失败，因为设计评审可以让你或者你的组织为他们提供良好的保障机制。
这样你的资深程序员就有时间把他们的经验扩散到多个组件设计之中，并负责它们的整体设计了，而这两点是你赖以成功的关键。
当技术债务上升时，对客户的响应能力就会下降。
在高技术债务的应用中，估算几乎是不可能的。
重大项目的管理必须像跑马拉松一样。设置良好的节奏，做好足够的准备，保证开发团队能够坚持到最后的冲刺阶段。
你可以要求开发团队偶尔进行冲刺，也可以要求他们在终点线前拼尽全力的奔跑，但不能要求他们在长期项目中一直保持冲刺状态。
在我们看来，很不幸的是，Scrum 把它的迭代成为 “冲刺”，特别是考虑到那些真正实施敏捷方法的团队，是基于历史上马拉松般的速度来规划的。
不现实的项目时间表，肯定会燃尽他们的精力，把团队带向不可避免的失败。
中期里程碑是项目节奏的关键。
敏捷方法可能不会为中期里程碑命名，因为根据敏捷的定义，产品在每一次迭代期或冲刺结束时，都应当是可发布的，所以每次迭代或冲刺都是一个里程碑。
程序员如果彼此不沟通，常常会变得冷漠无声，对什么事都漠不关心，对项目会带来破坏性的影响。
通过在冲刺计划会议上的通力合作，程序员经常互相分享各自的计划、任务 和 步骤，他们能够互相获得反馈。
程序员总是能够找到借口说他们是在 “磨刀不误砍柴工”，而且还会千方百计的证明 “这确实是必要的”。
有时候情况的确如此，但有时候得需要经理来决定什么情况下这种 “磨刀” 的功夫已经脱离了项目的初始目标，然后让程序员从他们开心的 “工具保养” 工作中回归到真正的首要任务上。
不管是否声明，你都有一个关键的职责：让项目愿景保持清晰。
程序员本身的特质（处理细节的能力、平衡各种想法并发散思考的能力），也常常让他们陷入各种细节之中。
你还会发现常常需要在功能、质量、时间之间进行权衡。
你需要问这样的问题：如果我们要实现这个功能，那么在之前的功能列表中，销售部门或市场部门愿意放弃哪一条，才能让我们仍然按时完成项目？
无论你是通过与你的团队成员一对一的谈话，还是通过小道消息，或者从问题上报的过程中发现障碍，你都不能为障碍的存在找借口。
相比于缺少某些功能特性，糟糕的质量更容易引起客户的不满。
你需要 “深入的倾听”，听到人们话外的意思，这样才能听懂他们真正需要什么。
对于真正的 Bug，你的反应最好不是诉诸惩罚，而是专注于如何在未来避免出现类似的问题。
你的任务不是挑错误，而是改善流程：更好的冒烟测试，更好的测试框架，持续的构建流程，确保活跃的代码分支不变得不可编译或不可运行，让正确的人及时做好设计与代码审查，恰好够用的编码指南（以及推荐与施行它的流程），完善的源代码控制系统，支持开发流程的工具，编码最佳实践与查错最佳实践的培训，及时的 QA 反馈，分配最好的程序员和查错人员去指导最缺乏经验的新人等。
先思考测试而不是代码，是一种微妙的改变。这样的改变会带来额外的好处，能够确保你完全理解需求。
于是 编码/测试 循环变为 测试/编码 循环，一旦形成新的习惯，你会发现 TDD 并不会带来多少额外的开发成本，只会带来更好的质量。
有证据表明，做 TDD 要比不做 TDD 多花 15% 的时间。但也有证据表明，TDD 能使 Bug 更少。（微软的两项研究显示，使用 TDD 后，Bug 的数目分别减少了 24% 和 38%。）
有时候，团队远远没有建立起足够的对质量的责任感，这就需要中间过程的帮助。
在检入代码时，程序员需要写一两段简短的说明文字，解释他们将如何测试代码，这样可以使他们慢慢建立起对质量的责任感。
知道其他人会检查自己的代码，会让程序更加小心，以免犯下愚蠢的错误。
解释自己的代码的行为，早已被证明可以帮助程序员，发现他们在其他情况下难以发现的错误。
而且所有的研究都表明，在程序员对代码记忆犹新的时候就发现并修复错误，比起后来在 QA 或者客户发现问题的时候再修复要容易。
不仅如此，代码审查人员还可以教年轻的程序员，如何更好的进行程序设计。
最好让代码所有人在审查前一周左右，按照模板或者 wiki 页面填写好需要被审查的代码段的说明。
最好有一个表格可以让审查人员填写他们的审查结果，指出他们的评论所对应的代码行号，以及提出更好的修正建议，或者仅仅只是提出思考。
一旦建立起代码审查的文化，你就可以建立起一个由资深程序员，对同级或更年轻程序员的代码进行审查的循环。
整个环节在最后冲向终点线的过程中发生了变化。
交付、最终版、发布、上线、完成 —— 不管你怎么称呼，完成软件开发都是一件很困难的事情。
修复不重要的东西，会给发布带来不必要的风险。
从现在开始千万不要再增加新的功能；现在要做的是不断改善质量。
软件永远无法达到尽善尽美。
挑战在于，如何知道何时它已经 “足够好”，该放手结束工作。“有时候，你需要 ‘架枪’ 逼迫程序员，他们才愿意交付产品”。
因此，你（或者产品经理，甚至是高层管理者）需要决定项目何时交付。
有时候，你需要重新定义什么是成功，甚至需要做出非常大的改变，才能让产品更早到达用户手中。
项目宣布成功之后，你应当尽早开展实实在在的庆祝活动。
这是一个让大家放下项目交付的重大压力，聚集到一起放松的很好的机会。
一个项目交付之后，你可能需要给团队片刻的时间来喘口气。
但在他们开始忙于下一个项目之前，你需要召开一个回顾总结会议，让大家一起反思在刚刚完成的项目中，学到了哪些东西。
避免心理防御是关键。
无论我们揭示了什么，我们必须理解并真正相信：考虑到当时的已知情况、每个人的技能和能力、可用资源和情境，每个人都做到了最好。
将期望集中放在下一个项目上，即在你们完成了上一个项目之后，整个团队如何在构建下一个项目时做到更好、更快、更高效。
着眼于未来，可以减轻大家认为你正在寻找上一个项目所犯的错误的感觉。
问问你自己，你的团队做出的贡献和学到的经验中，有哪些可以给公司的其他人带来价值。
下一个项目没准备好，不代表你的团队会失去活力。
闲暇时间往往是程序员重构混乱代码、编写完善文档、补救当初为了及时交付而赶工欠下的各种 Bug 的最佳时机。
交付软件之后，团队成员很容易觉得自己已经成功，但大部分情况下，交付后最关键的任务是倾听客户的反馈。
敏捷团队中的管理者
很多管理者都被项目缠身，没有时间去做好一个管理者。
真正的敏捷组织是让团队自己负责交付，而不是让管理者来负责交付。
麦格雷戈 X-Y 理论：
当我们转向敏捷时，通常会从技能型团队转向跨职能团队。
Scrum 告诉我们，一个团队最理想的人数是 7 人（上下浮动不超过 2 人），也就是 5~9 个团队成员（包括 开发人员、测试人员、设计人员、技术撰稿人），再加上一个 Scrum Master 和一个 PO。
团队的规模各不相同，但其关键是，每个团队不再是围绕专业技能来组织的。
相反，每个团队的配置是跨职能的，能够提供客户觉得有价值并能看到的功能。
每个团队都配置了足够多的来自每个专业的程序员，能够自给自足的完成相应的功能。
每个团队都有一个 PO 来对团队进行指导和支持。PO 专注于定义团队需要完成的功能，并对功能进行排序，以便团队始终为客户提供最大的价值。
团队是完成工作的地方。
管理者在敏捷团队中的职责，并不是专注于交付，交付的职责是被赋予团队的。
团队不向管理者汇报工作，他们是自组织的。
与之对应的，管理者是专注于技术能力和实践这些技术能力的人，专注于雇用合适的人。
除此之外，管理者还要专注于指导、辅导和支持员工做出好成绩。
作为一名管理者，你可以使敏捷文化得以实现，也可以阻碍敏捷文化的发展。
服务型领导关注的是领导，而不是管理。
他是为客户、用户、股东、管理层和员工创造文化，并将重点放在满足客户、用户、股东、管理层和员工等干系人的需求上。
管理者为团队划出了需要完成的事情的界限，并对团队说，我相信你能找到完成工作的方法。
一个 Scrum 团队的工作，就是在管理者划出的界限内，围绕着管理者提出的挑战进行自组织。
管理者的工作是提出适当的挑战，并消除自组织团队的障碍。
管理者所面临的挑战就是要相信成员和团队。
信任但要核实。
我只检查自己所要求的东西。
为个人和团队设定预期目标；如果需要，就对他们进行辅导；检查他们的工作结果；逐步提升对他们所需的辅导的理解。
敏捷管理就是关于，如何改善那些可以对卓越的工作提供支持的流程、环境和具体实践。
当团队自组织的时候，管理者还有很多事情要做，管理者的工作是对团队进行工程化管理，使团队能够全力以赴的完成工作。
如果你是 Scrum Master 且大家都在看你，那你的做法就错了。
既然你的目标是支持团队自我激励和自组织，那么真正重要的是每一个团队的成员都拥有自己的看法和观点。
这意味着你要相信他们，并辅导团队成员相互信任。
这种信任体现在 分享、沟通和协作、建立并重视团队合作，并创造一种 “所有人参与其中” 的团队意识。
从根本上来说，敏捷所强调的是，软件开发是一项团队活动。
研究显示，心理安全是高绩效团队的重要特质，团队成员在团队内部有一种安全感，有机会说出自己的意见。
管理者必须愿意甚至渴望被打断。
我们不仅要欢迎他们来打扰，还要主动邀请我们的员工在任何时候，有任何问题都来随时打扰我们。
在开始的时候，每个人都会谈论范围、预算和时间表，但到最后，就没有人真正关心这些东西了。
他们唯一关心的是人们喜不喜欢你的软件。
这是你唯一真正需要管控的标准。
我们还需要认识到，代码质量的好坏与程序员能不能屏蔽掉杂念、进入心无旁骛的工作状态直接相关。
作为管理者，我们的工作之一就是保护我们的团队，使其远离可能导致质量问题的干扰和多任务的影响。
归根结底，管理者需要设定质量预期，屏蔽噪音，然后检查结果。
重要的不是你的流程，重要的是你改进流程的过程。
曾经有人对我们提出了让人惊讶的建议：如果你没有在规定的时间内把所有的事情都处理好，请先试着缩短时间。
有效的设置时间盒，有助于工作的聚焦与高效。