设计真正伟大的用户界面没有什么伟大的奥秘可言，做到保持简单易用就可以。

‘保持简单易用’意味着不要让用户分心。恰恰相反，好的UI让用户达成目标。结果如何？你的培训和维护费用降低，并获得更开心、满足和高效率的用户。

当你面对一个全新的界面设计时，别忘了这些原则。

编辑手记：Kyle将在纽约举行的Web设计趋势上继续探讨用户界面设计的内容。

1. 了解你的用户

“关注用户：如果在关注竞争对手还是用户之间选择，答案总是后者。工作总是首先从用户开始。”——Jeff Bezos

了解用户，因为用户的目标就是你的目标。试着重述用户，了解他们的技能水平和体验，以及什么是他们需要的。找出用户偏好什么样的界面，并观察他们在 界面中如何操作。不要迷恋于追逐设计趋势的更新，或是不断添加新的功能。首要的任务是关注你的用户，这样才能创造出一个能让用户达成目标的界面。

2. 重视模型

用户的大部分时间都消耗在界面中，而不是他们自身上（Facebook，MySpace，Blogger，美国银行，学校/大学，新闻网站，等 等）。我们无需画蛇添足，用户在你正在创造的界面中看到的正是那些（已有的）界面已经解决的同样问题。利用已成惯例的UI模型，你将使用户感觉像在家中一 样熟悉。

CoTweet在邮件应用中运用了广为人知的UI模型。

3. 保持一致性

“用户期望越多的被正确验证，用户就越觉得系统在自己掌控之中，从而也就更喜爱它（系统）。”——Jakob Nielson

用户需要一致性。他们需要知道一旦他们学会做某项操作，那么下次也同样可行。语言、布局和设计是需要保持一致性的几个界面元素。一致性的界面可以让用户对于如何操作有更好的理解，从而提升效率。

4. 运用视觉等级

“设计师可以从混乱中找到统一；他们可以通过组织操控文字、图片从而清晰地传达设计意图。”—— Jeffery Veen，Web设计艺术家和研究者

设计时，要让用户把注意力放在最重要的地方。每一个元素的尺寸、颜色还有位置，它们为理解界面共同指明了道路。清晰的层级关系将对降低外观的复杂性起到重要作用（甚至当行为本身也同样复杂的时候）。

5. 提供反馈

界面要始终保持和用户的沟通，不管是当他/她们的行为对错与否。随时提示用户的行为：状态更改、出现错误或者异常信息。视觉提示或是简单文字提醒都能告诉用户，他/她的行为是否能够达到预期的结果。

BantamLive在界面中为大多数行为提供了一种嵌入式的载入提示。

6. （对用户）宽容

无论你的设计有多么的清晰明了，用户都会犯错。你的UI应当允许并宽容的对待用户的错误。要为用户提供可以撤销行为的方式，并且对五花八门的输入数 据尽量宽容（没人愿意只是因为填错了生日的格式而重头再来）。同样，如果用户的行为引起了一个错误，在恰当的时机运用信息显示什么行为是错误的，并确保他 /她明白如何防止这种错误的再次发生。

如何利用简单的验证码提高注册率一文中讲述了一个绝佳的例子。

7. 鼓励用户

一旦用户对界面有了经验之后,要奖励他/她们，使之进价。把复杂任务分解为若干简单步骤将会更显繁复和让人精力分散。提供更多的抽象方式——如键盘快捷键——完成任务，这样会让你的设计变得简洁易用。

8. 融入用户的语言

“如果你对每个像素、每个图标、每个字体都考虑再三，那么你同样需要斟酌每个词语。” —— Getting Real

所有的界面或多或少都有文字在其上。让文稿尽量口语化，而不是华美辞藻的堆砌。为行为提供清晰、简明的标签，保持简朴的文字叙述。用户对此将会很赞赏，因为他们不再是听命于他人的官腔——他们听到的是如朋友般甚至自己说话的表述方式。

9. 保持简洁

“一个现代的悖论就是：创造复杂的界面很简单，因为复杂到必须简化它们”—— Pär Almqvist

正所谓：大音希声、大象无形。 最上乘的设计中，你看不到华而不实的UI修饰，或是用不到的设计元素。换而是，其必须的元素一定是简洁且有意义的。当你想着是否要再界面上加一个心功能或 是元素的时候，问问自己，“用户真的需要这些吗？”或者是“为什么用户想要这个小巧的动态图标？”。你是否只是因为出于自我喜好而添加这些元素？记住，永 远不要在UI设计中给自己出风头。

10. 不断向前

爷爷：如果每次失败我都放弃的话，那么我将永远不会发明耐火裤！【这时裤子烧光了，露出了底裤】

爷爷：接缝处还在改良中……

节选自《未来小子》

《未来小子》一片是我最喜爱的电影之一。贯穿影片的主角Lewis一直在挑战着“不断向前”。这正是UI设计的关键准则。

人们常说，当开发界面的时候，你往往需要失败的快一点，这样就能频繁迭代。当创建UI之时，你总会碰到错误。没关系，只要不断向前，并且要牢记让你的UI简单易用。

本文描述了一个量化用户体验的快餐式方法，我发现这个方法对于提供给客户一个关于他们的网站和过去开发所作努力的快速、客观、形象的表现很有帮助。

1、什么是用户体验？

“用户体验”这个术语指的是一个概念：把最终用户作为设计和开发活动的焦点，而不是系统、应用程序或者单纯的审美价值。它是基于一般的以用户为中心（用户至上）的设计理念。

用户体验主要由四个因素组成：
·品牌
·可用性（注释：用户能够使用一个界面来达到他们的目的的难易程度）
·功能
·内容
单独作用的话，这些因素中没有一个能带来积极的用户体验；然而，如果综合起来，这些因素就组成了一个网站成功的主要因素。

举例来 说，一个设计精美的网站，却频繁地出现服务器错误或超时。或者想象一个很棒的数据库应用程序，由于某种原因而从未被使用过，因为它被深深地掩埋在了网站信 息架构的深处。在两种情况中，我们都可以看到，独立的品牌、可用性、功能和内容等要素是无法说明一个网站是成功的。然而，当综合在一起时，这些核心要素就 构成了用户体验的基础。

2、目标分析工具的必要性
比如说你来了一位新领导 – 他们对网站现状不满意，想让你帮忙把握网站的正确航向。如果你像我一样的话，第一件要做的事就是先浏览一下这个网站，然后在脑海中做一些粗略的记录。然后你怎样把这些想法和记录传达回给你的客户，而不是简单地像撕成八瓣一样对现有网站批判一番？

问题在于，我们每个人对一个网站是好还是坏的感知，是受我们个人背景和行业特性的影响而有所偏倚的。如果被叫来评价一个网站的优点和缺点，一个开发人员、可用性专员、设计人员或信息架构人员可能会有完全不同的评判。

一个客观的测量分析工具，会帮你提供给客户有事实依据的建议，而不仅仅是主观臆断和观点。本文中我们将探讨的方法会帮助你：

a、尽可能消除个人偏见（主观因素）
b、让不同背景的人（设计人员，开发人员，客户）能够在理解网站上有统一的共识
c、创建基准规则，以便于网站与其竞争者或过去的开发努力作比较
d、为你的客户提供一个关于他们网站的优缺点的事实依据和可视化的展示

3、衡量用户体验

如上所述，用户体验由四个相互关联的要素所组成：
品牌
可用性
功能
内容
但是，我们如何量化和衡量这些看似无形的元素呢？

方法很简单。我们把分析分为四个部分 – 每个用户体验的元素为一个部分。对于每一个元素，我们创建一系列的描述或参数，用于针对性地测量网站。我们为每一个描述创建一个从1到X的尺度范围；并且在这个范围内给每个描述打分。

一旦你完成了这个分析的第一部分，四个栏目中的每一个描述就都有了一个对应的分数。

在本文附上的范例分析中，我们只为每个元素使用了五个描述或参数。因此，我们使用了一个20分的尺度范围，这样网站的最高分值就是100。所以，如果我们为每个元素添加额外的五个描述或参数，我们就会使用10分的尺度范围来打分。

下面就是对范例分析中的每个元素以及描述或参数的概要：

a、品牌
品牌包括在网站中所有审美的、设计相关的项目。它带给网站想要的组织形象或信息的创意。用于测量品牌的描述包括：

网站提供给访客有吸引力的和难忘的体验
网站的视觉效果与品牌特征保持一致
图像、附加内容和多媒体对于体验的增值
网站传达出品牌的感知预示
网站利用了媒体的能力来增强和扩展品牌

b、功能
功能包括所有技术方面的和“后台的”进程和应用。它让网站提供给所有最终用户交互式的服务，而且重要的是，注意这有的时候同时意味着前台公众用户和后台管理员。网站功能的描述包括：

用户及时获得对他们查询和提交信息的响应
任务进程的清晰告知（比如，成功页面或邮件更新提示）
网站和应用严格遵守通用的安全和隐私标准
在线功能与离线业务流程结合
网站包含管理员工具来加强管理员的效率

c、可用性
可用性带来的是所有网站元素和特性的总体易用性。可用性之下的二级主题包括导航和易用性（友好度）（注释：易用性处理的是使在线内容可用于用户的体验，享受和使用的问题）。可用性的描述包括：

网站防止错误发生，并帮用户从错误中恢复
整体网页侧重针对主要受众优化
网站帮助访问者达成一般目标和任务
网站遵循它自己的一致性和标准
网站为残疾用户提供内容

d、内容
内容指的是网站的实际内容（文本，多媒体，图像）及其结构，或信息架构。我们来看信息和内容是如何按照定义的用户需要和客户的商业需求组织的。测量内容的描述包括：

链接密度有足够的清晰度，且容易导航
内容组织方便用户达到目标
内容及时准确
内容适合客户需要和商业需求
多语言的综合性内容
在 多数情况下，我会为这四种元素分别使用10到20个独立的描述。我建议你使用如上描述作为你创建你自己的分析的基础。请记住，如果你添加了更多的描述，你 必须也调整20分的尺度，以便每个元素的总分为100。例如，如果你为每个元素使用10个描述，那么你的评分尺度应该是1-20。如果你为每个元素使用 20个描述，你的尺度应该是1-5。

4、显示你的结果
一旦你完成了你的分析，并且得到了每个描述或参数的分值，就是时候把数据放入清晰而便于告知的格式中去了。

首先我们要做的是，把每个元素的所有的分值加总。因为我们已经设置了分值尺度，来为每个元素提供满分为100的分数，我们真正得到的是一个百分比的分数。一旦我们有了这些百分数，我发现最有效的是创建一个雷达图来直观地呈现。微软的Excel或者Open Office Calc都很适合，尽管任何带有图表功能的数据表软件都可以。

使用你的数据表软件，你可以创建一个可视化的数据展示。请参见你在上面下载的示例文件来获取更多的范例。

5、对你的分析发挥创意
关于本文描述的分析和方法最棒的事情是，他们可以用于满足你的特定客户或项目需求。

你当然可以在分析中添加第五个类别来描述易用性（友好度）或者商业指标。例如，你得到了一个政府客户，需要严格遵循 508规则（针对美国）。你可以容易地创建一套描述或参数来专门处理易用性（友好度）元素，修改你的图表来相应展示。同样，你也可以很容易地创建一个类别 来专门处理你的客户的重要商业指标，比如，ROI，点击率，转化量，或者重复顾客数。

可选地，这个分析平台还可以让你能够为你选择的元素添加更大的权重。比如说你有一个客户，他是奢侈品生产商，并且主要侧重在品牌和视觉效果上。你当然可以创建一个修改过的测量系统，来为品牌要素提供更大的权重，而为，比如说，可用性要素上减少权重。

6、实际应用
我已经把这个分析用于很多我所从事的项目。我常常在新客户的提案中包含一个“快餐式”分析作为附录，来提供预期的客户一个关于他们网站相对于竞争者的简单印象。

提供这类的评论通常能够给你一个极好的机会来展示你的专业性。机会是其它竞标的公司不会包含这样的免费咨询服务 – 并且你在提案中包含的这个报告可能会是一个对你有利的决定性因素。

在其它事例中，我已经有客户出钱购买关于他们网站的深入的分析和完整的建议。这类报告包括，对于每种描述或参数，完成不同的描述性段落，再配上截屏 范例。如果我最终通过跟进我的建议而赢得了客户，我通常会预定网站发布6个月后的再一次评估，作为显示进步的方式，同时加强我的服务的价值。

这种分析也能作为一个入门项目，引出更多的业务。如果你给这种分析定价合理，它可以是一个很棒的工具来让你得到新客户，并展示给他们你的服务的好处。

本文来看自：http://www.chinaz.com/Webbiz/Exp/01126115H009_4.html

指派一名优秀的程序经理，是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人，其实绝大多数团队都没有。

■ 文 / Joel Spolsky ■ 译 / 罗小平

Charles Simonyi，这位曾与Martha Stewart（译者注：美国女富豪，作家）拍拖15 年、WYSIWYG字处理技术发明人之一、从微软股票赚得10 亿美元（译者注：Charles Simonyi 曾是微软Office产品团队的负责人）、到过太空的天才程序员，是试图解决大型软件团队遇到的“人月神话”问题之第一人。他的方法是创立一个新的岗位，由超级天才程序员担任，负责系统中最重要功能的实现，而其他次要部分则交给一个由低级程序员组成的杂牌团队。他把这个岗位命名为程序经理（program manager）。虽然Simonyi 本人是天才级的，但他的这个想法却不怎么出彩，我想没人愿意做一个被人轻视的低级程序员吧。

若需详细了解这段历史， 可以阅读William Poundstone的《How Would You Move Mount Fuji?》

Jabe Blumenthal，是20世纪80年代后期在Mac Excel团队工作过的一名程序员。他捡起了这个头衔，却赋予了不同的含义。Blumenthal 发现软件开发已经变得日益复杂，以致没有哪个程序员有时间去关心如何真正保证软件的可用性和实用性。而市场人员又在一旁大谈客户需求，抱怨没人听他们的 话，没人将他们MBA式的天才想法转化为软件中可用的功能。产品设计方面不少的工作都需要花费大量时间，比如用户沟通、可用性测试、竞争对手产品的分析评 估、将复杂问题化繁为简等等。但绝大多数程序员恰恰没有时间做这些事情（实际上这些往往也不是他们的强项）。于是，Blumenthal 重拾“程序经理”，不过完全重新定义了这个职位。
程序经理需要做什么工作？

自此以后，一名程序经理的工作包括：

1. UI 设计

2. 编写功能规格

3. 团队协调

4. 充当用户代言人

5. 还有，穿Banana Republic 牌子的休闲Chino裤

在 小项目中，你有一个程序经理就够了，但对于大型项目，就可能需要配置多位了，每个人负责全部功能特性的一个子集。从众多项目中总结出来了一个经验法则：每 四名程序员配置一个程序经理。那么如何划分功能集呢，如果你遇到困难，我向你推荐我从Mike Conte那学到的方法：根据用户活动划分产品功能（http://www.joelonsoftware.com/uibook/chapters /fog0000000065.html）。比如：twitter.com可划分为四类用户活动：

1. 注册与登录

2. 发表帖子、阅读回复

3. 配置个人账户

4. 搜索新闻

我的第一份程序经理工作是在微软的Excel 团队，负责一个叫做“用户化”的用户活动（比如编写脚本、宏）。首先要做的事情是搞清楚用户的需求。于是我与很多用户交流，直到我长满茧子的耳朵只能听到相同的需求、让人厌烦为止。接下来，需要花很多时间与开发团队沟通，弄清在18个月的新版本开发周期中，些需求是合理的、可以实现的。并和Visual Basic 团队沟通，确定他们是否可提供编译器、代码编辑器、对话框编辑器，否则用户就不能在Excel 中使用宏语言。同时还必须跑去与Apple沟通，他们当时正在自己搞一门叫做AppleScript 的通用宏语言。此外，我还要和微软内部的其他应用团队，主要包括Word、Access、Project和Mail等打交道，因为他们也在做和Excel 团队差不多的事情。这个过程的绝大部分工作，都是沟通讨论——会议、邮件、电话……几乎无休无止。我被那段生活搞怕了，直到现在，在办公室的时候还怕听到 电话铃响。

第二步是写愿景规划。这是一个内容相当宽泛的文档，比如Visual Basic如何在Excel中工作，用户可能编写的宏是什么样子，需要技术团队构建哪些模块，以及它们如何解决用户的问题。然后在此基础上讨论修改，直到 没有太多分歧。至此，便可以开始编写详细规格书，要描述清楚每个不可再分的细节呈现在用户面前时的样子。

这是一份功能而不是技术规格书。也就是 说，它的全部内容都用于描述用户所见所为，而不是程序如何实现。若需进一步了解功能规格，请阅读 http://www.joelonsoftware.com/articles/fog0000000036.html。程序经理不关心开发团队的内部 实现细节。当我将这份功能规格发给开发团队的头头Ben Waldman后，他和他的团队再坐下来详细讨论实现工作。最后，他们很聪明地弄出一份精悍的表格，将我定义的面向对象的接口一一映射到Excel 内部功能。当然这不是我的事情，我对Excel 内部知之甚少，并不知道那些需求应该怎么实现。

老实说，我那时候对什么都是一窍不通。刚从学校出 来，对代码开发、程序测试、文档撰写、产品推广以及可用性测试等，完全没有经验。幸运的是，微软在每个岗位都有经验丰富的导师，他们教给了我迄今知道的全 部知识，也是他们真正承担了这么大的产品的全部实际工作。举个我知道的例子说吧，用户在宏程序里将电子表格中单元格的值复制给一个变量：

x = [A1]

问题是单元格的值可能是数字，也可能是字符串；而Basic 语言是早期绑定的，你必须首先用DIM将x 定义为Integer、Float 或String等确定类型，然后才能使用。

要 解决这个问题，Basic 必须支持某种动态类型，但我没那么聪明，想不出什么解决办法。不要紧，Visual Basic团队的程序员Tom Corbett想出来了（http://www.patentstorm.us/patents/5689709/description.html）。 Variants和IDispatch由此诞生了，借助“鸭式类型识别”（duck typing。“如果一只鸟，走起来像鸭子，叫起来像鸭子，那我们就可以管它叫鸭子。”），于是Basic 摇身一变，成了动态语言。这个事情说明，我的工作不是自己去解决问题，而是找到用户需要解决的问题，并保证程序员找出解决这些问题的办法。

一旦功能规格完成、技术团队开始工作后，我的职责就有了变化：（1）解决设计方面出现的问题；（2）负责与所有其他团队的沟通，以便节省开发人员的时间。例如，我要向测试人员说明全部功能是如何运转的，并帮助他们设计测试计划；确保文档团队明白如何为Excel Basic 编写一份高质量的教程和参考手册；和本地化专家确定本地化策略；向市场人员解释VBA在市场上的优势；和可用性专家设计可用性测试方案等。

程序经理需参加大量的会议，但其产出基本不超出规格文档这个范围，因此我一个刚毕业的无用之人也能胜任这份工作。完全没必要让一个有14年经验的资深程序员担当程序经理。实际上，有14年的开发经验，你反而可能因为知道太多，而无法扮演好用户代言人这个角色。

冲突

如果没有程序经理，聪明的程序员们在一起，可能设计出让用户难以理解的界面，也许只有Vulcan 人（《Star Trek / 星际迷航》中逻辑思维能力超强的外星种族）才会表示“正合吾意”。最好的程序员会聪明到不能理解用户为何不能记住16 个单字母的命令行参数。这些程序员往往难以割舍他们的最初想法，尤其是已经将自己的想法变成了代码之后。

程序经理给软件设计流程带来的最大益处，是可以引入程序员之外的第二种观点。而这种观点恰恰更接近用户的想法——这些用户往往既不想阅读使用手册，更不想写什么emacs-lisp函数，至于在他们大脑里将十进制数字转化为八进制，那就更不可能了。

一个好的程序经理对于UI 的工作方式有他自己的想法，和开发人员的相比，可能更好，也可能更坏，因此需要双方进行讨论。通常，程序经理是站在用户角度，希望凡事都尽可能简单易懂， 诸如有心灵感应力的用户界面、大到30″ 而又能放进口袋的屏幕之类；而开发人员想的是处处尽可能减少要编写的代码，支持命令行界面（他们会说“这怎么就不好用了呢？”）和Python绑定。

我记得Excel 5项目中最为经典的争论发生在一个开发人员和程序经理之间。开发人员希望数据透视表（pivot table）悬浮在电子表格的绘画层上，而程序经理坚持认为数据透视表应位于单元格的右侧。这个争论持续了很长时间，最后由程序经理胜出。而最终的设计比 当初任何一方的单独设计都好出很多。

为确保这种争论完全以事实为基础、在参与方间平等地展开，程序经理和开发人员地位对等是必要的。如果开发人员 负责向程序经理汇报，那么在争论过程的任何时刻，程序经理只要略感厌倦，就可以说“好了，讨论得够了，现在就按我说的办”。但如果他们是对等的，这种事情 就不会发生。就好比在法庭，我们不能允许任何一方的律师同时是法官。只有建立在这个理论之上，真理才最可能通过对等双方间的争论而被发现。只有任何参与方 都不具有不公平优势时，争论本身才可能是公平的。

这点很关键，如果你刚才还在梦里探究11年级的Sally 现在在哪儿，赶紧醒醒吧。她在Scottsdale做生物医学家，还入了共和党。我们必须明白，程序员不能是程序经理的下属，换句话说，开发团队的头头、CTO或CEO，都不应是负责撰写规格书的人。

大多数公司犯的头号错误，就是让程序员的上级编写规格书、设计产品。这样出来的设计，不能得到真正平等的审查，不能引出冲突与争议，自然就不会好到哪里去。

要我真正弄懂这个道理，其实并不容易。在Fog Creek 软件公司，我自己曾承担了该程序经理做的大量工作，为此我费劲口水，时刻提醒在我说错的时候，程序员要指出、争辩。我们不是大公司，但也已经到了需要真正 的程序经理的时候了——Dan和Jason，程序员喜欢和他们吵。

当然，程序员和程序经理地位对等的时候，程序员会略占优势。这样的事曾发生过几次：程序员让我介入他和程序经理间发生的争议。

“谁写代码？”我问。

“是我……”

“那好，谁负责将程序签入版本控制库呢？”

“我想还是我……”

“既然这样，那你还有什么问题呢？”我问，“你对最终产品的每个比特都有绝对控制权，你还需要什么呢，一顶皇冠？”

可见，这种体制将担子压在了程序经理肩上，要求程序经理能说服程序员，因为在某些时候，程序经理会面临程序员不理会争议而直接按自己想法行事的风险。因此，要成为一名优秀、有影响力的程序经理，要求你：（1）正确；（2）赢得程序员的尊重，唯此他们才可能承认你的正确。

注：本文节选自Joel Spolsky的博客文章，全文请参考杂志官方Blog：http://blog.csdn.net/programmer_editor

作者简介
Joel Spolsky，Fog Creek 软件公司（http://www.fogcreek.com/）创始人，曾在微软Excel 团队工作。他的网络日志“Joel谈软件”一度是最知名的IT博客之一。作者博客：www.joelonsoftware.com/。

（本文来自0902期《CTO》专刊）

来源： CSDN博客--有胜人生一场醉
原文地址：http://blog.csdn.net/baoqiangwang/archive/2009/10/19/4700713.aspx

一、架构师定义

架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。

二、构架师的职责

架构师的职责就是设计一个公司系统的基础架构，并提供关于怎样建立和维护系统的指导方针。具体来讲，架构师的职责主要体现在以下几方面：
1、负责公司系统的架构设计、研发工作。
2、承担从业务向技术转换的桥梁作用。
3、协助项目经理制定项目计划和控制项目进度。
4、负责辅助并指导系统分析开展设计工作。
5、负责组织技术研究和攻关工作。
6、负责组织和管理公司内部的技术培训工作。
7、负责组织及带领公司内部员工研究与项目相关的新技术。
8、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。
9、理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架）。
10、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。

三、架构师的目的
对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。

重用：人们希望系统能够重用以前的代码和设计，从而提高开发效率。

扩展：人们希望在系统能够保持结构的稳定的前提下很容易地扩充功能和性能。

简洁：简洁是一种美，好的架构一定易于理解，易于学习，易于维护。

四、架构师能力要求
1、系统架构相关的知识和经验。
2、很强的自学能力、分析能力、解决问题的能力。
3、写作、沟通表达、培训。

五、构架设计师（或者构架团队的成员）必须具备的技能

经验：既包括在问题领域的经验（通过彻底了解需求），也包括在软件工程领域的经验。对于一个构架团队，这些素质要求可由各团队成员来分别承担，但其中至少要有一名构架设计师能够把握项目的全局。

领导才能：能够推动各个团队的技术进展，并能在压力下作出关键性的决策然后将其贯彻到底。要提高效率，构架设计师和项目经理必须紧密协作。构架设计师主要负责解决技术问题，项目经理主要负责解决行政管理问题。构架设计师必须有权在技术问题上作出决定。

沟通：能够赢得他人的信任，以对其进行说服、激励和指导。构架设计师不能靠命令进行领导，而必须要赢得项目中其他人员的赞同。为了提高效率，构架设计师必须赢得项目团队、项目经理、客户、用户群体以及管理团队的尊敬。

以目标为中心、积极主动：不懈地追求成效。构架设计师是推动项目发展的技术动力，而不是空想家。在其职业生涯中，成功的构架设计师一直都要在捉摸不定和承受压力的情况下作出折衷决定。构架设计师只有将注意力集中在该做的事情上，才能在项目中取得成功。

专业：精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）。具备系统设计员的所有技能，但涉及面更广、抽象级别更高。

六、构架活动
确定用例或需求的优先级、进行构架分析、创建构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、确定设计机制、确定设计元素、合并已有设计元素。

七、构架工件
软件构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议。

备注：架构师书单 http://blog.csdn.net/calvinxiu/archive/2007/03/06/1522032.aspx

转自：深之JohnChen的专栏 

原文地址：http://blog.csdn.net/byxdaz/archive/2009/10/11/4653090.aspx