本文主要是介绍能力要成体系，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
2007年07月09日 03:29:00 这两天关于我那篇"架构师的能力模型"的BLOG上的讨论终于停歇了，所有的几十个回复我都一一看过。大多数不是在第一时间看到，也差不远了。正好CSDN的blog又新添了回访的功能，于是一一回访，看了看批评我的，或者赞许我的都是些谁。
但是我一篇也没有回复，回访时也没给人家留个信儿。以前的或许是懒，或者是没想说的，这次却不是。这次真的是故意不回。这有原因。
今天要讲这个话题，一方面是因为这篇"架构师的能力模型"的blog，另一方面则是看到了另一篇名为"真的汉子"的blog。后面这个，稍后会再讲它的关系，我们这里还先说我的这篇博客所反映出来的信息。
我调查了一下回复者的先后，大概是越到后面，赞同的或者基本赞同的就越多；越在前面反倒是批评者众。这个顺序很重要，因为它正好反映了一种架构师能力，就是谨慎。
我们先来说这套"架构师的能力模型"的图。批评者要么认为这套图在求大求全，是超人模型；要么在认为这是不切实际，追求完美。其实都不是。首先大家对我所指的"架构师"要有个概念。我们很多人都有设计工作，比较做数据库设计或者具体功能的设计。这些设计中也有"架构"和"框架"的概念， 例如插件架构／框架。但是，这是"架构设计"，不是"架构"；是一种技术，而不是一种能力。在我的架构师模型中，这些大概只占到"实现能力- <设计能力"中的很少一部分。>
因此先强调我说的"架构师"不是指"一个能做架构的人"。前者是把架构师当职能，后者是当工人。
那么我到底说的是怎样的"架构师"呢？comiunknown给了一个稍稍接近一点点的答案：
--------------------
1、3年的coder；
2、1年的客户沟通工作；
3、1年的team leader；
4、无限的学习、思考期，学会分析别人的系统，思考为什么这么设计的原因，如果
让我来设计，那些地方可以改进；
5、还要有一定的天赋/灵气，能够从纷乱的客户要求中挖掘出真正的需求。
--------------------
后面两条我基本同意，事实上也言及了我给出的能力模型图中的几个分支。但前三条，却正体现了一种行业积弊：浮躁。连Peter Norvig都在说"十年学会编程"了，那么我们那些"招聘五年开发经验的Web架构师"的小广告是不是该撤了？
那么，我们那种两年三年开发，或者从某某学校毕业就想当架构师的想法，是不是也该放下了？
然而，我也得承认有绝顶高手。大家智商不一样，没准儿Peter Norvig要十年才学会编程，某些人三年两年也学得会、学得好。当然了，这个我说服不了大家。但是要清楚的是，我们在这里说"架构师"，而"开发能力和设计能力"只是架构师能力的很少一部分，即使有人比Peter Norvig（或其它更多的大牛们）更牛，那么起码也不能说自己"学会写程序"就成了架构师吧。
还是没解释"什么是架构师"对不？当然。我就来说说"什么是架构师"，而什么又是"做架构"。
做架构差不多就是画图纸。象UML这样的东西就是制图元素，基本上你能用好一些建模语言，能构画出一个房子的基本骨架来，就是"会做架构"了。这些东西在学校能学、书上能教，照猫画虎个三年两年来，没有虎的威风，也有虎的样子的。这在"能力模型"中也有，大概在"实现能力- <设计能力-> <设计期语言"、"实现能力-> <模型化"以及一些其它很小的分支里头。>
而要有虎的威风气势，这起码要看过虎，而且要有面对真虎凛然不慎的心胸。在架构设计中，这样的能力也可以先从学习中来找，这是模型中"实现能力- <设计能力-> <了解既有系统或模型"的主要内容，在"实现能力-> <设计能力-> <设计评估"中，也有大部分内容是关于这一点的。>
在"设计评估"里有一句"懂得欣赏的才是艺术家"，我们这里在说让你学会欣赏的"法子"，却不见得你有品评者的心胸。所以类似于"学会肯定别人的设计"这些也成了你的能力，而你应该注意到，这里的"学会肯定.."已经不单纯是技术能力的范畴了，它已经涉及到你的性格修养。
当然有人说"架构是一门艺术"。作为艺术性格很强的高手、专学者或者"精英"，很多人并不会肯定别人，而是拘于自我认为自己是超人。这样的人中国自古就不缺，也有善评称其"雅士"或"独特"的，其艺术作品也大多成就斐然。但是有这样品质的能力，虽然不能说不好，却一定不能拿来做架构师。
因为他只会"做架构"，或者说只能"做非常好的架构"。却不懂得如何"推行架构"。
架构真的是"好不好"的问题吗？如同我对工程的理解一样，架构的问题的根源，也并不在于它是不是完美或者漂亮，而是在于是否合用。因此，架构师必须对实施架构的团队，以及实施的过程有充分的了解，知道他们的能力缺陷，知道实现过程要消耗的资源，清楚每个环节可能的故障以及先兆。只有这样，架构师才能设计一个让这个团队能实现，而且在实现过程中能受控的架构。
要知道，你作为架构师被请来，不是画几张图纸交给项目经理，说：你们去做吧，做不出来是你们不会做。即使你可以身体力行，在这个团队中教大家、培养大家，那么公司的开销呢？风险呢？这些东西难道就不考虑了？项目的周期因为实现的复杂程度而无法控制时，项目就死掉了。那么，追根究底来说，是不是架构师的问题？是啊，你为什么会做了一份"不合用"的架构呢？
所以这一部分能力，是在要你的开发经验、团队经验以及用人识人的经验中去找的，这些大概包括在模型图的"实现能力- <设计能力-> <了解你的主要沟通对象"和"实现能力-> <架构推行"中。>
你看我们说了这么多，还只讲了几个小的分支，主要还是在"实现能力"中打转。大多数人的问题是：我们为什么要了解"决策背景"，以及类似于"谈判"、"沟通"、"风险"等等这些方面的能力呢？
我们说过"做架构"不同于"是架构师"。问题的关键就在于规模。如果你只是为一个几人小组而设计一个架构，那么没关系；大概你还会是实施人员，因此更是没什么问题。但是，"架构师"应该面临的是大规模项目，是百人、数百人规模的团队的实施工作。架构师身边，除了具体的实现人员，还是更多的设计师、项目经理、技术专家、老板、客户..面对这些问题，你还能说"我会做架构"就够了吗？
要知道，上述的每一个角色，都会对架构造成"伤害"。我在做架构实施过程中说得最多的，就是"架构伤害"这个词。因为每个角色都会对架构有疑问、有想法。对于公司、客户高层来说，即使你是最权威的专家，在没能把你的设计讲述清楚之前，他们也是不会盲目地通过项目的。因为专家拍脑袋的教训，从（包括传统行业在内的）历史上来看，真的是血淋淋的。
架构必须面临的是决策者的思想以及方向，你得明白他们为什么是要做一个架构，希望这个架构支撑多长时间周期的持续开发和经营。然后，你得抺平这些"高端的思想"，把它变成一个可以具体实施的方案，因为具体到开发人员来说，他们是以完成任务为目标的，而不是去憧憬那些"高端的思想"。
作为架构师，你要站在一个既务实也务虚的角色上，你得理解项目经理、产品经理和开发人员最切实际的实施方案，也得了解战略决策者们为将来做出的规划。重要的是，架构师这个角色，对体系的保障正是面向这些规划的--你看看，"可持续、可移植、弹性、集成性.."这些不都是对战略的阐叙么？
现在你会还认为那些"超人能力"是不需要的吗？你还坚持三年两年就可以成就一个架构师这样美妙的的构想吗？当然，如果你要在一个小规模团队中担任架构角色，实现一些架构的设计工作，那么固然是行的，但请将眼光放开，想一想我们一直为大型团队而烦恼的那些问题..国内的软件行业，在大型团队上来说，真的是没有多少积累和思考的。
我们现在来说那些很快就回复的，以及回复时对上述问题根本没有思考的人朋友，他们犯下的，不正是这幅模型图最上面的那个分支中表现出来的问题吗？在"学会交谈"中就清清楚楚地写着"学会听"和"不要急于表达，以及肯否"。在这个例子中，真正的问题是：急于表达可能是个性问题；而急于肯否，则关乎于性格修养了。面临一件事物时，过早的肯否，其实是使你失去了更深地了解它的机会。
我们现在看到的这幅"架构师能力模型"，其实表达了个人能力、性格与心理素质的一种组合，这绝不是单独某个方面的提高或者补强。作为一个"工作型角色"（例如开发人员）来说，大要在技术方面擅长就很好了，专精更是不错。这也是我们技术角色的一贯思维。但对于"职能型角色"（例如一定管理职务或者管理链条上的中间环节）来说，"能力要成体系"就是重中之重了。
所以这又变成一个角色问题了。我们要从工作型角色变成职能型角色（例如做技术变成做管理），那么根本之处，便在于从专精能力变成有体系的能力培养。这就是我开始提到那篇"真的汉子"的博客文章的原因。周筠老师在讲她的这篇博客时说，她的一些编辑在面对MSRA的这位作者时，表现很紧张、很怯，基本上已经到了"不敢接微软那位‘汉子'的话"的地步。我听到这个故事的第一反应，是说：
--------------------
Aimingoo said (0:36:04):
这与胆量没多大关系。
Aimingoo said (0:37:32):
1、承认错误 2、据理力争
就这两条，就可以跟这个人打好交道了。
但细想下去，我又接着说：
--------------------
Aimingoo said (0:38:26):
随便说，第三条是"有礼有节"。这看起来是外交辞令。但是真的很有用。因为据理力争是必要的，但把握不好尺度，事就会砸。
而对于很多人，这三条是一条一条过来的。
imingoo said (0:40:43):
先是做不好承认错误，什么事都认为自己对；接下来做不到据理力争，是性格软弱的一面；
最后是不懂礼节，是缺乏教育的一面。
这三件做好，就算业务能力上有欠缺，也是人才了。
:)
然而我们看到，这里提及的三条，却正是技术人员，以及我们前面讲到的那种"艺术性格很强的高手"通常的问题。换在这样的故事里，就是技术再强再好，也不会跟这位先生打好交道。所以，这真的是要当成"个人能力体系的不足"来看，而不能单纯地"练练胆量"就可以了。
在我们讲"架构师能力模型"这个话题时，很多人认为这个模型求大求全，然而正是他们应该"太大太全"的那一部分能力是他们所缺的；很多人认为这是超人模型，然而这正表现了他们对"架构师"这个角色（而非"做架构"的能力）的盲目。同样，面对周筠老师所说的这位"汉子"，那些露怯者是不是"有一部分能力缺失"，或者对自己所处的"职能"（而非技术或职业）角色有些盲目了呢？
所以能力的体系问题，爱立信的这个模型是对的。随便说，这个三角模型将"个人内在素质"放在最中间，而这正好是我在"架构师能力模型"图中基本不讲的，这个问题便留给大家去思考好了。正所谓省是自省，得是自得，做人便要越活越浅，知已不足方能厚补，从而显得有力。而"做架构师"以及"做好职能角色"这两件事，合在一起便是一个自省自得，自我修养的功夫。放在表皮来看，用我常说的话来讲，就是"能力要成体系"了。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我的其它相关文章：
推个荐：十年学会编程
架构师的能力模型（图）
也说读书
谈企业软件架构设计
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1683128
这篇关于能力要成体系的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
