汤姆·迪马可（Tom DeMarco）是大西洋系统行会（www.atlsysguild.com）的负责人之一，同时他也是多塞特家族出版社的三本畅销书（《人件》，与蒂姆·利斯特合著的《软件艺术的状态》（Software State-of-the-Art），以及《为何软件开销那么大？》（Why Does Software Cost So Much?）和一套基础培训录像（与蒂姆·利斯特合作的《高产团队》）的作者。
Tom DeMarco本书用一个虚构的故事阐述了真实世界中关于项目管理的一般问题，以鲜活的文字和曲折的情节改变了项目管理书籍枯燥乏味的一贯形象，让你在享受阅读快乐的同时受益匪浅，对项目管理的重要原则终生难忘。书中很多章都以汤普金斯先生的日记作为结尾，其中记录了他日常收集的经验，掌握了这些经验，你一定也可以成为一名优秀的项目经理。
汤姆·迪马可（Tom DeMarco）生于1940年8月20日，美国宾州Hazleton市。在Cornell大学或电子工程学位，在Columbia大学获得硕士学位。并拥有巴黎Sorbonne大学的学位。
DeMarco最初在Bell电话实验室参与1ESS项目，研究第一部电子模拟电话交换机。曾担任法国的实时项目La CEGOS Informatique，曾负责瑞典、荷兰、法国和芬兰的在线银行系统项目。
DeMarco是亚马逊网上书店、巴诺书店最佳畅销书《最后期限》的作者，也是计算机咨询组织－－大西洋系统行会（www.atlsysguild.com）的负责人之一，同时他也是多塞特家族出版社的三本畅销书（《人件》（将于今年4月在清华大学出版社引进出版），与蒂姆·利斯特合著的《软件艺术的状态》（Software State-of-the-Art），以及《为何软件开销那么大？》 （Why Does Software Cost So Much?）和一套基础培训录像（与蒂姆·利斯特合作的《高产团队》）的作者。
个人简介编辑本段回目录
Tom DeMarco (born 20 Aug. 1940 Pennsylvania, USA) is an US-American software engineer, author, teacher and speaker on software engineering topics.[1] He is known as one of the developers of Structured analysis in the 1980s.
Tom DeMarcoTom DeMarco received a BSEE degree in Electrical Engineering from Cornell University, a M.S. from Columbia University and a diplôme from the University of Paris at the Sorbonne.[2]
DeMarco began at Bell Telephone Laboratories in 1963 where he served as part of the now-legendary ESS-1 project. This was a hardware and software endeavor to develop the world’s first commercial stored program telephone switch, now installed in telephone offices all over the world.[3] In later years, he managed real-time projects for La CEGOS Informatique in France, a French consulting firm that had a contract to build a computerized conveyor system for the new merchandise mart at La Villette in Paris. From 1971 to 1975 he was involved in building on-line banking systems in Sweden, Holland, France and finally New York. In the 1980s with Tim Lister he founded the Firm 'The Atlantic Systems Guild'. They shared offices with Dorset House, a small publisher that also spun off from Yourdon Inc. The company developed into a New York- and London-based consulting company specializing in methods and management of software development.
He has lectured and consulted throughout the Americas, Europe, Africa, Australia and the Far East.[4]
He is a member of the ACM and a Fellow of the IEEE. He lives in Camden, Maine, and is presently both a principal of The Atlantic Systems Guild, and a fellow and Senior Consultant of the Cutter Consortium.[2] DeMarco was the 1986 recipient of the Warnier Prize for "lifetime contribution to the field of computing", and the 1999 recipient of the Stevens Award for "contribution to the methods of software development".[2]
In his spare time, he is an Emergency Medical Technician, certified by his home state and by the National Registry of EMTs, and a founding member of The Penobscot Compact, a business-education partnership operating under the auspices of the Maine State Aspirations Program.
著作一览表编辑本段回目录
DeMarco has authored over nine books and 100 papers on project management and software development. A selection:[9]
1979. Structured Analysis and System Specification. Prentice Hall, ISBN 0138543801
1986. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall, ISBN 0131717111
1987. Peopleware : Productive Projects and Teams
1997. The Deadline: A Novel About Project Management. Dorset House.
2001. Slack, Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
2003. Waltzing with Bears: Managing Risk on Software Projects. With Tim Lister. Dorset House in March, 2003.
2008. Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. With Peter Hruschka, Tim Lister, Suzanne Robertson, James Robertson, Steve McMenamin. ISBN 978-0932633675
关注程序员自己的文化——专访Tom DeMarco编辑本段回目录
在程序设计的几十年历史中，Tom DeMarco是一个应该被铭记的名字。在2003年第2期《程序员》杂志的“名人堂”，我们已经介绍过DeMarco先生的经历和成就。最近，《程序员》记者通过电子邮件对这位软件开发的“泰山北斗”进行了采访。在采访中，DeMarco先生透露出他对软件开发的一些深入认识和想法。
Tom DeMarco关注软件中“人”的问题
《程序员》（下文简称《程》）：DeMarco先生，您好。最近，您的两本书——《最后期限》和《人件》在中国开发者中间引起了不小的反响。请问您本人如何看待这两本书？
Tom DeMarco（下文简称TDM）：噢，你很了解我的书的……这两本书代表了我最近一段时间的主要思想。我希望所有的读者——包括程序员、经理、客户以及所有与软件开发有关的人——重新关注软件开发中“人”的问题。我希望看到一种人本主义的回归，就像文艺复兴那样。
我相信中国读者很聪明，他们一定注意到了我故意在书中使用的轻松气氛，还有那种像推销员一样的夸张口吻。你知道，对于程序员的工作环境，老板们是有决定权的。可是，老板们只读这种口吻轻松随意的书。我也是不得以而为之。
《程》:不管是否喜欢您的书和赞同您的观点，读者们的确关心您的思想，并打算向您学习。
TDM：不谦虚地说，我想我是值得他们学习的。你看，一个六十多岁的老头，他和Dijkstra共过事，他参加了1968年NATO会议，他开发各种程序几十年，他从结构化走到面向对象……我的经验应该会对年轻人们有所帮助。这也是我写书、做培训的原因。
一点点运气都是成功的必要因素
《程》:我记得您的乐观态度。如果没有天降神兵般的帮助，如果没有那么好的运气，《最后期限》中的汤普金斯先生恐怕早就被吊死在摩罗维亚的肉钩子上了。但是，作为一个普通的软件开发者，我们怎么可能期望得到那么多的好运气呢？
TDM：不管怎么说，我们必须承认，在任何有风险的工作中，一点点运气都是成功的必要因素。软件开发当然也不例外。
《程》:但是，如果没有这些好运气，我们的项目难道不就变成一场死亡之旅吗？
TDM：优秀的经理能够让好运气降临到自己身上。比如说，当汤普金斯先生第一次见到贝琳达时，他就敏感地知道：她将成为项目组的一大财富。当时，就连贝琳达自己都还不敢肯定自己的能力呢。还有，你说的“天降神兵”中，很多人都是汤普金斯先生以前就认识的，他只是知道应该在什么时候向什么人求助而已。而且，他有一种独特的人格魅力，让那些初次见面的人也乐于和他交心，愿意帮他解决困难。所以，你说汤普金斯先生的成功是因为运气，我却说在很大程度上那是因为他的能力——知道应该选择哪些人，知道如何让这些人为自己拼命工作，这是一个管理者最重要的能力，对不对？
人与管理的简议
《程》:您在书中说，管理就是“找到合适的人，并保持这些人斗志高昂”，现在您又说汤普金斯先生的成功是因为那些难以捉摸的能力。您是否认为，只要找到合适的人，一切工作都可以顺风顺水？或者，我们是否需要再做些其他的工作来保证这一点？如果是，我们应该做什么？
TDM：“选择什么人”和“如何使用他们”，这就是最重要的事。然后，第二重要就是富有个人魅力的管理。所有其他的东西（过程、工具……）都只能起到一定的边界效应，但无法起到关键性的作用。
《程》:可是，这两种最重要的能力都显得很神秘，不是吗？我们要如何去学习它们呢？
TDM：我就知道你会提这个问题。没错，它们就是很神秘的能力，有些人天生就是优秀的管理者，有些人永远都没有这方面的能力。我有没有说过“它们是优秀管理者必须的能力”？啊，这是我的表达不够准确了。这其实是一个达尔文主义的问题：只有具有这些能力的管理者才可能一次次地带领项目走向成功，并被人们评价为“优秀的管理者”。
你说对了，很大程度上这些能力是无法学习的。但是，认识到它们的重要性仍然对我们很有帮助。首先，一些管理者可以清楚认识到自己缺乏管理的天赋；然后，他们可以去找一个真正优秀的管理者来帮助自己。知道自己无知，总比无知而不自知要来得好。
Tom DeMarco著作《程》:我们一直认为自己是科技工作者，但您却用这种近乎神秘的方式来解释我们的工作……
TDM：你说对了，我们是科技工作者，我们相信科学。什么是科学？就是知道某些事情的解决办法，也知道另一些事情不可能解决，还知道有些事情能够解决、但无法找出解决的办法。既然你相信科学，就不应该想着给所有问题找一个“科学的”解释。
而且，软件是一门实践的科学。我们不需要像证明费马大定理那样用三百多年的时间来证明某个办法有效，我们只是让各种不同的办法接受残酷的生存竞争。所以，教条主义是软件科学中最不可取的。
CMM，一种过时的东西
《程》:我想知道您对CMM的态度。您认为CMM对哪些企业会有帮助？又会有哪些副作用？
TDM：帮助？CMM？对于如今的软件企业，CMM有百害而无一利。
《程》:我记得您曾经说过，在长期说来，CMM有助于提高生产率，只是在短期内会造成阻碍。
TDM：你记错了，我说的是“过程改进”，不是CMM。你知道吗，CMM已经有超过20年的历史，它的成功经验都是在1985年前获得的。CMM试图将一个固定的模型强加于一个日新月异的行业之上，它鼓励你效仿IBM在1970年代所采用的软件开发方式。僵化，不敢面对变化，这是如今的软件业最忌讳的。所以我要说，对于绝大多数的软件开发，CMM毫无帮助。
当然，一定的过程是有必要的。但是，在这个变化的时代里，过程也必须拥抱变化，否则就不是好的过程。你一定还记得，CMM2级的特征是“可重复”，我认为这根本就是一个悖论：我们的每个项目都完全不同，我们的开发环境每年都在更新，如何去寻求一个“可重复”的过程呢？你看，所有伟大的软件企业，有哪一家做的事情是“可重复”的呢？
《程》:可是有那么多人、那么多企业热衷于CMM呢。
TDM：他们根本就是无可适从——他们无法适应变化，他们无法在这种全新的环境中找到自己的位置，所以他们总得给自己找点什么东西来信仰。William Clifford曾经说过，人们常常会根据自己的愿望而虔诚地相信一些东西，但愿望的强烈并不能使信仰变得可靠。
不过，对于只做外包项目的企业（例如很多印度软件公司）来说，CMM倒是一个不错的能力衡量标准。只有对于这种不需要动脑筋、不需要创新的企业，CMM才有意义。如果让我来评价，我会认为CMM是软件企业的耻辱符：等级越高，说明企业越缺乏创造力。
Tom DeMarco著作让员工偷一点懒吧
《程》:我注意到您最近出了一本新书Slack，这个书名很是有趣，能不能请您简单介绍一下这本书？
TDM：其实这本书原来的名字叫《敏捷企业的秘密》（Secrets of the Agile Organization）。在我看来，要让企业具有适应新世纪、新经济所必须的敏捷性，需要做四件事：1）给员工一点点偷懒的时间；2）帮助员工减轻压力；3）注重对员工培养的投资；4）评估风险、控制风险。
《程》:难道偷懒也能帮助提高生产率吗？这不是违反直觉的吗？
TDM：对呀，你应该让员工每周七天、每天十二小时地拼命工作，这样效率最高了——如果他们的工作是搬砖头的话。
你必须首先搞清楚，要让你的员工为你贡献什么，然后再决定如何安排他们的工作。对于软件开发者，我们需要他们贡献的是创造力，是他们的点子，是他们的聪明才智，所以，我们必须让他们常常放松，有自由思考的时间，这样他们才能把自己的才华发挥出来。
软件本质
《程》:Fred Brooks说过，软件中的关键问题导致“没有银弹”。但是，难道每种软件的关键问题都是一样的吗？比如说操作系统和ERP系统。
TDM：Brooks说，软件的关键问题就是“找出需要做什么”，而“怎么做”则是次要问题——所有的技术、工具和过程解决的都是这个次要问题。我完全同意他的观点。在“怎么做”的问题上，我们取得了极大的进展；但是，在“做什么”的问题上，几十年来情况似乎并没有太大的改善。我想，这是由于软件的本质造成的。
《程》:那么，什么是软件的本质呢？
TDM：我们的世界是模糊的、连续的、不精确的，但软件是精确的、离散的、形式化的，这就注定了软件不能完全描述现实世界。因此，我们需要知道描述哪些部分、忽略哪些部分，这就是软件的本质问题。显然，这是一件机器无法完成的工作，软件的本质意味着开发人员的存在意义。
《程》:您认为对软件业最好的比喻是什么？是工程学？是艺术？还是工艺学？
TDM：都是，但又都不准确。软件中有工程学的成分，有工艺学的成分，也有艺术的成分，所以它才如此复杂。
在过去的几十年中，我们在“软件工程”这条路上做了大量探索，并且取得了极其可观的成果（很荣幸我在其中也做了一些贡献）。但是，现在看来，边际效用递减律正在起作用，对软件工程进行更多的探索所能收到的效果正在变得越来越少。所以，我认为应该去考虑另一些以前很少考虑的问题。比如如何营造良好的工作环境，如何将新手培养成熟练的开发者……以前很少有人系统地考虑这些问题，所以如果在这上面投入努力也许能获得更大的效果。
眼中有英雄
Tom DeMarco《程》:最近Bill Gates来了中国，引起了整个中国IT业界的轰动。您如何看待Gates先生和他的微软帝国？
TDM：噢，我可是Gates和微软的崇拜者。现在，全世界的人都在使用计算机，微软在其中起到的作用胜过其他任何一家公司。而且，Gates本人很有意思：他有一个天才的头脑，总有精彩的点子；同时他又是一个优秀的商人，知道如何用自己的点子去挣钱。你也看到了，在《最后期限》中，我用Gates的形象刻画了摩罗维亚的国家元首。我想，这是我能对Gates表示的最大尊敬吧——不过，像Gates那样挥霍建豪宅，我也是反对的。这大概是老头的毛病吧。
说实话，如果说有一家公司是我心目中的理想企业，那就是微软。有很多人试图找出微软成功的秘密，可是他们常常去关注微软的开发过程。其实，微软的开发过程有什么可研究的呢？他们有全世界最优秀的员工，这些人享受着全世界最舒服的工作环境，不管用什么过程，我相信他们都能取得这些成就。其实，微软最值得研究的也是这两个问题：如何得到优秀的员工；如何让员工尽量发挥自己的能力。
《程》:您大概也知道，很多人抨击Gates和微软，说他们贪得无厌，说他们垄断……
TDM：贪得无厌？哈哈，这大概是对一个商人最好的称赞吧？至于垄断嘛……你还记得IBM垄断案吗？1969年，美国司法部控诉IBM垄断了个人计算机市场，而且用各种手段阻止其他公司的竞争——他们的手段可比微软厉害得多呢。IBM是怎么说的？他们说自己预见到计算机革命的巨大潜力，并通过自己“高超的技术、远见和产业”来统治该行业。政府最终在1982年撤消了对IBM的控诉，理由就是“计算机产业的本质决定了它是充满风险和竞争的”。像这样一个充满风险和变化的产业，如果微软真的像他们说的那样垄断长达十多年之久，那我就更要崇拜Gates和他的微软了。
《程》:除了Gates先生，您认为哪些人称得上是程序员中的英雄？
TDM：我尊敬的英雄有Barry Boehm、Victor Basili、Bob Glass、Ed Yourdon、Ken Orr、Fred Brooks、Capers Jones、Tim Lister，还有苹果公司的Sheila Brady。你看，他们曾经有过辉煌的成就；他们关注程序员群体的利益；他们不断探索新知，并把自己的知识和经验传递给新一代的程序员；他们不关心那些流言蜚语，也不热衷于哗众取宠，他们只关心如何帮助程序员更好地成长、如何让程序员能够不断进步。只有这样的人，才配得上“英雄”的称号。
关注程序员自己的文化
《程》:最后，按照我们的惯例，请您对中国程序员说一句最想说的话吧。
TDM：文化。只有拥有了共同的文化，同样职业的一群人才能成为一个社会群体，才能得到整个社会的重视，否则他们就只是恰好有些共同之处的乌合之众。工人、农民、商人……甚至连流浪汉都有自己的文化。软件开发者也应该努力营造并维护自己的文化，而我写的一些书也是在为这种程序员文化尽绵薄之力。
这就是我想说的：在技术之外，请关注程序员自己的文化。
最后期限(Tom DeMarco) 汤普金斯先生的日记本编辑本段回目录
优秀管理的四大要素
Tom DeMarco 选择正确的人。
为他们分配正确的工作。
保持他们的积极性。
帮助团队凝聚起来并保持团队的凝聚力。
其它一切都只是“文案”。
安全和变化
除非感到安全，否则人们就不能去迎接变化。
在所有成功的工程中（以及在绝大多数其他有价值的工作中），变化都是基本的要素之一。
安全感的缺乏会让人们反对变化。
逃避风险是致命的，因为这会让你也得不到与风险同在的利益。
人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感，但是如果察觉到管理者可能滥用权力来惩罚自己，他们也会觉得没有安全感。
负面效应
威胁不是提高业绩最好的方法。
如果分配的时间一开始就不够，不管威胁有多么吓人，工作也无法按时完成。
更糟糕的是，如果目标没有实现，你就必须兑现你的威胁。
管理者必需的身体部位
管理涉及到心、肠胃、灵魂和鼻子。
因此……
用心来领导，
相信你的肠胃（相信你的预感），
构筑团队的灵魂，
训练一个能嗅出谎言的鼻子
用指挥战争来作为管理的一个比喻
在战役开始的时候，管理者真正的工作已经完成了。
Tom DeMarco面试和招聘
招聘涉及到所有与管理相关的身体部位：心、灵魂、鼻子和肠胃（但是主要是肠胃）。
不要试图单独去招聘——两副肠胃远比一副肠胃的两倍要好。
对于新的雇员，让他们承担与以前曾经成功过的同样难度的项目，把有挑战性的目标推迟到一下次。
证求提示：你最希望雇的那个人可能还知道其他很好的人选。
多听，少说。
生产力的提高
没有“短期生产力提高”这样的东西。
生产力的提高是来自长期投资的。
任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油
风险控制
通过控制风险来管理项目。
为每个项目创建并维护风险统计表。
跟踪根源性的风险，而不只是最后那讨厌的结果。
评估每种风险具体化的概率和可能造成的开销。
对于每种风险，预测标志其具体化的早期征兆。
任命一个风险控制官，这个人不应该维护组织内部“我能行”的态度。
建立简单的（可能是匿名的）通道，让坏消息能传递到高层。
防止失败
壮士断腕。
控制住失败比优化成功更能提高你的全面成绩。
要有闯劲，尽早取消失败的工作。
除非必要，否则就不要自已去凝聚一个团队：出去找一个已经成型的团队来用。
保持好的团队在一起（只要他们自己愿意），以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。
把凝聚在一起的团队——准备充分、并且也愿意接受新的工作——作为项目的收获之一。
项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。
有无数种方法可以浪费一天的时间……但是没有任何一种方法可以拿回一天的时间。
开发过程的建模和模拟
将你关于完成工作过程的直觉建模。
在同事的交流中使用这些模型，以便交流、提练关于项目运转的思想。
用模型来模拟项目的结果。
概据实际的结果来调整模型。
“病态的政治”
每一天，你都必须准备拿自己的工作去打赌……
……但是这也不能保证“病态的政治”不会影响你。
“病态的政治”可能在任何地方出现，哪怕是最健康的组织里面。
“病态的政治”的特征：对权势的渴望超过了组织本身的目标。
即使这种不合理的目标与组织的目标背道而驰，它也可能出现。
“病态的政治”最恶劣的副作用：它使精简的项目变得危险。
Tom DeMarco度量
度量每个产品的规模。
不要执着于单位——在等待客观度量的时候，先用你自己的主观单位。
从所有能得到的原始数据（可计算的软件特征）自己构造度量单位。
从已经完成的项目中收集原始数据，以推导出生产力趋向。
不断完善你的度量方程式，直到它的计算结果与原始数据库中的项目工作量有最好的对应关系。
借助数据库画一条趋势线，把预期工作量作为人造度量单位值的函数显示出来。
现在，针对每个要评估的项目，计算出人造度量单位值，并根据这个值在趋势线上找到预期工作量值。
用生产力趋势周围的干扰水平作为映射的公差指示。
过程和过程改进
好的过程和持续的过程改进是绝好的目标。
他们也是非常自然的目标：优秀的技术工作者一定会注意它们，不管你是否告诉他们。
正式的过程改进程序需要花钱、花时间；特定的过程改进工作还会延缓项目进度。尽管最终会体现出生产力上的收获，它们也不可能抵消花在过程改进上的时间。
但是，项目有希望从单个的、正确选择的方法改进中得到足够的收益，并赢回为这次改变付出的时间和金钱。
在项目进行的过程中，不要希望在超过一个方法的范围内实施改进。多种技术的改进程序（比如说提高整整一个CMM等级）很可能让项目比不实施这些程序完成得更晚。
标准过程改进的危险就在人们可能失去重要的走捷径的机会。
特别是对于人员超编的项目，标准过程看上去很严谨，因为它们制出了足够的工作（有用和无用的），让所有人都忙碌不停。
改变完成工作的方式
如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成。
高速完成的项目用在调试上的时间也成比例地少得多。
高速完成的项目用在设计上的时间也成比例地多得多。
如果你不关心别人，不照顾别人，就别想让他们为你做一些不同寻常的事情。如果要让他们改变，就必须去了解（并赞赏）他们的过去。
压力的效果
压力之下的人无法更快地思考。
增加加班时间只会降低生产力。
短期的压力乃至于加班可能是有用的策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长期的压力肯定是错误的。
经理之所以会增加那么多的压力，也许是因为他们不知道该做什么，或者因为其它的办法困难而感到气馁。
最坏的猜想：使用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。
愤怒的经理
管理中的愤怒和羞辱是会传染的。如果高级管理者喜欢骂人，低级管理者也会有样学样（就像经常被骂的小孩很容易变成爱骂人的父母）。
管理中的骂人被认为是一种刺激，可以让员工提高效率。在“胡萝卜加大棒”的管理策略中，辱骂是最常见的“大棒”。但是，哪有人在被辱骂之后还能做得更好的？
如果经理使用辱骂的方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
含糊的规格文档
规格文档中的含糊标志着不同系统参与者之间存在着未解决的冲突。
如果一份规格文档不包含完整的输入输出列表，那么它就是毫无希望的：它根本就还没开始说明任何东西。
没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己，而不是责备文档。
冲突
只要在开发过程中有多个参与者，就一定会有冲突存在。
创建、安装系统的业务中特别容易出现冲突。
绝大多数系统开发团体都缺乏解决冲突的能力。
冲突应该引起重视，冲突并不是缺乏职业道德的行为。
应当提前声明：所有人的“赢”都是受重视的。确保每个级别的人都能赢。
谈判困难，调解容易。
如果两个人的利益是完全或者部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。
记住：我们都站在同一边，跟我们对立的，是我们要解决的问题。
催化剂的角色
有这样的一种催化剂式的人格。这样的人会帮助团队成型并凝聚，保持团队的健康和生产力，从而对项目作出贡献。就算“催化剂”别的什么都不干（其实，通常他们也会干很多别的事），这种催化剂的角色也是重要而有价值的。
调解是“催化剂”的一项特殊工作。调解是可以学的，而且仅需要很小的投资就能学会。
调解应该从一个小小的仪式开始。“我能帮你们调解一下吗？”在解决冲突的时候，这是必要的第一个步骤。
人类的错误
将你置于死地的，不是你不知道的东西……而正是你“知道”决不会置你于死地的东西。
人员安排
在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让所有的人都有事可做）。
如果在设计开始完成之前，工作先被分给了许多人，那么人与人之间、工作组之间的接口就会很复杂。
这会使团队内部耦合度提高，会议时间、重复劳动和无效的工作都会增加。
理想的人员安排是这样：在项目的大部分时间里，由小型核心团队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入大量的人手。
可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目比起来，完成的时间反而会更长。
项目社会学
让不必与会的人可以放心离开，从而保持会议的精简。有一份公开的议程，并严格执行，这是最简单的办法。
项目需要仪式。
用小小的仪式来使人们注意项目的目标和理想的状态：小规模会议、领缺陷工作等等。
采取行动，防止人们随便发怒。
记住：愤怒＝恐惧。随便对下属发怒的经理一定是因为恐惧才会这样做的。
意见：如果所有人都懂得“愤怒＝恐惧”这个道理，就能明显地看出发怒的人是在害怕。由于无法再隐藏自己地恐惧，他也就不会再生气了。（这不能解决这些生气的人的问题，但是肯定可以让其他人好受一些）。
“病态的政治”（旧话重提）
别想根治一个病态的人。
不要浪费时间，也不要因为尝试治疗上司的病态而使自己受到威胁。
有时候，你唯一的选择就是等待，等问题自己解决，或者等一个让你继续前进的机会。
奇迹是有可能发生的（但是千万别去指望它）。
精兵简政
精兵简政是失败的公司使用的办法，它让员工负担失败的责任。
公司的目标应该正好相反：兴旺而人性化。
当你听到“精兵简政”这个词的时候，请记住它的弦外之音：失败和恐吓。
基本常识
项目既需要目标，也需要计划。
而且这两者应该不同。
