研究软件管理和软件工程的权威和代表人物Gerald M. Weinberg

wanggenhu0

Gerald M. Weinberg温伯格是从个体心理、组织行为和企业文化角度研究软件管理和软件工程的权威和代表人物。1997年，温伯格因其在软件领域的杰出贡献，被美国计算机博物馆的计算机名人堂选为首批5位成员之一。他撰写了30多本书籍和上百篇论文,其每本新书都备受瞩目。

wanggenhu0

Advice for Software Development Managers
© Gerald M. Weinberg, 2004 www.geraldmweinberg.com
给软件开发经理的建议

Software Development Magazine recently interviewed Jerry. Here are some of his answers.
软件研发杂志最近采访了Jerry。以下是部分访谈录。

Q: What’s the most important piece of management-related advice anyone has ever given you?
问：你得到的最重要的一条关于管理的建议是什么？
GW: If you blame your employees, you're a bad manager. You hired them, accepted them, supervised them, and directed their training. You’re responsible. If you don't like what's happening, look to your own behavior. But, if there's credit to be given, it's theirs.
温伯格：如果你抱怨你的员工，那么你是一个不善于管理的经理。你雇佣了他们，接受了他们，监督了他们，并指导他们的培训。你是有责任的。如果你不喜欢他们的表现，审视一下你自己的行为。如果项目成功的话，荣誉是他们的。

Q: What about when a manager has been hired into a group where some or all employees were already hired by someone else?
问：另外一种情况是，公司直接引入一位经理管理一个团队，而这个团队的成员已经存在，并不是由这位经理亲自雇佣的，这种情况怎么办？
GW: You don't take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off -- or you don't take the position. I don't know why managers don't understand that. They take on new assignments like high school kids on their first blind date.
温伯格：你并不是被动的承担了这份管理工作。在你接受这个职务之前，你需要与这个团队的每一位成员进行面谈，让他们签约受雇于你，或者解聘他们——再或者，你放弃这个职位。我不知道为什么许多管理者都不理解这个道理。他们接受新任务，就像高中生盲目地去赴他们的第一次约会。

Q: What if an employee begins to exhibit bad behavior after he or she has been hired -- behavior that wasn't apparent in the interview phase?
问：如果员工在他/她受雇后，表现出了在面试阶段并不明显的不好的行为，怎么办？
GW: Well, that happens, and that's what managers get paid for handling. It can be a setback, but it's your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I've been trying to remedy for years -- so in a sense, I'm to blame, because I've succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn't need managers.
温伯格：这种事情时有发生，这也是任何一位管理者拿了薪水要处理的事情。坏事可能会成为好事，你有责任认真处理此事。不幸的是，并没有多少技术管理者对此有所准备，让坏事成为好事，这也是我多年来希望能够做到的事情——因此，从某种意义上而言，应该被抱怨的是我，因为我仅仅在不多的几个案例上获得了成功。毕竟，如果每一件事情一直都进展顺利，就不需要什么管理者了。

Q: If you were to publish a third edition of The Psychology of Computer Programming, what new insights would it include? (Dorset House Publishing released a Silver Anniversary Edition in 1998.)
问：如果你准备出版《程序开发心理学》的第三版，书中会考虑增加哪些新的观点？（Dorset House出版社1998年出版了该书的银年纪念版，该书的中译本也于2003年出版。）
GW: I might add something about how to make yourself so valuable that your work will never be outsourced -- something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that's just not being done because the odds of success are so poor.
温伯格：我补充的内容将会提高你的价值，以保证你的工作不会被外包出去，否则的话，不仅很多工作会被外包出去（没你的份），而且你正在进行的开发工作也会失去，因为（如果自负和过度自信的话，）成功的几率实在是太低了。

Q: Is this bad behavior coming from the developers themselves, or do you mean to say the entire industry is to blame for not staying on top of innovation?
问：这种不好的行为是源于开发人员本身，还是您认为整个产业都未能站在革新之巅？
GW: It starts with the developers, and managers, too. But the overall result is, as you suggest, the entire industry getting too involved in navel-watching and competitiveness over the wrong values. For a long time, customers had nowhere else to go for service and had to put up with whatever we gave them. Now they have choices, and they're getting even.
温伯格：始于开发人员，也始于管理者。但是整体的结果，正如你提到的，整个产业都没有找对方向，在一些错误的地方去钻牛角尖。很长时间以来，客户没有办法获得其他服务，因为他们不得不要接受我们为他们提供的服务。现在，他们有了选择，他们也在获得公正。

Q: In Are Your Lights On? (also available from Dorset House), you note that people like to complain. How do good managers draw the line between harmless venting and disruptive pessimism, if such a line needs to be drawn?
问：在《你的灯亮着吗？》一书中，您指出，人们喜欢抱怨。优秀的管理者如何区分无害的情绪发泄和具有破坏性的悲观主义，如果需要划分这种界限的话？
GW: "Drawing the line" is probably not the most useful metaphor. The approach I like most is to listen to the complaint for a reasonable amount of time, then say, "And what do you propose to do about this?" Depending on the reaction you get, take it from there.
温伯格：“划分界限”也许并不是最有用比喻说法。我最喜欢的方法是在合理的时间内聆听他们的抱怨，然后对他们说，“那么你打算怎么办？”根据你得到的反馈，可以做出一些推断。

Q: You once said, "If you can’t manage yourself, you have no business managing others." Could you elaborate on that? What does it mean to manage one's self?
问：您曾经说过，“如果你不能管理你自己，你就用不着去管理其他人。”您能解释一下这句话吗？管理你自己是指？
GW: Well, perhaps you can look at Kipling's famous poem,"If." It starts:
If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting,
Or, being lied about, don't deal in lies,
Or, being hated, don't give way to hating,
And yet don't look too good, nor talk too wise;
Most of this poem is still pretty good advice about what it means to manage yourself (except, unlike in Kipling's day, it now applies to women, too).
温伯格：哦，也许你可以看一下吉卜林的著名诗歌“如果”。诗中是这样写的：

wanggenhu0

今天收到台湾城邦的信，温伯格的书很快就要在台湾出版了。“明年一月「顧問成功的秘密」，四月「你想通了嗎」，溫伯格的一些書要陸續出版了。”他们对温伯格的定位是“软件管理思想家”，这是借鉴了大陆“软件与系统思想家”的定位的，不过感觉也还好。

很高兴温伯格的思想就要影响到台湾了。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=183535

wanggenhu0

某些时候你的确可以欺骗所有的人；你甚至可以永远欺骗某些人--但是，你不可能永远欺骗所有的人。
--亚伯拉罕·林肯
从事软件这一行当的人们十分强调摒除二义性，作家们亦是如此。然而有的时候，作家们会刻意地模棱两可，本书的名称就是这样一个例子。所谓的"质量软件管理"，既可以理解为"高质量软件的管理"，也可以理解为"软件行业的质量化管理"。之所以为本书这样命名，是因为我认为上述两个方面是密不可分的。这两种解释的关键词都是"质量"{① 原文中两种解释分别为"the management of quality software"和"quality management in the software business"，它们的开头都是"quality"一词。--译者注}因为这个关键词常常会被误解，为了防止这里的歧义性过于离谱，我们首先需要对该关键词的含义作一讨论。
关于软件质量的故事
在我家的亲属中，只有我的外甥女Terra 承袭了她舅舅Jerry(本书作者Gerald M. Weinberg 更习惯被别人称呼为Jerry。--译者注)的作家职业。她写过几本有关医学发展史的书，在这些书的写作过程中，我一直密切关注，就好像是出自于我自己的手笔一样。正因为如此，当我在她的处女作"Disease in the Popular American Press1"中发现一些由于粗心大意而造成的排版错误时，我曾经感到非常难过。比如，其中有些文字会被整段整段地遗漏掉（参见图1-1）。而当我发现这些错误都是由她所使用的文字处理软件造成的时候，我就更加感到难过了。这个文字处理软件名为CozyWrite，其开发商MiniCozy 软件公司正是我的客户之一。
The next day, too, the Times printed a letter from "Medicus,"objecting to the misleading implication in the microbe story that diphtheria could ever be inoculated against; the writer flatly asserted that there would never be a vaccine for this disease because, unlike smallpox, diphtheria re-
Because Times articles never included proof -- never told how people knew what they claimed -- the uninformed reader had no way to distinguish one claim from another.
图1-1 摘自Terra Ziporyn 所著书中的一页样张。可以看到，CozyWrite 文字处理软件将其中"re-"之后的文字遗漏掉了。
Terra 要求我在下次前往MiniCozy 公司访问时与之理论一番。我找到负责CozyWrite 开发的项目主管，他承认这种错误的确存在。
"但是这种错误很少发生，......"，他辩解道。
"我认为这个理由站不住脚"，我反唇相讥道："在她的书中，我发现了多达二十五处这样的排版错误。"
"只有在要对一整本书进行排版时，才会发生这种错误。在数以十万计的用户中，我们或许都找不到十个以上的人会把这样大规模的任务用单独的一个文件来组织。"
"但是我的外甥女的确这样做了。这是她的处女作，而她的这件作品被搞砸了。"
"对此我当然感到遗憾，但是如果仅仅是为了寥寥十来个用户，而去修正这个软件错误，我们认为这很不值得。"
"为什么不呢？在广告中，你们可是声称过CozyWrite 可以支持对整本书进行拍板的呀？"
"我们尝试过实现这种功能，但是还没有成功。我们最终有可能会修正这个错误，但是如果现在进行修正，却很可能会引发更大的错误--所谓更大，是指这种错误会影响到几百甚至几千位用户。我自认为我们的取舍是正确的。"
就在这位项目主管侃侃而谈的时候，我意识到自己已经陷入了情感矛盾的泥潭，不能自拔。作为MiniCozy 公司聘请的顾问，我只能认同他的观点；但是作为一位作家的舅舅，我却对他的辩解极其反感。如果要是当时有人问我说，到底CozyWrite 是不是一个质量过关的软件产品呢？恐怕我只有张口结舌的份了。
如果换成您，您会如何回答呢？


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=337365

wanggenhu0

质量的相对性
在上面的故事中，我之所以会陷入两难的境地，可以通过质量的相对性来加以解释。这个关于MiniCozy 公司的故事清楚地告诉我们：某个用户认为是质量完全过关的某个软件产品，另一位用户可能会认为质量不完全过关。
发现相对性
由于软件的质量，有过种种定义。只要考察一下这些定义，您就会发现上面提到的相对性。不过，只有仔细加以考察才能有所发现，因为这种相对性通常都被隐藏起来了；即使在最好的情况下，也是很不明显的。比如，让我们来看看Crosby 给出的定义：
所谓质量，就是"符合需求"。2
这反映了一些软件开发者的思想，他们认为用户的需求是无缘无故地从天上直接掉下来的，但是实际情况并非如此。因此，下面的定义会更为精确一些：
所谓质量，就是"符合某个用户的需求"。
正如可以从我外甥女的文字处理软件一事中看到的，对于不同的个人，同一个软件产品往往会体现出不同的"质量"。对于Terra 而言，她所关心的是其读者；但是对于MiniCozy 公司的那位项目主管来说，他关注的却是其用户中的主流。一旦认识到了这一点，我关于MiniCozy 的自我矛盾就迎刃而解了。
那个masked 的人是谁？
简而言之，我们不能脱离具体的人来抽象地谈论质量。
每一条关于质量的陈述，都是关于某个（某些）人的陈述。
这句话既明确又含糊。在大多数时候，"某个（某些）人"到底指谁并不明确，而且这类关于质量的定义，听起来就像摩西从西奈山上带下来的刻在石板上的东西{这里作者指的是十戒（Ten Commandments 或Decalogue ）。据《旧约全书》（the Old Testament）记载，在西奈山（Mount Sinai）上，神用指头在两块石板上写下十项戒律，赐颁给摩西。--译者注}一样。这也就是为什么虽然有那么多关于软件质量的清议空谈，但是最终却都徒劳无功--你崇拜的可能是金牛像{ Golden Calf，一种祭祀用的牛形金像，是以色列人崇拜的偶像。--译者注}，而我崇拜的却可能是石板。
如果能够考虑到质量的相对性，那么我们就可以利用这个工具来把这些讨论落实为实在的结果。每当有人提出一个关于软件质量的定义时，我们只需简单地问一句：
在这里所讨论的质量背后，到底是针对什么人而言的呢？
关于软件质量的组成要素，有很多提法已经为我们所熟知，但是它们常常又是互相矛盾的。现在，就让我们通过上述的启发式方法，重新审视一下这些提法。
高质量就是毫无纰漏
a. 对于某些用户而言的确如此--这些缺陷会把这些用户的工作搞砸
b. 对于某些主管而言的确如此--他们会因这些缺陷的存在而受到指责
高质量就是提供众多的功能
a. 对于某些用户而言的确如此--他们在工作中会因这些功能而受益（当然，如果他们
确实了解这些功能的话）
b. 对于市场营销人员而言的确如此--这些人坚信，功能越多就越有销路
高质量就是简洁而优雅编码
a. 对于开发人员而言的确如此--他们非常看重同行们的评价
b. 对于计算机科学领域的教授们而言的确如此--他们陶醉于简洁优雅
高质量就是高性能
a. 对于某些用户而言的确如此--他们的工作使他们的计算机不堪重负
b. 对于销售人员而言的确如此--他们销售的软件必须通过标准测试
高质量就是低开发成本
a. 对于某些用户而言的确如此--他们想要购买上千份该软件
b. 对于某些项目主管而言的确如此--他们在开发开发时囊中羞涩
高质量就是高开发速度
a. 对于某些用户而言的确如此--他们的工作正等着该软件下锅
b. 对于某些市场运营人员而言的确如此--他们企图在竞争对手来得及杀入之前，就独
霸市场
高质量就是高用户友好性
a. 对于某些用户而言的确如此--每天八个小时，他们都需要目不转睛地盯着屏幕使用
该软件
b. 对于另一些用户而言也是如此--每次使用该软件时，他们总是记不住上次使用时的
界面细节
行政上的两难
认识到质量的相对性，通常已经可以让我们摆脱语义上的两难困境。作为一本讨论质量的书，能够在一开始就解决这个问题，实在是难能可贵。但是，这还远不足以消除政治上的两难困境：
对某一个人而言更高的质量，也许对另一个人而言就意味着更低的质量。
比方说，如果我们的目标是提高"整体的质量"，那么我们就不得不对所有相关的用户作一权衡。这样，为了实现整体的高质量，我们就首先需要确定所有有关的用户，并对其各自的需求作充分全面的了解3。因此在每次设计中，对于任何的软件工程方法，我们将必须为对应于每个用户的质量进行衡量。然后再把这些测量的结果分别相加，才能比较采用不同方法所能获得的总体质量。
当然，在实际应用中任何软件开发项目都不会严格地进行这项繁杂的工作。取而代之的方法是，首先把大多数人排除在外，也就说首先确定清楚：
在进行决策的时候，应该考虑到谁的意见？
比如说，MiniCozy 公司的那位项目主管不仅对Terra 的意见毫不理会，而且认定在他进行软件工程上的决策时，Terra 的意见是微不足道的。从这件事上我们可以看出，软件工程并不是一个民主的过程。更为不幸的是，它也不是一个理性的过程，因为在确定究竟要考虑谁的意见时，往往是根据个人的主管情感做出判断的。


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=337371

wanggenhu0

质量就是对某个（某些）人而言的价值
质量概念的内涵中包含了政治的或情感的因素--如果从质量的另外一种定义来看，这一点在明显不过了。在我们目前讨论的初期，用户需求的概念还显得有点幼稚--究竟谁的需求需要首先考虑？这里并不明确--因此这个概念还没有多大用处。下面这个定义的可操作性或许更强一些：
质量就是对某个（某些）人而言的价值。
我这里所说的"价值"，值得是"为了使自己的需求得到满足，人们会愿意支付什么或者采取什么行动？"打个比方说，假如Terra 不是我的外甥女，而是MiniCozy 公司总裁的外甥女。要是那位项目主管深知自己的总裁会为此事采取什么样情绪过激的行动，恐怕他为那个文字处理软件的质量所做的定义早就是另一番模样了。倘若真的如此，那么在确定应该首先修正软件中的哪些错误时，恐怕Terra 的意见将是最优先考虑的。
总而言之，质量的定义总会带有政治的和情感的色彩，因为它总要通过一系列的决策，才能确定到底要理会哪些人的意见，这些意见相对而言的重要性有多大。当然，这种基于政治和情感的决策过程--正如所有基于政治和情感的重要决策一样--在多数时候并不会为公众所察觉，这很适合于软件的开发者，他们乐于做出一副崇尚理性的模样。关于质量的这种定义，为什么总是没有多少人会认同其实际作用？原因正在于此。
即使做出这些决策的人是有头脑的，而在大多数时候，他们也会对这种现象失察，因此我们的工作就变得更为困难了。也正以为此，如果负责软件质量的主管不能保证在决策时依靠公众的头脑，那么对他们而言，至关重要的一项工作就是至少要确保真正运用自己的理性进行判断。这也正是我们的主要任务之一。
Precision Cribbage
为了检验我们对上述定义及其适用性的理解程度，让我们来看看另一个故事：在年轻的时候，我最喜欢的游戏之一就是与父亲一起玩Cribbage 纸牌游戏。这个游戏的发明者是诗人JohnSuckling 爵士{约翰·萨寇灵（1609-1642），英国诗人和朝臣。其诗作包括Session of the Poets、The Constant Lover、Aglaura 和Ballad of a Wedding 等，其作品机智自然，有时甚至开些低级趣味的玩笑。--译者注}，它在世界上的有些地方极为流行，但是在其他地方的人们却可能对这种游戏一无所知。父亲去世之后，我仍然很怀念与他一起玩Cribbage 纸牌的时光，因此很希望能找到一位固定的牌友搭档。最后，我很高兴地发现在Macintosh 平台上运行的一个Cribbage 游戏共享软件，名为Precision CribbageTM，作者为加利福尼亚州圣何塞市的Doug Brent。
我认为Precision Cribbage 是一个经过精心设计而成的软件作品，如果与大多数共享软件相比，这一点更为明显。尤其令我高兴的是，该软件为我提供了一个很好的游戏--尽管其水平一般，通常十局中它只能赢我一到两局。因此我按照要求给Doug 寄去了一封信，缴纳了共享软件使用费，此后用它玩过很多次这个游戏。
虽然如此，我还是很快就发现了Precision Cribbage 的计分算法中的两个明显的错误。第一个错误是：当你手中有三张牌为同一点数，而剩下的两张的点数也相同（用扑克牌的术语讲，也就是所谓的 Full house），『葫芦。扑克的牌型，有三张牌与另两张牌点数分别相等。例如：（.K，.K，.K；.4，.4），或者（.6，.6，.6；.8，.8）。--译者注』）时，其计分会间歇性地出现错误。很显然，这个错误并非是故意遗留的，因为在有些时候，这种牌型的计分完全正确。

图1-2 Cribbage 纸牌游戏中计分错误的例子。正确的分数应该是4，而不是8{根据Cribbage 纸牌的计分规则，在这手牌中，一对（.2 和.2）值2 分，一种15 组合（.9 和.6）也值2 分，共4 分。--译者注}。
第二个错误产生的原因，是作者对计分规则理解有误（对于一个声称可以与人一起玩纸牌游戏的程序来说，这肯定是需求的一部分）。当有三张同花色的牌在手，而第四张该花色的牌已经被切去了时，还是应该计分的。对于这种情况，我完全可以从数学上证明其算法有误4。这个故事之所以与我们讨论的问题有关，是因为尽管在这个游戏软件中存在两个计分的错误，我还是对Precision Cribbage 的质量完全满意，以至于每个星期我都要挤出好几个小时的宝贵时间来玩这个游戏，我也很乐意支付共享软件的使用费--尽管我完全可以省下这笔钱，而不必担心受到任何形式的惩罚。
总而言之，对我而言Precision Cribbage 意味着极大的价值，为了体现这种价值，我愿意花费自己的时间，甚至在需要时支付相应的费用。而且，即使Doug 后来更正了软件中的这些错误，也不会为其带来多少新的价值。


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=337374

wanggenhu0

所有这些锁定现象环环相扣，最终会造成一些模式。人类学家Dani Weinberg『Weinberg 先生的夫人。——译者注』是我的搭档，每当他与我一同前往一个新的企业，为其提供有关软件组织的管理方法的咨询时，我们总是很快就能注意到两个重要的事实：

1． 任何两个软件企业都不尽相同。

2． 就其本质而言，任何两个软件企业都没有多大区别。

正是因为第一点，在解决软件管理中真正重要的问题时，不可能企望会有现成的方法。然而与此同时，正是由于第二点，每当来到一个新的软件组织时，我们也不必都从头开始。每个软件组织中都包含由一定数目的普通人构成的群体——尽管在不同的企业中，他们的数量可能相差很大，他们服务于的产业可能不同，他们使用的程序开发语言可能不同，他们可能位于不同的国家，甚至他们生活的年代也不尽相同。对于这种群体，本书将给于特别的关注。

也可以通过另一种人类学的方式来表述这种现象：存在某种软件文化，这种文化可以跨越时间、空间以及环境的界限。你有很多种办法，可以验证这种软件文化的存在。首先，英文的软件书籍在全世界都很畅销。在很大程度上，这种文化属于英语文化。这类书籍的翻译版本销路也很好，因此有关软件方面的笑话在全世界都能大行其道。关于软件的会议跨越了国界，针对这些会议的与会者的调查显示：这些人的组成跨越了产业的界限，同时也打破了年龄层次的界限。对于我们来说，这种软件文化的存在不能不说是一件幸事——因为它使我们得以互相学习。因此对您或者您所在的软件组织而言，我们从自己的客户那里所了解到的规律将具有潜在的价值。

Dani 与我所了解到的最具价值的规律之一就是：在整个软件文化圈内，只有寥寥数种不同的模式（也就是所有软件组织所具共同特性的宏观类型）。区分这些模式的一种方法，就是去观察软件组织所开发的软件的质量。我们已经知道，软件组织所开发软件的质量也会锁定在固定的水平上；同时由于文化所固有的保守本性，任何改变现状的努力都会受到遏制。从该文化圈的以下几个特点，你可以再清楚不过地看出这种保守的特性：

1． 对其目前的软件质量水平现状沾沾自喜。

2． 如果要尝试提高其软件质量，人们首先担心的是目前质量水平可能因此下滑。

3． 对其它文化缺乏了解。

4． 对其身处其中的软件文化视而不见。

质量的重要性来自于其所具有的价值。因此，把握软件质量的能力也就是把握软件工作所具价值的能力。为了创造一种质量软件的新文化，作为软件开发人员或主管，您必须懂得如何有效地应对这些因素——这也正是本书的目的所在。

有益的提示与建议

1． 你可能希望能够确定自己的软件的所有潜在用户，并且了解其对不同用户所具有的价值。自不用说，你不可能指望在这些方面做得尽善尽美；但是这并不等于说，你的这种尝试努力没有任何好处。实际上或许你将发现，哪怕你只是在自己的脑子里考虑考虑这种尝试，也会有大有裨益。而一旦切实体会到了这些好处，也许你就会着手深入主要的用户中去进行访谈，以确定对他们而言的价值所在。

2． 由于文化所固有的保守性，任何改革的努力都会受到重重阻力。你应该认识到，自己进行改革的目的正是为了能够更好地继承以往工作方式中好的方面——在认识到这一点之后，你将可以更好地应对这类阻力。在开始你的改革计划之前，你应该首先承认原有方式的价值；即使是要改变文化的模式，也要首先明确哪些特性是你希望继承的——如果能够这样做，将会获得更好的效果。



小结

质量是相对的。对某一个人而言的质量，对另一个人则甚至可能意味着质量不足。

    为了确定质量的相对性，需要透过其定义的文字表面，发现其中隐含的一个或多个对象。

为此，我们需要提出这样的问题：在这个关于质量的叙述背后，对应的到底是什么人？

不折不扣地讲，所谓质量就是软件产品对于某个（或某些）人的价值。正是在这个观点的基础之上，我们才有可能协调一致地解释下面的论点：

n         高质量就是毫无纰漏

n         高质量就是提供众多的功能

n         高质量就是简洁而优雅编码

n         高质量就是高性能

n         高质量就是低开发成本

n         高质量就是高开发速度

n         高质量就是高用户友好性

所有这些论点可能同时都是正确的。

虽然我们总是自欺欺人地试图理性地来考虑质量问题，但是在很大程度上，质量实际上是一个政治的或者情感的问题。

质量并不等同于不存在错误。即使不能逐字逐句地地符合其需求，一个软件产品仍然可能被某些用户认定为高质量的。

改进质量并非一件易事，这是因为其开发组织的运作方式会倾向于锁定在某种固定的模式上。对于其现有的质量水平而言，这些开发组织已经适应；但是关于应该如何做才能将质

量提高到新的层次，他们心中并不清楚——犹如叶公好龙一般，实际上他们并不愿意尝试

把自己的愿望落实为行动。

为众多的软件开发组织所采用的模式不外乎少数的几种类型（或者成为亚文化群），这些类型具有其各自的特性。

文化具有与生俱来的保守本性。对于软件开发组织而言，这种保守性在以下方面体现得淋漓尽致：

n         对其目前的软件质量水平现状沾沾自喜

n         如果要尝试提高其软件质量，人们首先担心的是目前质量水平可能因此下滑

n         对其它文化缺乏了解

n         对其身处其中的软件文化视而不见

练习

1． 我曾经致信Doug Brent，向他表达我的感激之情，同时指出其软件中的两个错误实例；

但是至今为止，我还没有受到任何答复。如果Precision Cribbage 已经经过了修正，对我

而言当然不是坏事；然而我却不会过分去留意这种修正，因为一旦后来我能找到另一个适

宜的程序来玩Cribbage 纸牌游戏，原来的软件所具有的价值就立即贬值了。请讨论一下：

当某个软件产品的早期版本或者其竞争对手的产品投入使用时，该软件产品的价值（也就

是其质量的定义）是如何变化的？

2． 在使某一给定的硬件体系结构逐渐标准化的过程中，所在软件组织将会锁定在那些特征上？请逐一列举出这些特征。

3． 关于所开发软件的质量，您所在软件组织中的同事们是否的确对目前的质量水准沾沾自喜？从哪些证据可以看出他们的这种心态？如果有人敢于对其略有微辞，您所在的企业将

会如何对待他们（的意见）？





Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=337376

wanggenhu0

提高质量为何如此之难
Precision Cribbage 的故事说明，"符合需求"并非是质量全部含义--除非你接受的是某种关于需求的非传统定义。这个故事同时也说明，基于错误的数量来定义质量也是不全面的--这方面的例子有：
所谓质量，就是指没有任何错误。
虽然实际上这类定义不堪一驳，但是许多年来它们一直是人们关于高质量软件的主流认识。在这种意识的支配下，软件开发人员及其主管们对提高软件质量的要求置若罔闻。难道他们不愿意去提高质量吗?即使没有其他人向他们提出这种要求，哪怕仅仅是为了满足自己的自尊心，他们也应该这要去做呀？毫无疑问，他们的确愿意提高质量，但是事实并非如此--原因何在？
"还不算坏"效应
CozyWrite 和Cribbage 只不过是两个典型的故事，我还能举出成百上千的这类事例；我一点也不怀疑，你也可以举出许多这样的例子。如果你问一下软件开发人员："你们是否对高质量的软件产品有兴趣？"我敢肯定，出于其职业的自尊心，他们一定会回答说："当然！"
然而，假设你要是向他们专门询问一下CozyWrite 或Precision Cribbage 的改进问题，其开发人员将会回答："但是，它已经是一个好的产品了呀。其中的确有错误，但是这是很自然的事，所有软件都存在问题。而且，（既然用户愿意购买它，就说明）它总要比竞争对手更好一些。"很自然地，下面的三句话的正确性都是可以证明的：
1. 用户的确在使用他们的软件产品，而且因此很高兴，所以这个产品是高质量的；
2. 没有哪个软件没有错误（至少我们还不能证明其反面）；
3. 用户是在对多种相互竞争的产品进行比较之后才确定购买它的，这说明用户认为它相对更好。
在这种环境之中，除非有来自外界的推动力，否则开发者自身不会有多少积极性去提高软件质量。比如说，要是用户不再使用或者不再购买其软件产品，那么开发者才可能会决定去改进质量--但是也许已经为时太晚。如果出现了一个管理体制更为高效的竞争对手，那么原来销售软件的企业就只有淡出市场的份了。
但是对于那些服务于某个更大企业的内部软件开发部门而言，他们几乎不会面临多少竞争，因此这种部门的前景注定会日渐萧条。这种萧条是否重要，取决于其上层企业对"质量"的定义。如果上层企业能够获得其所需要的价值，而且也不知道还有更好的途径，这种萧条的状况将一直持续下去。但是一旦其所从属的上层企业开始不满起来，危机就将发生。
"这不可能"效应
你是否知道，要是你有八英尺六英寸高，你就可以被NBA 的一支球队中聘为首发中锋，并且因此每年可以挣到3,000,000 美元？现在你已经知道了这一点，那么为什么不马上开始一个增加身高的计划呢？这种问法幼稚得可笑，因为你并不知道如何才能使自己长高几英尺。
你是否又知道，要是可以把你的软件中的错误数量减少至每一百万行代码中不超过一个，你的软件市场就会每年增加3,000,000 美元的份额？这种问法同样幼稚得可笑，因为你并不知道如何才能把自己的软件中的错误数量降低到每一百万行代码中不超过一个。
在他的" Quality Is Free"5 一书中Philip 说过，提高质量的积极性总是来自于对质量的代价（我更偏爱使用"质量的价值"一词，虽然二者的意思完全一样）的分析。在我的咨询经历中，我经常要与深受困扰的项目主管们交谈，他们之所以有所烦恼，大多是因为他们企图削减软件的开发费用，或者缩短开发周期；但是，我却很少遇到哪位主管为软件质量的提高烦恼过。他们不用大伤脑筋，就可以轻松地告诉我为了削减费用或加快进度，那些工作才是应该做的；然而，对于提高软件质量所能带来的价值，他们却似乎从来也没有考虑过去评估一下。
而当我建议他们评估一下质量带来的价值时，他们通常的反应让我感觉到，自己好像是在告诉他们长高到八英尺六英寸之后的价值--对他们来说，提高质量是"挟泰山以超北海"的工作。既然对如何实现这个目标一无所知，又为何要因为对其价值的评估而自寻烦恼呢？即使知道如何评估，但是既然我们对这种价值并不认同，那么又有什么必要去实现它呢？图1-3 显示出了这个恶性循环的过程。这里采用的是作用图的形式，我将在稍后对这种图表进行解释，并且将在本卷中一直使用它。现在，让我们暂且特别留意它是如何解释提高质量的工作的开展为何这样举步维艰。
图1-3 一种恶性的循环，它导致开发组织无法着手提高软件质量
对图1-3 中图表的解释仁者见仁，可能得出乐观的结论，也可能得出悲观的结论。从乐观的角度来看，这张图表说明，一旦开发组织开始领悟到质量的真实价值，其改进质量的积极性就会提高，进而可以促进其更好地理解如何才能提高质量，最后反过来使其更好地理解到质量的价值。Crosby之所以不惜付出质量分析的代价以改革开发组织的行政机制，原因正在于此。
尽管如此，从悲观的角度来看，这种循环也可以理解一种阻碍作用，它会阻碍以更高质量为目标的改革。如果不能意识到质量的价值，实现质量的积极性就是无本之木；反过来，对实现质量的方法的理解也就无从谈起。既然连实现质量的途径都不清楚，那么评估其价值又有什么意义呢？
锁定效应
图1-3 也恰好是说明锁定效应的一个例子。一个被锁定的系统会尽力使自己维持在现有的运行模式上，纵然有很多合理的原因要求改变它，该系统依然故我。关于锁定现象，最佳的例子莫过于标准编程语言的选择。无论是由于何种历史原因，一旦某个企业现在正在使用某一种编程语言，那么就需要花费更大的代价才能使之更换成另一种语言；在试图考察其他可替换语言的价值时，该企业的积极性也会同时下降；因此，根本就不可能知道如何去更换编程语言。其后果是，该企业会死抱目前正在使用的语言不放--这就像在选择车辆靠左还是靠右行驶的规则时，不同国家会固守自己现有的约定。
在本卷书中，我们将会看到很多有关锁定情况的例子；但是在目前，我们首先只需注意到这样一个事实：锁定现象都是连锁式发生的。要是你锁定于某一特定的编程语言，那么你同时也很可能会所定于下面的全部或者部分方面：
  支持该编程语言的一整套软件工具
  支持该语言的某种非标准变体的硬件系统
  由若干特定的学校培训出来的人力资源
  从其他某些特定的企业聘用来的人力资源
  精通该语言及其工具的一群顾问
  由使用该编程语言的其他用户组成的团体
  一批通过改编程语言步步升迁的主管
  面向该编程语言的专业书籍以及技术培训
  与该编程语言对应的软件工程基本理论
  与该编程语言对应的用户界面基本理论
按照上面的次序，这些因素将依次使得相应的企业锁定于其后续的因素。如果你试图改变其采用的标准编程语言，就会在整个企业的范围内造成一些列连锁反应，在其中的每一环节，你的努力都会遇到各式各样的阻力。
对于一个开发组织而言，调整其采用的标准编程语言究竟有无益处，这个问题并不重要。正如临床医学家Virginia Satir 经常挂在嘴边的一句话所说的：
"在选择工具时，人们优先挑选的并不是最适用的，而是自己最熟悉的。"


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=337383

wanggenhu0

致谢
一位读者在信中写到：“最近我查阅了您关于Fieldstone方法的作品，我发现这真使我所急需的。很多年来我一直在收集 fieldstone ，但是一直不能理解，所以不能尽我所能地收集，并且从没有使用过它们。几年前，我甚至把大量笔记给扔掉了，这些笔记在我现在看来都是fieldstone。仅仅是因为当时我没有真正的了解它们有什么用以及使用方法，它们看上去占了很大的地方却毫无作用。（咳…）我认认真真读完了你的书，照你所说的付诸实践，并且将书中的过程融为自我意识的一部分。我再次拿起纸笔，继续我未完成工作，不过现在我已经对自己充满信心了。像以前一样，感谢你充满思想，又不乏行动指南的作品。”
抱怨
当看到这篇文章时，我感到很惭愧。但这种反馈是对作者最好的鼓励。当读者不断地抱怨时，这应该引起他们的关注：
“第一个问题和你在‘温伯格谈写作’中提到的FieldStone方法有关： 你最终会将你的素材(stone)转录到计算机中。我总是在思索怎样才能把它做到最好，甚至不惜使用非结构化的数据库类型工具（例如像Ask Sam）。我找到EndNote 作为参考 （这是值得一提的，我仍然是一个不能找出 books’ folks 的人），但是我还是没有找到你用来收集和查找素材的工具。是我错过了什么，还是仅仅把简单的事情搞复杂了？我总是企盼一种简单而系统(marginally structured)的方法来获得基本信息，再加上日期、标记（然后链接上网址、图片等），然后综合/查找我需要的。现在，我在按照我的方法用一个简单的网络程序来试验。但是我想知道你用来处理大量素材的工具是什么。”
回复
在那个赞扬的反馈之后，我怎么能拒绝这个请求呢？
嗯，你并没有错过它。我没有直接说我使用的工具，有以下原因：
<!--[if !supportLists]-->  1.    <!--[endif]-->有很多可以选择的
<!--[if !supportLists]-->  2.     <!--[endif]-->我换了已经很多年了，我在使用更新更好的工具
<!--[if !supportLists]-->  3.     <!--[endif]-->我混合使用了很多工具
所以，正因为如此，我首要的标准就是软件不能使用繁琐或私有的格式，这将不能与随之而来的新工具配合使用。
现在，我主要的工具是一个Mac的小程序，被称为Mori（一个之前被称做Hog Bay Notebook的升级版）。Mori在PC上好像不适用，但是它的作者推荐了一个类似的PC程序，叫做NoteLens。这就像一个内部wiki，有过之而无不及。这样，我可以同时用多种方法来组织素材，例如链接、概要，或是简单的移动和分类。
Mori 看起来可以存储任何东西，但是更多的时候我还是保存些大型的文件（制图、图片），它们都是普通的Mac文件，尽管有时这些存入Mori会更慢。它还提供了很多可自定义的数据视图，但是我还没试过。这是一个很丰富的系统，在你使用它的时候很容易控制不住自己，但是对于我而言它只是一个工具，不是玩具。我用不同的视图来管理小说和非小说类的作品。我也会使用Mori记事本来存储我的通讯录，例如发行商、代理商和水管工人。
不同的项目，我放在不同的Mori记事本里，但是，如你所知，很多素材一时不能决定属于哪一类（过去或是将来）。我把不便分类的放在一个记事本里。但是这些未分类的素材往往会和日常的Mac文件和文件夹混淆在一起，我总是要仔细读它们，看看是不是有一些可以被用到现在的项目上。（也许我同时会有二十个项目在进行，它们都在各自的Mori记事本中被详细的构思）。
现在存储设备很便宜，我保存了所有的记事本（当然有几种方法备份），甚至是已经完成的或是被放弃的项目。我甚至想要为所有的Mori记事本做一个独立的Mori元数据记事本目录。我可以把它们都一个大的Mori记事本里，但是这看起来不是很谨慎和有效。我会改变我的想法，但我是个保守的人。如果某个Mori太大了，阻塞了数据库，我怕失去任何stone。
无论如何，我总是想方设法扩充我掌握的fieldstone，当我听到读者谈到他们使用何种工具或是他们如何使用该工具的，我都会很高兴的。


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1526329

wanggenhu0

今天是个春意盎然的好日子了，我打算做点春季的清理工作。书柜实在是太挤了，我扔掉了10本书。这真是一件令我痛苦的事情啊。所以我决定要整理一下我的链接库，然后把它们介绍给我的读者们。
Dean Wesley Smith
http://www.deanwesleysmith.com/mt/
Dean是我小说创作的良师益友。在他的论坛上，他来回答关于写作的问题。有时，他声称常常对一些问题直言不讳，这也是这个站点值得看一看的一个原因。
这里的很多帖子都涉及到写书、买书与代理之间不同之处的方方面面，以及任何人关于任何问题的提问。不用署名，看完之后什么都不用做。

俄勒冈州的Chris和她的丈夫J. Steven York，是我的两个创作上的朋友。他们的文章很灵活（irregularly），但是很有想法（provocatively）。Chris最新的帖子是关于作者在座谈会<!--[if !supportAnnotations]-->[h1]<!--[endif]--> 上应该如何表现（how writer's ought to behave）的，那是一份很好的作品。http://cfyork.blogspot.com/
《The London Times》上的一篇文章，讲了畅销书以及如何促销
http://www.timesonline.co.uk/article/0,,1056-2202068,00.html
作者的错误
http://www.vickihinze.net/
作家Vicki Hinze的blog上有一系列的帖子是关于作家所犯的错误的，也许你从没想象到会有如此多。华盛顿州立大学的Paul Brian教授有一个非常有价值的在线读物，《英语中的常见错误》http://www.wsu.edu/~brians/errors/errors.html#errors
以此作为参考，你再也不会为“wrack”和“rack”，或者“prostate”和“prostrate”而困惑，或者被其它好几百项常见的易混文字所困惑。

如何回答出版商的议价（幸运的你）
代理商Kristin Nelson在她的博客中谈到了一系列未签约作者如何回应出版社议价的问题。在Agent 101里有很棒的资料。这是第一个帖子的可以在这里找到：http://pubrants.blogspot.com/2006/06/agenting-101-part-one.html
这些有用么？
加入一些评注可以有助于其他人评估这些站点。尤其是几个其他有价值的作家的评论的链接。
<!--[if !supportAnnotations]-->
--------------------------------------------------------------------------------
<!--[endif]-->
<!--[if !supportAnnotations]-->
<!--[endif]--><!--[if !supportAnnotations]--><!--[endif]-->
<!--[endif]-->
<!--[if !supportAnnotations]-->
<!--[endif]-->


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1526336

wanggenhu0

在我最近的一次咨询培训班上，我们花费了一天多的时间讨论与客户谈判的问题——任务委派、价格、条件、进度，甚至还包括咨询师与客户之间关系的方方面面。作为课后的练习，我们都要就一些事情与他人进行谈判。我得到了双人的免费大餐。有人以低于定价50元的价格买了件夹克。还有一位参与者不但得到一部手机，还从他的客户那里赚来两份酬金。
至少对于美国人来说，“讨价还价”似乎是个贬义词，是一项禁忌——我们的练习就是克服这项禁忌。我们学习了很多关于谈判的知识，但是最重要的却是我们在心里为自己树起的“情感障碍”。为了加深对这种障碍的了解，让我们来看两个关于谈判的场景。这里客户雇用了咨询师为他们开发一个软件组件，但是咨询师却犯了些错误。

场景一：
Bob（客户老板）：Fay，你估计这个组件什么时候可以准备测试？
Fay（咨询师）：如果能得到我申请过的设备，我非常肯定可以在14周内进行测试。
Bob[面露惊讶]：哦
Fay：有什么问题么？
Bob：嗯…
Fay：我想我可以加紧工期，在12周内搞定它。
Bob[依旧面露惊讶]：哦
Fay：该死。好吧，如果万事顺利，我可以在10周内完成。
Bob[稍露悦色]：你是说8周？
Fay：行，我想我可以赶在8之内周做好。
Bob[微笑]：棒极了，Fay！我知道你能做到！

场景二：
Darlene（客户老板）：Ira，你估计这个组件什么时候可以准备测试？
Ira[咨询师]：如果能得到我申请过的设备，我非常肯定可以在14周内进行测试。
Darlene[跳起来，提高嗓音]：Ira，没说的，这可不行。我希望能在8周内完成，晚一天都不行！
Ira[目光瞟向自己的鞋带]：嗯…但是事情太多了…
Darlene[脸色通红，嗓音又提高一个八度]：Ira，希望你不要和我在这里讨价还价！你知道我们是一个团队，这里容不下唱反调的人！
Ira[喉咙干燥，艰难地咽下口水]：行…我想我可以…
Darlene[突然挤出一丝笑容]：你可以完成！我知道你已经有办法了，Ira。[转身向门走去]好，就这样吧。我已经得到了你的保证，不要让我失望。8周后见！[走出门]

Q：这两个场景之间有什么重要的不同么？
A：没有，没有什么重要的不同。Bob的手段趋于缓和；Darlene的手段更加强硬，但的确没有什么重要的不同。成功的谈判通常涉及到多方面的协商，包括进度、资源和技术细则。但是上述两个场景里根本没有包含任何这方面内容的协商——这不过是两种不同类型的操作手段，让一个人顺从于另一个人的摆布。

场景三，这次应该能有好一些的结局：
Annabelle（客户老板）：Myron，你估计这个组件什么时候可以准备测试？
Myron（咨询师）：如果能得到我申请过的设备，我非常肯定可以在14周内进行测试。
Annabelle[面露失望]：哦
Myron：有什么问题么？
Annabelle：嗯，的确是。
Myron：既然进度这么重要，那么让我们看看其他方面还有什么余地。
Annabelle：我无法给你更多的人手了。我们已经人手短缺了。
Myron：该死。好吧，现在加入新人恐怕只会帮倒忙。但是，有些事是无法退让的——我们不能延期进度、不能获得更多的资源、还不能改变合约的规定。
Annabelle：的确是这样的。不过我还是需要在8周以内拿出一些东西来，给我的营销团队看看。届时会有一个业务博览会，我们必须为它做出一个demo，我无法改变这个日期。
Myron：好吧，我建议我们有必要考虑考虑在demo中先忽略掉一些特性，哪怕先做个假的实现。
Annabelle[面露微笑]：Myron，听上去这的确是我们的当务之急。一起来看看，8周里你能给我们做出什么可以良好工作的东西。

-----------------
于是，Annabelle和Myron尽心于下面的事情：哪些特性对于一个好的demo是至关重要的（她的问题），同时也在Myron团队的能力范围以内（他的问题）。没有谁强迫谁；没有谁受制于谁。谈判保持开放的氛围，彼此互信。没有尔虞我诈、没有面红耳赤、没有事后妥协。
当然，这种谈判会增进信任——信任他人，以及更重要的是，信任你自己。

-          你必须感觉自己没有被利用，可以开诚布公。
-          你要理解在交易过程中自己一方的情况，对此要充满自信。
-          对于自己的无知要勇于承认，不卑不亢。
-          认识到下面这一点也是有用的：在协商过程中不断地颠三导四的协定不客观，也不可靠。
按照我的经验，一个咨询师和客户在一起，所犯的一多半错误都是由于缺少充分的谈判造成的——通常的结果都是，缺乏技能，还要去应对不同形式的有意或无意间被谈判的对方牵着鼻子走的情况。


你明白了么？我已经获得了你的担保，去掌握如何更好地摆脱被控制的境地。那么，不要让我失望！

原文链接: http://secretsofconsulting.blogspot.com/2007/01/yielding-to-pressure-vs-negotiating.html



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1529489

wanggenhu0

最近，有一位作家写信向我抱怨，认为自己一无是处。总之，他说到，“我相信你是了解自我批评的。无论怎样，如果我能用什么东西干掉它，让我得到肉体得到的修炼，我会义无反顾地去做。”

应对自我批评
总想着自我批评，这是无益的。更不能做伤害自己的事情。

如果你是个小孩，批评是你常做的。一个30岁（或更老）的身体里有4岁的想法。干掉4岁的想法不过是另一个4岁的想法。
然而，你需要的是用30岁的想法来工作或谈话，而不是4岁的。理智点，4岁的想法是不可取的啊。你现在是个成年人。想想要是某个小孩总在忧虑这些问题“我说的太多了？还是不够？我做的有意义么？”“别人会不会觉得我很傻？”，然后才如履薄冰地做事，你会怎么办？
无论如何你不能杀了这个孩子，而你能做的就是教育他。

一些外部批评

另外，既然你能听到很多优秀的外部批评，为什么还要被内心幼稚的自我批评所困扰呢？下面的一些批评值得借鉴。例如：
Some writerisms by C.J. Cherryh
Elmore Leonard's 10 rules
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
你还有其他好的外部批评么？请补充到我的列表中。
怎么测试你的外部批评？
在听取任何批评前，无论是自我批评还是外部批评，先用这个不错的方法来测试一下：
他们有什么证据证明他们的批评是有价值的？

这个测试不适用于高中和大学的英语老师，你的大部分朋友，大多数编辑和代理商，还有你的母亲。
当然，如果你只有4岁这也不适用，你还不会写字吧。

我的批评测试还需要添加什么其他的标准么？


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1532868

wanggenhu0

要想成为一名成功的软件咨询师，你需要注意看似无足重轻的语言。在计算机软件领域，到处充斥着这类陷阱。让我来谈谈这个主题，我需要引证一个更广为人知的领域——犬类培训。
我妻子Dani的职业是人类学研究，因此她自然是个富于技巧的倾听者。如今，她已经从人类学家的职位上退休了，但是她却把她作为人类学家和管理咨询师的全部技能和经验，带到了她的新职业中——为狗和饲养者和培训者提供行为咨询(behavioral consulting)。跨领域的综合会产生很多有趣的想法，比如她告诉我的训练军犬的方法。通常，军犬训练过程中最大的问题不在于“狗”，而在于“人”。
倘若有个人听说一只狗接受过攻击性训练，大概有三分之一的人会转过身对狗下命令；“KILL（咬）！”
开个玩笑。
让我们看看狗会怎么做。
为了防止这些鲁莽的行为以及脱口而出的言语，军犬的训练者从来不使用类似于“kill”这些词作为攻击的命令。相反，他们使用一些类似于“health(健康)”的良性词汇，这些词语绝对不会以命令的语气说出来。
这类预防措施是必要的，因为一条经过训练的狗相当于一个信息处理机（information processing machine）,从某方面讲非常像“长着尖牙的计算机”。任意一条武断的命令，对于狗来说可以意味着任何事情，这取决于它是如何被训练的——或者说，被编程的。
这个武断性与狗是否为军犬并无很大关系。训练者也许会对下列情况感到尴尬：Rover听到ROLL OVER命令后，飞奔而出去叼住一个球（狗的名字“Rover”与命令“ROLL OVER”发音相同），好在这并无大碍。但是如果训练狗的时候，是以咬住喉咙作为对命令ROLL OVER的响应的话，那么情况就完全不同了。
做好维护，否则计算机会露出利齿
这和计算机是相同的。因为计算机是需要编程的，又因为程序中的很多字段的含义是非常随意的，所以，一个单独的错误就会将一台原本能提供帮助的计算机转变为可以攻击并且破坏企业的机器。这就是为什么我永远都不能理解我的一些客户，他们对待维护工作的态度如此漫不经心。一次又一次地，我听到经理在辩解，说维护工作可以让能力差一些的（而且便宜的）员工来完成，维护操作的开展也完全没有正规的控制与准则——因为它并非至关重要的。看起来再多的争论也不能让他们相信相反的观点——直到他们经历了一次因维护引起的代价高昂的重创。
幸运（或者不幸）的是，代价高昂的维护事故相当普遍，因此管理者会有很多课程（lesson – 既有“课程”又有“教训”之意），即使学费相当高昂。我私下保留着一个列表，上面记录着我的客户在程序中犯下的代价惨重的错误，其中花费最大的就是维护错误。大部分问题都出现于修改了先前运行程序中的一个数位(digit)。
在所有的案例中，“修改”都被认为是无害的、“微不足道的”，因此，在需要做出修改前，总是由一个检察员临时地通知一名底层维护程序员去“修改那个数位”——不写修改指令说明书、没有测试计划、也没有人复审新的修改，甚至于完全不在乎一个程序员与组织机构日复一日的运作之间的差异。这非常像是一条经过训练的狗执行“KILL”命令——或者是“HELLO”。
只修改一行
我曾经做过研究，确定了在为维护而进行修改时犯错误的可能性，这依赖于修改的规模。以下是表格的第一部分：
      修改的行数        犯错的可能性
1                    .50
          2                    .60
          3                    .65
          4                    .70
          5                    .75
看到如此高的比率，开发者通常会感到震惊，原因有二。首先，在开发过程中做修改比在维护时修改更容易。开发中的修改用于简化、精练代码，并改进代码的结构。通常，这些代码不会被看不见的手从很远的地方进行修改，因此它们不会包含一大堆难以琢磨的子程序调用。在大多数代价惨重的灾难中，都能看到这些程序间调用指令的身影。
第二，在开发阶段的错误变动导致的代价通常影响较小，因为修正这些错误并不会影响到现实中的操作。因此开发者并不会过多地关注他们的错误，也因此更容易低估错误发生的频率。
在开发过程中，你简单地修改一个错误后仿佛什么都没有发生过。不像是维护阶段，那时你必须为错误导致的破坏收拾残局，然后花费无数个小时在各种会议上解释，为什么这个错误不会再次出现了——直到它下一次出现为止。
由于这两个原因，开发者将维护过程中出现错误的高发生率归结为：这是无知的或者缺乏经验的维护程序员引起的。但是如果我们继续看看上述表格的下面几行，我们会发现，真正的起因既不是“无知”，也不是“缺乏经验”。
     修改的行数         犯错的可能性
         10                    .50
         20                    .35
谁杜撰了这些听起来无辜的词语
而且又有多少次你听到那些程序员的经理同意这种论调？以至于“修改很微不足道时”，工作起来就“仓促而粗劣（quick and dirty）”。
如果“微小”的变化真的很微小，这种“无所谓”的态度倒也无所谓——如果程序的维护工作就像是公寓楼的维修工作的话。并不是说看门人的工作不会带来风险，但是看门人也可以这样假设；修理厨房水槽里的垫圈，并不会招致巨大的风险，不会导致建筑物的倒塌并且埋葬了所有的住户。不过，如果对每日运行着业务的程序也作这样的假设，就非常不安全了。然而我们使用词语时过于随便和武断，“维护”一词在各种各样的场景下就被滥用了。
无论是谁为计算机程序编写杜撰了“维护”这个词，他都是个有些粗心、缺乏思考的人，就像那个训练军犬，让它听到命令“KILL”或“HELLO”就去扑杀的那位驯犬师一样。作为“事后诸葛”，我建议“维护”程序员更应该充当脑外科医生的角色，而不是看门人——因为“打开”一个工作中的系统更像是打开人类的大脑，并换上一条神经，而不是掀开水池更换垫圈。如果维护工作被称为“软件脑外科手术”，它的管理还会容易么？
按照这种思路来思考。假设你有一个坏习惯——比如对一只军犬说“KILL”，你难道会对脑外科医生这么说么？“医生，撬开我的头骨吧，切掉这个小毛病。尽管做这一仓促而粗劣的工作吧——这不过是很小的变化！仅仅是一次微不足道的维护！”
职业精神
当然，作为咨询师的你，从来不会在语言上的如此粗心，不是么？但是，当你被正处于麻烦的客户——就像细微的但损失惨重的维护修改——召集来时，就要倾听他们“无辜”的语言。它所包含的线索是，你只需做很小的修改，就能修正问题了。
噢，请等一下！
<!--[if !supportLineBreakNewLine]-->
<!--[endif]--> 原文链接: http://secretsofconsulting.blogspot.com/2007/03/innocent-but-dangerous-language.html

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1533868

wanggenhu0

最近我收到一封来自Catherine (cat) Morley的信，她是Katz-i International Web & Graphic Design（http://www.katzidesign.com）的设计与开发主管。

她同时也是Creative Latitude的项目经理。Creative Latitude (http://www.creativelatitude.com) 是一个世界范围的社区，它致力于融合各种的富有创造性的纪律规范，包括促进集体合作、教育和商业道德的实践。Cat还是NO!SPEC crusade (http://www.no-spec.com)的项目经理。

她回复了我关于写作的blog上的帖子，不过我觉得我的回复应该放到关于咨询的blog上，事实上，所有的设计师都是咨询师。她写道：

Cat: 不，我不是作家，但是我的确有你的那本《温伯格谈写作（Weinberg on Writing）》，而且过不了多久我将会用到它。我喜欢这本书，并已经建议了所有热衷于写作的设计朋友都去买一本。

Jerry：正如你所知，我同样不是个作家。嗯，我算个作家，不过我首先是个（计算机系统的）设计师，我写的第一本书以及其它很多作品都是关于设计这个主题的。

Cat：简短的解释 – 我正在为设计人员制作一套丛书，称作“与人合作(working with)”(作家、程序员、摄影师、营销员、印刷工等等)。目标市场 – 初次踏入设计业务的新人。动机 – 帮助刚刚接触设计业务的新人避免犯严重的错误，这些错误是那些经验丰富的设计师曾经犯下的。附加效益 – 客户(有希望)避免遭受犯同类错误带来的损失… 为了这些，我找到您… 我们正在遍访业界的解决此类商业问题的设计师。这里有两个小问题…

问题一：作为一名专业作家，在设计人员与你就一个项目进行接触前，您希望/要求他们明确哪些要点？

Jerry：我有作家与设计师的双重身份，因此我对设计师抱有很高的期望值。就在上个月，我曾经和一位名叫Brandon Swann的青年设计师一同工作，为我的新小说《The Aremac Project》设计封面(现在你可以在我的主页上看到他的作品)。我希望他能懂得如何倾听我的要求和想法，然后发挥他个人的主动性，为我的设计要求至少提交三种可能方案的草图来。我希望他能对图书封面的意图有个大致的了解——这些封面应该是干什么用的——然后将他个人的创作激情和我作为客户的需求结合起来。我希望他能准备好在我和出版商之间进行周旋，就像我对设计的精益求精一样。

顺便提一句，Brandon要努力做到上述几件事，方可绘制出令人印象深刻的、精彩绝伦的封面来。

问题二：当与设计师一同工作时，在您眼中（他们身上）最重要的问题是什么？

第一个：自负。一个设计师需要相当程度的自我认同，但是在向客户提供服务的时候，应当有所收敛。很多人这一点做得并不好。（这个问题在我的那本《成为技术领导者》中进行了探讨，在我（和我夫人）的《系统设计原理概要》同样有所涉及。）

第二个：也许和第一个相关：做不到静心去倾听。（Charlie、Edie Seashore和我合著的那本关于反馈的书，《你刚才说什么？：给予与接受反馈的艺术》，讨论的正是这个问题。）

第三个：对当前的状况（他自己或客户的）不明了，而且也不去澄清它们。（我和Don Gause合著的两本书探讨了这个问题：《你的灯亮着吗？——发现问题的真正所在 》和《探索需求——设计前的质量》。）

当然了，很多设计者就是缺少沟通，无论是创作过程中，还是面对面的交流中。我关于写作与关于咨询的著作都涉及到了这个问题。

这并非全部，但已足够了。

访问一下Cat关于设计者的blog，你会不虚此行的。

有些事情想想可以，但不可强求。

Mike Morgan写过一封略带调侃的信：“如果架构师必须像程序员那样工作”,其内容与今天的主题“设计师/咨询师如何与他们的客户合作”是相关的。作为一名设计师，必须懂得的一件事就是怎样保持清醒，并且抓住Mike Morgan这样的潜在客户。

在那封信中提到，客户不断地增加并变化本已含糊不清的需求，因此，架构师必须列出相关的特性，保证这些特性是架构师可以为用户解决的。如若不然，在不关他事的时候，他的自负会使他越陷越深。他连最基本的话都忘了——这就是提醒客户每次关于变化的交流都会花费开支。

同时，很明显地，架构师将无法看到或弄清楚很多情况，正是这些情况让那封直言不讳的信变得很尖锐。当然，他需要做的第一件事——如果他全心全意地为客户着想——是面对面地（与客户）交流，举行一个反馈会议，告诉用户在这种方式下，商业活动取得成功的开销与机遇。这位客户必须明白，某些事情想想是可以的，但是这和对它们惦念不忘是不同的——的确，无论惦记什么，该放下时就放下。

我建议每一位咨询师都做这样的练习，读一读这封内容虽是虚构，但所谈问题却是客观存在的信，并且在它谈及的每个问题旁标注上你会如何处理。在不久的将来，这将是一笔宝贵的财富。

原文链接: http://secretsofconsulting.blogspot.com/2006/09/what-should-designers-know.html



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1540841

wanggenhu0

今天早上我在我写作中小歇的时候，做了个Kevin Alexander 的小测验：
http://www.writersdigest.com/articles/alexander_finishthatnovel.asp
测验的题目是很多年轻作家经常问我的一个问题：你真的能坚持写完这部小说？我们会了解，或者说发现，是什么导致了结束。

Anderson是以这样的开场白来开始测试的：

“统计表明几乎所有美国人都在写小说。但是有多少人能真正的完成它呢？这个比例非常小以至于用非科学计算器都没法算出来。你是精英么，是这些可以完成小说的少部分人么？”

在过去的两年里，我完成了至少8本小说，我试图验证这个测试。我的结果是：

“祝贺你。你是个有多产的作家，为了高质量的作品甘愿牺牲睡眠、欢笑和精力。你不仅可以完成自己的小说，还有可能记录别人的故事。你是不是Nora Roberts(注)？总之，你该歇一歇了。”

但是我并没有牺牲睡眠、欢笑和精力，那是怎么回事呢？测试有9个多项选择题，答案A对于“完成者”是“对”的。我选了8个A，但是1个D。D是最糟糕的答案。这是我的D选项：

Q：选择最能反映你日常工作日程的选项。

D．恩，我想，说我有一个“日常工作日程”，这有点冒昧了。

熟悉我Fieldstone方法的读者都会了解“日程”并不属于我，而“动机”才是我的。这就是为什么我认为Anderson的所有测试题目可以简化为唯一的问题和答案：

你决定写这本书的原因是因为：

<!--[if !supportLists]-->A.      <!--[endif]-->这正是吸引我的领域。

如果这是你的答案，而且确实是你第一个选择，那么你就会想尽办法完成你小说。其他的——金钱、名誉、你的日程——这些只是不同作家的细节问题。如果这个领域真的适合你，你就会找到克服障碍的方法完成你的小说。

如果这个领域不适合你，你也许完成了你的小说，但是它并不成功，而且你自己都不会满意的。
  
注：美国女作家，关于她的更多信息可访问 http://www.noraroberts.com/bio.htm
原文链接
http://weinbergonwriting.blogspot.com/2006/12/are-you-ever-really-going-to-finish.html


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1548885