项目经理:太累,不懂领导到底要啥。
团队成员:闲得无聊,不知道要干什么。对工作没有积极性,不主动。
这样的结果就是:领导和项目经理的个人能力,基本决定了项目成功的可能性。
然后大家开始分析为什么会这样,原因在哪里,于是就引入了MSF的团队模型。
当然这个实验模型为了突出问题,做了很多简化,但在实际环境中,这些缺陷是确确实实存在的。
MSF的团队模型中,分成了6个角色,这6个角色是:程序管理、开发、测试、发布管理、用户体验、产品管理。每个角色之间是平等的关系,没有上下级的行政差别。
这几个角色并非一定要和人一一对应,当你没有足够的人手时候,一些角色可以重叠,由一个人兼任,但开发不推荐和其它角色兼任,这是因为要保持开发的封闭性。
当你的团队人数众多,规模比较大的时候,可以把大团队划分成小团队,再由核心团队总揽。既可以按照软件功能、特性来分成功能团队,也可以根据职能划分,例如,程序管理角色有多个人担任。这充分体现了MSF非常灵活、务实的一面,适应性很强。可以用于几个人的小TEAM,也可以适用于规模很大的团队。
敏捷软件开发理论适应性就弱些,大家公认不太适合超过10人的团队组织,而且,对成员的要求更高。
在另外一个模型-过程模型里面,MSF敏捷的一面又显露了出来。通过把复杂的项目分成多个版本进行迭代开发,来充分的简化项目难度。每个版本都有自己要完成的功能范围,可以看成一个“小项目”,项目小了,复杂度、难度自然大大下降,当然成功的概率就高的多。而且,和项目相关的人能很快的评估项目成果,来决定项目的“下一版本”方向。
在每个项目过程中,都包含一个很完整的阶段,项目构思、项目计划、项目开发、项目稳定、项目部署。从项目构思到项目部署结束,每个环节都有很多的所谓“里程碑”成果。就是每个阶段都有很明确的要求,到底要拿出什么成果。而这些成果,是需要团队成员共同努力来取得的,正好和团队模型相互结合。
在项目的任何一个阶段,每一个团队成员都要有成果,大家是并行工作的。这样一来,就避免了传统组织方法的很多弊病,如开发没结束,测试难以进行。在这样的模型中,不再是一个上司发号施令,下面的人去被动执行,已经演变成了大家都能积极主动的参与进来,每个人都有事情可以做。不同的角色在不同的项目阶段,分别起到主导作用。
课程中还有一个很重要的MSF原则贯穿其中,那就是风险。所谓风险,简单的说就是事件有可能发生,但是不确定何时何地。
团队最早开始做的事情之一就是管理风险,我们通过分组,在课堂上模拟了一遍,很有意思。每个人根据实验要求,挖空心思,冥思苦想,想象在项目过程中到底会发生什么事情,判断可能性和后果。连团队成员怀孕,无法继续工作这种事情也被找了出来,戏剧性的是,一个学员就承认,自己的团队就遇见了这样的麻烦,而且还不知道到底应该怎么办。
管理风险的目的就是把握主动权,在风险发生的时候能迅速处理,从而保证项目能顺利进行下去。这样一来,客户会对我们更有信心,更信任我们,项目成功的可能性会进一步提高。
课程的后面,就是具体的项目执行过程了,如项目计划的制定、开发、稳定、部署等等。其中不乏精彩的观点和指导方针,让你有法可依。
这就是我在MSF培训结束后的体会和总结。
理论和实践从来都是相互交织的,没有理论,做事情就没有章法,没有后劲。缺乏实践,理论就变得十分空洞,陷入空谈。你必须把理论不断的应用于项目管理实践,才能不断的成长、成熟。
所以在这里向大家推荐“微软解决方案框架”这套理论和课程。
大家可以去 http://www.newtrain.com.cn/ 和微软合作的培训组织
http://www.microsoft.com/msf 微软解决方案框架相关内容查看一下相关信息。
想成为项目管理者的各位好汉,准备好了吗?
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/