经理武器库中一个经常被忽视的工具是“经验法则”——一个简短而简洁的陈述，体现了一个强有力的信息，给听众留下了深刻的印象。米奇·曼托和罗恩·利希蒂是《管理不可管理：管理软件人员和团队的规则、工具和见解》的合著者，他们确定了八大管理挑战和21条经验法则来帮助经理应对这些挑战。
我们都按照经验法则进行管理。有时我们会自己制定规则——也许是在经历了一些艰难的挑战（或失败）之后，这会给我们带来一个重要的教训。有时，教训已经形成，如此简洁，以至于我们可以用短语或句子来传达它。而在其他时候，我们则难以将复杂性归结为其精髓。
在我们作为程序员的职业生涯早期，我们都读过弗雷德·布鲁克斯1975年里程碑式的书《神话中的人月：软件工程论文》。[1]这本书充满了今天仍然相关的智慧，被广泛认为是软件项目管理艺术中的权威著作，成为程序员中的经典。像许多读过它的人一样，我们发现布鲁克斯的一行智慧金块既难忘又非常有用——比如这本书，现在简称为布鲁克斯定律：
将人力添加到后期的软件项目可以使其更晚。
在管理软件项目时，我们无法计算使用此报价的次数。
寻找和分享其他令人难忘的规则的愿望是写我们的书《管理不可管理的：管理软件人员和团队的规则、工具和见解》的灵感和驱动力，在这本书中，我们收集了300多条我们和我们的同事用来管理程序员和团队的经验法则。
本杰明·富兰克林收集并出版了第一批著名的格言、谚语和经验法则之一，被称为《贫穷理查德年鉴》。[2]大约在同一时间，托马斯·富勒出版了自己的谚语书，其中包括了这条普遍存在的生活规则：[3]
及时缝一针可以省九针。
我们在成长和生活中学到的这些规则通常同样适用于管理软件开发和其他生活。尽管编程代码可能是最可变的材料，但不止一位软件开发经理应用了这个传统原则。
测量两次，切割一次。
几乎每个人都曾在某个时候未能遵循这一规则，我们大多数人都活下来后悔了。也许没有人像美国航天局的科学家那样引人注目。他们的火星气候轨道器航天器以公制单位编程，而是从地球上的地面系统接收英语单位的指令，导致航天器离开其火星轨道轨迹，进入火星大气层，在那里解体。
另一个我们喜欢的传统规则，虽然不太为人所知，但它来自于比我们的职业早数百年但仍然适用于我们的许多规则。
生活更简单，当你在树桩周围耕作时。
有时候不好的做法根深蒂固，你只需要围绕它们进行学习和引入更好的做法。
在本文的其余部分，我们将考虑管理挑战的八个主要领域，并从我们的书中选取了300多条规则来解决这些挑战。
解决问题
招聘
沟通
团队合作和合作团队
交付项目/产品
要求
开发过程
管理自己
问题解决我们的商业伙伴在解决世界饥饿或治愈癌症方面提出问题已经够糟糕的了——愿景是他们的工作。但是，当我们解决问题——无论是他们的问题还是我们自己设计的问题——而没有将复杂性分解为步骤并将这些步骤排序以便我们可以一次解决几个问题时，我们会对自己造成伤害。
罗恩：在查尔斯•施瓦布，我和我的同事们正在应对一个挑战，即将这家曾经是世界领先的折扣经纪公司转变为在线金融服务的首要品牌。我们经常引用这条规则：
规则#1：不要煮沸海洋。
这条规则并没有减弱愿景的规模，但它提醒我们不要一次性解决所有问题。
当我和米奇分享时，他非常喜欢，以至于他也把它作为Gracenote的口头禅。但他经常用另一个经常被引用的原则来跟进：
规则#2：分而治之。
这是解决任何看似棘手问题的关键。这个规则特别吸引人，因为它可以用来解决任何问题，无论大小。不断划分，直到找到你可以处理的问题的一部分，并解决它。然后“从堆栈中弹出另一半”并解决它，或者将其分成两半并递归。
招聘1986年皮克斯动画工作室从卢卡斯影业分拆出来后不久，史蒂夫·乔布斯作为CEO积极参与皮克斯，他在一次管理会议上讨论了自己的招聘理念：
规则#3：A雇用A。B雇用C。
乔布斯强调了雇佣正确的人（“A”）的重要性，因为允许“B”进入组织对组织的侵蚀远远超过了一个错误的雇佣。
我们认为雇用合适的人是经理最重要的责任。但是你如何确保找到合适的人呢？Dave Wilson是一位软件架构师，曾指导苹果、Sun、惠普、Portal和ParcPlace的开发，他分享了一个帮助寻找优秀程序员的规则，我们俩都独立验证了它。
规则#4：雇用那些在自己的时间里建造东西的人，只是为了好玩。
虽然我们从来没有限制自己只雇佣那些用自己的时间建造东西的人，但这是雇佣合适的人的一个很好的试金石。
沟通关于管理的一个重要教训——通常也是一个难以学习的教训——是沟通与倾听一样重要。许多公司提供“反思性倾听”的经理培训，重点是真正倾听，然后用承认演讲者观点的信息回应。
提醒我们倾听的规则非常有帮助。罗恩第一次从金伯利·威夫林那里听到这个经验法则，金伯利·威夫林是旧金山湾区非营利性技术专业人士协会SVForum工程领导SIG的联合主席之一：
规则#5：我们有两只耳朵和一张嘴。按照这个比例使用它们。
一个存在时间稍长的思想的简洁词语：希腊出生的罗马奴隶和斯多葛派哲学家埃皮克提图（公元55-135年）被引用说，“我们有两只耳朵和一张嘴，所以我们可以多听少说。”
除了成为一个好的倾听者，沟通还包括每天抽出时间与员工见面和交谈。正如戴夫·威尔逊所说：
规则#6：如果不干涉，人们很快就会偏离项目目标。优秀的项目领导者几乎每天都会与人交谈。“你做了什么？为什么？成功了吗？”
米奇：惠普长期以来推崇的“四处走动管理”最佳实践是我们最喜欢的管理工具之一。一天快结束时，我经常发现自己在程序员中间徘徊，停下来和那些不“低头”的人交谈。这些短暂的“一对一时刻”虽然是公开的，但帮助我与人们的行为、他们正在做什么、他们遇到了什么障碍，甚至他们的感受（身体、精神和情感）联系起来——所有这些都没有安排会议和正式坐下来的开销。这些共享时刻是我最喜欢的时光之一——希望我的员工也是如此。
罗恩：我在苹果的一位经理蒂姆·斯威哈特说过：
规则#7：如果你是一名人员经理，你的员工比你正在工作的任何其他事情都重要得多。
他继续说：“如果团队成员在尴尬的时候过来聊天，把你正在做的事情放在一边，集中注意力。他们可能正在鼓起勇气告诉你一些重要的事情。我注意到，当突然的闲聊不是通常只是闲聊的人时，这一点尤其正确。这可能只是无法获得完成任务所需的信息，也可能是即将到来的离婚、所爱之人的死亡，或者对他们来说同样毁灭性的个人层面的事情[…]这些事情可能会给你精心安排的日程带来真正的麻烦。如果他们知道你会把他们作为你的首要任务，他们更有可能在事情即将变得非常糟糕时更早地过来。”
团队合作和协作团队你如何让一个团队努力工作来交付你需要的东西？我们认为从敏捷和Scrum思想领袖迈克·科恩那里学到的一条规则是真理：[4]
规则#8：并置团队将始终优于等效的分布式团队。
我们一次又一次地看到这条规则是正确的，我们也相应地管理了内部团队。总是令人惊讶的是，有多少“环境”信息在共享团队的成员之间流动。它还打破了团队成员之间可能出现的障碍。产品营销经理和程序员以彼此之间的“问题”而臭名昭著；共享他们甚至可以从这些不同类型的生物中快速结交朋友。同样，JSON的发明者、企业家和软件架构师道格拉斯·克罗克福德指出：[5]
规则#9：我曾经遇到过开发团队和测试团队之间存在对立的公司。当我们将两个团队放在一起，让测试人员负责帮助开发人员改进他们的程序时，效果会更好。
不幸的是，在当今地理位置分散的虚拟团队世界中，搭配可能是你负担不起的奢侈品，也可能是你无法培养的方向。为了解决这些团队可能面临的时间、距离和文化等额外挑战，你需要使用你能想到的每一种沟通方法，让你的团队感觉不那么疏远，联系更紧密。Skype、IM、电子邮件和定期电话会议都有所帮助，但最终你必须加倍努力，确保沟通上下流动才能成功。
交付项目/产品你有多少次看到程序员沉迷于应该做的事情而不是需要做的事情？杰米·扎温斯基是早期的网景首席开发人员，他经常以友好的方式发表这句话，这有助于让团队保持任务：[6]
规则#10：你不是来写代码的；你是来运送产品的。
微笑着说出来，但通过“深入了解”代码的状态来支持它。
专注需要伴随着正确的强度水平，以避免让你的团队筋疲力尽。如果你一周又一周地让他们晚上和周末工作，你最好采用皮克斯CTO埃德·卡特穆尔的这条规则：
规则#11：项目应该像马拉松一样奔跑。你必须设定一个健康的步伐，能够赢得比赛并期望冲刺到终点线。
米奇：在皮克斯，埃德鼓励我以这种方式管理项目，从那以后我就一直在实践这条规则。自从我和罗恩分享这条规则以来，他也是这样做的。在面试新候选人时，我们找到了一种方法来提出这个原则，以便设定适当的期望：有时程序员将需要非常努力地工作，为终点线和项目完成冲刺，但我们不指望程序员一直冲刺。
除了管理下（你的团队），你还必须通过设定适当的交付期望来管理上（你的老板和同事）。这个传统规则对我们双方都有好处。
规则#12：承诺不足，交付过多。
它胜过我们所知道的任何其他方法。另一方面，你不能低估太多，否则你会被贴上派克的标签。
要求根据我们的经验，软件开发最先失败的地方是需求。需求几乎总是模棱两可的，它们可能会被覆盖或超范围，运行到数百甚至数千页，或者完全缺失。当编程管理不足或不堪重负时，产品管理通常同样受到挑战。
在需求缺失或参差不齐的地方，我们想提醒我们的产品构想同事路易斯·斯里格利的经验法则：
规则#13：没有要求或设计，编程就是将错误添加到空文本文件的艺术。
识别功能的重要性和优先级长期以来一直是许多产品经理的烦恼。在瀑布式流程的时代，产品经理避免选择要包含哪些功能，而是写了数百页的需求，包括他们能想到的一切。这导致了需要数年才能完成的项目。他们的同事很快意识到，要想看到他们的宠物功能实现，他们需要把更多的东西塞进下一轮。所有这些都忽略了一个事实，即很少有程序员能够阅读和保留所有这些功能页面，更不用说它们的相互关系、依赖关系和细微差别了。这是导致敏捷方法的一部分。
但是变化可能是危险的；它提供了另一个逃避决策的借口。在敏捷时代，一些产品人员避免承诺，声称敏捷意味着永远不必提供需求。这与事实相去甚远。施瓦布移动交易系统的VPNasos Topakas，当时负责Ofoto、StubHub和SendMe Mobile的开发，这样说：
规则#14：你计划使用什么软件方法论并不重要；你总是需要知道你试图设计的需求。
需求问题并不全在产品管理方面。编程团队和经理经常要求在开始编码之前将需求冻结和不可变。Mars Rover任务协作信息门户的中间件架构师Ron Mak分享了另一个需求真相——至少是基于客户输入的需求。
规则#15：迭代至关重要：客户在看到之前不知道他们想要什么。
更新一个非常古老的智慧金块，“证据就在布丁里”，我们每天都牢记杠杆软件CTO约瑟夫·克莱因施密特的经验法则：
规则#16：一开始，每个人都会谈论范围、预算和时间表，但最终，没有人真正关心这些事情。他们唯一关心的是：人们会喜欢你的软件，或者他们不会。所以这是你真正应该管理的唯一标准。
发展进程我们都见过流程太少和太多的组织。
•流程太少导致一事无成，因为克服混乱需要付出太多努力。
•太多的过程导致一事无成，因为需要付出太多的努力来克服这个过程。
我们都学会了在过程太少和太多之间保持平衡。
罗恩：长期以来，我一直称自己是“及时”和“刚刚好”过程的倡导者和实施者。然后，我的施瓦布同事约翰·斯蒂尔，当时是首席QA架构师，分享了他的QA规则之一：
规则17：尽可能少QA，不能少。
我很快意识到处理的适用性，我这样解释了规则：
规则#18：尽可能少地进行过程。
即使作为程序员，我们都从一开始就承担了责任，不仅要编码产品，还要确保它们运行良好。我们反对将“完成”定义为不满意（如果不是高兴）客户的心态，我们倾向于用客户满意度来表达。
那种心态并不总是能够被许多最初在孤立环境中编码的程序员所理解，在这些环境中，他们的最初职责非常有限，以至于他们从未看到他们的工作与客户之间的联系。有时，对于某些产品，让程序员在客户尝试（和失败）使用应用程序时监视他们，甚至让程序员观看此类客户体验的视频，这可能会有所帮助。
当面对客户同理心水平极低但从他人那里“获得”数字和实践的程序员时，我们求助于IneraCEO、转折点软件开发VPBruce Rosenblum的以下经验法则：
规则#19：优秀的开发人员每小时编码花费两个小时进行测试。
我们经常认识到需要在显眼位置张贴这条规则。
我们还牢记Joseph Kleinschmidt关于程序员和质量的另一个常用规则：
规则#20：您在项目的第一周要求的代码质量是您之后每周获得的代码质量。
管理自己最终，管理始于自己。你必须学习和实践时间管理、优先级管理、沟通管理、跟进管理等等。我们认为新经理最难学习的一课是这一课，Schwab罗恩的部门负责人、雅虎的执行VP大卫·迪布尔简洁地表达了这一点。
规则#21：不要让日常让你筋疲力尽。
他对自己的管理团队发表上述声明，强调管理者有“真正”的工作要做。鉴于看似紧急的事情——电子邮件、会议、办公室例行公事——很容易填满一天，只有有意识地利用我们的一天，我们管理者才能防止这种情况发生，并承担责任。只有管理好自己，我们才有希望成功地管理我们的责任。
总结我们收集的经验法则和智慧金块在多年的软件人员和团队管理中对我们有很大帮助。我们看到它们甚至让最老练的程序员感到失望。我们用它们来强调我们的观点，并平息程序员之间以及经验丰富的管理团队之间的激烈辩论。当使用得当时，几句话的经验法则可以比任何长时间的讨论都更有效地传达信息。我们希望我们在这里分享的规则能像对我们一样帮助您，使您能够更有效地管理软件人员和团队。
Mickey W. Mantle在Evans&Sutherland、Pixar、Broderbund和Gracenote等公司担任软件和硬件产品创建者、经理和高管已有40多年的软件开发经验。他目前开发移动/平板电脑应用程序、写作和咨询。
罗恩·利希蒂从事软件开发已有30年，其中大部分时间担任编程经理、开发总监以及苹果、富士通、Razorfish和施瓦布等公司的产品和工程副总裁。他之前写了四本书和数百篇文章。他为大大小小的初创企业和公司提供咨询，将混乱转化为清晰，并使他们的软件开发运转良好。
有关我们和我们的书的更多信息，请查看我们的管理难以管理的网站。
