您的位置:
在国内，不少做过几年程序员，被同事、圈内的朋友公认为技术水平不错的人，在考虑自身职业发展的时候，可能会想当然的认为："我可以做项目经理了，感觉做个项目经理也没啥特别难的"。
但如果你真的有机会，去尝试带一个团队，哪怕是只有几个人的一个小TEAM的时候，你就会发现，你必须面对一系列的问题和麻烦，而这些事情的处理结果，基本上和个人技术水平无关。
举一些例子：
"自己每天被领导施压，忙忙碌碌，累得吐血，可手下的几个人，却让人觉得他们闲的发慌"。
"给他们布置的任务，好像怎么也做不完，一拖再拖，个人感觉是很简单的事情"。
"好容易分工做完了几个模块，整合起来却怎么都不对，老是出现错误，还得我自己亲自动手修改处理"。
"交给了客户一个测试的版本做展示，客户第一句话就是：这个不是我们想要的"。
"眼瞅产品交付的最后期限逼近，可软件的问题层出不穷，错误百出，这怎么能让客户满意并且验收签字呢？"。
"天天加班，把人搞得生理时钟失调，昼夜颠倒，做这个项目的人怨声载道，整天怒气冲冲，威胁辞职、罢工"。
在具体的软件项目运转中，这些令人头痛的问题接连不断，常常把人搞得焦头烂额，心烦意乱，任你技术水平再高，都没用。俗话说的好："你浑身是铁，能碾几颗钉"。事必躬亲，大包大揽的结果只能是把自己累垮，工作还没做好。在软件越来越复杂，需求多变的情况下，个人英雄主义、单打独斗是行不通的，干活还得靠大家。
痛定思痛，你也会很聪明的想到：我必须使用软件工程方法、开发流程来管理我的团队。但你真的要在团队中套用上鼎鼎大名的CMM，更令人沮丧的事情还在后面：CMM中光是那一堆名词和文档，就够大家理解好久的了。而且，这些标准、指南更像是评分手册，可操作性不足。项目组好像整天在忙，老是开会，烦不胜烦，搞出一大摞文档，真正的软件却总是出不来。
还有不少其它的项目管理方法、指南，也是难以在实际环境中操作应用。
你必须找到适合自己公司团队的开发流程、框架，不仅要完整，而且必须有良好的可操作性，比较灵活，适应范围广泛。所以，向在软件项目管理上成熟、完善的公司学习，是个很有效的办法，能让你迅速掌握在项目管理上的各种方法和技巧，并且上升到理论水平。
在软件行业，微软公司的软件产品众多，产品线齐全。这个软件巨人在各个市场上取得的成功也是有目共睹，其软件项目的开发、管理过程也一直是大家很感兴趣的焦点。
笔者有幸参加了一次软件项目管理的培训，由微软中国顾问咨询部门的讲师主讲，为期三天，大有斩获。好多困扰已久的问题和疑惑得到了解答，有种豁然开朗的感觉。
课程内容是MSF-MicrosoftSolutionsFramework，微软解决方案框架，所谓MSF，就是微软公司定义的用于软件项目管理的一套完整的流程、方法。讲义是从英文教材翻译过来的，MSF的版本是3.0。你可能会觉得奇怪，怎么这个框架还有版本。嗯，没错，微软公司的讲师声称，当VisualStudio.net2005发布的时候，会整合、携带MSF4.0一起面市。
因为MSF自身也是根据软件产业环境，根据新的思想、新的理念、新的实际项目经验不断调整，不断演进的，并不是教条。如3.0版本的过程模型中，就比2.0版本多了一个称为部署阶段的过程。
