关闭

不是一番寒彻骨,哪得梅花扑鼻香

标签: 项目管理工作工具敏捷开发框架
1408人阅读 评论(1) 收藏 举报
分类:

       不知道选择这个系统分类是否合适,我更觉得我的这篇短文是属于项目管理类别的。

       从我公司的组织形式来看,作为权力的实施方,属于行政级别的,对项目来言,项目内的资源作为项目负责人并没有最大的权限来管理。作为一个从技术角色上升到项目管理角色的员工,我感觉对于我自己转变的凤凰涅磐终于真正开始了,至少我自己已经意识到了,其结果或者是惨烈的被大火吞噬,或者是获得重生。

       为了提高自己,特别是在大中型软件项目中成就自己的理想,我对专业内的书籍学习了一本又一本,包含团队管理的,也包含项目管理的,特别是对近年来相关领域中出现的先进的思想也作了针对性的学习,当然这些思想主要是西方人的。在阅读中,我不断的思考,是呀,多么先进的管理思想,如果能够在我的项目中应用肯定会带来更大的收益,在项目中创建一个完全平等的开发组织,让大家能够发挥自己,让大家都能实现快速的成长,而作为项目管理者的角色,我也可以更专注于我自己的领域,和团队中每一个人一样,把项目的成败寄希望于每一个人,对于专业的人来讲,会马上想到这是敏捷开发的团队型组织。于是,接下来的开发中,我便按照我理想中模式去在我的团队中实践:在我确定的框架下,让每一个人都去参与设计,去在设计中去实现需求,然后按照自己的设计完成整个项目的主体部分,能够实现人人都能在项目中最大限度的成长自己,该是多么美好的结局。然而,事与愿违,当按照计划我来检查进度及具体实施情况下,我震惊了,我犯了一个多么大的错误呀,我没有想到我准备委以重任的下属在整天学习所谓的先进工具,想在项目中实践他所学到的每一种工具以及思想,最为头疼的是当我指出来时,却发生了令人不快的争执,更让我想不到的是这位下属拿出他在上学时的教材来支持他的观点(题外话,真不知道现在大学计算机的教材为什么这样和实际工作脱节,似是而非的描述完全是错误的),我意识到我的这种实践失败了,我又何尝不是一个照理论去直接使用的追随者呢!!

作为我的下属,我没有理由去埋怨,因为问题的确是出在我的身上,经过认真的反思,这种在强烈挫折感下的反思,我不排除有另一种极端的可能,但却能说明我所犯下的致命错误。还是以罗列的方式来一一列举吧:

ü         忽视了下属员工宏观控制能力差的现实。我们项目组里的员工大部分是刚毕业2年左右的学生,在他们工作的这段时间里,所从事的工作以及工作的性质决定了其所注重的是技术实现细节,而缺乏对项目整体约束因素的考量,虽然我有详细的项目计划要求大家遵守,但对于他们来讲,却不一定去考虑项目计划,因为他们不会承担风险,也由于在组织管理上项目组并没有绩效的管理,故成败并不影响其个人,如此以来个人就会陷入到自认为重要的里面去,而忽视整体的约束限制。

ü         人力管理中的问题,中国人是不同于西方人的。记得曾仕强先生曾经在他的“中国式管理”中有这么一句话“西方人讲究法制,中国人则讲究人治”,如果有了既定的法则和开发的制度,则西方的软件开发者们会按照既定的法则去达成团队最大的目标,而对于中国人来说,却不是这样的,至少在国内这样的管理方式成功的企业不在多数。并不是说中国人责任心不强,在我的项目团队里提供给了项目组的各个成员充分发挥自己的空间,但对项目来说还是有框架、时间、功能等的限制的,而各位同事的发挥却完全超出了我的想像,大多数是想着怎么去让自己学到的更多的东西使用在项目中,而没有考虑项目的约束,直到后来的检查才发现了大量的问题,并大大偏离了项目的航道。或许没有公司企业文化背景的项目自由度反而会造成更大的失败吧。写到这里,我不得不承认,到此为止,我已经是对项目失去了控制能力,并面临着沟通失败的危险。

ü         个人参与度严重缺乏,没有及时跟进。在项目的前期阶段,由于其他事情的原因,且完成的需求规格报告也已经通过了公司和客户的评审,在确定了项目设计开发方式之后,我认为采取的开发方法是让每个人充分参与到设计中去,给个人充分发挥的空间,在这个阶段让每个人都能拿出自己的方案来,对这些个方案做评审。出发点不错,我把自己的精力大部投入到了自己所从事的领域,而在管理上开始疏漏,直至发现问题的时候,我才意识到我犯了一个多大的错误!如果我能每天都对大家的成果做出检查,而不是听取口头和书面汇报,及时的去跟进检查已经交付的成果,去思考大家的方法,并从实际的项目角度去理解,刨除危险因素,那可控性肯定会在控制范围之内。

ü         整个过程中,失去了对项目的控制能力,在认识到这种危险的苗头时没有及时纠正。在这个项目的开发中,特别是在需求过程中,客户明确提出,使用当前流行的设计方法,由于我们部门长期所从事的工作较为底层,没有在这个分析领域的专家式人才,且由于项目时间紧张,如何按照需求完成项目才是最主要的,采用这样的技术并不是全盘使用各种各样的设计工具以及方法,也是由于对此领域没有过实际的设计经验,且也没有投入大量精力去学习,当提出一种新的方法和概念的时候,目光被其先进性吸引了过去,对于做技术的来说,这种好奇性是有情可原的,但对于管理者来说,应该首先想到的是风险,只有经过实际的评估之后才能决定采用。虽然在执行过程中,已经认识到这样的问题,却仅仅是通过对员工的询问是否能够使用这种工具或者方法来达成目标,一个在狂热中的人怎么会有理智呢,再说这个也不是他所能把握的。

ü         错误估计员工的能力,也是导致管理过程失去控制因素之一。这个在第一项中已经有所指出,我的组员是由工作经验不算丰富的员工组成,而我采用的方法应该是在领域内已经有所建树的有经验的员工身上使用的。错误的估计形式,不仅使项目的前期工作被延误,更为严重的打击了员工的积极性,在认识到这一点之后,我可能需要更多的精力去通过解释等途径去挽回他们的积极性,我所占用的成本已经很高了。这里给我敲响了一次大大的警钟,无论在什么事情中,一定要量才施用,不能被华丽的说词蒙蔽了风险。

ü         没有充分利用项目外专家的智慧。在项目确定下来之后,我忽视了行业领域内的其他专家,而是独立的去运作这个项目,这个是和我的精神状态有关的,没有去使用这些资源,而是由没有经验的人来进行设计,这中间所表现出来的问题可真是太多了。。。。。。

 

我个人在项目内部,由于精力的因素,也产生了一些缺乏激情的情绪和状态,这些也是导致问题出现的重要原因。以上这些描述性质的自我反省,希望对我和与我类似的各位敲一下警钟吧。要么充满激情的去工作,要么就不要去干,否则,会给你的项目带来灾难性的后果。我也在反思如何去应对这些问题,如何在我的团队内部去实现正常的状态,我仍然在努力的思考,在周末的时间里,我会把我的感想与大家共同分享,也请您提出宝贵的建议。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:8132次
    • 积分:125
    • 等级:
    • 排名:千里之外
    • 原创:4篇
    • 转载:2篇
    • 译文:0篇
    • 评论:3条
    文章分类
    最新评论