没有登录
中国开发网: 论坛: 程序员情感CBD: 贴子 531444
haitao
架构师的能力模型
架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
│└核心
├技术技能
│├模型化
│├实现能力
│├决策背景
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
├学会谈判
├风险与防备
├抽象思维
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)




架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
││├技术和专业能力(Technical/Professional)
││├人际关系的能力(Human Competencies)
││└业务能力(Business Competencies)
│└核心
│ └个人内在素质
├技术技能
│├模型化
││├建立抽象模型
││├基于模型分析与评估
││└准确地图形表达
│├实现能力
││├对不同层次上的架构师的实现能力要求是不一样的
││├架构推行
││├体系/系统的把握
││└设计能力
│├决策背景
││├需求决定设计
││├丰富的领域知识
││├业务或产品线规划先于架构
││├不要急于做出重要的决策,但可以先实现基础
││├你不一定是技术高手,但一定要广闻薄积
││├做一些具体的工作,用以验证系统或找到感觉
││└思考与控制成本
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
│├学会交谈
│├心理分析
│├局面分析
│└写作训练
├学会谈判
│├对结果的预期
│├过程的控制
│└适时地停止讨论
├风险与防备
│├冷静观察
│├最大的风险是成本的枯竭
│└准确理解决策者的意图和方向
├抽象思维
│├理性决策
│└把事情搞清楚
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)




架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
││├技术和专业能力(Technical/Professional)
│││└关联到->技术技能
││├人际关系的能力(Human Competencies)
│││└关联到->个人特性
││└业务能力(Business Competencies)
││ ├关联到->技术技能
││ └关联到->个人特性
│└核心
│ └个人内在素质
│ └类似于诚信、坚韧、耐心等等,不在讨论的范围之内
├技术技能
│├模型化
││├建立抽象模型
││├基于模型分析与评估
││└准确地图形表达
││ ├尽可能标准化
││ ├标准化之外的定制部分一定要注明
││ └避免歧义(例如箭头、框图的使用)
│├实现能力
││├对不同层次上的架构师的实现能力要求是不一样的
││├架构推行
│││├熟悉软件工程的各个环节
│││├熟悉各类脚色的性质与特长
│││├对组织结构的灵活把握
│││└有限制地运用职权
││├体系/系统的把握
│││├了解公司的决策过程
│││├了解系统工程
│││├了解产品或产品线工程
│││├了解市场与用户
│││├了解客户心理与承受力
│││└了解人的认知系统
││└设计能力
││ ├了解你的主要对象沟通
││ ├设计期语言(例如建模语言)
││ ├了解既有系统
││ └设计评估
│├决策背景
││├需求决定设计
││├丰富的领域知识
││├业务或产品线规划先于架构
││├不要急于做出重要的决策,但可以先实现基础
││├你不一定是技术高手,但一定要广闻薄积
││├做一些具体的工作,用以验证系统或找到感觉
││└思考与控制成本
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
│├学会交谈
││├学会听
││├注意交谈时的表情与姿态
││└不用急于表达,以及肯否
│├心理分析
│├局面分析
│└写作训练
│ ├更加准确地表达自己的观点,并推行它
│ ├更强的逻辑性
│ ├文档是架构的主要输出
│ └学会通过文档定义事物,并推行它
├学会谈判
│├对结果的预期
││├谈判不是辩论而是折衷
││└取舍是一个过程而非结果
│├过程的控制
││├我可以不同意你的观点,但捍卫你说话的权利
││├学会说:你是对的
││└有些时候争执不是因为正误,而是因为面子
│└适时地停止讨论
│ ├对不起,我还没想清楚
│ ├我们能否先尝试一下
│ └没有结论也是结论
├风险与防备
│├冷静观察
││├尽可能早地发现风险
││└尽可能晚地做出决策
│├最大的风险是成本的枯竭
││├控制时间
││├把握变更
││├人际关系
││├资金链崩溃
││└领导或客户的耐心
│└准确理解决策者的意图和方向
├抽象思维
│├理性决策
││├不要一成不变
││├不要从众
││└不要求完美
│└把事情搞清楚
│ ├善于定义和否定
│ ├逻辑分析
│ └关注事物的层次分解
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)




架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
││├技术和专业能力(Technical/Professional)
│││└关联到->技术技能
││├人际关系的能力(Human Competencies)
│││└关联到->个人特性
││└业务能力(Business Competencies)
││ ├关联到->技术技能
││ └关联到->个人特性
│└核心
│ └个人内在素质
│ └类似于诚信、坚韧、耐心等等,不在讨论的范围之内
├技术技能
│├模型化
││├建立抽象模型
││├基于模型分析与评估
││└准确地图形表达
││ ├尽可能标准化
││ ├标准化之外的定制部分一定要注明
││ └避免歧义(例如箭头、框图的使用)
│├实现能力
││├对不同层次上的架构师的实现能力要求是不一样的
││├架构推行
│││├熟悉软件工程的各个环节
│││├熟悉各类脚色的性质与特长
│││├对组织结构的灵活把握
│││└有限制地运用职权
││├体系/系统的把握
│││├了解公司的决策过程
│││├了解系统工程
│││├了解产品或产品线工程
│││├了解市场与用户
│││├了解客户心理与承受力
│││└了解人的认知系统
││└设计能力
││ ├了解你的主要对象沟通
││ │├决策者
││ │├用户
││ │└设计师
││ ├设计期语言(例如建模语言)
││ │├语言是贫瘠的
││ │├因其贫瘠而准确
││ │└不要向所有人讲同一种语言
││ ├了解既有系统
││ │├至少同时跟踪(track)两到三套大型框架
││ │├了解最新的框架技术与模型
││ │└尝试向更多的人推荐它
││ └设计评估
││ ├从设计的表面看到设计者的意图
││ └没有最好的设计,只有适当的设计
│├决策背景
││├需求决定设计
││├丰富的领域知识
││├业务或产品线规划先于架构
││├不要急于做出重要的决策,但可以先实现基础
││├你不一定是技术高手,但一定要广闻薄积
││├做一些具体的工作,用以验证系统或找到感觉
││└思考与控制成本
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
│├学会交谈
││├学会听
││├注意交谈时的表情与姿态
││└不用急于表达,以及肯否
│├心理分析
│├局面分析
│└写作训练
│ ├更加准确地表达自己的观点,并推行它
│ ├更强的逻辑性
│ ├文档是架构的主要输出
│ └学会通过文档定义事物,并推行它
├学会谈判
│├对结果的预期
││├谈判不是辩论而是折衷
││└取舍是一个过程而非结果
│├过程的控制
││├我可以不同意你的观点,但捍卫你说话的权利
││├学会说:你是对的
││└有些时候争执不是因为正误,而是因为面子
│└适时地停止讨论
│ ├对不起,我还没想清楚
│ ├我们能否先尝试一下
│ └没有结论也是结论
├风险与防备
│├冷静观察
││├尽可能早地发现风险
││└尽可能晚地做出决策
│├最大的风险是成本的枯竭
││├控制时间
││├把握变更
││├人际关系
││├资金链崩溃
││└领导或客户的耐心
│└准确理解决策者的意图和方向
├抽象思维
│├理性决策
││├不要一成不变
││├不要从众
││└不要求完美
││ ├任何看起来完美的事物都一定有问题
││ ├左顾右盼不如先行尝试
││ └可以让问题暴露出来
│└把事情搞清楚
│ ├善于定义和否定
│ ├逻辑分析
│ └关注事物的层次分解
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)





架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
││├技术和专业能力(Technical/Professional)
│││└关联到->技术技能
││├人际关系的能力(Human Competencies)
│││└关联到->个人特性
││└业务能力(Business Competencies)
││ ├关联到->技术技能
││ └关联到->个人特性
│└核心
│ └个人内在素质
│ └类似于诚信、坚韧、耐心等等,不在讨论的范围之内
├技术技能
│├模型化
││├建立抽象模型
││├基于模型分析与评估
││└准确地图形表达
││ ├尽可能标准化
││ ├标准化之外的定制部分一定要注明
││ └避免歧义(例如箭头、框图的使用)
│├实现能力
││├对不同层次上的架构师的实现能力要求是不一样的
││├架构推行
│││├熟悉软件工程的各个环节
│││├熟悉各类脚色的性质与特长
│││├对组织结构的灵活把握
│││└有限制地运用职权
││├体系/系统的把握
│││├了解公司的决策过程
│││├了解系统工程
│││├了解产品或产品线工程
│││├了解市场与用户
│││├了解客户心理与承受力
│││└了解人的认知系统
││└设计能力
││ ├了解你的主要对象沟通
││ │├决策者
││ │├用户
││ │└设计师
││ ├设计期语言(例如建模语言)
││ │├语言是贫瘠的
││ │├因其贫瘠而准确
││ │└不要向所有人讲同一种语言
││ ├了解既有系统
││ │├至少同时跟踪(track)两到三套大型框架
││ │├了解最新的框架技术与模型
││ ││├同时阅读它的正面与负面的评论
││ ││├不要做新技术(与思想)的狂热者
││ ││└尝试重构它的模型
││ │└尝试向更多的人推荐它
││ │ ├看清楚它的历史与面临的问题
││ │ ├找到它的竞争者或者(面对同一问题的)不同的实现方案
││ │ ├它一定存在某个应用边界
││ │ └目的只是为了讲清楚它,而并不是视图影响别人的选择
││ └设计评估
││ ├从设计的表面看到设计者的意图
││ │├发现问题的关键而非外表
││ │├简单的设计是对的,但前提是全民的分析
││ │└设计的结果如果不能体现设计师的折衷过程的痛苦,那一定不是好的设计
││ └没有最好的设计,只有适当的设计
││ ├学会平衡设计
││ ├学会肯定别人的设计
││ └回到原始需求去看看
│├决策背景
││├需求决定设计
││├丰富的领域知识
││├业务或产品线规划先于架构
││├不要急于做出重要的决策,但可以先实现基础
││├你不一定是技术高手,但一定要广闻薄积
││├做一些具体的工作,用以验证系统或找到感觉
││└思考与控制成本
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
│├学会交谈
││├学会听
││├注意交谈时的表情与姿态
││└不用急于表达,以及肯否
│├心理分析
│├局面分析
│└写作训练
│ ├更加准确地表达自己的观点,并推行它
│ ├更强的逻辑性
│ ├文档是架构的主要输出
│ └学会通过文档定义事物,并推行它
├学会谈判
│├对结果的预期
││├谈判不是辩论而是折衷
││└取舍是一个过程而非结果
│├过程的控制
││├我可以不同意你的观点,但捍卫你说话的权利
││├学会说:你是对的
││└有些时候争执不是因为正误,而是因为面子
│└适时地停止讨论
│ ├对不起,我还没想清楚
│ ├我们能否先尝试一下
│ └没有结论也是结论
├风险与防备
│├冷静观察
││├尽可能早地发现风险
││└尽可能晚地做出决策
│├最大的风险是成本的枯竭
││├控制时间
││├把握变更
││├人际关系
││├资金链崩溃
││└领导或客户的耐心
│└准确理解决策者的意图和方向
├抽象思维
│├理性决策
││├不要一成不变
││├不要从众
││└不要求完美
││ ├任何看起来完美的事物都一定有问题
││ ├左顾右盼不如先行尝试
││ └可以让问题暴露出来
│└把事情搞清楚
│ ├善于定义和否定
│ ├逻辑分析
│ └关注事物的层次分解
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)




架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
││├技术和专业能力(Technical/Professional)
│││└关联到->技术技能
││├人际关系的能力(Human Competencies)
│││└关联到->个人特性
││└业务能力(Business Competencies)
││ ├关联到->技术技能
││ └关联到->个人特性
│└核心
│ └个人内在素质
│ └类似于诚信、坚韧、耐心等等,不在讨论的范围之内
├技术技能
│├模型化
││├建立抽象模型
││├基于模型分析与评估
││└准确地图形表达
││ ├尽可能标准化
││ ├标准化之外的定制部分一定要注明
││ └避免歧义(例如箭头、框图的使用)
│├实现能力
││├对不同层次上的架构师的实现能力要求是不一样的
││├架构推行
│││├熟悉软件工程的各个环节
│││├熟悉各类脚色的性质与特长
│││├对组织结构的灵活把握
│││└有限制地运用职权
││├体系/系统的把握
│││├了解公司的决策过程
│││├了解系统工程
│││├了解产品或产品线工程
│││├了解市场与用户
│││├了解客户心理与承受力
│││└了解人的认知系统
││└设计能力
││ ├了解你的主要对象沟通
││ │├决策者
││ │├用户
││ │└设计师
││ ├设计期语言(例如建模语言)
││ │├语言是贫瘠的
││ │├因其贫瘠而准确
││ │└不要向所有人讲同一种语言
││ ├了解既有系统
││ │├至少同时跟踪(track)两到三套大型框架
││ │├了解最新的框架技术与模型
││ ││├同时阅读它的正面与负面的评论
││ ││├不要做新技术(与思想)的狂热者
││ ││└尝试重构它的模型
││ ││ ├如果你做不到
││ ││ └如果你做到了
││ │└尝试向更多的人推荐它
││ │ ├看清楚它的历史与面临的问题
││ │ ├找到它的竞争者或者(面对同一问题的)不同的实现方案
││ │ ├它一定存在某个应用边界
││ │ └目的只是为了讲清楚它,而并不是视图影响别人的选择
││ └设计评估
││ ├从设计的表面看到设计者的意图
││ │├发现问题的关键而非外表
││ ││├通常的主要原因在于对目标的理解不同
││ ││├次要原因在于对系统的抽象能力
││ ││└最次要的原因是设计表达能力
││ │├简单的设计是对的,但前提是全民的分析
││ ││├尽可能与设计者讨论他的分析过程
││ ││└做好需求确认
││ │└设计的结果如果不能体现设计师的折衷过程的痛苦,那一定不是好的设计
││ └没有最好的设计,只有适当的设计
││ ├学会平衡设计
││ │├系统可持续发展吗?
││ │├找出实施该设计的所有条件与限制,评估所有干系人对它们的态度
││ │├关注系统的弹性
││ │└留下问题,但不要放过错误
││ ├学会肯定别人的设计
││ │├架构师的设计能力不一定是最强的
││ │├你只是架构角色中的一员
││ │├你只是系统角色中的一员
││ │└懂得欣赏的才是艺术家
││ └回到原始需求去看看
│├决策背景
││├需求决定设计
││├丰富的领域知识
││├业务或产品线规划先于架构
││├不要急于做出重要的决策,但可以先实现基础
││├你不一定是技术高手,但一定要广闻薄积
││├做一些具体的工作,用以验证系统或找到感觉
││└思考与控制成本
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
│├学会交谈
││├学会听
││├注意交谈时的表情与姿态
││└不用急于表达,以及肯否
│├心理分析
│├局面分析
│└写作训练
│ ├更加准确地表达自己的观点,并推行它
│ ├更强的逻辑性
│ ├文档是架构的主要输出
│ └学会通过文档定义事物,并推行它
├学会谈判
│├对结果的预期
││├谈判不是辩论而是折衷
││└取舍是一个过程而非结果
│├过程的控制
││├我可以不同意你的观点,但捍卫你说话的权利
││├学会说:你是对的
││└有些时候争执不是因为正误,而是因为面子
│└适时地停止讨论
│ ├对不起,我还没想清楚
│ ├我们能否先尝试一下
│ └没有结论也是结论
├风险与防备
│├冷静观察
││├尽可能早地发现风险
││└尽可能晚地做出决策
│├最大的风险是成本的枯竭
││├控制时间
││├把握变更
││├人际关系
││├资金链崩溃
││└领导或客户的耐心
│└准确理解决策者的意图和方向
├抽象思维
│├理性决策
││├不要一成不变
││├不要从众
││└不要求完美
││ ├任何看起来完美的事物都一定有问题
││ ├左顾右盼不如先行尝试
││ └可以让问题暴露出来
│└把事情搞清楚
│ ├善于定义和否定
│ ├逻辑分析
│ └关注事物的层次分解
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)




架构师的能力模型
├url:http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx
├作者:aimingoo
├转换:haitao
├三角形
│├边
││├技术和专业能力(Technical/Professional)
│││└关联到->技术技能
││├人际关系的能力(Human Competencies)
│││└关联到->个人特性
││└业务能力(Business Competencies)
││ ├关联到->技术技能
││ └关联到->个人特性
│└核心
│ └个人内在素质
│ └类似于诚信、坚韧、耐心等等,不在讨论的范围之内
├技术技能
│├模型化
││├建立抽象模型
││├基于模型分析与评估
││└准确地图形表达
││ ├尽可能标准化
││ ├标准化之外的定制部分一定要注明
││ └避免歧义(例如箭头、框图的使用)
│├实现能力
││├对不同层次上的架构师的实现能力要求是不一样的
││├架构推行
│││├熟悉软件工程的各个环节
│││├熟悉各类脚色的性质与特长
│││├对组织结构的灵活把握
│││└有限制地运用职权
││├体系/系统的把握
│││├了解公司的决策过程
│││├了解系统工程
│││├了解产品或产品线工程
│││├了解市场与用户
│││├了解客户心理与承受力
│││└了解人的认知系统
││└设计能力
││ ├了解你的主要对象沟通
││ │├决策者
││ │├用户
││ │└设计师
││ ├设计期语言(例如建模语言)
││ │├语言是贫瘠的
││ │├因其贫瘠而准确
││ │└不要向所有人讲同一种语言
││ ├了解既有系统
││ │├至少同时跟踪(track)两到三套大型框架
││ │├了解最新的框架技术与模型
││ ││├同时阅读它的正面与负面的评论
││ ││├不要做新技术(与思想)的狂热者
││ ││└尝试重构它的模型
││ ││ ├如果你做不到
││ ││ │├它实现得太糟糕
││ ││ │└它实现得太精彩
││ ││ └如果你做到了
││ ││ ├你可能并没有了解这个系统
││ ││ ├你可能根本没看到问题
││ ││ ├你努力解决的问题不是它主要面临的
││ ││ └我承认你是超人
││ │└尝试向更多的人推荐它
││ │ ├看清楚它的历史与面临的问题
││ │ ├找到它的竞争者或者(面对同一问题的)不同的实现方案
││ │ ├它一定存在某个应用边界
││ │ └目的只是为了讲清楚它,而并不是视图影响别人的选择
││ └设计评估
││ ├从设计的表面看到设计者的意图
││ │├发现问题的关键而非外表
││ ││├通常的主要原因在于对目标的理解不同
││ ││├次要原因在于对系统的抽象能力
││ ││└最次要的原因是设计表达能力
││ │├简单的设计是对的,但前提是全民的分析
││ ││├尽可能与设计者讨论他的分析过程
││ ││└做好需求确认
││ │└设计的结果如果不能体现设计师的折衷过程的痛苦,那一定不是好的设计
││ └没有最好的设计,只有适当的设计
││ ├学会平衡设计
││ │├系统可持续发展吗?
││ │├找出实施该设计的所有条件与限制,评估所有干系人对它们的态度
││ │├关注系统的弹性
││ ││├提供可能性,而不是设定它的使用方法
││ ││├负面的现象是需求无度或系统失控
││ ││└弹性、易用性和稳定性是难于平衡的
││ │└留下问题,但不要放过错误
││ │ ├问题,只是无法清楚局部对全局的影响
││ │ │├架构师对体系的影响
││ │ ││├表现
││ │ │││├稳定性
││ │ │││├弹性
││ │ │││└效率
││ │ ││├外延
││ │ │││├可持续
││ │ │││├可移植
││ │ │││└可部署
││ │ ││└功能
││ │ ││ ├集成性
││ │ ││ ├扩展性
││ │ ││ └可用性
││ │ ││ ├升级
││ │ ││ ├发布管理
││ │ ││ └配置
││ │ │└关注它们,因为问题随时转变为错误
││ │ └错误通常导致的后果
││ ├学会肯定别人的设计
││ │├架构师的设计能力不一定是最强的
││ │├你只是架构角色中的一员
││ │├你只是系统角色中的一员
││ │└懂得欣赏的才是艺术家
││ └回到原始需求去看看
│├决策背景
││├需求决定设计
││├丰富的领域知识
││├业务或产品线规划先于架构
││├不要急于做出重要的决策,但可以先实现基础
││├你不一定是技术高手,但一定要广闻薄积
││├做一些具体的工作,用以验证系统或找到感觉
││└思考与控制成本
│├关联自->技术和专业能力(Technical/Professional)
│└关联自->业务能力(Business Competencies)
└个人特性
├有效沟通
│├学会交谈
││├学会听
││├注意交谈时的表情与姿态
││└不用急于表达,以及肯否
│├心理分析
│├局面分析
│└写作训练
│ ├更加准确地表达自己的观点,并推行它
│ ├更强的逻辑性
│ ├文档是架构的主要输出
│ └学会通过文档定义事物,并推行它
├学会谈判
│├对结果的预期
││├谈判不是辩论而是折衷
││└取舍是一个过程而非结果
│├过程的控制
││├我可以不同意你的观点,但捍卫你说话的权利
││├学会说:你是对的
││└有些时候争执不是因为正误,而是因为面子
│└适时地停止讨论
│ ├对不起,我还没想清楚
│ ├我们能否先尝试一下
│ └没有结论也是结论
├风险与防备
│├冷静观察
││├尽可能早地发现风险
││└尽可能晚地做出决策
│├最大的风险是成本的枯竭
││├控制时间
││├把握变更
││├人际关系
││├资金链崩溃
││└领导或客户的耐心
│└准确理解决策者的意图和方向
├抽象思维
│├理性决策
││├不要一成不变
││├不要从众
││└不要求完美
││ ├任何看起来完美的事物都一定有问题
││ ├左顾右盼不如先行尝试
││ └可以让问题暴露出来
│└把事情搞清楚
│ ├善于定义和否定
│ ├逻辑分析
│ └关注事物的层次分解
├关联自->人际关系的能力(Human Competencies)
└关联自->业务能力(Business Competencies)
我的blog:http://szhaitao.blog.hexun.com & http://www.hoolee.com/user/haitao
--以上均为泛泛之谈--
不尽牛人滚滚来,无边硬伤纷纷现 人在江湖(出来的),哪能不挨刀(总归是要的)
网络对话,歧义纷生;你以为明白了对方的话,其实呢?

您所在的IP暂时不能使用低版本的QQ,请到:http://im.qq.com/下载安装最新版的QQ,感谢您对QQ的支持和使用

相关信息:


欢迎光临本社区,您还没有登录,不能发贴子。请在 这里登录