如何解决初级软件项目经理的常见错误.doc

如何解决初级软件项目经理的常见错误 对于一个刚刚就任软件项目经理的人，对于一个软件项目管理方面的新手，总有一些初级的、常见的错误出现，如何去解决它们，如何去凝聚团队的力量来保质保量的完成软件项目？本文为您提供一些参考意见。 如此“赏罚分明” 新官上任的第一把火是什么？有时候首先想到的是如何使用自己的领导权威。 某公司规定：凡员工迟到十分钟，扣 50 元；迟到半小时，扣一天工资……（注意，项目经理及以上级别领导不限）。 经常在项目管理的论坛里面看到“惩罚更有效还是奖励更有效”的讨论，其中“惩罚派”占多数，毕竟被管理者都是“浮躁刁蛮的中国程序员”。参与者往往引经据典，分析人性劣根，甚至抨击独生子女的娇惯等等。有论者认为“奖励几百块钱的工资，程序员根本不会在乎”。 但是这个问题在很多项目中是彻头彻尾的伪命题，因为往往有一个“领导特殊”的尾 巴，尽管不是所有时候都明确的写出来。自外于员工的管理不是行不通，在工业革命时代，在中国现在的血汗工厂里面都取得过成功。但是程序员一般把自己看成脑力劳动者，事实上他们的工作性质确实是这样，需要个人的创造性和热情。假如你确实觉得自己的技术人员都只需要两只手，那么这种所谓的赏罚分明也许不是一个坏主意，毕竟你可以打击程序员的自尊，让他们意识到自己只是多余的垃圾。 如果不是的话，那么对于你来说，采用惩罚还是采用奖励并不重要，因为如果一视同仁的要求都不能达到，那么你制定的规则完全是可以随意揉捏的人治，团队将毫无士气 可言。 遗憾的是，现实中经常出现对下属要求严格，自己却在公司玩游戏的项目经理， 10 点才来上班的架构设计师。既然如此，又何必劳神去思考赏还是罚呢。无论你采用什么方法，最重要的都是一个“信”字。 笔者的建议是：赏罚不是包治百病的良药，赏罚的基础是团队内部的凝聚力，否则任何赏罚措施都无法收到预期的效果。管理者的职务之所以有存在的意义，是因为人类的组织架构需要把多个个体的力量集合起来，向一个方向使力，而不是因为需要管理者和被管理者的两个阶层。 那么如何建立这个玄乎其玄的凝聚力？如何让程序员认同团队的目标 就是个人的目标？其实我们需要的并不是一只万里长征的铁军，只需要稍稍的信任，就可以解决软件开发中的很多问题。管理者可以问问自己：我会搞特殊化吗？我严于律人宽于律己吗？其实这些问题不是难解决与不难解决的问题，只是想解决与不想解决的问题。 当然，