OOPAA

Focusing on OO, Patterns, Architecture, and Agile
posts - 29, comments - 75, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

同事预审

Posted on 2010-08-31 21:19 mingj 阅读(3173) 评论(0)  编辑  收藏 所属分类: agile 敏捷PM 项目管理

在如今大部分的组织里面,是否给申请技术职位的人提供工作机会——这个最终决定权属于管理部门。经理们雇人,经理们裁人:一切都天经地义。然而在某些组织里面,这些技术人员能否得到工作机会却是取决于——至少部分取决于——他们将来的同事。这种同事预审的最终结果只有一种:当经理们让技术职员拥有发言权的时候,每一个人——申请人、职员和经理——都会和盘托出自己的想法。

招聘流程的前期阶段基本上没有变化:通常由第一线经理对申请人的材料进行最初的筛选。经理也许会要技术方面的高级职员先审阅简历,把所有的申请人归为“下一步”和“不,谢谢”两类。经理也许会给那些简历看上去非常华丽的申请人拨打电话聊一聊,做一个初步审查,决定邀请哪些人过来现场参加面试。获邀的申请人会被告知他将和团队在一起呆上36个小时。一旦众多的同事参与到招聘的过程中,面试的当天往往非常的漫长。

在抵达公司并与经理寒暄过后,申请人就随同各位团队成员开始一系列的面试。每轮面试的会谈时间从30分钟到90分钟长短不等。

虽然每位参加同事预审的面试官从申请人身上得到的信息相同,但每个人都会使用不同的方式调查。很显然,每个人都希望对申请人的知识、技术和能力做出评估。所以,针对招聘职位的类型不同,从团队的角度出发也许会要求申请人编写一些代码,或者创建一组测试。但是,每个面试官都会再以个人的角度去评估申请人,他会问自己:“我能和这个人一起工作吗?”“他能适合我们这个团队吗?”“他会让我们团队变得更强,还是更弱?”

此外,每个面试官将以自己在团队之中担当的角色去评价申请人。举个例子,如果申请人是一名开发人员,相较于团队里的开发人员,身为测试人员的面试官就会提出不一样的问题,以挖掘申请人的个性特征。

每个面试官也会根据自己的以往经验去评价申请人,问自己这样一些问题:“这个人展现出的技能与解决问题的方式,是我最为欣赏的吗?”“这个人在多大程度上让我回想起曾经合作愉快的同事,又在多大程度上让我回想起无法合作顺畅的同事?”“这个人是不是像他表现出来的那般优异,又抑或他是在假装如此?”面试官背景的多样性,使得团队可以从多个视角和价值取向来甄别将来的同事。

在把申请人交给下一轮的面试官之后,这一轮的面试官向经理——或者面对面地交谈、或者通过邮件,又或者拨打电话——就他对申请人的印象和意见发表个人的观点。每位职员都需要针对“假如由我来裁决是否雇用这个人”这个议题投下自己的一票。

如果面试一切进展顺利,申请人最终会回到经理这里,而此时经理也已经知晓了所有面试官对该申请人的看法。经理现在要从他自己的角度出发来面试申请人,然后告诉申请人是否得到了工作机会。即使其他的面试官都表示认可这名申请人,经理也可能会由于某些原因决定不对其提供工作机会。但是,如果团队的大部分成员都对该申请人倒竖起了大拇指,那肯定是没有理由再雇用此人了。

当团队在招聘过程中真正拥有话语权的时候,此时就出现了多赢的局面:

  • 当前的团队成员是赢,因为新员工加入团队的时候,大部分的团队成员都已经跟他见过面——实际上已经接受了他;不被职员接受的那些人是绝对不可能跨过那道门槛的。

  • 申请人也是赢,因为他处在了更有利的位置来决定是否要加入这支团队。他可以接触到未来的同事,而不仅仅是老板。他可以询问工作的真实情况,同时也可以感知公司的文化。

  • 经理是赢,因为他可以借鉴整支团队在技术方面对申请人做出的评价,而不是仅仅凭借自己的揣测。他也知道团队在一定程度上已经接受了这个“新员工”,而且团队对他个人的成功也非常重要。

  • 最终,团队作为一个整体也是赢,因为团队成员在参与同事预审的过程中,可以向其他人学习。在阅读其他人对申请人的评价时,团队成员能发现其他人使用的问题和标准,而他们可以在以后的面试中把这些派上用场。经理也能对自己团队成员的思维方式有更深的了解。

从经理的角度上讲,同事预审在雇用团队领袖的问题上面同样有效。为什么不邀请团队里的一些成员去面试未来可能成为他们老大的人呢?

不管申请人是开发人员、测试人员,抑或是经理,寻找到一位真正合适的人选从来都不简单,但往往又很重要。这是团队参与的项目。

只有完成本垒打或者击球成功,管理才值得嘉许。”

——卡西·史丹格(Casey Stengel


只有注册用户登录后才能发表评论。


网站导航: