做人做事做架构师.doc

做人做事做架构师 引子 究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满……你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐忑。如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去”，要么“顺着代码铺就的道路，亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型。 你能不能做一个好的架构师？架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表。所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当工人。能做一份工作列表中的事，并不等于就成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪个位置，而技术技能只是做事实施的必需。架构师这个职务，同时要求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做人、做事，做架构师。因此“模型”由“个人特性”和“技术技能”两个方面构成，在第一张图中，我特别说明“个人特性”既包括人际关系的能力，也包括（具体）业务能力；“技术技能”也是如此。所以个人特性主要与“做人”有关，部分地也包含“做事”的要素。 图1 架构师能力模型 “有效沟通”以及“学会谈判”与做具体的事无关，是个人能力特性的公共方面。前者是过程，后者是知道如何定目标与求结果。而“风险与防备”是做事过程控制的关键，与前面两项正好构成了一个做事基本能力的完整体系。基本上，这三项个人特性都是一个“普通程序员”所不具备的，甚至在大多数情况下，普通程序员并不愿意去具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟通总是会使事情变得更加麻烦，谈判则徒耗时间而无济于事。然而事实上，在整个的架构决策过程中，架构师需要不停地沟通与谈判。将“架构”变成“决策”的过程，其实就是对各个技术角色（及其思想）兼容并包的过程，你需要不断地协调需求、实现之间的各种问题，也需要面对各种投资者（时间、资金、人才等方面的决策者）进行谈判，以确定项目的规模——没有规模也就没有范围，没有范围如何展开设计呢？ 一部分开发人员会认为上述过程是“项目经理”的事情，但真的如此吗？当你作为一个更高级别的架构师，以至于要影响到多个项目的决策时，你就全然不会有这种感受了。因为这种情况下，你的决策将先于项目的启动，或者说你已经不单单是一个技术角色了。 设计是架构能力的一部分，但架构师不是设计师——看清楚二者之间的不同，你才真正迈出了架构师职业生涯的第一步。 抽象是思维能力、模型化是表达能力 个人特性中另一个非常重要的方面是“抽象思维”，而这是与架构师角色直接相关的一种能力。这种能力既有职业技能特征，又是普遍性的能力。 所谓普遍性的能力，是指“抽象”在我们——作为人这种个体的——生活中无处不在。例如我们说花、草，说桌、椅……我们用语言去指称任何一个既已存在的（可以脱离我们的语言而自然存在的）事物时，就用到了抽象。说“桌子”的时候，既没有描述桌子的具体形式，也没有说明它的规格，但我们用这个名词时，所有人都知道“桌子是什么”。所以，名词概念是整个抽象逻辑系统中的主体。如果失去了这些名词定义，我们基本上不能说话，也不能描述任何东西——那便到了“只可意会不可言传”的境地。 用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达的含义，例如我们说“这个系统设计为一个三层结构”。然而架构师面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必须自已构建一个抽象系统，这就需要概念抽象能力、概念表达能力和基于概念的逻辑表达能力。 概念抽象能力是一种思维能力。简单地说，就是“把目标分解或概括清楚”：你要么概而言之“它是什么”，要么详细地说明“它包括什么”。必须使用大量的语汇来陈述这个“什么”，这不单单是表达为文字，也表达为你在思想过程中的一个完整系统。通常用的方法是“映射系统”。例如你可以用数学中的“数轴”来映射“实数域”。将目标系统形式化为一个概念化的、可讨论的结构系统后，你的抽象过程就基本结束了。 图2 能力模型中的个人特性 然而这个“抽象系统”可能只构建在你的思维意识里，还必须把它描绘出来。因为不能只是你自己思考清楚，系统就能设计完成。这个“描绘”就依赖于后面两种表达能力，一种是描