工作感言:小组管理心得

      我是技术人员出身,作为一个组员的时候,只要自己把手上的任务做完就OK了(埋头写代码其实也是件很爽的事,其它的都不用管),当有幸成为一个小组(5个人左右)的组长,刚开始真的是很不适应,当看到有的组员写的代码很乱时,恨不得马上训他一顿,让他重写;看到有的组员速度很慢时,心里比他还急,真想直接帮他CODING等等,让我管几个人真是麻烦死了,一路上基本都是先吃亏、再总结,再实践,如此反复,摸着石头过河。以下是我在这方面的一些管理小心得,与大家一起分享交流。
      在管人这块比较头痛的问题:组员不听话、不服从管理,组员做事怠慢(怠工),压不住人,与组员关系有点僵。
1,管理有据可依==对事不对人。与组员关系闹僵、组员不服从管理其中很大部分原因是该组员认为组长对他的管理不合理或事先不知道、出事时吃大亏。我的解决方法:
(1)白纸黑字、“丑话”说在前。
      所有的管理章程都事先摆到桌面上,让大家知道有这回事,还可以提意见,视情况对管理章程进行更改。最好在开始一个项目的时候,做为“誓师大会”的一项事程。

(2)“疑罪”从无。
      有些组员的行为当时你感到这样做不对,但是又没有相关的规定不允许这样做,假如当时你直接指责或责怪,组员很有可能不服气,假如这种情况多次出现在同一组员身上,他很有可能认为你在针对他。像这种情况最好整理一下,在每周小组例会上提出,大家讨论,形成规定(重复第一步的效果),然后按规定执行。
      事例:
      开始接小组的时候,每个任务都规定的时间,到了时间大家基本上都能上交,但我发现有的任务里虽然所有功能都做了,但有的根本都走不下去,我认定是没完成任务,但组员说:你看我这都完成了,只是中间有错误,程序哪能没有错误的;像这种情况,就是扯皮的事,再说下去就变成吵架了。再说没有规定说上交的任务里不能没有错误呀(没有任何错误估计谁都不敢包)。
      这件事还真让我郁闷了一段时间,你说又不是,不说又不是。后来我把测试那套东西引进来,不能存在1类错误<设计中有的功能未实现>,2类错误<存在严重的错误使流程无法继续>),在小组例会上专门做了说明,并加了任务质量那一栏。验收时只要有这类错误就可以算未完成,反之即使有其它的BUG也算通过(另算时间)。

(2)依“法”执行、赏罚分明。
      有了上面所做的工作,这一步就简单多了,只要照着规定来就行了,每项管理都能找到相对应的依据,组员也就基本心服口服了(百分之八九十这样),最主要是至少不会觉得是我在凭自己的感情在管理,想怎么样就怎么样。

工作感言:小组管理心得

2,多施加无形压力,少直接指责与批评。
      小学生式的管理
      这是我刚开始管理中的最大错误之一,前面我也说到刚开始时看到有的组员速度很慢时,心里比他还急。记得有一次,遇到这种情况(他的任务拖了时间),当时我又看到该组员不是很卖力(典型有没依据,凭感觉管理),我就直接叫他:你快点弄你的程序呀,现在时间都好紧了……当时人家虽然没说什么,但在之后的工作讨论中,他的话语中对我有很明显的火药味,以致关系弄僵,再则他的效率也没有明显的提高。后来在与我的朋友谈到这件事时,我朋友笑着说我这是很明显的“小学生式的管理”,看到一点问题,就直接指责、批评,大家都是二十多岁的人了,谁受得了呀,谁心里都会对你不满。
      多施加无形压力
       但毕竟有问题是要解决的呀,你不解决小组的效率就上不去了。后来还是一位日企工作的朋友介绍了个方法给我,思路是你要给他无形压力,让他自己看到问题,让他自责;这比你直接批评他要强多了。后来我们小组第周开个小例会,每个人先讲自己的任务完成情况(我也是做技术的,组员任务我看一眼就知道大概了),但让他讲,就让他有了压力,当着这么多人讲自己完成不了任务,只要不是脸皮很厚的,都会觉得自责,接下来一周就努力多了,这比我直接批评就强多了。

 

3,大事要明确,小事别较真。
      大事上要明确,这点我认为我还是做得不错了,系统的架构,一些关键技术的选用,我都有自己的见解,然后就是跟组员、上级技术人员讨论;只要是我认为好的(能够一五一十地说明理由),我一定会坚持到底(对方提成的观点不能说服我的情况下),哪怕是面对上级技术人员,因为是我在管理整个小组,负责某一个项目或产品。
      小事别较真,这点我就做得有点过了,主要是把小事都当成大事了,一方面也是由于我刚从组员上来,还有对CODING比较狂热;比较有时组员跟我说某个地方要用某种技术,我总会提出自己的见解,当与组员的意见不一致时,我总是强调自己的,这容易打击组员的积极性,而且让人觉得你很“独”。后来经朋友开导,想想很有道理,组员在他那一块加入点新的技术,或者为了编程方便要求数据库表加那么一两个字段,任务要求不变,同样的完成时间,也不用我麻烦,为何不让他去试试呢?再说连这点小事都管,那你能不累,不烦吗?遇到种小事就放手让别人去做吧。
       大事上要明确,小事别较真,区分哪些是大事,哪些是小事,这就是你智慧所在了。

4,做人要厚道,得饶人处且饶人。
      管理依据制订之后,什么都按依据来,组长是占优势地位的;但是规据是死的,人是有感情的,在一些不违反规定的情况下,尽量做点人情,体现一种人情味,暖人心,这样更有利于小组的管理。
      比如,前面说到任务是明确地规定的完成的时间的,有时到了规定的时间,可能还有少量的工作未完成,但又不想申请延时(会影响绩效之类的,或者不能再申请延时了),这时验收任务,两种情况,1组员说完成了,2说要等一下;这时完全可以按规定收上来,按照要求来检查,完成就是完成,不完成就是不完成,像上面说的通常都可以归为不完成;但是做人要厚道,这时我一般都会先记按时完成了,然后跟他说:现在暂时没空,要到明天某某时候才能检查;这样的话他可以利用晚上的时间,明天的时间补功课(我检查的时间一般放在周五这样,这样的话他还可以利用休息的时间偷偷完成),当然提前是所差不多,其实我一直都会关注每个人的任务,他们每天的进度我都是大概了解的。质量检查同理。
      前几天在园子里面看到一篇文章,说到小组几个人大热天挤在一房间CODING,向上反映空调不冷,居然反被别人打了小报告。这人就是典型的不厚道,再说相对CODING所创造出来的价值,即使换台又算什么?关键这还伤了大家的心,真是损失大了。
   
技术选用及管理
      像很多技术人员一样,我也是一个不折不扣的技术狂热者,出来什么新技术呀,特别是那种看起来很酷、很炫的技术,我总是按耐不住,自己亲自照着教程狂敲代码,看着代码在自己机子上跑起来,心里就高兴得不得了;还有就是好用的开发工具出来一个新版本,管他个三七二十一到网上下一个,在自己机子上一装就忙活起来了。
      当时我的眼里新的就是比旧的好,从大学时代开始,每次做项目,即使我是组员我也要建议用新的,越新越好!不过感觉大学里老师还是挺照顾我的,实在不行就让我用在我做的那一块,不过期间也吃了不了不少苦头,有些技术看起来很酷,有时一个很简单的功能却实现不了,花了不少的时间来解决,不过也算乐要其中了吧!
      不过当我站在小组组长的角度去看待之前的这种做法,其实是很有问题的。用得太新的技术(开发工具)会造成的问题
(1) 小组组员水平参差不齐,接受时间长短不一,且效率会暂时相应下降。
(2) 出了问题,不好解决。记得有一次用了很新的技术,在中文网站是基本上找不到答案,只好硬着头皮到外文网站上去找,最后还是在比较偏的地方找到了解答,真是苦不堪言。
(3) 时间不好估算,特容易担误时间。因为之前没有相应的数据统计分析,完全是靠个人感觉,感觉特不可靠,中间出点问题,弄掉一个上午或下午算是好的,有的可以折腾好几天呀!
      但又不可完全排斥新技术,搞技术的不弄新技术,那还有什么搞头?我的做法:
(1) 对于要求质量高、时间紧的项目尽量不用新技术,全部用之前用熟的技术,因为之前的技术基本用熟了,只要按着前面规范走,肯定不会出错。(每个人都很熟,质量有保证,时间有保证,这是多大的保证呀!我想这也是一些大公司开发软件时选用相对“落后”技术的原因吧)
(2) 对于其它相对宽松的项目,选择性地用新技术,当成新技术的练兵厂。将新技术变成自己的老技术。
(3) 忌项目超过2/3选用新技术,除非时间真的可以忽略不计。个人痛苦经历,不堪回首,时间差了海去了。
 
积极与上级交流,主动与下级交流
      交流的重要性应该不用摆什么理由了吧,再则无论你再怎么按依据进行管理,上级与你,你与组员是管理与被管理的关系,这是一对天生的矛盾,之间怎么都会有矛盾、怨气。轻则之间关系比较僵,说话带火药味,重则直接影响到整个项目的成败!
      像项目之前大家开几个讨论会,每周开个例会,这就为了促进交流;但这是固定时间的交流,而且比较正式,大家说话都比较顾忌,因为说出来的东西很快落实执行。当然也有让大家畅所欲言的,这时大家能畅所欲言当然比较好,但是比较少。
      除了固定的交流之外,就是自由发挥的交流,个人觉得这才是交流的关键所在。
      之前我仅仅认为交流就是工作时要注意多跟别人谈话,相互之间交流信息,但发现执行时往往没有什么效果,比如跟组员交流,工作时坐到他旁边问问他工作得怎样,回答都是很客套的话(后来我想了一下,换到是我,上级突然坐到你旁边问你工作怎样,你也会比较拘束吧,所以肯定是客套话啦),跟上级交流就更麻烦了,工作时你还要先跟上级约时间,跟上级先把内容的大概说一下,上级一听还以为出个什么大事呢,反之没什么事你谈什么呀?
      后来我才发现这是由于交流的时间选得不对,工作时间只有正式的交流比较有效,那么只有选用非工作时间了。
      跟上级交流我一般都选在吃午饭、或者一起出去活动的时候(这种时间少)。比如:在吃午饭的时候,在食堂里,坐到上级旁边,边吃边聊,以下是聊天记录:
      国家大事,花边新闻。。。。。。
      我:“对了,下周就要开始的那项目的客户怎么样,好不好说话,对时间要求紧吗?”
      上级:“那客户。。。<描述客户>,对时间要求有点紧呀,最好一个月就搞定”
      我:“呀,他那需求还真挺多的,两个月都搞不定!”
      上级:“这么久。。。。”
      我:“只是可能,我根据需求好好估算下时间,**时候把计划给你。”
      这个时候我需要的信息都交流完毕了,
      (1)摸清了上级对工作完成时间的期待值。
      (2)把我估算的时间先大概透露到上级(其实之前我早就算过时间了,要三个月呢,与上级期待差很多,先给他打支预防针,避免正式上报时上级很吃惊;之前有个类似的事,上报时间与上级的差太多,被狂骂,教训呀!)
      跟组员交流就容易多了,我占主动权,当然不能把他直接叫出来,到外面聊聊,那样的话估计他本人,其他人都以为出什么事了呢,这时候我一般是利用空余时间组织小组的人员去活动下(活动经费可以申请,也可以AA制,少量的话自己出也行),利用活动的空隙,跟他随便聊聊,再把话题自然一点转到工作,这时候一般人都会跟你畅所欲言,还有你会发现经过活动之后,大家的关系会融洽很多,工作的积极性也提高了。以下是比较大众化的运动,很适合众人一起活动

工作感言:小组管理心得

 

你可能感兴趣的:(工作)