领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
一个国内技术专家参加MCA面试的失败经历
作者 王翔(Vision Wang) 发布于 2007年9月23日
IT领域名目繁多的认证已经让人见多不怪了，但是作为软件行业最高的两个认证之一，MCA（Microsoft Certificated Architect）考试一直以高考试费用、高经验门槛和低通过率著称。在本周悉尼进行的MCA面试中有来自中国大陆的技术专家参与，下面是与他交流中他谈及的一些体会。
不论是MCA考试一万美元的考试费用，还是10年的软件从业经验，任何一个条件对于已经对很多考试麻木的国内IT人员而言都是一个很高的障碍。考试内容不仅涉及技术底蕴、团队领导能力、项目规划和组织能力，还包括分析、沟通、协作能力考察，全程英文环境（虽然可以请翻译，但考虑到翻译对相关的技术词汇理解能力，还是算了），最复杂的就是面对4位MCA考官异常苛刻的面试。
上周一个大陆的技术专家参与了MCA面试，虽然现在结果还不明，但获得了很多有用的体会：首先，MCA考核的不是单纯微软技术，他考核的内容非常广泛，评审中最少一位、一般两位是非微软专家，而且来自不同地区（北美、欧洲、印度、亚太等），如果你仅仅对微软技术有所了解，那会被评定为知识面太过狭窄。项目和工作经历的考察非常关键，虽然在填写个人材料时可以说明自己在项目中的领导地位，但要经得起4位已经获得MCA资格考官的推敲和追问，而且考官的项目背景也是根据申请人的项目类型背景有所选择的。虽然很多时候架构师给人的感觉是偏重技术性的，但CMMI、6希格玛、MSF、Agile的相关知识都要掌握，不仅要能够“照本宣科”地背出来，更主要的是能够根据考官提出的风险信息和虚拟的项目异常情景给出令考官满意的回答。也就是说MCA对这个A的要求不仅仅是架构师，而是“架构师 + 项目经理 + 系统分析师”的综合体。
也许参与MCA考试的技术专家之前已经很习惯于评审别人的各个技术方案、已经完成了很多组织级的最佳模式和开发规程的制定，但参加MCA面试则需要介绍一个自己觉得最满意项目的技术实施情况，扩展性、可用性、安全性、关键模块的松散耦合处理还有各种经典架构模式的应用都要经受考官异常苛刻的检验。其中一些关键点的考察是这位朋友认为最令人难忘的经历，比如：“在你的方案中三个异地数据中心的双向复制是怎么实现的，Identity类型数据如何处理，如何避免震荡”等。还有就是一个比较软性的考察，对参与者年龄和实际工作时间的考察，评委一般都是四、五十岁的人员，参与的项目经验也是绝大多数同行望尘莫及的，刚刚从业10年的技术专家的经验在他们眼中是相对不足的，除非你可以在很多问题的回答上、在自己特别出“彩头”的项目介绍上的确令他们信服你确实完全合格了。
MCA虽然就是个IT认证考试，但通过与这位参与者的交流，发现对于什么是架构师，架构师应该具有的技术能力、项目组织能力、人际工程能力有了全新的认识，考虑到架构师在软件项目中愈发重要的地位，为了更好参与国际竞争，也许MCA（和SCEA）都是一面不错的镜子。
后记：
在本新闻即将发布时，消息传来，那位同行没有通过。考官的点评是知识领域过于狭窄，没有行业内其他产品家族的实施经验，另外就是工作经验仅限于一个行业，而且仅有10年，虽然工作经历中参与实施了该行业的很多项目（规模在RMB 8、9位数），但知识体系不适于MCA这个全球认证。另外就是软件工程方法局限于CMMI，对于利于中小规模项目实施的Agile方法几乎没有涉猎。
简而言之，就是觉得这位参试人员知识体系不足以应付我们这个行业“群雄并起”的局面。
其实软件工程方面的知识没有那么复杂
发表人
liu ozzzzzz
发表于
Re: 其实软件工程方面的知识没有那么复杂
发表人
Codelicious ^
发表于
Re: 其实软件工程方面的知识没有那么复杂
发表人
liu ozzzzzz
发表于
Re: 其实软件工程方面的知识没有那么复杂
发表人
hello hello
发表于
构架师最忌知识领域过于狭窄
发表人
Chu Kevin
发表于
我认为对的
发表人
Wei Jianjun
发表于
-
其实同国外特别是欧美人士的交流不需要太多理论的知识，当然如果你有IE基础，并且对财务理论有理解，同时对系统论和方法论都有涉猎，会容易很多。不过就单纯的软件工程方法来说，如果参加MS的考察还是首先应该了解一下MSF,其次普遍情况下还需要明白一点UP，而最近的情况是agile成为了必选。至于CMM那套东西，完全可以说只是听过，没有研究。同时还必选有自己对于问题独特的见解，比如说对方强调agile适应小项目，你马上就应该反驳说其实agile非常适应于大型项目和大型企业，至少FDD和LEAN是如此。而一般情况下，讨论的重点在迭代的实施和方式的选择上。
-
ozzzzzz大虾也在这里啊...哈哈...
我觉得MCA是言过其实... 任何问题都没有唯一的正确答案
其实领域NARROW反而是好事, 现在还有谁认为自己什么都懂的? -
企业构架师，最关键的任务其实是实现互操作为基础的EAI，SOA等构架；所以知识面肯定除了涉及微软的外，BEA，IBM，ORACLE，OpenSource等都要涉及，并且最好能有其他技术平台的实际操作经验。
MCA也是我的理想，可惜目前我对于微软的很多技术都还停留在理论上（要获得实际操作的机会是很难得的），其他平台更是了解皮毛。比这位仁兄还差得多，离MCA就更远了。 -
作为技术领域专家，领域越是深入，当然是最重要的。而如果做为构架师则还差很远。
我这里强调的是，构架师的主要工作不是技术而是管理和商业。我对现在某些人炒作Architecrure非常反感。 -
之前认识的两位MCA一位41岁考没通过，43岁通过的，另一位算是MIT的超人型的，毕业后一直在美林，不过也是37岁通过的。
-
是的。
6 条回复
关注此讨论 回复