但如果你真的有机会，去尝试带一个团队，哪怕是只有几个人的一个小TEAM的时候，你就会发现，你必须面对一系列的问题和麻烦，而这些事情的处理结果，基本上和个人技术水平无关。
举一些例子：
"自己每天被领导施压，忙忙碌碌，累得吐血，可手下的几个人，却让人觉得他们闲的发慌"。
"给他们布置的任务，好像怎么也做不完，一拖再拖，个人感觉是很简单的事情"。
"好容易分工做完了几个模块，整合起来却怎么都不对，老是出现错误，还得我自己亲自动手修改处理"。
"交给了客户一个测试的版本做展示，客户第一句话就是：这个不是我们想要的"。
"眼瞅产品交付的最后期限逼近，可软件的问题层出不穷，错误百出，这怎么能让客户满意并且验收签字呢？"。
"天天加班，把人搞得生理时钟失调，昼夜颠倒，做这个项目的人怨声载道，整天怒气冲冲，威胁辞职、罢工"。
在具体的软件项目运转中，这些令人头痛的问题接连不断，常常把人搞得焦头烂额，心烦意乱，任你技术水平再高，都没用。俗话说的好："你浑身是铁，能碾几颗钉"。事必躬亲，大包大揽的结果只能是把自己累垮，工作还没做好。在软件越来越复杂，需求多变的情况下，个人英雄主义、单打独斗是行不通的，干活还得靠大家。
痛定思痛，你也会很聪明的想到：我必须使用软件工程方法、开发流程来管理我的团队。但你真的要在团队中套用上鼎鼎大名的CMM，更令人沮丧的事情还在后面：CMM中光是那一堆名词和文档，就够大家理解好久的了。而且，这些标准、指南更像是评分手册，可操作性不足。项目组好像整天在忙，老是开会，烦不胜烦，搞出一大摞文档，真正的软件却总是出不来。
还有不少其它的项目管理方法、指南，也是难以在实际环境中操作应用。
你必须找到适合自己公司团队的开发流程、框架，不仅要完整，而且必须有良好的可操作性，比较灵活，适应范围广泛。所以，向在软件项目管理上成熟、完善的公司学习，是个很有效的办法，能让你迅速掌握在项目管理上的各种方法和技巧，并且上升到理论水平。
在软件行业，微软公司的软件产品众多，产品线齐全。这个软件巨人在各个市场上取得的成功也是有目共睹，其软件项目的开发、管理过程也一直是大家很感兴趣的焦点。
文章来源于领测软件测试网 https://www.ltesting.net/
