02大道至简阅读笔记之二
第6章 谁是解结的人
第一节 是谁的问题
可见，在通常情况下，一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。特质的形成，是管理者的问题。他或者是主观地培养，或者是在不经意间形成，或者这根本就是管理者个人特质扩散开来的一种群体特征，但无论如何，维护有益于团队整体的特质，是管理者的责任。
注：团队特质可以简单的理解为企业文化。
第二节 正视你的成功
虽然发掘、彰显和维护这种特质是管理者的责任，但是并不是一个管理者来到一个团队大喊一声“我有特质”，于是团队就有特质了。一般情形下，管理者有个体特质，是管理者的问题，不是团队的问题。因此我们也注意到，很多人反对“空降兵”式的管理者。因为（大多数情况下）这些从天上掉下来的人，一开始就拿着自己的特质或以前团队的特质来“主动地”影响新的团队。他们最经常说的话是“我通常习惯这样这样”，或者是“我们以前怎样怎样”，又或者是“我原来所在的部门如何如何”。
成功的经验往往最不可信，因为一方面，成功者沉醉于成功的喜悦，并急于与人分享快乐与荣誉，而不关注这些成功的前提与背景；另一方面，听取这些经验的人则因为那些“既有的成功”而丧失了应有的警惕。
经验，是源于对过去的思考，而不是对过去的复制。面对那些在你面前说“我们曾经这样成功做过”的空降者，不妨先把他们想象成一条条肺鱼。只有提得出质疑，才能换个角度看到那些成功经验所依赖的背景，也才能看到某些成功背后的偶然的或者关联的因素。
每个走上管理者角色的人都无可置疑地拥有非常多的辉煌。对于这些，无论你是空降还是地面进攻，也许在你还没抵达这个团队的时候，大家就都已经知道了。但你是来解决问题而不是来分享成功的。你的那些成功经验，未见得都是可以或应该与团队分享的。如果需要，对失败案例进行分析，并与团队中的成员分享可能要好得多。
千万不要把自己的经验直接拿到项目中来套。“我曾经做过”、“我这样想过”、“对这个问题我思考过了”，这些言论只能把问题的根苗填实在团队的缝隙里。
第三节 总得先做点儿什么吧
团队特质如此重要，但看起来，它无论如何都会是较长远的事。管理者既然不能一开始就照搬某种模式，也不能立即着手去建立一种未知的团队特质，那么我们总得先做点儿什么吧？
首先，你的团队无论如何都需要有一个远期的目标（然而我发现事实上很多管理者并不善于描述远景）。团队的远景与目标不一定非得是“特定项目的特定结果”，例如远景不见得是你现在正在做或准备完成的项目。举一个例子来说，远景可以是“打造公司的精英团队”，或者“挖掘某项目技术在某某行业中的应用”这样的描述。前者以精神形象约束团队，后者以技术方向引导团队。远景的具体设定，取决于团队的结构、项目的特性和管理者的个人素养。
远景更多地侧重于方向的描述，而阶段性目标的确也是必须的。这至少有三个原因：
明确阶段性目标以便于团队实施和检测；
细化的设定目标更加灵活，便于修正；
阶段性成功能充分激励团队的士气。
但是无论对大的远景，还是小的目标，在团队中并不需要每个人都予以密切关注。所以对目标进行阶段性设定与回顾，是使这些“并不时时关注方向的人”也能体会到方向感的最佳方法。阶段性的目标在微软的工程中被称为“里程碑”，可见这是一种卓有成效的、实践性很强的工程方法。而我在Y公司工作的七年时间里，最终、也是最失望地离开的首要原因，是在那样长的时间里，我都只知道为谁工作，而不知道工作的目标--更高层的管理者从来都没有告诉我“整个公司（或我所在的团队）在未来的方向是什么”。
无论一个人是何等的努力与敬业，七年（或更短）的时间都不知自己在为什么努力与敬业，他也必将失去激情。
如果每个人都必须不断地调校方向与留心脚底才能跑到“正南方10公里”，那么“企鹅队列”是必然的结局。所以第二限定应当被分解成这样：最前面的人去看看有没有墙，其他人则关注脚下有没有坑--方向与远景不妨让大家都知道，但“保障方向”这件事，应该只交给头羊。
现在我们有了一个“起码像个样子”的团队。基本上来说，这个团队有三点特性：
方向和目标明确；
团队并分工协作；
能意识风险并有规避策略。
第四节 你不是团队的腿
无论他如何陈述理由，产生这个结果的内在因素只可能有两个：
他根本不再对10公里之外的风景抱以期望，甚至认为那不过是望梅止渴的幻想；
我现在就有点这种思想，老是认为我们的SIP不如sipp，做起来没意思,不抱希望！！！
他消耗了相当的体力，接近极限而无法再坚持。
如果“头羊”是技术经理，或者是团队中的某个“精神领袖”，那么（作为项目经理的）你就是教官。你的工作主体是：协调、督促、激励、监督和凝聚。--当然你还可以做些别的事，例如去操场外给大家买些冰水。然而有一件事你绝对不能做：试图帮那个说“跑不动了”的人跑下去。
你不是团队的腿。
大凡是从技术出身的管理人员，总会有愚公那种本能的“实现欲望”。如果一件事自己能做而别人不能或者做得不够好，那么他总是恨不得自己去做。的确，对于一些技术细节来说，你“也许”能立即着手去解决。但是，一方面你根本不可能通过“亲力亲为”解决掉“团队行进”的问题；而在另一方面，你至少为团对带来了下面这四重危险。
首先，你应该让团队的每一个人清楚：“我”必须跑到终点，否则“团队”倒不了终点。这是每个个体的责任，没有人可以替代--这是培养责任心和树立价值观的事。假使你真能成为这个人的腿，“跑”到终点，那么这个团队的成员将会质疑自己的价值和能力，也会忘记自己的责任。一个人如果在团队中没有价值，也没有责任，那么他离辞职也就不远了。
接下来，培养一个最怕的是“教而不习”：你教他，他要么不学，要么不用。但是，事情的真相，不见得就是这个“懒”到不学习，而是你过于勤快，让他失去了“习”的机会。所谓学习，就是让他在过程中看到问题，并了解到解决问题的方法，最后解决之。例如“累得跑不动了”的问题，你应该告诉他，可能是因为：
呼吸没有调匀；
使用嘴而不是鼻呼吸，伤到了肺；
出汗过多，导致缺盐；
脚与地面的摩擦过多，无谓消耗；
你现在应该注意到：如果你真的帮他跑到了终点，那么他将无法知道这些；或者他即使“学”过这些知识，也无法将现在的疲劳与它联系起来。正是因为你愚公式的勤奋，使团队成员失去了“习”的机会。另外一方面，事事亲历亲为虽然容易服众，却也容易滋长集体的惰性：团队成员如果只能把你、把项目、把公司当成学习观摩的场所，自然于项目无益，于团队无益。然而，你还愤愤不平：这些人怎么又懒又笨，什么事都要我动手。--如果团队在你面前只是愚公的集合，那么可能是你出了问题：不会教习，或过于自负。
在sip项目中我是否犯了这个错误？
今天看到鲁这儿管那儿问，我心里有点不舒服，好像这样显得自己在项目中重要性降低了似的，实际上，当初我也不是这样么，现在终于能理解当初小泉和刘海寅对我的那种微妙态度了，其实我必要这样嘛，找到自己的位置好好干就行，没必要在意是谁在那儿打杂！再说了，鲁在项目中的时间也比我长，也应当由他负责，机会均等嘛！
在接下来，于一个人而言，“成功”的激励远大于其他。一个人从来没有享受过登顶的乐趣，那么他一定不会喜欢登山的过程。而你帮他跑到终点，事实上也剥夺了他作为团队成员来分享成功的权利（虽然项目奖励可能不会少，然而这只是形式的，而非内心的所得）。让一个人总是去做“没有成就感”的工作，他必将渐而生厌，你也无异于自毁长城。
最后，你过于强调的个人能力，这会助长团队的惰性。团队管理是促进整体行进的过程，因此基本上来说，你的行为事实上是在暗示其他的团队成员“你们也可以不跑到终点”。这种暗示的结果，是管理层变成了执行层。由此，原来的执行层变得效率地下，而管理层疲于奔命。你忽略了管理自身的价值，以及你作为管理者的工作内容，因而为整个的管理过程种下了恶因。
对于团队来说，“解决掉一个技术问题”，远比“团队的整体行进”次要，因此你不要冲在前面披荆斩棘--把这件事交给技术经理去做，或者教而习之，由成员去做。你首先要明确自己的责任是“整个团队的目标”。
如果你真是好的教官，如果你关注于“整体的目标”，那你应该早早地发现这个团队或某个个体存在问题的“原因”（例如奔跑时的姿势不正确这种技术问题，或者某个成员垂头丧气这种情绪问题），而不是等到有人倒下，才去解决“跑不动了”这种问题的“结果”。大多数管理者并不是因为能力不够而做不到这一点（哪怕这看起来好像是“未卜先知”的神术），而正是因为你过度陷于实施，无法履行你的监督职责--因为你不可能监督自己。
应该记住管理者的责任也包括“监督，发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题，在问题出现之前定位它、分析它，并组织人力去解决它，而不是：
等到问题出现之后再去冲到前面；
然后在还没有清楚地意识到问题的根源时就试图解决之；
最后刚解决了表面问题或者侧面问题，又发现更多的问题挡在前面；
最后之最后，你垮掉，团队也垮掉。
如果需要，你不妨去真的买几杯冰水。你也不妨从这杯冰水开始，思考管理一个团队的方法与技巧。
第五节 三鼓而竭
“三鼓”这样的傻事大家都经常在做。例如老板请吃饭，几次下来大家就都习以为常了；又如月奖、年奖、项目奖，到后来就都成形式了；......
这还是外力的“鼓”（激励），打不了是让人觉得厌烦或者无视而已。我们下面来说另一种情况。
我知道有很多管理者习惯否定别人的想法，而不是肯定之。这个问题的根源，一般是由于管理者从技术出身，因而总是主观地认为自己“有更加绝妙的想法”。但是，不管你的想法是否真的“绝妙”，从管理的角度来说，这种“否定别人”的做法，其实是一个非常愚笨的主意。
这源起于不同角色“做事”的态度：管理者做事是不怕不做，怕一步错，步步错；而开发者做事，则不怕做多，不怕做错，最怕不做。这种差异，形象地说，就是“管理这是绵羊，开发者是愣头青”。然而，如果老绵羊又正好是摔了一头包的愣头青，或者自认为比别的愣头青更有思想的愣头青，那么他通常就会站在别人面前，说：“你这样不行”。
然而这样的管理者无形中忽略了两个问题：
如愤青一样，愣头青之所以“楞”，多是因为激情之故。然而少了激情，再正确的决策也难以有效实施；
“行不通”只是你对事情的评估，而不是实施过程中的观察。因此“行不通”三个字难以说服于人，也未必真就如此。
这两个问题，一个是说“情当如此”，另一是说“理当如此”。为什么这么说呢，我们先来看看这个愣头青在做这件事时的情绪因素：
首先，他与你讨论，就证明他积极地关注这件事，这比漠不关心，人浮于事要好；
其次，他能够“有想法”，这证明他已经主动地在事件过程中发现问题，比视而不见的人要敏锐；
接下来，他敢于向你“提出”想法，这证明他能够打破管理边界，向上层管理层主动沟通，这是团队中的良好品质；
再下来，他能够“主动”寻求解决问题的手段，这证明他能独立思考，并且比别人更有主见。
一个人如果具有“积极、主动、敏锐、主见”这些良好品质而不被认可，那么无疑是令人沮丧的。久而久之：
他会自我否定，并学会放弃，再也没有勇气提出任何东西，变得人浮于事；
你将继续听到更多的意见，他勉力抗争直到你改变或者他离开。
第一种情况：你牺牲了一名优秀员工，而成就了你的自负。第二种情况，鱼死网破。
根本上说，“怎么做一件事”是一个人的态度问题、性格问题、品性问题。团队成员能有点想法，本身就是值得提倡的：想法成熟，则对工程进展有推动（如改进工程技术、方法）；想法不成熟，善以用之，则可以对团队建设有推动（如进行团队教育、激励）。因此，万不可拒“意见（或想法）”于千里，把团队“自下而上”沟通的道理给堵死了。--你在牺牲团队成员的同时，是失去了建设团队特质的机会，二者之任意，都是你作为管理者的失职。
现在开始，你不妨把这个愣头青看作愿意“贡献集体智慧”的表率，从他开始，为团队内部的积极沟通带个好头。至于接下来如何讨论：认同他、引导他，或者说服他，那才是“理”问题。
态度可以认可，至于“想法好不好”是技术问题。你不宜急于表态，因为团队中还有头羊，还有“精神领袖”，实在不行，还有“聚师而谋曰”。
即使所有的讨论都倾向于对这名员工的否定，你仍然可以给出一个机会来让这名员工去自我证明。这种机会可能只是几个小时或者一两天的技术探索。这种情况下，如果他能够证明他的正确，那么他会感激这次机会；如果结论是他错了，那么你无形间树立了自己的威信--这件事，只是说“不”，是做不到的。
第六节 先人后己
让一个管理者向别人说“忙”，是一件很惬意的事。“有得忙”才证明重要，成天无事可做的人，存在的价值（起码看起来）也就小得多。所以多数管理者试图从一早到公司，就让自己显得“很忙”。然而，先不论这种状态背后的心理因素，管理者一定不要忘记在开始“忙”之前做一件事情：驱动你的团队。这就是我所谓的“先人后己”。
如果他先人后己，在开始自己的工作之前就来招呼大家了：安排每个人的工作，或者解决某些人的问题，那么这会是美好的一天。然而，如果他总是等到发现很多人无所事事时，再来找大家的茬儿，那么这个项目经理离离职也就不远了--当然，也有可能团队会面临解体，他的项目经理自然也做不成。
这个“让影响到别人的事先做”的思想，与“团队高于个人”的观念是一致的。然而有很多人、很多时候不能分辨一个问题是自己的问题，还是团队的问题，因此也不能正确地决策其先后。这种情况下，我只建议你装得很闲，或者希望忙里偷闲，问问自己：“如果这件事不做，会如何？那件事不做，又会如何？”找到影响面最大的一件，交给别的人（或者）大家去做，而自己做“不是太重要”的那件事就可以了。
更退一步说，即使你什么也不做，也比整队人马停下来要强得多。
即便如此，也还有一种“先人后己”是你容易忽略的：奖励，也要先人后己。
Soul随后谈了他认为“不错的”原因。他说：我们的工作量未见得多于程序员，而薪水可能比人家高，并且重要的是，我们站在管理的前端，能得到的机会自然就比别人要多。团队成员其实比我们付出得更多，而得到的更少。因此，我们应该把荣誉真实地反馈给团队，而不是贪为己有。
做事时固然要“先人后己”，面对成功与荣誉时也要“先人后己”。前者得以完成团队建设的重任，后者则表达你对团队价值的认可。
对于像外包这种情况，我如何“先人后己”呢？交给他我不太放心，毕竟他的责任心可能没有我的强。
答：看了第七节就可以找到办法了，因为它不是个问题。你想做一个优秀的管理者，连一个外包都利用不好，谈什么管理呢，好机会呀！
第七节 自相矛盾
看看我们都说了些什么？我们在说你有了一个团队，然后从团队的特征开始，我们谈到了组织、沟通、激励和执行。是的，这些都很重要。但我们还漏掉了一个重要的环节，那就是“问题”。如果团队中没有“问题”，那么看起来就不需要管理者了--你大多数时候是被找来解决问题的，不是吗？
乔丹认为这是一种主观与消极情绪的区别。而我看来，这就是问题的定义。伟大球员和普通球员的差别，就在于伟大的球员总说：这不是个问题。
所以温伯格是对的：“你认为这是个问题，它就是个问题”。
我不知道我所呆过的那么多团队，为什么总是存在这样那样的矛盾。例如，员工与员工的、员工与老板的、进度与质量的、技术与市场的.....你会发现，你总是在利益、正误等这样的问题之间权衡，这些选择带来了你的痛苦：也就是我们所说的矛盾。
换而言之，你的“认识”决定了问题，你的“选择”导致了矛盾。
之所以“矛盾”看起来也是一种“问题”，是因为矛盾通常是你无法取舍、无从选择的感觉--这种感觉来自于“你期望选得更正确，但你感觉你无法做到”。
是的，我正要说：温伯格又对了，这是你的预期与体验的差异。温伯格接着说：“要想解决问题，要么改变期望，要么改变体验。”是的，你现在就可以“放下”，改变你的体验（的需求），从“不要认为这个矛盾是问题”开始，重新设定条件。例如：不要用矛来击盾，而是用矛、盾以击敌。如此，岂不是可以尺长寸短，尽可用之。
所以学会否定矛盾、消化矛盾，看到矛盾产生的内因外因，转而借之用之，才是解脱的方法。
比如我现在碰到的问题--我们自己做sip根本没有sipp好，所以我有消极情绪，认为是决策者调研的败笔（你认为这是个问题，它就是个问题）。照作者的意思，是不是该这样，首先我不要认为这个矛盾是问题，这仅仅说明我们还有相当一段路要走，心态要积极（从“不要认为这个矛盾是问题”开始）。现在我们可以把我们做的sip当作盾，sipp当做矛，我不要用sipp来击我们的sip。而是分析sipp的优势、劣势，以及sip和它的差距、优势等等方面（看到矛盾产生的内因外因），把这些东西考虑到我们的sip中，即转而借之用之（不要用矛来击盾，而是用矛、盾以击敌；转而借之用之）。这才是解脱的方法吗？
还有最近遇到的让我改周的问题单，我对他的方案不认可，写得那么复杂还让我改，我认为其是个问题。但是，为什么我一定要认为它是个问题呢，我干嘛不当做是了解别人思想，练习看复杂代码的好机会呢？确实，你认为这是个问题，它就是个问题，你认为它不是个问题，它就不是。
第七章 从编程到工程
第一节 语言只是工具
然而，这是我自1997年接触到管理，以及1998年接触到工程以来，第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系！
对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句“语言只是工具”。
第二节 关注点
从这个模型中可以看到，在“程序”与“方法”层面，是关注于“（具体的）实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。
以前我当的小组长算是什么角色呢？我看可能还是偏重与开发经理一点，毕竟是负责具体的开发行为。
第三节 程序
EHM模型图中，在最内层的环里，是“程序=算法+结构”。这是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。
第四节 方法
你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。
同理，理解过程也需要编程经验，理解对象也需要编程经验，理解MDA（模型驱动架构）与SOA（面向服务的体系架构）还是需要编程经验。
这可能就发生在你去回顾你的上一行代码编写的经过，或者上一个项目失败经历的那一瞬间。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。
第五节 过程
过程伴生工程而出现。过程解决的是工程中角色间的关系问题。
因此过程中的问题，就是角色、沟通和环节的问题。
哪些环节重要，取决于具体的编程行为，也就是具体的项目。
分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。
角色的确定，以及角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互的协作是否紧密，是这个项目能否成功的保障。
注：过程指RUP,XP,模型与模型语言等
第六节 工程
过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的呢？
很显然，软件规模的不断增大是根本的原因。.......
注：工程指需求管理，过程管理，配置管理，文档化等
第七节 组织
所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
注：组织指管理，计划等
第八节 BOSS
很多人以为BOSS是给自己发钱的那个人，这其实是错误的。发钱的决策通常是由以下三个角色来做出的：
部门/团队经理：你的直接上司，他是雇佣你的人，是他用薪金的多少来衡量你的价值，或者反之。
绩效经理：如果你的公司有这个角色的话，那么他总是盯着你的错误以决定你薪水的扣除比例。
财务经理：有钱？没钱？没钱？有钱？
是不是应该在日常工作中有意识地在直接上司面前表现表现？比如主动承担工作，而不是被动地等着上司安排！我对外包也是希望别人主动，那么我的上司肯定也希望我主动，这段时间看起来鲁比我表现得好一些，他主动替标哥分担问题单，我看来得找点措施弥补一下，比如功能测试计划。
BOSS在公司中解决的是“经营”问题。这其实是在比“组织”更靠外侧的一层--在前面的图例中并没有给出，这也意味着“经营者”与“工程”基本上没有关系。
第九节 上帝之手
软件工程的体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。
第八章 你看得到工具的本质吗
第一节 利器何以为先
由此可见，使用工具的方法，比工具本身更关键。所以“欲善其事，先利其器”这样的言论，未见得是全对的。
第二节 神乎其技又有什么用呢
秦无剑技而一统天下，宋有康肃而痛失半壁！不知用法，不知用处，如同那习得屠龙之术者一般，神乎其技又有什么用呢？
第三节 工具的本质
如同工程与编程，单以编程而论，讲究技法之精妙，追求细节与枝节是可以的；单对于工程来说，能让团队理解、统一执行、迅速有效的实战技法，才是真实所需的。就像战争一样，团队化的工程中，技法的优劣并不是关键。关键在于某种技法是否能为团队带来整体的成效，而不在于某个人是否喜欢，或者深谙于此。如同陈康肃公，有当世无二之技，不能用于“群战”，也是无益。
工具之于工程，本质在于关注并发挥得益于工程全局的那些特性。一人一技，一器一物，又岂能是工程的要义？因此，我们最终看到拥有利器巧技的六国都不在了，最后只剩下一个强秦统一了天下。
我对作者本章的观点严重不敢苟同，照作者的意思，好像是因为六国有了利器巧技才导致其被秦所灭的，六国就什么都不干，就专注于造剑了？我拥有利器巧技有什么错，只是无善用者而已。六国被灭，主要是和人相关，和它拥有利器没有任何的关系。二战时的德国，最先拥有潜艇等先进武器，为什么战败了呢，是因为它拥有先进的武器吗，不是。在抗战中，为什么新四军那么喜欢三八大盖，那么喜欢重机枪，在《人间正道是沧桑》中，为什么杨立青要造那么多大炮？所以啊，这个地方是作者为了迎合写书而硬是牵强地贬低工具。
我认为“欲善其事，先利其器”是没有一点问题的，你不能因为工程的重要性就贬低工具的作用！
第四节 唯手熟尔
很多的高手，对于工具的本质并不是了解的。他写程序快，只是记忆中读过的、写过的代码多于别人；他思考问题比别人细致，只是因为他有过比别人更多的错误；他能带领项目团队，只是因为他经历过足够多的项目团队。
这样的人可以算是能人：有能力的人。但未必真有识见，真有才略。
“尔安敢轻吾射！”当我在论及RUP（Rational统一过程）、UML（统一建模语言）这些具体的工具只是“工程之末”的时候，很多人愤而所言，与当时陈尧咨说过的话，又是何其相近？
我还是不敢苟同作者，手熟，不就是我们平常所需要的经验么？！没有经验，看你哪来的真知灼见！！
第五节 鲁班带了坏头
鲁班这种典型的“工匠思想”，总结下来有三个问题：
以良匠之名为目标，而不是以做工程为目标；
以工具之利为恃仗，却不关注工具用在哪里；
以技法之巧为较量，却不知技法应为团队所用。
现在来看，这不都是大多数软件开发人员（和技术人员）的问题吗？
不敢苟同。鲁班就想成为良匠，这有什么错吗，他的角色就是这样。比如造大炮的人一定要去关注大炮在哪儿用吗，如果人人都去想大事，想管理去了，谁来做这些基本的工作！！简直是瞎扯淡嘛！
第六节 工匠思想
软件开发圈子中，持有这种“工匠思想”的鲁班门生历来不缺（很遗憾，其中也包括我）。
只不过大多数人把这种“工匠思想”的来源看成“八九十年代的个人英雄主义”。他们认为这种思想是一种现象的延伸，而不认为是一种“开发人员的本质特性”。
鲁班的虚名，给工匠们设定了用以安身立命的目标：成为良匠。我尽管要说，这是一个坏的表率；但也要说，这的确是好的品质。
为什么呢？
我曾经在给CSDN的一篇文章中写过：
“如今业界天天都在讲的，除了模型分析就是架构设计，再远一点的就是管理的艺术与实践。诚然，这些都是好东西，都该逐一细论。然而如果连程序员都去思考模型、架构与管理艺术了，那么个体终将是个体，每个人都是分析师、设计师与项目经理，则项目自然做不成了。”
所以在我看来，不同的工程角色的确应当有他自己的关注点。这个角色能考虑到别人想不到的问题，固然不错；但如果他格尽职守，只关注自己的那一部分，也是本分。
我们在EHM图中说，工程体系的第一个关注点是“实现”。也就是说，你可以是“关注于自己能否成为良匠”的工匠，但是作为工程角色，你起码应该关注“如何实现”。放在项目中，具体的要求其实就是：一项技术是以完成工程需求为目标的，而不是彰显个人技术为目标的。
对于管理者来说，重要的并不是“让大家都关注工程的每一个方面”（这事实上也做不到）。工程管理者应当认识到开发人员的“工匠思想”的本质，并善用之。如同我们前面说的，你认为工匠思想“是个问题”，它才是问题。
我在Y公司和N公司都遇到过这样的例子。某些开发人员是编程高手、技术尖子，因此一些管理者想“发挥他们更大的作用”。于是将他们提上高位，许以“经理”、“副总”这样的职位和职责。但这些人要么工作不得力，要么工作不开心。最终工作没有做好，员工也没有得到激励，反倒破坏了组织结构。
在很多公司看来，“当官”可能是对员工的最大激励。然而身处官场的人又如何能理解技术人员的思想呢？其实很多的开发人员，无非是追求更宽松的工作环境、更好的学术研究氛围。换而言之，他们根底上就是关注于工具与技法的。
如果公司不能利用这些“本质特性”，非要设定他们的“仕途”。那与以矛击盾有什么区别呢？--我们说过，大多数矛盾都是自找的。
公司应当给出员工“在技术方向上的发展路线”。很多大公司在这一点上其实做得不错。他们把技术职级与管理职级分开，使得技术人员可能通过技术提升来得到与管理者相近的薪酬。但事实上，管理者整体的薪酬总是高于技术群体的，因此薪酬的激励终归有限。对于开发人员来说，吸引他的是无限的发展空间。例如当初微软打算用三百万年薪和数万股票从Borland挖走AndersHejlsberg，未果。后来，盖茨提出给他一个小组和极多的资源，“让Anders尽情地发挥”。Anders这才动心，从此就有了VS.NET。
Anders显然是无可争议的、最优秀的程序员，
第七节 化而用之，融通与融同
“融通”与“融同”的区别在于：前者以一通十，有运用变化的能力；后者则知工具之大同，信手而得，随心而用。
无所谓是什么，只在乎它能不能用。
于某时某事，适用的就是最好的。前提是你要看明白这些工具实质的能力。只要能够分辨出所需部分、适度地用在你的工程中，就可以了，......
明白这些工具实质的能力也是要花时间的，白痴！
第八节 南橘北枳
然而对于确定的项目来讲，只有对这个项目有用的那些“功能”，才是这个工具的价值所在。所以，识见到工具“设计”所满足的那些“确定的需求”进而明确工具与项目的关系，才是解脱之法。
第九章 现实中的软件工程
第一节 大公司手中的算盘
大公司在标准、理论、语言上的争来争去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企
图，其最终目的是在整个软件工程体系中的全面胜出。
在整个软件工程体系中的全面胜出能获得什么益处？
第二节 思考项目成本的经理
愚公如果停下来，思考的问题可能是碎石的“方法”。而项目经理从细节中跳出来，思考的问题就应当是完成工程的“方法”。评价这个方法的好坏的标准只有一个：节约成本。
思考成本，这是D先生给我的教训：
不计成本的项目计划不会得到经营者的支持；
毫无目的地消耗成本是项目中的慢性毒药；
最致命的风险是成本的枯竭。
我经常注意到的成员因素包括时间、人力、资金和客户成本。而大多数情况下，人们不会把客户的数量及耐心当作（客户）成本来计算。而在我的项目规划中，这是成本。
第三节 审视AOP
AOP不是语言。AOP首先是方法论，这就像OOP是“面向对象的编程方法”这种方法论一样。......
所以接下来AOP的三个概念我们就明白了。
指示/拦截器：考察这些对象以“达到什么样的目的”（即需求）；
引导：在目标上实现这些需求时，目标所需要表现出来的公共特性，引导特性可能需要配合编译器来实现；
元数据：如果需要，为即有对象实体再补充一些参考数据。
第四节 审视MDA/MDD
MDA（Model Driven Architecture）也是一个方法论层面上的名词。它讨论的是“创建出机器可读和高度抽象的模型”的方法。受MDA影响的开发活动被称为MDD（ModelDriven Development）。
我不厌其烦地罗列这些名词，只想告诉读者一个事实：什么都可以“驱动开发”。
回到软件工程的过程环节来吧，你会看到“以什么驱动开发”只是一个“以哪个环节为中心（或导引）”的问题。
抛开实现的技术细节不论，在工程中，“以什么驱动开发”其实是一个过程问题。而你应该明白，过程的选择（或制定）取决于你的工程需要，以及它在相关领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司们的鼓吹。
也就是说，MDA架构作为一个新的软件开发方法的架构，即使在技术研究、底层协议和软件实现方面经过了持续地完善地而渐直成熟，然而如果没有同样成熟的软件过程理论支持，那么它在工程中的实用价值一就有限。
仔细审视一下这个MDA，如果你现在就决定将下一个项目建立在这个架构的基础上，或者用MDD的方式来开发BIOS,那么你离精神病院就不远了。
第五节 审视AP和XP
因此，AP以及它的核心思想“敏捷软件开发宣言”，是以实现、实施、实践为主要手段，以体现人本为主要内涵的行为准则。主要表达在：
一个人本化的、共有的团队特性与气质；
一个契约式的团队组织结构和领导风格；
一些以“解决问题”为中心的思想方法。
XP实质上是使团队遵循这些“行为准则”的一些“形式化的方法”。当然，XP在对一些工程要素的权衡上，也给出了建议和实践结果。但这并不是具体的过程方法，也就没有逾越或颠覆瀑布模型。
“敏捷”，其根本的思想就是用最快捷、有效的方法完成工程。因此，你可以把在“包含瀑布模型在内的”任何过程模型上，基于上述表达进行的开发实践都叫做“敏捷工程”。
第十章 是思考还是思想
第一节 软件工程三个要素的价值
“牛粪图”中描述的工具、方法与过程也被称为软件工程的三个要素。在本书中他们被分解开来思考，并不是要孤立这三个层面--他们实际上是相互作用的。
例如“过程”问题，就既有实施过程的工具，也有相关的过程方法理论。
你能把每一个“管见”拼合起来，你得到的才能是“豹”，而不是“斑”。所以尽管本书割裂了软件过程的各个要素，并从每个孤立的层面来审视。然而实质上，你应该回归到软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。
工程的整体问题仍旧是“实现”。
第二节 其实RUP是一个杂物箱
我或许总是在批评RUP，但是我不得不承认它是对前人在软件过程思想方面的高度包容。
请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那你应该把目光投向瀑布模型，而RUP其实就像是一个杂物箱一样“包容”了全部的已知理论。
RUP能不能被用起来，将取决于你刚才那个挑挑拣拣的行为，以及现在你在拿到钓竿后的辨别能力与组织能力。
啥意思？
第三节 UML与甲骨文之间的异同
在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。
在这本书里，他们都被作为沟通的工具。因此目标是沟通，而不是“选用工具”这件事本身。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳子记事的原始人面前去用它。
所以在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。
第四节 经营者离开发人员很远，反之亦然
EHM真实地反映了“老板不懂技术”的合理性，同样也真实地反映“开发者转型为老板”的道路将是相当漫长与艰难。
于是，项目经理这个中间角色就有了一种使命：协调经营者与开发者之间的沟通。
你要理解这种根源：角色的关注层面完全不同。
第五节 矛盾：实现目标与保证质量
需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚，或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的，那么他们便会开始埋怨客户的苛刻及工期的紧张。
总之一件事，没有人会跳出来说：我们原本就错了。然而事实上问题可能真的处在源头：我们把目标定错了。
我们看到，在项目的平衡三角（时间、资源和功能）中讨论的是目标问题，但并不讨论质量问题。
如果原定的目标（的整体）本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保证不了质量。
问题是：又有谁愿意在最初签订协议的时候，就降低或者放弃协议的标的呢？
那我们该咋办嘛？
第六节 枝节与细节
刚才说到目标与质量的问题时，提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说，它是一个具体的方法，而不是目的。
大多数情况下，管理人员有责任去审核、评估其他成员的工作成果。这个时候可以讨论“细节决定成败”这样的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。
而在另一些情况下，例如管理人员做事件的决策的时候，就必须要学会忽略枝节问题。
比如在做架构设计决策时，像按钮图标好看不好看这些细节估计就得忽略，而在具体地实现这个按钮时，估计就得关注了，否则版本一发布，可能就因为你的一个图标而显得不够专业。
因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖(chuo)，就快点回头。
沾上了泥淖(chuo)是什么意思？回头是什么意思？
用脚趾去感觉，有时比用头脑去思考来得有效。
第七节 细解“法”与“式”
软件工程学科中的很多思想与其他传统的工程学科既有的思想、方法和理论有紧密的关系。所以甚至有些软件工程角色被推荐去阅读类似于《建筑的永恒之道》这样的书。......
我得找找这本书翻翻？
由此看来，《营造法式》中所解决的问题，与我们今天的软件工程中所遇到的问题如出一辙：
工程管理者不能兼通各个工种；
不同的开发人员对设计和只做的理解不仅相同。
那么《营造法式》是如何解决上述的两个问题呢？
这就回到了“法式”这个词的含义上来了。法式二字，是宋代官方文件的常用词，法指“律令”、条例，“式”指定式、方法。所以《营造法式》颁行的初衷，是希望能有办法将工程中所用的元素：
“按类分别排出，有条例规章作为依据”；
“按照条文画成图样，对将来的工作有所补助”。
那么，我们怎么能指望在某种（或几种）过程理论，以及一些模式方法之上，找到一个能一成不变的办法去实施我们的软件工程呢？
相较于《营造法式》，我们的软件工程实践类学术专著仍然非常粗糙，未必能像“法式”那样值得趋从跟随。当然我们也不应当因噎废食，妄论优劣。因此对于“某某模式”与“某某模型”之类，我们的态度仍然是“与式不同，比类增减”。
“与式不同，比类增减”是啥意思？
第八节 灵活的软件工程
“未蕴而变，自欺也。知律而变，智者之道也”，实为良言。
“知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知就里地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好。而真正的问题在于，这些人（我们通常叫做Copy&Clear）并不知道这些技巧，技术和方法的原理，因而不知道变通，也不知道回避错误。
有时确实是这样，比如我可能会简单地使用多媒体定时器，但是上次关闭定时器引起程序崩溃的问题，我就抱怨是多媒体定时器没设计好，实际上我知道，应该是我没使用对，为什么没使用对呢，那就是我对其原理理解不够。但是，有时我们确实没有那么多时间去研究透一个东西，我们该如何选择呢？
浙公网安备 33010602011771号