作者：netcasper 来源：CSDN博客 酷勤网收集 2007-10-21
一次偶然的机会知道了迈克尔•波特，当时他作为嘉宾参与了中央电视台制作的《对话》节目。那期对话我看了两遍，深深为波特的学识和执着所折服，于是买了他的《竞争战略》来看看。
《竞争战略》系统地提出了一套指导公司制定竞争战略的框架。Framework可是程序员最喜欢的单词之一，就冲着这个词也得看看它都说了啥！全书共分三篇十六章，刚刚看完第一篇共八章，就忍不住要跳出来说点什么，因为我发现它不仅仅能够指导公司制定战略，甚至可以用这套理论指导我们的职业发展。公司里同事之间的关系，正如产业里各个公司之间的关系一样，是既竞争又合作的。我们做着同一个项目，却又争夺着有限的加薪、升职机会。我们所处的环境是相当复杂的、又是不断变化着的，多种因素交织在一起影响着我们的竞争能力，要想在这场较量中胜出，我们不仅要有一个明确的、恰如其份的战略，更要学会一套能够指导我们制定战略的工具。
不知道程序员是不是一个工作环境相对恶劣的职业，至少，做这一行的人相对喜欢抱怨环境恶劣，毕竟，软件行业在中国才刚刚起步，有太多的不规范之处。不过，我不打算在这里讨论这个问题，仅摘一段The Art of Unix Programming里的话，送给那些仍被其困扰的同行：
Software design and implementation should be a joyous art, a kind of high-level play. If this attitude seems preposterous or vaguely embarrassing to you, stop and think; ask yourself what you've forgotten. Why do you design software instead of doing something else to make money or pass the time? You must have thought software was worthy of your passion once...
To do the Unix philosophy right, you need to have (or recover) that attitude. You need to care. You need to play. You need to be willing to explore.
看到这个once的时候我被深深地感动了，不仅仅因为它让我联想到了“曾经有一份真诚的爱情摆在我的面前……”，而是因为它让我再一次认真地想一想，是不是要沿着这条路走下去。
我一直坚信程序员就是我所想从事的职业，可以实现自己的价值，而且现在的工作环境不错，有相当大的自由度，但是在日常工作中，却时常会有挫折感。我清楚地知道自己想做什么，可是我不知道自己所想做的是不是能够得到同事，甚至是公司的认可，是不是可以凭借所做的事情获得相应的回报。我知道必须和同事合作，但是又不得不和他们竞争有限的加薪机会；我希望能有一个长期的、持续的发展，但是竞争的存在使得我不得不做些短期的工作，使年度总结不至于太苍白，我知道得平衡一下，但却不知道到了哪里才算平衡。
我越来越觉得个人的发展与公司的发展之间的差距没有想象中的那么大，可以试着学习一些发展公司、甚至是发展经济的知识，也许可以帮助我更加有意识地发展自己。毕竟这是一个经济的世界，关于经济的理论应该有着更广泛的用途。这是我第一次尝试着用专业之外的知识指导职业发展，我将以自己为例，运用《竞争战略》第一篇里讲述的理论，剖析竞争环境，制定竞争战略。
形成竞争战略的实质就是将一个公司与其环境建立联系。——《竞争战略》
《竞争战略》第一章名为“产业结构分析”，指出“一个产业内部的竞争状态取决于五种基本竞争作用力”，即“进入威胁、替代威胁、买方侃价能力、卖方侃价能力、现有竞争对手的竞争”。显然，直接套用是套不上了，不过，倒是可以借鉴一下波特的具体分析过程。
进入壁垒和退出壁垒
这两个壁垒的高低决定了职位的竞争激烈程度。进入壁垒越低，潜在进入者选择这个职位的可能性越大，竞争越激烈。这个道理很直观，就拿我从事的编译器开发为例，通常情况下编译理论被认为是计算机科学里最晦涩艰深的学科之一，大多数人学过就忘了，唯一记得的就是难学。这样的话，即使有从事这方面工作的机会，也会选择放弃。那是不是进入壁垒高了竞争就不那么激烈呢？也不是，还要看退出壁垒。想想看，我费了那么大劲入了门，谁要是让我改行我还不得好好寻思寻思啊，总不能让前面的心血白白浪费了，怎么也得把投资回收的差不多啊。在我看来，那些偶然进入编译器开发领域的人，要么知难而退、早早退出，要么越陷越深，不忍放弃；而真正促使竞争激烈的，是那些有意识地进入这个领域接受挑战的高手、天才。由于人才难得，做这一行可以获得相对高薪；可是高手云集，要取得成就，有所突破就很难，容易产生挫折感，“既生瑜，何生亮”是最贴切的描述。
其实壁垒不仅仅是技术上的，还包括感情上的，尤其是退出壁垒，很多人也确实是这么想的，想想都做了这么久了，有了感情了，索性一直做下去，不再换了吧。而转换成本是进入壁垒中的一个重要因素，我们可以从两个方面分析它，一是跳槽后做同样性质的工作，虽说工作内容在理论上是基本相同的，但形式上却可能是完全不同的，这时就要花费一定的力气去熟悉它；另一方面，老板找人替换我的代价也可以看作是转换成本，比如提出“软件蓝领”概念的人其目的就是想获得较低的转换成本。显然，转换成本越低，竞争也就越激烈。
在意识到自己的强项与弱项以及处在什么样的环境之后，就可以给自己一个清晰的定位。进而，可以采取相应的行动影响壁垒，使其向着能够提升竞争力的方向发展。最后一点是必须关注整个行业的变化，因为行业的变化会引起壁垒的变化，进而影响我们的相对竞争能力。
以我自己为例。
2003年毕业后一直从事编译器开发工作，属于入门级选手。当初选择这个方向是因为确实对它感兴趣，很想知道编译器这个程序员最重要的工具都做了哪些事情，如何做的。在国内，做编译器的厂家不多，而以编译为研究方向的实验室在大学中也是凤毛麟角，因此，新入行者（包括我在内）相对于编译领域来说多数是白纸一张。所以，进入该行业的壁垒并不是对编译理论的掌握程度（技术壁垒），而是取决于转换成本。那些能够使得招聘单位转换成本尽可能小的人必然成为优先选择对象。
既然编译领域机会少，难度大，属于进入壁垒高的行业，自然选择这一行业的人也就少。我相信编译领域也属于退出壁垒比较高的行业，因为有太多的人不十分了解编译却仍然成为优秀的程序员，可见编译知识的应用领域不算广泛。双高造成了行业内部竞争十分激烈，使我处于两难境地，一方面我很喜欢这种工作，另一方面又很难出人头地。
到这里不得不提一下读《竞争战略》的最大感受，就是所有分析只是为了唯一一个目标——获得利润。十分理性，也十分冷酷。我想我也不得不做出“鱼与熊掌”的选择，只是现在还不知道该放下哪个好。说实话我觉得出人头地的想法有点虚荣，但克服它又很难。至少得做出点能获得大家认可的东西吧。
当然，如果更深入一点，还是会发现能够扬长避短的方向，只是需要一点点耐心和洞察力。不过这个还是留到以后再说吧，敬请关注。
有效地贯彻任何一种基本战略，通常都需全力以赴。——《竞争战略》
继第一章提出五力模型之后，波特在第二章提出三种基本战略——总成本领先战略、标歧立异战略(differentiation)、目标集聚战略 （说实话，这三个词翻译得有点别扭。）。
没有想出在软件开发上有什么概念可以与成本相对应的，先不考虑第一个战略。后两个战略很好理解，用中国话说就是“另辟蹊径”和“术业有专攻”。
拿我自己来说吧，刚进入公司的时候什么都不懂，人家在拼命赶进度，我也帮不上忙。先是看看文档，读读教科书，百无聊赖之际机会终于来了，公司希望支持调试优化过的代码，这部分工作理论性不强，多数都是琐碎的技术细节，正好适合我这样初来乍到的人熟悉上手。可以说优化过的代码极难调试，也没有什么成型的解决方案，因此对我们的要求也不高，先把框架搭起来，能实现哪些功能就先做着，最强的要求就是调试选项不能影响优化代码的生成，并且生成的代码必须和不加调试选项时完全一样。就这样，在大家的宽容下，我一边看论文啃教科书熟悉基础理论，一边接任务写代码了解特定实现，半年之后可以独立完成分析、实现，一年之后就开始凭一己之力重写整个支持调试的框架。虽说到目前为止支持的功能有限，效果也不理想，但是对我个人来说，获得的东西实在太多了。毫不夸张地说，现在我完全可以胜任关于优化的任务，实际上，我曾经修改过一个模块的算法（与调试支持无关），这个模块被认为是我们的编译器里最复杂的模块之一。
这是一种另辟蹊径，没有从优化入手，而是从调试开始。实际上这是公司为培养新员工而另辟蹊径，也只有在其他人的宽容下才得以进行，有一定的局限性，不易模仿。但是，当我跨过第一道门坎之后，已经可以凭借自己的能力和经验来选择发展路线了。继续做调试，或者转去做优化都是不错的选择，不过我有了个朦胧的想法，打算再另辟蹊径，不过这一次就不能指望别人的宽容了，必须首先说服别人，我要做的工作有多么重要，然后踏踏实实的把东西做出来。如果能够成功地给别人留下一个“说到做到的另辟蹊径者”的形象，那么以后另辟蹊径时，阻力就会小很多。
再说说“术业有专攻”。除了一次被拉壮丁去修改模块算法，我一直在做支持调试优化代码的工作，前前后后一年多时间。随着功能不断增多，局势发生了微妙的变化。调试不能破坏优化，但优化也不能破坏已经取得了的调试成果，为此还专门做了一套测试集。如果有些同事对支持调试不感兴趣，或者没时间做深入的了解，他们在自己的任务接近完成的时候，会邀请像我这样的人对他们的工作做一番检查(review)，确保不会破坏什么。当然，测试集是最后一道关卡，如果测试通不过，也要找我们帮忙调试。这样，我就在一个相对狭窄的领域里树立了威信、建立起壁垒，从而减少了竞争威胁。
波特在这一章的末尾提到，任何战略都是有风险的，详细内容这里不再赘述，总结成八个字——审时度势、与时俱进。
准确地译解市场信号的先决条件是进行基本的竞争者分析。——《竞争战略》
程序员这条路该怎么走呢？只要钻研好技术，肯定前途无量吗？如果技术不算出类拔萃，就肯定没有出头之日吗？
如果你还认同我的假设——“个人发展和公司发展有共通之处”，那么不妨问问类似的问题。一个公司只要生产的产品好，肯定能成为百年老店吗？如果公司无法生成一流产品，难道就只能等着倒闭吗？波特在《竞争战略》第三章开篇就提出“竞争战略包括为企业定位，以使企业区别于其竞争对手的能力具有最大价值”。这句话背后的假设是没有任何企业可以在所有方面领先对手，所以，能否充分发挥相对优势决定了一个企业的前途。
对于个人来说，也应该是这样吧。
同事关系的本质是什么呢？朋友？对手？或者兼而有之？他们是以怎样的方式、在多大程度上影响着我们的发展呢？在读过《竞争战略》第三、四章之后，我发现自己竟然从来没有认真地观察、分析他们。
“对竞争者的分析有四种诊断要素：未来目标、现行战略、假设和能力。”首先分析同事的工作目标是什么，是专注于技术，还是会转向管理，是为了权力还是名利。然而，期望与能够达到的实际值之间会有一定的差距，家庭是制约事业发展的因素之一，因为每个人都不得不将有限的精力分摊到家庭与事业上，更极端的词如“祸起萧墙”、“后院起火”，从反面强调家庭的影响是多么巨大；当然，一个健康幸福的家庭对事业的帮助也同样不可小觑。然而，家庭并非是事业之外唯一需要花费精力的地方，每个人都有自己的爱好，愿意为获得某种享受或技能而付出额外的时间与精力。我就是这样一个人，有太强烈的个人爱好，可以说在很大程度上减缓了我在编译领域的发展。我感到自己对OO的理解比较肤浅，希望能有更深入地了解，前一段就一直在读这方面的书。还没读出个眉目，这两天又开始读The Art of Unix Programming，为Raymond涉猎如此之广而深深地震惊，希望在完成这一系列文章之后，去亲身体验书中提到的项目与技术。我坚信这些努力必将带来长期收益，但是不得不暂时面对由精力分散引起的巨大竞争压力。
每个人都对自己的情形有所假设，这种假设可能正确也可能不正确。比如说某些人能够摆正自己的位置，另一些人狂妄自大、自不量力，就是这个意思。我就经常假设自己是个相对比较好的程序员，而对形式化的理论则比较头大，说实话，读同等水准的代码和论文的感觉简直是一个天上一个地下，可我从事这样的行业不读论文又不行，唉，怎一个愁字了得啊。除了对自身之外，我们对环境也存在这样那样的假设，比如“IT行业是在上升还是衰退”、“IT的高薪相对于付出来说到底算不算高”，以及“中国做IT的人里面究竟是圈钱的人多还是做事的人多”。不同的假设往往引出不同的行动，多多了解同事心中的假设，就不会对他们采取的行动感到诧异。
一个人的能力往往有很多种，而且可能发展的很不均衡。通常来讲有以下几种：核心能力、成长能力、快速反应能力、适应变化的能力，以及持久力。不同的能力在不同的情形下可以发挥各自的作用，这里不再赘述。
“市场信号指一个竞争对手的任何行动。”我知道同事们在做着各自的事情，可那又意味着什么呢？让我们看看波特在第四章里教给我们什么。
第一种发出信号的形式是“行动的提前宣告”，即丑话说在前头，引起那些可能会受到影响的人的注意。“正确地辨别一项预先宣告是抢先行动还是安抚行为是非常重要的。”如果按照宣告采取行动对己方越有利，对对手越有害，则是抢先行动；如果对己方获利不明显，且可以减少对对手的影响，则是安抚行动。做项目计划应该算是安抚行动吧，大家坐在一起，把自己下个release期间想做的任务讲一下，然后看看相互之间有没有什么依赖关系或者影响，最后尽可能安排一个对所有人影响都最小的check in次序。这种做事的方法大概和我们的项目有一定的关系，做编译器嘛，总也没个头，就是一个版本一个版本地升级，做到后来就比较自由，对哪部分感兴趣就可以做哪里，分配任务的时候很少，一般只是对新加入的同事才分配任务，等他们熟悉了就可以自己找活干了。
第二种是“在既成事实之后宣告行动或结果”。这么做无非是为了达到生米做成熟饭的目的，或显示超强的能力，令大家对其刮目相看。其实我一直就是这么想的，咱偷偷做点东西，然后拿出来让你们看看咱是何许人也！不过刚进公司就被教育，不能让老板感到意外，所以一直不敢造次，老老实实地汇报吧。当然我也知道，这事后宣告总显得不那么光彩，不像提前宣告，有利于合作，减少资源浪费。
第三种最经典——“竞争对手对产业的公开讨论”，“这种讨论可能有意识或无意识地企图使其它企业在同样的假设条件下运作，以使错误动机或战争的机会减到最小”。就是他想让你按照他划出的道道来走，你开始可能不赞同，可架不住他老说，谬误重复一千遍就成了真理。想起什么了没有？脑白金？黄金搭档？对于咱程序员来说，最熟悉的词就是“软件工程”了吧，不知有多少人多少公司为了各自的目的鼓吹着各式各样的开发流程，可是等像咱这样的程序员拿来一用，发现不但不像趁手的兵器，倒像一副束手束脚的镣铐。
还有一种是“交叉规避”，这让我想起了围魏救赵。你说我这不好？我觉得你那也不怎么样，凭什么说我？！这种传递信号的方式没什么正面的用处，主要用于表达不满但又不想造成激烈的冲突。
看看吧，有这么多方法可以用来分析我们的同事，你愿意为此牺牲一些做技术的时间和精力吗？
在一个产业中制定竞争战略可视为选择参加哪个战略集团的问题。——《竞争战略》
波特在第七章将结构分析方法应用于产业内部，说明该方法的应用范围比较广，我们可以用它分析IT业与非IT业之间的关系，也可以分析IT业内部开发系统程序与开发应用程序之间的区别，甚至还可以用来分析项目组里做优化的与做调试信息的之间的关系。
即使在同一个项目组里，也会有不同的分工，如果侥幸拥有选择的权力，到底选择哪一种？
首先，不妨看看已经在做这类工作的是哪些人。世界上有两种人，把人分成两种的人和不这么做的人。哦不不不，抄串行了。世界上有两种人，有些人，你希望他们永远都是你的同事（或者上司、下级），和他们一起工作如沐春风，简直是一种享受；而另一些人，你却再也不想看到他们，他们逃避责任、看不清问题的本质偏偏还要胡搅蛮缠。
与有些人一起，竞争是良性的。他们无私地给予你帮助，也坦然接受来自你的回报；他们尖锐地指出你的问题，也虚心接受来自你的批评。很多时候，你们愿意互相妥协，以谋求共赢；又相互挑战，像一场游戏。那种感觉让人觉得很刺激、很兴奋，那实在是一种默契。
与另一些人在一起，竞争完全是恶性的，如同一场战争，你死我活，不讲过程只求结果。很没意思！但这样的人总是会有几个出现在你身边。他们推卸责任，让你做替罪羔羊；争抢功劳，不惜撕破脸皮大打出手。在IT还是暴利年代的时候，有太多这样的人进入了IT业，如今，他们仍然活跃在各自的岗位上，他们并不去锻炼什么能力，因为他们有手段。
曾经看到过一句话，“人生最大的幸福是与自己喜欢的人在一起，做着自己喜欢做的事情。”如果“二者不可得兼”，你愿意选择哪一个呢？我想我还是会选择人，与那些我愿意与之工作的人呆在一起。都说环境塑造人，其实这环境也不必太大，就拿上大学来说，学校名气再大，牛人再多，对我有决定性影响的不过三五人而已，这样的人也只可能出自那些与我朝夕相伴的人中间。孟母三迁不也就是求个好邻居嘛！我非常感激那些曾经引领我向上的人，今后，我会有意识地选择与这样的人一起工作。
环境太复杂太复杂，让我们不得不制定一个战略，以免被刺得太痛，或者迷失了方向。制定战略是一次选择，更是放弃，那是对环境有了深刻认识后的无奈、也是对人生苦短的感慨。
当工作成为一种负担
最近读到一篇文章——《目标管理，从谁的目标着手？》（哈佛商业评论2004年第10期），其中一段是这样的，“公司有公司的考虑，而且公司认为员工必定有兴趣完成公司的事而不是自己的事。实际上这是不可能的。每个人的工作目标总是要满足自己的心理需求。如果有人不这样认为，而认为这种内心的强大力量可以完全不予理会或者可以长期用钱打发掉，他便是在自欺欺人。”（P132-133）
不知从哪天开始，对工作感到厌倦。其实也不是不想工作就想成天待在家里，而是厌倦了一直从事调试信息相关的工作。当初一起做调试信息的几个同事由于各种原因离开了，只剩我一个人撑在这里。刚开始的时候还是很有激情的，觉得编译、调试都是很神奇的东西。一年半过去了，该知道的都知道了，不知道的一时半会也知道不了，从抽象的角度来说，对调试已经没有神秘感了。剩下的就是实现的问题了。最初的框架搭得并不好，不够抽象，正好其他人也走了，就我一人，自己说了算，于是把原来的框架推倒重来，顺便锻炼一下自己的设计能力，看看自己对设计模式的理解到底到了什么程度，能不能熟练地运用。忙忙碌碌两个月下来，亲手设计并实现的框架新鲜出炉了，可没兴奋两天就厌倦了，像成天吃肉的人终于有一天受不了了，要吃青菜。我也想换点事情做做。
这也正是让我苦恼的地方。当我在这个领域做出了点成绩，却怎么也跳不出当初选择的跳板了，这种工作算是彻底长在我身上了。有bug要我去fix，有feature要我去实现，根本不做第二人想。其实也并不能说这里面没有什么可做的了，至少，在框架的搭建上仍有很多潜力可挖，我也并不是想以后再也不做这方面的工作了。但我真的很想用两个月的时间做点别的，而且已经有了具体的想法。可是无形中有一种压力，让人不能随心所欲，仿佛我不做调试信息就是不务正业，尽管谁都不会真正说出口。客户需求要满足，还有bug等着fix，任务列表一长串，而且哪个都不能等，都很急！
前两天和老板谈了自己的感受和想法，老板表示理解，但也希望我能先把项目急需的事情做好，让手头上的工作告一个段落，再想其它的也不迟。从敬业的角度来说，老板这么说一点都不算过份，就算老板不说，我自己也是这么打算的，毕竟拿人钱财替人消灾。但从感情的角度来说，我真的受够了，现在是身在曹营心在汉，静不下心来做手头的工作，老是想着另外的事情该怎么做。我相信，真要是让我先去做别的事情，等回过头来再做调试信息，我会像当初一样拥有激情。
当然，抱怨是没有用的，一方面把手头的事做好，另一方面也要积极去争取自己想做的事情，一时做不了可以等等，可以利用这段时间再多想想，准备地更充分一点，如果将来能够顺利完成的话，也能为下次提出类似要求增加得到批准的砝码。
最后再引用这篇文章里最触动我的一段，抒发郁闷。“而这些年轻人关心的是：我和我自己的需求怎么办？谁会倾听？管理层会为我提供多大的帮助，让我在实现管理层目标的同时也满足我的个人需求？”（P134）
职业发展“阴谋”论
曾经为个人职业发展苦恼过，不愿意做救火队员，哪里需要哪里上，希望持续地、系统地发展个人能力，随着工作经验地增长，能够对大型系统的设计、开发过程有足够的认识，有能力主持软件项目开发。可惜往往事与愿违，哪能咱想做啥就做啥，那还要老板做什么？！
经过一段时间的交流沟通，一个小小的“阴谋”浮出水面，说服老板也许并不像想象中那么难。
首先，切忌刚刚有了模糊的想法就向老板去争取，不要告诉他（或她），都曝光了还能算阴谋吗？老板希望看到的是切实可行的解决方案，不要指望老板能够比你更加了解你的想法，更不要指望老板能帮你透彻地分析你的技术构想。这不是老板的工作。
很多时候，想法来源于困扰。系统的某个部分设计得异常蹩脚，开发总是受制于它，终于有一天，你有了一个天才想法，如果这样设计不就ok啦！然而，抽象的思考往往忽略现实问题，那就是无处不在的、紧密的耦合。再好的设计，却无法溶入到系统当中，也是白费。
这时，就需要我们多做一些试验。与其说是为了说服老板，不如说是为了自己的将来负责，我们必须对自己努力争取来的机会有充分的信心，而不应该将其当成一场赌博。因为那关乎我们的声誉，而声誉又能为我们争取到更多更大机会。
从某种程度上说，试验的结果并不重要，重要的是我们在这个过程中学到了“什么是可以做的，什么是不能做的，或者是暂时无法做到的”。我们对整个系统有了更深刻的认识，这时可以把试验的过程、结果与大家分享，一方面可以避免重复劳动，更可以群策群力寻求突破。如果试验的结果是正面的，就可以向老板提出实施该方案。不过，技术上的可行性只是老板批准的必要条件，还要考虑投入产出是否合理，以及任务的优先级等等。所以能够如愿以偿还是要靠一点运气啊。
当然这些都是后话，重要的还是“阴谋”的实施过程。要沉得住气，尽可能做得详细周密些，当阴谋曝光时设计应该实现的差不多了，可以留一些琐碎的、打扫战场一类的工作，但设计涉及到的主要方面一定要尽可能地挖掘。还要注意时间分配，别让老板觉得你成天不干正事也不知道在瞎搞些什么。一天做一点点，细水常流，这是我从一个同事那里学到的。要善于利用开发工具，所有的试验都是我们的宝贵财富，不能像狗熊掰玉米，掰一个丢一个，要学会搜集、整理、归类。
当我有了这些想法之后，就开始着手搭建自己的开发环境。阴谋嘛，总不能用公司的cvs server和tracker。在自己的工作机上装了fedora 2，然后搭建cvs server，ext的连接方式。不过每次输入密码很烦（连cvs diff一下都要输入密码），就尝试了SSH的RSA认证，通过应用ssh-agent和ssh-add，只需要输入一次passphrase（不是密码）就够了。然后又装了cppunit和bugzilla，bugzilla又需要apache、postfix和MySQL。我一一把它们装好，可是费了不少劲，很多时候设置失败都是因为权限问题，毕竟咱不是土生土长的linux developer，只算有点业余爱好而已。另外，我喜欢用Emacs的diary做一些日常的记录，于是把diary文件也import到cvs server上，这样就可以在几台机器上共享一个diary了。
有了这些，应该可以开始我的第一个阴谋了吧:-)
下面就看我能不能沉得住气了。
预留：
团队协作能力
曾经有这样的感受，与某些人合作非常舒服，而与另外一些人在一起就像是噩梦。我相信，这不仅体现了一种态度，更是一种能力，也许就是传说中的“团队协作能力”吧。尽管团队协作能力非常重要，但大多数人对它的理解十分有限，我就为此困惑过、苦恼过。
隐约觉得，团队协作能力并不是一种可以轻松掌握的能力，仅仅有协作的愿望更是不够的。说起来有些尴尬，如此重要的一种能力，我们竟然说不出它到底指什么，更不知如何衡量、如何学习，有种听天由命的感觉。
一个人的力量是有限的，只有大家携起手来，才能取得更大的成就，而团队协作能力则能够确保众人的合力大于单个人的力量。对于如此重要的一种能力，决不能这样听之任之，一定要不断地学习、锻炼。
XP十分强调metaphor的作用，一个准确、形象的metaphor可以让人迅速理解、掌握问题的本质。
足球是我最喜欢的运动，喜欢看，也喜欢踢（虽然已经很久没踢过了）。足球场上四种角色——前锋、中场、后卫和门将，一共11个人组成了一支球队。通常一名球员只以一种角色出现，但是他不仅要与角色相同的同伴协作，更要与其它角色的队友一起为争取比赛的胜利而努力。每名球员不仅要清楚自身角色的职责，还要明白其它角色在战术上存在的意义和相应的作用，因为他必须通过与其它角色交互来获得比赛的胜利。他不仅要在抽象的概念上明白一支球队是如何通过分工协作来完成整场比赛的，还要掌握具体的技术细节以完成相应的战术要求。在此基础上，如果球员提高个人技战术能力，成为对球队拥有显著影响力的球星，就可以增强整个团队的实力。更加完美的是，球员们还能感受到球队整体打法存在的问题，并通过不断地尝试形成新的风格。当年，伴随着全攻全守、防守反击这样的新式打法横扫足坛的，必然是一支伟大球队的诞生。
我想，团队也应该和球队一样，要想成为具有生产力的团队，其成员必须既理解整个系统运作的抽象模型，也有能力完成自身角色所赋予的职责，这两种能力加在一起就是“团队协作能力”。一名伟大的成员则不仅可以通过不断增强个人能力来增强团队按照模型运作的能力，还会随着实力和经验的积累推动系统运作模型的演化。
知道了什么是“团队协作能力”，如何学习、训练就是自然而然的事情了。两手抓，两手都要硬。之所以将对系统抽象运作模型的理解提升到如此的高度，是因为成员交互过程中很多的矛盾、冲突来源于系统固有的缺陷，不随成员的变化而变化。对于这样的矛盾，我们应本着对事不对人的态度来处理、解决。
学开发，只看软件工程著作是不够的
近日看了两篇IEEE Software上的文章，讲述开发软件究竟需要哪些知识，以及怎样学习。
[1]中提到，如果你希望通过阅读软件工程著作了解和学习如何开发软件的话，恐怕难以如愿，因为这类著作更愿意关注一些轻量级的内容，如项目管理、软件开发过程改进、进度和成本估计等等，而软件开发本身由于是整个软件工程生命周期中最难以理解、也是理解得最少的一部分，所以只能抽象地讲讲，甚至被完全忽略。
然后，文中列出了一系列技术问题，并指出，只有在设计和编码的前前后后解决了这些技术问题，才能使开发和维护工作更轻松。我觉得其中最精彩的部分是"Considerations before design"一节，作者认为在设计前所有开发人员必须掌握两方面的知识——problem-domain expertise and solution-domain expertise。业务知识的重要性就不用多说了，现在网上不知多少文章劝告那些将近30岁的开发人员不要一味钻研技术，要想赚大钱必须对业务特别熟悉。对此我不敢苟同，能够理解和能够描述之间还是有很大差距的，何况任何技术都有它自己的局限性。比如“庖丁解牛”这个典故，它说明的是对牛的结构越清楚，肢解的速度越快，对刀的损耗也越小。然而，如果连刀背刀刃都分不清楚，又如何来解牛呢，即使对牛再了解。当然，刀作为一种解牛的工具其复杂度是很低的，很容易掌握，它与软件开发技术的复杂度是不能比的，可偏偏就有很多人在无视、否认软件开发技术的复杂性。
那么，为什么软件工程教科书都不教这些知识呢?[2]给出的解释是，首先，业务知识与软件无关，它超出了软件工程学的范畴；其次，能在程序设计语言手册、系统文档、以及库手册上找到的技术知识往往过于具体、涉及过多的细节，而更多的技术知识甚至只存在于一个个程序员的经验当中，还没有被总结出来作为一种可以教授的知识。文中还提到，除了这两类知识外，problem-solution integration expertise也是不应忽视的。否则，岂不成了“纸上谈兵”！根本不知如何运用的知识又怎么能算知识呢？
课本不教，大家是从哪里学来的呢？“人类是如何学习的”是心理学研究的问题之一，一般来讲，有两种学习的方式——模仿和摸索。既然没法教，我们也只好摸着石头过河了。
The practitioner is using his or her intelligence to find and then build linkages between the problem domain and the solution domain. As observers have noted, programming is an endless struggle with How? Why? What? Whether? and When? Typing takes place when enough questions are tentatively answered to permit the programmer to put a structure in place. [2]
那么，老师们又能做点什么呢？ 作者提出了四点建议，其中最后一点是：
Fourth, teach by doing. Software engineering is not book learning. Teach with problems and projects where students (and teachers) labor to build and modify nontrivial, even real, systems in working groups.
知道了学什么，以及如何学，“大家有没有感到这个世界美好了许多啊？！”
--------------------------------------------------------------------------------
[1]. James A. Wittaker and Steven Atkin, Software Engineering Is Not Enough, IEEE Software Vol. 19, No. 4
[2]. Nicholas Zvegintzov, Do We Know Enough to Each Software Engineering?, IEEE Software Vol. 20, No. 5
来自：http://blog.csdn.net/netcasper/category/36069.aspx?PageNumber=3