管理、计划、执行、协作
以前当小组长,手下两三人到四五人不等,人数不多,管理起来想对容易,但由于自己经验理论都有限,在管理,计划,执行和团队的协作上有太多的迷茫和不知所措,同时由于还要把过多的精力放在需求分析和设计,以及关键代码的实现上,所以有时不免会对公司管理制度、计划制定、进度控制的要求上会有些抵触情绪,在团队协作上也想当然或者不自觉地忽视,当项目做得还算顺利的时候,有时候甚至认为这些其实都不重要。这次感受了项目的混乱之后,才意识到管理,计划,执行和协作对项目成功的重要性,虽然不能照搬理论或者固有的模式,但是这些方面的理论学习,思考和实践应用对项目确实很重要。但由于理论和实践个方面还是有限,难以说出应该怎样,怎样才好,只能浅薄地从一些方面描述项目中的问题和自己个人期望的样子。
一、这次项目虽说由不同的几个不同的任务组成,各个任务都有其各自负责的小组完成,但整体上的目标一致,因此团队从大的方面说还是一个整体的团队,共有二十多人,对于IT项目来说已经是较大的团队,但这么大的团队内组织混乱,各自为政,岗位不清,责任不明,未能形成一股合力。领导过多,而且级别从属不明,缺乏制约关系,不能形成管理的梯次关系。
二、项目最高领导能力有限,威信不够,而且缺乏带头精神。作为最高领导,应该从整体上把握项目的状况,负责客户的沟通,参与计划的制定,进度的控制,和团队的管理。然而事实上却并非如此。不管什么事情,都不能亲力亲为,甚至几乎所有工作不加选择的转移给下属,包括与客户的沟通。在项目的整个过程中,基本上看不到他参与的影子。这表明其能力和处事方法方面存在问题。但如果其人能够带头冲锋陷阵,也可让其他人甘心付出,从而降低其作为领导对项目的不利影响,但实际上,此人却在兄弟们辛苦工作的时候打游戏,加班的时候休息,但在公司领导来的时候却积极表现,在出问题的时候还责怪下属,这种恶劣的影响造成团队势气的低落。
三、项目关键领导做事方式上存在问题,技术出身的人,专注于技术,而忽略了业务分析和团队管理,
考虑问题总是就是论事,不能从整体上宏观把握局势,由于前期分析的缺乏和宏观管理的忽略,造成下层工作量的增加和难度的加大,从而造成下层人员的任务难于完成,这时候,他又不得不将自己陷入底层的繁重工作中去,更加忽视了高层的分析和管理。从而造成了一个恶性循环。
四、公司的现状以及做法,项目的混乱,领导的做事方式引起团队成员的不满,而这些情绪没有得到任何一方的重视和及时调节,他们眼内只看到了公司的利益和项目的利害关系,而忽视了员工的想法和情绪,忽视了团队成员的心态和情绪对项目的影响,结果造成这个团队的战斗力有限,效率低下。虽说团队有许多优秀的人员,但却不能发挥其重要性。不要说员工应该以集体和项目利益为重,但这些都要建立在他们要得到应有的尊重的前提和相对公平的环境中去。在我看来,大伙都还知道遵守自己的职业道德,履行自己的职责,甚至于为项目做出应有的贡献,但在经受一波波混乱的冲击后,一次次不公平环境的影响、一次次被忽视,一次次的失望之后,很难有谁能够保持良好的精神状态,保持高的工作效率,仍然不顾得失地无私奉献了,更何况,公司不能将利益建立在员工的无私奉献之上。
五、由于项目有多个小组组成,而各个小组的人员属于临时结合起来。小组内部的沟通基本不存在障碍,然而小组之间的沟通却存在障碍。当然,作为员工应该建立良好的人际关系和外部协作环境,但在短时间内很难建立起来,在初期合作的过程中总会存在不协调的因素,作为项目的关键领导,在这种情况下应该注意组织各个小组之间的讨论,加强彼此之间的业务沟通,以推进项目的速度。但实际上,关键领导总是忽视这些,把大部分的沟通任务踢给编程人员,结果编程人员由于其内向的性格以及初期合作的陌生,导致在沟通上总是碰壁,在几次碰壁之后,便放弃努力,消极等待。这样就造成了工作的搁置,从而浪费了时间,阻碍了项目的进展。
六、知识管理的缺乏:由于人员流动的频繁,文档的缺失,开发环境的混杂,规范的不统一,造成了工作量的大幅增加。项目没能按照业务的推动来分析和编码,而总是从老的代码中推导业务的逻辑。于是大家不得不被前人的代码搞得昏头转向,不得不艰难地从混乱的代码中推导业务的逻辑,不得不一遍又一遍地调试因环境差异带来的问题。大家的时间都花在了没有意义的工作中去,而没有学习到新的东西。郁闷自然是避免不了,埋怨自然也多了不少。
经历了这次项目之后,我深刻地意识到管理对项目的重要性,管理的艺术性。认识到了自己要学的东西实在太多太多,了解到自己的视野和知识范围应该更加广泛,否则,发展的前景就不甚光明了。为了自己不重蹈前人覆辙,我耐心的将这些问题整理下来,以便自己以后有机会领导项目的时候避免发生同样的问题。我知道不能一下子避免所有的问题,但希望经历一次就能改进一点,详细有一天能够很好地带出一个项目来。 我要不停地学习,思考,实践 ……