解开MSF团队管理的秘密

热度3426票  浏览1267次 时间:2009年9月15日 16:32

摘要
    
MSF,全称是Microsoft Solution Framework,微软解决方案框架,是微软进行研发活动的方法论。微软的研发团队是让人羡慕、让人关注的团队,微软的研发团队是如何工作的?本文将为你解开其中的秘密。

 

   俗话说“三个臭皮匠胜过诸葛亮”,但实际工作中出现的常常是“三个诸葛亮不如一个臭皮匠”。

   您的软件开发团队有这样的一些问题吗?

   日程安排一团糟、功能不合适、到处都是系统错误,而原因就是左撇子不知道右撇子在做什么……

   一想到要出下一个版本,就觉得头晕想吐。

   神出鬼末的缺陷,杀之不尽的缺陷,无止境的加班。

   对计算机完全失去兴趣,萌生转行的念头。

   ……

   Oh my god!这就是软件开发吗?

   在谈软件开发团队之前,我们先看看优秀的团队,都具备怎样的一些特点?

l        英明的领袖

l        优秀的个人

l        严明的纪律

l        良好的沟通

l        一致的目标

l        协调的行动

l        良好的团队氛围

l        良好的习惯

l        ……

   您的团队有这样的特点吗?


特别声明:
如需转载此文,请给出指向本网站的连接,如下:
作者:张传波
摘自:http://www.umlonline.cn
如不能按此要求,请不要转载此文。

 

MSF的八大原理

软件开发团队管理有自身的特殊性,它更强调:

l        激发大家的潜能和创意。

l        让每一位成员有机会成为“牛人”。

l        充分发挥“牛人”的作用,并让牛人和其他团队成员和谐地工作。

l        让每位成员投入到创造性的工作中,享受成功的愉悦。

软件开发团队是一个种很特别的团队,很容易形成群众领袖,这种领袖并不是公司任命的,而是在实际工作中通过突出的工作表现,在所有成员的心目中自发形成的,这些人就是我们常说的“牛人”,这些牛人是最让公司又爱又恨的人了,如何让管理好这些牛人,如何让牛人们和谐地工作,这是软件开发团队管理的一大难点。

微软可以说是牛人如云了,微软的团队管理有什么秘密呢?

微软的MSF有以下八大基本原理:

一、推动开放式沟通

几乎90%的团队问题,都可以归结为沟通问题,沟通管理已经成为团队管理中最泛滥的一个词语了。这里又有一个新名词,“开放式沟通”!

“开放式沟通”具备以下的特点:

l        即时、主动

需要沟通时马上进行沟通,感觉到有问题时马上进行沟通,事后诸葛亮是为人所不齿的。

l        有效

用最直接最有效的方式沟通,抓住要害,准确表达,尽量简短。

l        形式多样

用尽可能多的最合适的方式沟通,面对面谈话、邮件、msnQQ等,哪种方式最有效最直接,就用哪一种。

l        参与

强调人人参与,人人都要主动沟通,同时也要主动去和每一个人沟通。团队每一位成员都参与到每一个活动中。

l        包容

认真聆听各方面意见,鼓励不同意见。

l        直接、坦诚

说话不需要拐弯抹角,不需要诸多粉饰,用最直接最坦白的话来表达。

l        对事不对人

不戴有色眼镜看人,所有的沟通都是为了把事情做好。

 

二、为共同的前景工作

简单的说就是大家的目标要一致,并一起为这个共同的目标努力工作。

所有伟大的软件必定有一份宏伟的前景文档,该文档描述了软件将会带来什么社会价值、经济价值,开发本软件的目的是什么,本软件应用的范围、领域,本软件能解决什么业务问题,本软件有什么特性等等。

如果达不到以下任何条件之一,都不能算“为共同的前景”工作:

l        这个前景是大家一起来制定并一致通过的;

l        团队中的任何一个人在任何时候都能清晰地说出本项目的前景的大致内容。

l        用前景来指导工作,明确工作的重点,明确工作的方针,用前景来解决工作中的分歧。

很多人都会喊团队需要有一致的目标这样的口号,能不能做得到?以上三点就是检验的标准。

 

三、赋予小组成员权力

“在最优秀的小组里,不同的个人会在不同场合下体现出其领导能力,他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导,因为如果这样的话,这个人就无法和其他人融为一个整体,而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”

——Tom DeMarco  Timothy Lister

微软的团队是没有固定的领导的,因为任何人都是领导,每位成员都有不可替代的作用,每位成员在自己专长的领域中担当领导的作用。

 

四、清晰的责任和共同的职责

测试一下大家对这点的理解,如果你的团队中出现这样的问题,这样处理是否合适?

项目进度推迟、项目预算超出计划,公司领导把项目经理叫去,严厉的批评了一顿,而没有责备过任何其他项目成员。

软件发布出去后,发现严重的缺陷,公司领导把测试人员叫去严厉批评,也没有责备过任何其他项目成员。

你们的团队中,有没有这样的情况:

只有项目经理为项目的进度、预算劳心劳累,其他人都在“安分”地完成“本职”工作,不会主动过问其他情况。

出现问题时,谁是问题责任人的皮球会被踢来踢去,没有人愿意承担责任。

为什么有这样的问题呢?应该如何处理呢?是责任定得不够清晰吗?

团队的每一位成员,肩负起自己所在领域的责任,团队的每一位成员共同对最终解决方案负责,同时鼓励小组成员对非他们直接负责的领域作出评论和贡献。

软件开发团队中,有项目管理、需求分析、设计、编码、测试等各个领域的人才,每领域的负责人对自己的工作负责。另外一个方面,软件是团队共同劳动成果,所有人对最终的解决方案负责,最终解决方案只有有问题,就是整个团队的责任,最终解决方案取得优异成绩,就是整个团队的功劳。软件开发团队,是一个“一荣俱荣、一损俱损”的团队,只有这样才能把全部人的利益扭在一起。

了解了微软的这个原理后,大家对前面提到的问题有答案了没有?


特别声明:
如需转载此文,请给出指向本网站的连接,如下:
作者:张传波
摘自:http://www.umlonline.cn
如不能按此要求,请不要转载此文。

 

五、关注交付的业务价值

客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子。看上去可笑,但这样的情况却经常发生在我们的身边。

关注交付的业务价值,意思就我们工作中的每一份工作产品,都应该是需求驱动做出来的,这样才能保证我们最终做出的软件就是客户所需要的东西。这个原理有以下几层意思:

l        小组成员要对客户的需求有一致的充分的理解。

l        要让客户积极参与到项目过程中去,随时了解小组的理解和客户的需要是否一致。

l        需求驱动地完成所有工作,保证最后的软件产品符合客户的需要。

 

六、保持灵巧,预测变化

软件是智力型创造性活动,保持灵活、适应变化是软件开发的最高境界了!我感觉这条原理是最难把握的一条了。

这个原理主要体现在以下方面:

l        软件开发过程

微软采用的不是RUP,也不是XP,而是类似于螺旋形的阶段式分版本发布。微软会把软件分成若干的版本发布,除了平时我们见到的Beta版、Release版,其实在Beta版之前还会有若干的内部版本。每个版本都包含相对完整的功能,都能实现部分业务价值。每一个版本就是一个开发周期,每个周期包含远景、计划、开发、稳定、部署五个阶段。这样的一种开发模型,能很好地适应需求变化,发现设计、编码缺陷,优化设计,更容易控制软件质量,便于随时做出商业决策。

图一:微软的开发模型

l        设计方案

执着于优雅设计的人士,可能很喜欢做出完美无缺的设计,关注于业务的人士,可能更关注于尽快要拿出软件。我们追求的是适度设计,而不是过度设计,如何做出一个简单的而又适应变化的设计,是对软件设计高手们的一大考验了。

 

TAG: 团队管理 MSF
顶:237 踩:235
对本文中的事件或人物打分:
当前平均分:-0.57 (951次打分)
对本篇资讯内容的质量打分:
当前平均分:-0.35 (931次打分)
【已经有1072人表态】
190票
感动
111票
路过
131票
高兴
130票
难过
138票
搞笑
105票
愤怒
118票
无聊
149票
同情
上一篇 下一篇
首页 第1页 第2页 第3页 第4页 第5页 第6页 第7页 第8页 第9页