作为管理者，我们多数人很容易陷入一种典型的失败情境：习惯把人当作固定的模块来管理。当然，这种惯性来源显而易见。回顾我们在走上管理岗位之前所做的准备：我们之所以被认为具备管理者的素质，是因为作为办事员、技术员或开发者的我们所表现出来的良好绩效。这样的绩效得益于我们能够将资源划分为模块，例如软件的过程、电路板或其他工作单元。我们用黑盒的特性来构建这些模块，从而达到屏蔽模块内部特性的目的。设计这些模块，使得它们可以通过标准接口来使用。由于长年累月对模块化方法的依赖，新晋的管理者很少会怀疑是否能沿用同样的方法对人力资源进行管理。很不幸，这常常并不奏效。 在第一部分，我们一起来探索一种迥然不同的思考人及管理人的办法。这种办法考虑的是怎样去适应人的“非模块化”特征。 干酪汉堡，做一个，卖一个开发的本质完全迥异于生产。然而，开发管理者的思想却通常被生产环境衍生而来的管理哲学所左右。 假设你是一位本地快餐店的老板，那么采用如下任何一条或多条高效生产度量都是合情合理的：
在快餐行业（或者任何生产环境），这些都是司空见惯的合理手段，但对你来说不是。这种“干酪汉堡，做一个，卖一个”的思维观念在开发领域是致命的。这种做法只能让你的团队士气低落，让他们无法将精力集中到真正的问题上。这种管理风格与开发工作水火不容。 要管理脑力劳动者，你需要与前面走的路背道而驰。我们提出的相反做法会在下面几节详述。 错误在所难免对于大多数脑力劳动者来说，工作偶尔出错再自然不过，也很健康，没什么危害。但总有些教条主义者会把工作中的错误和罪恶联系起来。我们需要采取措施去改变这种态度。 面对一群软件开发经理，我们介绍了一种迭代式设计的策略。这个想法是针对那些天生容易出错的设计的，我们应该彻底抛弃而不是去修复。这种设计活动上的死胡同是我们可以预期的，而为此付出的成本却微不足道，不过就是从头再来，轻装前进。令我们感到惊诧的是， 许多管理者觉得这是给他们老板出了一道不可能解决的政治难题：“我们怎么能丢掉公司付钱生产的产品呢？”他们好像更相信我们应该补救这个有缺陷的版本，即使从长远来看，我们可能会付出更多。 营造一个不容许任何失误的氛围会让大家持有戒心。他们不愿去尝试那些有可能变坏的事情。当你试图体系化流程时，当你倾向于墨守成规时，你就在强化这种戒心，于是大家就会人为地被禁止做出关键的战略决策，因为他们害怕犯错。在不允许犯错的规定下，或许平均的技术水平会稳步提高，但团队的社会氛围却会遭受可悲的伤害。 相反的做法是鼓励大家犯错。你可以不时问问大家遭遇了哪些死胡同，并明确地让大家明白：最佳答案并非是“没有”。当有人说了出来，应该祝贺他们 —— 这是他们应得的。 管理：傻瓜定义管理的复杂度使得我们很难简单地定义它，但在伦敦的一次专业学术组织大会上，我们遇到的一位资深管理者让这些细微差异变得荡然无存。他用一句话总结了他对这个主题的观点：“管理就是踢屁股。”这等于说管理者负责全盘思考，而他的手下就照章办事。这种想法可能对于制作干酪汉堡会奏效，但在依靠脑力而非体力的环境中是没有用的。在这样的环境，每个人都要带着脑子工作。踢他们的屁股，可能会让大家行动起来，却不可能让他们去创新、创造以及思考。 即使向人们施压可以增加短期产出，长远来看还是无效的：对于所有工作者来说，若是因为他们感到动力不足而需要老板来“弥补”，没有什么比这更让人沮丧的了。 最可悲的是，这种管理手段几乎永远都会让生产过剩。你根本不需要使用严格的度量来促使大家工作——大部分人是热爱他们的工作的。你有时可能需要采取一些手段让大家少工作一会儿，这样就可以做一些更有意义的工作（更多想法参见第3章）。 稳定的项目濒临死亡稳定的生产思维对项目工作尤为有害。我们很容易忘记项目生命周期的最终目标就是要结束自己。一个项目唯一的稳定期就是将死之时。除非你正在一个被取消或将要取消的项目中，所有的项目管理关注点都应该投入到开发的动态调整上。然而在一个新项目中，我们衡量员工的价值却使用了稳定状态下的特征：他们写了多少代码或者产出了多少文档。我们对于每个员工在整个开发投入中的切合度关注甚少。 几年前，在我教授一堂企业内部设计课程时，一位高级管理者抓住我，要我评估课堂的学员（他项目上的员工）。他对一位女士尤为好奇，毫不掩饰对她的质疑：“我看不见她给项目带来的贡献，她不是一个好的开发人员或测试人员，或者任何其他专业人员。”在做了一些调查后，我发现了一个引人注目的事实：在她12年的公司生涯中，她所在的项目没有一个不是获得巨大成功的。她的贡献不是很明显，但她所在的项目总是成功了。在课堂观察了她一周，并与她的同事交流过后，我得出一个结论：她就是一个超级催化剂。她的存在使得团队内部更有黏度。她帮助团队成员互相交流和相处，有她的项目会变得更加有趣。当我试图向那位管理者阐述这一理念时，我被震惊了：他居然不知道催化剂这个角色在一个项目中的重要性。 催化剂很重要，因为项目总是处于不断变化的状态。一个能够让项目更稳定的人抵得上两个做事的人。 我们只是做事，没时间考虑工作自身如果分配给你一个任务，你会花多少时间来真正实施这项任务？不可能百分之百。实施之前肯定需要做一些头脑风暴，调研新方法，找到规避一些子任务的方法，阅读相关材料，培训，还有试错。 回首我们作为管理者的那些年，我们都没有正确地认识到这一点。我们都花了太多时间去做事，却没有花足够的时间提出关键问题，“这件事到底该不该做？”稳定阶段的干酪汉堡心态使得我们根本没有去思考这项工作。这种心态会推着我们把百分百的投入放到实施状态。倘若真要为没有思考时间寻找借口，那么这个借口永远都是时间压力——就好像还有什么工作可以在没有时间压力的情况下完成似的。 随着更多利益的介入，思考方法的重要性也显著提高。正所谓“磨刀不误砍柴工”，我们必须学习如何多花时间在思考上，少花时间在实施上。项目需要的投入越夸张，成员就越应该学习如何更好地协作，对这份工作的热爱也会变得更重要。项目越是需要在一个无法完成的固定时间交付，项目团队就越不能缺乏频繁的头脑风暴，或者项目组聚餐之类的活动来帮助团队形成一个统一的整体。 但是，这些都是人文关怀。每个人都知道怎么做，对吗？错。在做事情上我们都是如此的一根筋。我们花费不到5%的时间在计划、新方法调研、培训、读书、评估、预算、排期、人员安排这一系列活动上。（5%这个数字来自于对系统开发项目的分析，但这个数字涉及的范围应该更广，可能涵盖了所有拿薪水的工作者。） 关于读书的统计结果让人尤为失望：以软件开发人员的平均水平为例，平均每人没有一本和工作相关的书，甚至没有阅读过一本相关书籍。这种现状让每一个重视质量的人心怀忧虑。对我们这些写书的人来说，简直就是一场悲剧。 质量——如果时间允许20世纪的心理学理论指出，人类的特征被一系列基本天性控制：生存、繁衍、领地等。这些都是直接植入我们脑子里的。你可以不带任何情绪理性地分析这些本能（正是你现在做的），但当你感知到它们的时候，总是会带有浓厚的感情色彩。即使对于这些内在的价值观仅有一点小的挑战也会让人感觉失望。 任何强烈的情绪表达都显示了大脑中的原始价值观受到了威胁。一个新手管理者也许会相信工作可以在不掺杂个人情绪的情况下完成，但只要管理者具备一点点经验，就会知道事与愿违。我们的工作给了我们表达自己情绪的很多机会。 你想想，总有一次某人的情绪完全因为工作相关的事情而被煽动起来。好好思考这件事，然后反问自己（可能是第n次了），情绪从何而来？若对这件事的背景一无所知，我打赌，它一定是威胁自信的一大成因。在个人生活中，造成情绪化反应的因素可能很多，然而在工作环境中，主要的导火索就是对自信的威胁。 我们通常倾向于将我们的自信与生产出的产品质量（并非产品数量）紧紧关联。（因为某些原因，生产出大量质量马虎的产品带来的满足感很小，尽管在某些情况下需要这么做。）采取任何可能牺牲产品质量的行动都可能挑起员工反对你的情绪。 飞离卓越的航班管理人员设定的不可达到的期限威胁着产品的质量，但他们不会这样去思考这一问题——他们自认为给了团队一个有趣的挑战，可以激发他们去追求卓越。 有经验的员工（老油条）却不这么想。他们知道，在枪口下，他们的任何努力都是受到约束的。不能自由调配资源，以满足准时交付的要求。要想增加更多的人，或者减少功能？没门！只有质量是可以降低标准的。当员工处于极度的时间压力之下时，质量就开始被牺牲了。他们会把问题藏到脚垫下面，或者直接扔给产品的最终用户。他们交付的产品是不稳定、不完整的。他们会讨厌自己做的事情，但能有什么选择呢？ 一些死板现实的管理者会这样回答上述问题：“我们一些同志会为了‘质量’在一个任务上无休无止，但市场才不管你啥质量呢——昨天就赶着要这个产品了，即使质量粗糙也行。”多数情况下，你对市场的判断或许正确，但通过施压让大家制造出达不到自己质量标准的产品终归是错误的。 我们这些管理者总是认为质量只是产品的另外一个特性，可以视市场的需求而调整。就像你涂在自制蛋糕上的巧克力酱：想要多点就多涂点，想要少点就少涂点。 然而，产品制造者对待质量却完全不同。因为他们的自信来自于产品质量，所以会有自己的一套质量标准。对他们而言，要让自己满意，最低标准就是要达到过去做到的最好质量。这当然要比市场要求并愿意为之付出的标准更高。 质量，远远不只是最终用户的要求，而是达到高产能的一种方法。 如果你对这点有疑问，想象一下下面的试验：到大街上随便找100个人，问他们认为谁是以高质量著称的组织、文化或者国家。估计一半的人会告诉你是“日本”。我们再问另外100个人：什么组织、文化或者国家以高效能著称？同样，大多数人还是会说“日本”。这个国家在作为质量领袖的同时，也以高产能著称。 等等，高质量怎么可能和高产能并存呢？按常规理论，若要提高产品质量，就必然需要在生产过程中花费更多。为了找到答案，让我们一起来看看两位最受尊敬的评论家田岛（Tajima）和松原（Matsubara）对日本现象的解释： 价格和质量的对立在日本并不存在；相反，高质量带来成本的降低却是被广泛接受的想法。 质量是免费的，但是……很早之前，惠普就被认为是一个通过制造者自定义高质量标准而提升生产效率获益的典型组织了。从一开始，惠普就信奉质量。在这种环境下，需要更多时间或资金来生产高质量产品的说法压根儿就没有出现过。因此，开发人员形成的文化是交付的质量要超越市场的质量要求。他们追求质量的标志成为提高他们工作满意度的动因，从而拥有行业内最低的人员流失率。 再谈帕金森定律英国作家诺斯古德·帕金森（C. Northcote Parkinson）于1954年引入了一个概念，认为工作会自动膨胀，占满一个人可以用的所有时间，这被称为帕金森定律。 倘若你不知道其实很少有管理者接受过管理方面的正规培训，你可能会错以为他们都是科班出身，在学校就学过帕金森定律及其分支理论。即使管理者对管理一无所知，他们也极为认同帕金森定律这一针对员工及其态度进行管理的公理。定律为他们提供了强有力的证据，只有设定不可能完成的交付日期，才能保证工作的完成。 帕金森定律和牛顿定律生命苦短，不能在工作中虚度光阴。只要大家热爱工作，就不可能让一项工作变得遥遥无绝期——这会推迟获得他们向往的满足感。在不需要降低标准、牺牲质量的时候，他们和你一样，期望工作能快点完成。 如果经历了我们的见闻，你就不会这样说了每一位管理者在职业生涯中一定会遇到一个员工不想工作，或者完全达不到质量标准，又或者无法完成工作。对此，帕金森定律管用吗？ 在一个健康的工作环境里，要是某人表现欠佳，可能是因为能力不足、缺乏自信，或者无法理解项目中别人的想法和项目目标。通过增加进度压力无助于解决上述问题。一旦某位员工表现出工作低效，对工作质量漠不关心，就是发出了明确的信号，说明这个可怜的家伙快被工作困难给压垮了。他需要的不是更多的压力，而是调换工作，或者跳槽到另一家公司。 即使在极端情况下，依靠某人是唯一的出路，管理者也应该将此作为最后的选择。团队发出的声音会更好。我们见证了一些良好团队的管理者和大家站在一起，共同批评那些不与别人协作的员工。 在随后的几章中，我们会就团队以及怎样促进团队良好的化学反应展开讨论。这里，我们不会讨论什么方法有效，而是讨论什么方法无效：把你的团队成员当做帕金森型的员工是不可能奏效的。这只能消磨他们的意志，让他们失去前进的动力。 作者简介： Tom DeMarco和Timothy Lister是The Atlantic Systems Guild公司（www.systemsguild.com）的首席咨询师。该公司主要提供高复杂度组织结构方面的咨询业务，并且特别关注人在整个组织结构中的重要性。自1979年以来，他们俩共同在全球范围内就管理、评估、效率及企业文化发表了一系列演讲，撰写了大量文章，也为很多企业提供了咨询服务。
Tom
DeMarco
译者简介： 肖然，在从事了多年计算机算法及复杂度研究后，肖然决定尝试变理论为实践，于是开始了软件工程之旅。2006年和开发团队一起第一次运用Scrum，并开始尝试XP的很多技术实践。2008年加入ThoughtWorks中国后，他有幸在不同交付项目上系统地学习、运用敏捷的各种实践，并有机会在这个过程中和业内很多思想家探讨了软件开发的各种挑战。在最近两年的工作中，肖然尝试将敏捷、精益思想引入企业管理及组织创新过程中，和组织一起梳理、制定目标，并规划迭代的实施方案。 张逸，软件开发生涯经历了从程序员、项目经理、测试经理、开发部长、技术总监到架构师的一个循环，现在幸福地回到程序员的起点。热爱文学、热爱技术，文理兼修，可惜都不精通。现为ThoughtWorks咨询师、程序员。居住在成都，最向往的大约就是在阳光下安静悠闲地品读自己喜爱的图书了。管理上，正大力推进敏捷与精益在软件开发过程中的实践与转型；技术上，热衷于在传统设计领域中引入函数式设计思想。著译包括《软件设计精要与模式》、《WCF编程》、《Java设计模式》和《恰如其分的软件架构》。
滕云，一个半路出家的程序员；一个军事武器狂热分子；一个并不合格的古典音乐爱好者；一个拙劣的填词人。平时喜欢踢踢足球、吹吹口琴、练练书法等。目前主要从事金融和保险领域的企业级软件开发，主要感兴趣的技术领域包括Java EE、Linux、领域驱动设计和持续交付等。他的译著有《实现领域驱动设计》。 本文节选自《人件（原书第3版）》第一部分，机械工业出版社华章公司，2014年8月出版。 |
|
|
