# 02 干酪汉堡，做一个，卖一个 开发的本质完全迥异于生产。然而，开发管理者的思想却通常被生产环境衍生而来的管理哲学所左右。 假设你是一位本地快餐店的老板，那么采用如下任何一条或多条高效生产度量都是合情合理的： * 压缩出错率，让机器（“人”这台机器）能够尽量平稳地运转。 * 对工作上犯错的员工采取严厉手段。 * 把工人当成是机器上可替换的部件。 * 优化稳定状态。（根本不用考虑运行是怎样开始的，或者需要怎样去终止运行。） * 标准化流程，让一切有章可循。 * 消灭试验——总部那帮家伙就专门干这事儿。 在快餐行业（或者任何生产环境），这些都是司空见惯的合理手段，但对你来说不是。这种“干酪汉堡，做一个，卖一个”的思维观念在开发领域是致命的。这种做法只能让你的团队士气低落，让他们无法将精力集中到真正的问题上。这种管理风格与开发工作水火不容。 要管理脑力劳动者，你需要与前面走的路背道而驰。我们提出的相反做法会在下面几节详述。 ### 错误任所难免 对大多数脑力劳动者来说，工作偶尔出错再自然不过，也很健康，没什么危害。但总有些教条主义者会把工作中的错误和罪恶联系起来。我们需要采取措施去改变这种态度。 面对一群软件开发经理，我们介绍了一种迭代式设计的策略。这个想法是针对那些天生容易出错的设计的，我们应该彻底抛弃而不是去修复。这种设计活动上的死胡同是我们可以预期的，而为此付出的成本却微不足道，不过就是从头再来，轻装前进。令我们感到惊诧的是，许多管理者觉得这是给他们老板出了一道不可能解决的政治难题：“我们怎么能丢掉公司付钱生产的产品呢？”他们好像更相信我们应该补救这个有缺陷的版本，即使从长远来看，我们可能会付出更多。 营造一个不容许任何失误的氛围会让大家持有戒心。他们不愿去尝试那些有可能变坏的事情。当你试图体系化流程时，当你倾向于墨守成规时，你就在强化这种戒心，于是大家就会人为地被禁止做出关键的战略决策，因为他们害怕犯错。在不允许犯错的规定下，或许平均的技术水平会稳步提高，但团队的社会氛围却会遭受可悲的伤害。 相反的做法是鼓劢大家犯错。你可以不时问问大家遭遇了哪些死胡同，并明确地让大家明白：最佳答案并非是“没有”。当有人说了出来，应该祝贺他们——这是他们应得的。 ### 管理：傻瓜定义 管理的复杂度使得我们很难简单地定义它，但在伦敦的一次专业学术组织大会上，我们遇到的一位资深管理者让这些细微差异变得荡然无存。他用一句话总结了他对这个主题的观点：“管理就是踢屁股。”这等于说管理者负责全盘思考，而他的手下就照章办事。这种想法可能对于制作干酪汉堡会奏效，但在依靠脑力而非体力的环境中是没有用的。在这样的环境，每个人都要带着脑子工作。踢他们的屁股，可能会让大家行动起来，却不可能让他们去创新、创造以及思考。 即使向人们施压可以增加短期产出，长远来看还是无效的：对于所有工作者来说，若是因为他们感到动力不足而需要老板来“弥补”，没有什么比这更让人沮丧的了。 最可悲的是，这种管理手段几乎永远都会让生产过剩。你根本不需要使用严格的度量来促使大家工作——大部分人是热爱他们的工作的。你有时可能需要采取一些手段让大家少工作一会儿，这样就可以做一些更有意义的工作（更多想法参见第 3 章）。 ### 人力商店 在生产环境中，很容易将人当作是机器的零部件。部件磨损了，你可以换个新的。新的部件可以和原来的互换。你定的新部件，无论多少，都不过是数字而已。 很多开发经理持相同态度。他们竭力说服自己：没有人是不可替换的。正是因为他们害怕关键人物会离去，于是强迫自己相信没有所谓的关键人物。管理的本质不就是保证工作正常进行，而不用管个体的去留吗？他们的行为看起来就好像有这么一个奇妙的人力商店，只需拿起电话说：“给我派送一个全新的 George Gardenhyer 过来，但让他不要那么高傲。” 我的一位客户在对一名出色的员工进行薪资评估时，惊讶地发现这个员工想要的并不是涨薪。他说他在家时，常常会灵光一现，想起一些绝妙的主意，但糟糕的互联网连接却让他很是心烦。难道公司就不能帮他在家安装一条网线，再给他买台高性能的工作站吗？公司当然可以。在接下来的几年，公司甚至在这位员工家里帮他建立了一个小型办公室。当然，我这位客户的案例有些不同寻常。要是换做一位洞察力偏弱的管理者，他会怎么做呢？太多的管理者认为工作人员展现其个性是一种威胁。 -TRL 有这么一个案例。老板是一名洞察力不够强的管理者，他对员工的个性表现出极端的受威胁感：他有一位富有才华的员工常年在外到访客户现场，花销自然不少。通过对他报销的分析，显示他在食物上的花销远远超过了其他出差人员——他在食物上的花销超出其他人 50%。在一封愤怒的公开信中，这位老板给这名员工打上了“食物犯罪”的标签。而这位员工的总体花销没有超支，不管他在食物上有多少额外花销，他在其他方面节省了。这名员工并非花的更多，他只是与众不同。 对于盲目尊崇生产世界管理风格的管理者来说，员工的独特个性是一种持续的困扰。人性化的管理者却能认识到正是这种独特性使得项目团队产生了化学反应，是团队充满活力与高效的源泉。这是需要培养的。 ### 稳定的项目濒临死亡 稳定的生产思维对项目工作尤为有害。我们很容易忘记项目生命周期的最终目标就是要结束自己。一个项目唯一的稳定期就是将死之时。除非你正在一个被取消或将要取消的项目中，所有的项目管理关注点都应该投入到开发的动态调整上。然而在一个新项目中，我们衡量员工的价值却使用了稳定状态下的特征：他们写了多少代码或者产出了多少文档。我们对于每个员工在整个开发投入中的切合度关注甚少。 几年前，在我教授一堂企业内部设计课程时，一位高级管理者抓住我，要我评估课堂的学员（他顼目上的员工）。他对一位女士尤为好奇，毫不掩饰对她的质疑：“我看不见她给项目带来的贡献，她不是一个好的开发人员或测试人员，或者任何其他专业人员。”在做了一些调查后，我发现了一个引人注目的事实：在她 12 年的公司生涯中，她所在的项目没有一个不是获得巨大成功的。她的贡献不是很明显，但她所在的项目总是成功了。在课堂观察了她一周，并与她的同事交流过后，我得出一个结论：她就是一个超级催化剂。她的存在使得团队内部更有黏度。她帮助团队成员互相交流和相处，有她的项目会变得更加有趣。当我试图向那位管理者阐述这一理念时，我被震惊了：他居然不知道催化剂这个角色在一个项目中的重要性。 -TDM 催化剂很重要，因为项目总是处于不断变化的状态。一个能够让项目更稳定的人抵得上两个做事的人。 ### 我们只是做事，没时间考虑工作自身 如果分配给你一个任务，你会花多少时间来真正实施这项任务？不可能百分之百。实施之前肯定需要做一些头脑风暴，调研新方法，找到规避一些子任务的方法，阅读相关材料，培训，还有试错。 回首我们作为管理者的那些年，我们都没有正确地认识到这一点。我们都花了太多时间去做事，却没有花足够的时间提出关键问题，“这件事到底该不该做？”稳定阶段的干酪汉堡心态使得我们根本没有去思考这项工作。这种心态会推着我们把百分百的投入放到实施状态。倘若真要为没有思考时间寻找借口，那么这个借口永远都是时间压力——就好像还有什么工作可以在没有时间压力的情况下完成似的。 随着更多利益的介入，思考方法的重要性也显著提高。正所谓“磨刀不误砍柴工”，我们必须学习如何多花时间在思考上，少花时间在实施上。项目需要的投入越夸张，成员就越应该学习如何更好地协作，对这份工作的热爱也会变得更重要。项目越是需要在一个无法完成的固定时间交付，项目团队就越不能缺乏频繁的头脑风暴，或者项目组聚餐之类的活动来帮助团队形成一个统一的整体。 但是，这些都是人文关怀。每个人都知道怎么做，对吗？错。在做事情上我们都是如此的一根筋。我们花费不到 5%的时间在计划、新方法调研、培训、读书、评估、预算、排期、人员安排这一系列活动上：（5%这个数字来自于对系统开发项目的分析，但这个数字涉及的范围应该更广，可能涵盖了所有拿薪水的工作者。） 关于读书的统计结果让人尤为失塑：以软件开发人员的平均水平为例，平均每人没有一本和工作相关的书，甚至没有阅读过一本相关书籍。这种现状让每一个重视质量的人心怀忧虑。对我们这些写书的人来说，简直就是一场悲剧。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-yi-bu-fen-guan-li-ren-li-zi-yuan/02-gan-lao-han-bao-zuo-yi-ge-mai-yi-ge.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.