Warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in /home/wushaobo/wushaobo.info/wp-includes/class-wp-hook.php on line 298
» 2011 » August Shaobo Wu's blog
RSS

Monthly Archives: August 2011

Sequel

This is the slides for my introduction of Sequel.

 
Comments Off on Sequel

Posted by in Uncategorized

 

Tags: , , ,

新人的coach与被coach

项目在更替,人员在变动,总会有加入一个项目成为新人的时候。什么能让你更快上手?

技术经验?领域知识?适应能力?勤奋程度?聪明与否?

都没有错。技术经验让你更早能开始写程序;领域知识帮助你更快理解业务与需求;适应能力帮你更快调整工作方式,与同事更协调地合作;勤奋学习让你尽快补上缺少的东西;聪明与否让学习和接受新东西变得更容易。

可惜的是,项目和项目是不同的,个人因素的作用不是故事的全部,总有你不知道的业务、没听过的规则。所以刚进入项目时你只能是一个“新人”,你需要coach帮你度过这个时期。

今年内我第二次半途加入项目的经历让我明白,如何coach新人以及新人如何配合coach,是非常重要却常被忽视的事。

找到知识范围——新人的第一件事

一个新人加入项目,他需要知道什么?

项目背景、业务逻辑、数据关系、涉及的技术、架构与运作、代码结构、工具选择?交付计划、沟通方式、项目组的各种习惯以及约定、客户/合作者情况、工作的技巧?

我多希望这个被coach的新人能和coach他的团队成员共同来想一想,不过可惜的是,不常见到。

理想状况,coach的人能把这些的信息以合适的进度全部传递给新人,新人也能将听到的知识全部归纳吸收。但这常常不可能,人的思路就像画画,怎么期望他一笔下去画到完?何况coach并非专职的,他也有手头的工作要做。

于是就要求新人上心,推动关于知识范围的讨论。

帮助新人跨越认知边界

人的认知范围是有边界的,常常有你不知道的认知边界之外的事,它们不像不知答案的问题,而是根本不知这有个问题。做coach的人,你不仅有义务让被coach的人听到问题的正解,你也有义务为被coach的人指出他所不知的问题。

在这方面最难的要算理解客户的业务需求,这些抽象的规则如果没人告诉新人,新人很难知道;而困难也存在于coach一方,他们不容易意识到有多少业务要讲给新人听,常常是遇到了才说起来。同时两方还有一个共同的想法:新人不用知道太多历史,目前的已经够多怕吃不消。这样的环境里,新人加入一月也不一定了解所有的业务,就像我的上个项目,在项目的最后两个月加入,可直至roll off都仍有盲点没清除。不过让人稍感欣慰的是,从工作的角度谈,那些历史没有让我的日子太难过,因为遇不到它(遇到的都不得不了解了)。总之,积极让新人面对他不熟悉的项目部分会帮他扩展认知范围,他成长得就更快。

话很多与话很少——互动很重要

不是想在这儿谈论人的性格,而是想说互动很重要。努力做一个话多的人,在coach和新人之间确实是对的。话多话少分场合,当你踏踏实实看文章练技术的时候,闭嘴才是应该的。

做为coach,应多问问新人做着什么、怎么想的;多讲讲情况,谈谈窍门,问问遗漏了什么。同时,新人在所有交流中都应坚持这样的积极方式:常问常重复,把知道了的讲出来,请coach听;把自己没听清的问出来,两人一起弄清;把coach不小心略过的问题拾起来,记下之后去问;把联想到的可能说出来,更正你的过程就是辨析正确的事的过程。

那么新人本身话少怎么办?我深信,只要老员工主动说话了,他就会回答;只要给新人一个放松的说话氛围,他就会慢慢打开话匣,一来二去话自然就能多起来。所以大家也可想一想,在评论身边的同事话少的时候,你是否意识你可以做一些事去改变他?

高效而有深度地做coach

古人云:“知无不言,言无不尽”,把这个要求提给做coach的人正合适,但还要加上一个词:敏感。

我发现从coach中收获最大的新人,并不是被灌输大量知识的人,也不是最快问到问题答案的人,而是他的coach对他的处境最敏感的人。对新人的处境敏感,就是操心着他能否理解要点,是否满足他的问题背后想知道的知识,是否把道理和窍门完整地呈现在他的面前,关心着他是否正确运用了学到的去解决类似的问题。把这几点放在心上吧,对被coach的新人的处境敏感起来。

接着,还要再对自己的讲解敏感一点。耐心安排完全面对被coach人的时间;控制自己不要跑题过远,牵扯太多;不停地反思有没有把关键点都讲到,有没有把他的问题答完整;亲近一点,把他的反馈看在眼里。我觉得好的coach应该做得到。

我脑海里浮现出两个例子。

一个正面的例子是,当初入职两个月的我拿自己的笔记给新入职的同事,讲Hg的基本使用和在项目里提交代码的流程,因为把规则有条理地讲给了新人,并分析了可能遇见的问题及应对方法,新人虽然慌张但一天内就基本掌握了。

作为对比的,我上周刚加入的这个项目组里闹了个小笑话,一位新人同事在git的push和commit命令上(都能用“提交”这个词讲)和coach他的同事出现了误会,coach他的人希望他“频繁提交”,本意是常push一下。但新人同事git经验尚浅,对“提交”的直接反应就是commit,于是每次被问及“有没有提交”时,他都回答说“提交好了”。在我看来这挺郁闷的,虽然我们都把这件事当笑话提起。如果coach新人的同事能在头一次就把整个流程对着命令讲清,并主动的看一次新人自己操作,那么问题可能会被避免;如果这位新人同事能主动去讨论他对提交规则的理解,或者把命令本身讲出来核实一下,那么也不至于误会。