在国内，不少做过几年程序员，被同事、圈内的朋友公认为技术水平不错的人，在考虑自身职业发展的时候，可能会想当然的认为：“我可以做项目经理了，感觉做个项目经理也没啥特别难的”。
但如果你真的有机会，去尝试带一个团队，哪怕是只有几个人的一个小TE AM的时候，你就会发现，你必须面对一系列的问题和麻烦，而这些事情的处理结果，基本上和个人技术水平无关。
举一些例子：
“自己每天被领导施压，忙忙碌碌，累得吐血，可手下的几个人，却让人觉得他们闲的发慌”。
“给他们布置的任务，好像怎么也做不完，一拖再拖，个人感觉是很简单的事情”。
“好容易分工做完了几个模块，整合起来却怎么都不对，老是出现错误，还得我自己亲自动手修改处理”。
“交给了客户一个测试的版本做展示，客户第一句话就是：这个不是我们想要的”。
“眼瞅产品交付的最后期限逼近，可软件的问题层出不穷，错误百出，这怎么能让客户满意并且验收签字呢？”。
“天天加班，把人搞得生理时钟失调，昼夜颠倒，做这个项目的人怨声载道，整天怒气冲冲，威胁辞职、罢工”。
……
在具体的软件项目运转中，这些令人头痛的问题接连不断，常常把人搞得焦头烂额，心烦意乱，任你技术水平再高，都没用。俗话说的好：“你浑身是铁，能碾几颗钉”。事必躬亲，大包大揽的结果只能是把自己累垮，工作还没做好。在软件越来越复杂，需求多变的情况下，个人英雄主义、单打独斗是行不通的，干活还得靠大家。
痛定思痛，你也会很聪明的想到：我必须使用软件工程方法、开发流程来管理我的团队。但你真的要在团队中套用上鼎鼎大名的CMM，更令人沮丧的事情还在后面：CMM中光是那一堆名词和文档，就够大家理解好久的了。而且，这些标准、指南更像是评分手册，可操作性不足。项目组好像整天在忙，老是开会，烦不胜烦，搞出一大摞文档，真正的软件却总是出不来。
还有不少其它的项目管理方法、指南，也是难以在实际环境中操作应用。
老板：我以为大家知道的事情，原来他们根本不了解，不知道，信息完全不对称。
项目经理：太累，不懂领导到底要啥。
团队成员：闲得无聊，不知道要干什么。对工作没有积极性，不主动。
这样的结果就是：领导和项目经理的个人能力，基本决定了项目成功的可能性。