关于项目管理的一些想法

gavin_yj 2008-03-07 03:58:12
最近看了这上面的一些帖子,有很多观点都很好,结合现在所处部门的现状,发发牢骚,太久没写东西的,都有点遗忘了,欢迎大家排砖。
csdn的帐号在我上大学的时候注册的,赫赫,时间是相当的早了……


最近看了一些书,包括《重构—改善既有代码的设计》及《JAVA设计思想》等,更多的是一些有关项目管理的书籍,期间看到了这样一个比喻:项目经理是船长。一艘船在大海上航行,船长站在瞭望台上眺望着远方,掌握着前进的方向。突然发现船的动力不足,船长走下瞭望台,开始拿起浆划船,又发现船煤烧完了,赶紧抓起铁匠丢了点煤进去。当别人问他这个船现在行使到哪里了,还要多久才能到目的地,他重新爬上瞭望台,可是周围的一切都是陌生的,地图也因为海风吹走了。
一个很直观的比喻,很形象地指明了作为一个项目经理应该关注的事情是什么。项目经理并不是项目的保姆,不能什么都做,关注的事情应该是宏观的关键的。我们部门刚刚成立两年多一点点,现在很大部分都是新人,因此项目经理层如何能够更好的带好团队顺利地完成项目就显得尤为重要。就我个人觉得,做好项目经理关键在于对人的管理上,项目流程、风险控制、绩效考核等等这些或多或少都有现成的规章制度可以参考,而对于如何有效地调动项目成员的积极性,如何协调团队内部的不和谐的音符,如何处理老员工的怠慢、新员工的消极等,却是没有现成的教科书可以参考的。现在这个社会浮躁的很,况且公司不是军队,多数人都是为了利益而不是责任走到一起的。显然用冰冷的制度和高压的态度来进行管理是不可行的。现在的人都追求一种所谓的平等,虽然绝对的公平或平等并不存在,但在我们的日常管理当中却可以做到稍微人性化些,比如与下属的交谈应该像诤友式的交谈,坦诚的就事论事的说,而不能像师生或明确的上下级那样公式化生硬的交流。
关于怎样能带好一个团队,我以下几个不成熟的观点:
1、每开始组建一个新的团队,都要努力把团队建设成学习型团队,让大家认识到,只有相互学习,个人才能从工作中最大收益。不管是新员工还是老员工,肯定都有不足之处。会编码了,项目的业务流程熟悉了吗?熟悉业务流程了,能够进行正规的设计吗?会设计了,那熟悉系统的架构吗?哪怕你已经了解系统的架构了,那么技术管理呢,项目管理呢,质量管理呢,大项目管理呢,项目群管理呢,再往上,还有部门管理呢。总之,学无止境,对于一个有职业规划上进的人来说,每参与一个项目都是新学一门功课,可能都是做编码,但是为什么不同的项目对于某些接口、某些基类、某些规范的应用都会不一样呢,设计者在进行这样的设计的时候对这些业务是怎么考虑的,有什么好处呢,为了性能还是为了便于维护呢,等等。因为作为一个成功的项目经理,在开始带领新团队进行项目开发的时候,应该考虑如何能够让项目成员看到自身的进步,从而调动成员的积极性,形成良性的学习、竞争的局面。大家互相学习,一起进步,共同完成项目,才是成功的团队应该具备的特点。
2、公平,公正,在压力中求进度,不能让人闲着,也不能让大家太累了。如果一个项目必须靠常规性的加班才能够完成,那么项目经理就有必要反省了:是因为在接手项目的时候报价有问题还是因为自身编排任务及项目控制有问题?或者说,是因为我们现在求的是生存,只能用加班这种手段来赶工期完成项目。不管加班的出发点是什么,个人觉得这绝不是一个成熟的部门该出现的现象,偶尔为之是可行的,但当加班成为一种惯例,这就很让人崩溃了。当部门逐渐壮大之后,应该考虑的更多的是该如何保证部门的可持续发展,有经验的开发人员都是宝贵的财富,作为新人而言,可能人力成本上会稍微低些,但与之比较开发成本会高许多,因此如何有效地管理有经验的员工,让他们发挥100%的能量也是项目经理应该关注的事情。现阶段而言,不管怎样的加班,都有个不得不做的理由吧:生存第一!我们要生存、部门要壮大、公司要原始积累,这是必不可少的。
3、对于规章制度的运用。在进行规章制度一定要其建立的合理理由,有理由则解释给团队成员,如果觉得太繁琐无意义,就应该至少在自己的团队中废除,不要为了表面功夫,搞一些无聊的制度。管理是为了让员工方便,从而发挥员工的能量,不是为了让管理者方便。
4、做好项目内外部的沟通工作,上面提到的三点,不可避免的要求项目经理必须和团队内部成员保持良好的沟通。当然与客户、与高层的沟通也都是必不可少的,但个人觉得团队内部沟通是最重要的,如果前面两项都做得很好,但项目组内部不团结,不认同项目目标,一切都是枉然。
5、保持十足地干劲,做好每个项目的收尾工作。个人觉得这是项目管理最容易忽视的工作,很多项目到后期的时候大家都会有松懈和大意,这是很致命的,应当在日常管理中有清醒的认识,不到最后一刻觉不要松懈。
要想成为一个合格的优秀的项目经理,并不是一件容易的事情,应该多学习一些理论知识,然后结合部门实际,在日常工作中多总结借鉴,从而形成行之有效的良好的管理风格。其实在平时的工作当中,我们经常犯的一个错误就是花太多的时间和精力浪费在一些次要的问题上面。并不是说次要的问题不需要我们花时间处理,而是说在我们的工作当中,重要的是要抓住主要的关键的问题。比如当开发人员的代码质量不高时, 主要问题是代码而不是测试, 如果一味加强测试时间,将使开发者和测试者疲于奔命, 效果却甚少改进. 一段代码, 有经验的人细细审查, 找出可以改进之处并改之, 无数潜在Bug便消失了, 试想如果指望在测试阶段发现这些问题, 要花多少力气?
能够看清问题的本质,抓住问题的重点并不是一件容易的事情,常说应该活到老学到老,不管是技术、语言、管理、为人处事等等,身边的每一个人身上或多或少都会有闪光点和值得自己学习的地方,用一个平常心去面对得与失,经常反思自己,改善自己,提高自己,生活也就会变得简单而美好了。其实上述的很多想法并不局限于自己对于项目经理这一层的理解,不管外部环境怎样,我总是告诉自己,应该拒绝平庸。
...全文
328 6 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
limin4506 2008-03-12
  • 打赏
  • 举报
回复
整体不错!!!
langxiaofeng 2008-03-07
  • 打赏
  • 举报
回复
细节决定成败
ran0307 2008-03-07
  • 打赏
  • 举报
回复
还有你考虑的只是普通的项目团员,但也要考虑项目经理及部门经理的立场;
他们需要听他们话的人,服从命令的人,光是上述这些是不够的;
说到底,要有人性的负面,不能光做好事.
gavin_yj 2008-03-07
  • 打赏
  • 举报
回复
其实这不能算是我的观点,因为很多都是这里的前辈所想所说的,只是我看了之后深有感触,因此稍加整理放到一起而已,
赫赫。。。
ran0307 2008-03-07
  • 打赏
  • 举报
回复
有经验的人细细审查, 找出可以改进之处并改之, 无数潜在Bug便消失了, 试想如果指望在测试阶段发现这些问题, 要花多少力气?

其中关键之处还有,不要让担当者开发维度过于单一,应该适当多元化一些,比如新手也可以做他人的编码审查,这样既可以看到他人的优点也可以看到自己的不足...相教见长,是这个道理吧~

1,268

社区成员

发帖
与我相关
我的任务
社区描述
软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧