39. 重新定义敢死队

 

那次会后, 我开始思考敢死队的意义。以前我一直认为敢死队相当于救火队,哪里有警报我们就冲向哪里,这样的工作是无法计划的。可G说我们可以主动地有计划地工作,显然像救火队一样等着警报是不行的。如果不做救火队,敢死队的意义何在?

我开始从公司的产品流程考虑。每个新产品由开发部做出来,通过质检部测试后发行,由销售部卖给客户,许多客户需要服务部帮忙,上门进行安装调试,然后客户投产使用,如果客户遇到问题,Tech Support部门会帮助解决。这些环节如果每一步都做得很到位,根本没有必要建立敢死队。记得我以前工作的小公司只有五十来人,每个部门十来个人,出了问题各部门头头互相帮忙,总能过关,从没有想到过需要什么敢死队。

大公司就不一样了,人员遍布世界各地,很难管理配合,各个部门有自己的业绩评定标准,但由于这些评定标准不统一,很容易使人为了自己部门的利益,不顾大局,以致给公司造成损失。比如开发部的业绩评定要看新版本的开发和上市,只要新产品通过检验上了市,就算大功告成。可新产品里的功能是否符合客户的需求,就不一定了。质检部的评定标准是在规定期限内完成所有验证步骤,找出产品的问题。可这些验证步骤常常是开发部提供的,很可能与客户生产完全脱节。销售部的业绩是按销售额来评定的,为了拿到订单,有些销售人员可谓不择手段,有时明明知道我们的产品功能没有达到客户需求,还硬是让客户签了字,然后逼着开发部改写软件。服务部需要的是上门服务的小时数,有时看客户有钱,还没弄懂客户的要求,先报个大数目,派去上门服务的雇员却不一定胜任,白白在客户所在地耗时间。Tech Support按解决问题的数量和所用时间来评定,遗留问题的数目越少越好。结果碰到疑难问题,一线和二线互相踢皮球,使问题长时间得不到解决。

公司高层管理为了避免这些弊病,建立了一套客户上诉系统,上诉的问题直接送给相关产品的总负责人,这些负责人为了能尽快解决上诉的问题,会抽调几个技术水平高头脑又灵活的雇员,专门处理这样的难题。这就是敢死队的由来。

看来,如果坐等客户上诉,像救火队一样等着火警,我们根本无法做到有计划地工作。那么我们就应该在防火上下功夫。

不久,我们三位敢死队长来到加拿大G所在的办公室,开始制定我们的工作计划。G说:“每个部门都有自己的评定标准,只有敢死队的评定标准是保证客户满意,我们要想打主动仗,就要帮助每个部门,使每个环节都保证客户满意。同意吗?”

太好了,我们想到一块了。另外两位敢死队长已经是老资格了,我们四人你一言我一语,G在黑板上做记录,很快便写下了帮助每个部门的具体做法:

参与产品设计,让开发部人员真正懂得客户的需求。

按照客户的实际用途编写测试步骤,加进质检部的测试系统。

产品做成后上门为客户做现场试用,把客户的意见反馈给开发部。

产品上市时办培训班,让其他部门的雇员掌握新功能。

为销售部编写产品演示流程,保证销售人员正确展示产品。

为服务部编写示范课题。

为Tech Support编写常用问题解答。

……

能想到的都写在黑板上了,G问:“有没有落下那个部门?”

我们想了一会:“对了,培训部。那些培训教师口才都很好,可他们都不懂产品,只会照本宣科。”

“那我们就给他们本让他们宣,把我们的培训教材给他们。”

“每个新产品我们先讲前两期课,让他们来接受培训,等他们弄明白了,以后的课都让他们讲。”

哎,我在心里感叹,如果早这样做,我能省多少事。

所有该做的事都列下来了,G问:“有没有什么事是我们不该做的?”

我们答不上来,G笑眯眯地说:“不包办代替,你们说怎么样?”

太棒了,每件事我们可以帮助他们,引导他们,推动他们,也可以和他们一起做,但他们不能把工作完全丢给我们。

这天的会开得轻松愉快,第二天我回到家,G已经把会议记录整理出来,编辑成正式文件。

从这以后,我一直按照这份文件来安排我和部下的工作,果然效率非常高,每件事都提早安排,很少有警报发生,不需要加班加点。G很少干涉我们,凡事要我自己作主,如果需要他帮忙再找他,一般情况只要每星期做个汇报就可以了。

我和G一起工作的时间不长,可他对我的影响很大,他编辑的那份敢死队职责成为我工作的圣经。

 






西山 (2012-02-22 18:10:23)

这样的领导在他下边干着舒服,还能学到很多,桑妮好运气。

桑妮 (2012-02-28 01:58:12)

这集讲开会,使整个系列最枯燥的一篇,但是没有这个会就不会有后面的故事,西山是唯一的听会者,呵呵。谢谢西山。

Piggy (2012-02-28 21:13:53)

原来工作可以这样做,管理果然有一套。。