Fire Fast 再深一层的是什么？

写在前面，前段时间在上海 GTLC，有幸主持了闭门会议中的一桌，之所以说一桌是因为一场闭门会议有好几桌，每桌话题不同，我参加这桌主题是关于“Fast Fire，事故和故事”；会上收获颇丰，结合经验，总结成文，分享给大家。



大家都知道为什么要 Hire Slow，Fire Fast，Fire Fast 可以解决问题，终归在做的时候心里是晦暗的，是会留下一些遗憾的；但是又必须要做这件不愉快的事情，自己心里清楚，为了整体必须要这么干，对方心里也清楚，我呆不下去了，要被干掉了，但终归是不愉快的。



有些人会把这个工作交给 HR，自己躲在后面，最后 HR 没有搞定，不得已硬头皮出面收拾残局。



没有完全避免 Fire 的方法，即使有，不是理想就是离死不远；



减少 Fire 的次数不能靠指标，我说的是不能设定淘汰的指标数量，不要为了淘汰而淘汰，说的就是末位淘汰制，管理者的懒惰，想法是好的，差的都淘汰，好的都留下，结果是你考核出来差的走了，好也走了不少。



Fire Fast 再深一层的是什么？我认为是怎么样快速识别合适的人，帮助新成员快速融入，以及激发他们的潜能，尽量避免被 Fire Fast。



至于不合适的，就不应该通过面试，若通过面试了，就要在试用期 Fire Fast，这也是试用期比较残酷（新员工最卖力）的原因。



靠谱的 HR 很重要

靠谱的 HR 就像团队的高潜力人才，有点可遇不可求的感觉，这么些年，我也合作过一位靠谱的，到什么程度？举个招聘的例子，我说我需要一位 DBA， 要求是一二三等等，HR 把 JD搞定，一周内我收到三份简历，但从简历来看，每位候选人都满意的超出预期，薪资合理，面试之后三位都合适，综合考虑后发了一封 offer ；



从提需求到 offer 不超过两周，这里看似简单，其实 HR 做了大量的工作，多个人才渠道对接，海量简历筛选（对，HR 筛简历的能力非常重要），电话初聊、简历核实、到面试、背景调查、最后给出建议，offer 后还得说服候选人等等，节省了我不少时间；



当然也遇到能让我累的半死的 HR，简历初选基本等于没做，这个工作转移到面试官，每周给我安排的面试满满的（即是订阅了我的日程），不得以我只能要求每周固定时间面试；一面二面的面试官抱怨每天都在面试，没有时间干活，老板又给了一些比较主观的判断标准，更让下面的人摸不着头脑。好不容易有个入职新同事，就像大熊猫一样保护起来，怕跑了没人干活，这样的过程，苦不堪言。



总结一下靠谱的 HR 至少具备以下特点：

• 强悍的人才获取渠道建设能力

• 丰富的简历筛选的经验

• 考察候选人可以直击本质



总的来说，一句话，HR 给的候选人，要是靠谱的，虽说不能一给一个准，但也不要通过率低到惨不忍睹。这需要 HR 有分辨候选人质量的专业能力、需要丰富的识人经验、还需要吃苦耐劳；



试用期怎么用？

有些人简历漂亮，面试舒服，也没有其他对手挖墙脚，顺利入职，却在试用期总是感觉不那么对劲儿；高级任务做不了，低级任务不屑于做，试用期考核时，有些为难，模棱两可。



9个月理论是有道理的，三个月试用，三个月改正，三个月观察；一个人如果真的不合适，很有可能浪费你9个月的成本，不但占用编制，更重要的是阻碍寻找更合适的人；这个时候确实要果断，不能拖泥带水。



正确使用试用期三个月就很关键，一定要试用期压力测试，我的策略看起来没有人性，却很有效果。



试用期也是帮助新人融入团队的关键时期，熟悉工作环境，熟悉各类系统，熟悉代码，适应工作风格，这些不能靠口述来传授，最有效的方法是动手；



我的方法是三小两中一大；



先分配三个小任务，比如修 bug，辅助小功能实现，独立小模块开发，通过三个小任务，任务周期从一天到三天的工作量不等，一来让新人熟悉代码环境、研发流程、部署工作，二来考察其工作能力和态度，一般牛人是不会拒绝小任务的；



如果小任务不愿意做，那么可以安排有难度的，我相信贸然进行有难度的任务，是要比熟悉环境的同级别同事要多几倍的时间，而且质量不一定有保证，任何有点历史的项目，一定会存在暗坑，往往会踩中。



小任务考察通过，两个中级任务就可以安排进来，可以是要求配合进行重点项目也可以是独立负责支撑类项目，新人既有环境上的挑战，也有业务广度的挑战，需要争取一些资源的支持和左右沟通的工作，看看深度协作是否节奏一致，或者能调整的一致；



最后交给其一项大任务，可以大到一个重点项目也可以是重点项目中的重点功能 一定要独立完成甚至带人完成，权力在握，又是重点工作，其驾驭能力和心态是什么样的，很容易就可以看出来。



经过三小两中一大的“成长”之路，这个人能否通过试用期，基本就清楚了。



试用期中如果连续两次出现问题，不要犹豫，Fire Fast，通过试用期后，再解雇的话成本增加一大截不说，时间也耽误了。



模棱两可时倾向于更坏的选择

这是一句话经验，当模棱两可时，应该选择更坏的选项，非常的悲观，却也是概率上的最优结果，往往选择相信好的一面之后，换来的却是明月沟渠；



这句话的经验至少可以放到面试和试用期考核这两个地方；



面试结果捉摸不定，模棱两可，好像适合又好像不适合，那就不要纠结；好像可以定的P6也行P7也行，那也不要纠结；



试用期考核结果有好有坏，反馈褒贬不一，先分辨真伪，再做出最坏选择，总不会错；不要有错失恐惧症，你不会后悔的，也不要看扁对方，只能说候选人不适合这个团队，不代表到了其他地方就不能能发光发热；



新人融入要友好

这一部分是 HR 的工作，一部分用人部门的工作；



制定详细的新人入职 check list，就我的亲身经历，这个过程极为重要，直接决定新人对公司的第一印象，进而影响其工作态度；



讲讲我入职美篇的例子，第一天入的时候，HR找一张桌子给我，然后就没有其他的了，整的我无所适从，不知道该干什么，老板也不在，周围同事都不认识，好吧，作为一名空降兵，自己来动手解决问题的觉悟还是有的，网络连接上，四处张望一下熟悉环境，然后我就站起身，开始四处观察，看看工程师敲些什么代码，设计师做些什么设计，编辑运营们写些什么文章，当然都是默默进行，一圈转下来，知道这家公司是工位是按客户端/前端/后端划分，设计师、运营坐在一起，QA集中在一块区域，至少我知道以后在什么地方找人；



对，还没开通公司工作账号，没办法浏览入门文档（事实上当时简陋到就没有这些文档），于是乎我开始与临近座位的小哥攀谈，以掌握更多的信息；代码管理SVN、上线用FTP（没错，是FTP）、单体应用、线上核心应用主机两台超高配置（为什么没有拆分？好吧，他们担心手工操作FTP发布时间差导致不稳定）、所有业务在一个数据库实例、redis常年内存99%等等，这些没有架构设计没有运维，甚至连运维 HC 都没有；系统因为各种原因三天两头宕机；做项目所有人一窝蜂，手忙脚乱；



不过，好在整个研发流程算是完善的，从需求设计到研发管理、质量控制和上线节点把控的还不错，尤其是需求文档比较清晰，但缺少一些必要的内容，比如必要的流程图、数据流图等；



看完这些，是不是有些绝望了，是不是后悔了；说实话，这个想法真的冒出来过，甚至缠绕了我一段时间；



不过，我来就是要解决这些问题的，不能做逃兵啊；如何帮助美篇从刀耕火种进化到现代化，是另外一个故事了；这里重点是描述帮助入职新人融入团队的重要性，连我都差点跑了，更何谈其他人。



文末提供一份参新人 On Boarding 清单，大家可参考或修改实践。





研发新人 On Boarding



破冰 （入职第一天）

破冰部分由 Leader 执行

1. 新人入职当天，Leader 必须在场接待，表示欢迎并负责引导/安排工位/介绍新人导师

2. 相关账号/权限初始化

3. 工位安排后，进行团队人员介绍（站会形式，新人自我介绍和同事自我介绍）

4. 带领新人到各部门与客服/运营/商务/财务等对接人见面，知道遇到什么问题可以找谁

5. 中午/晚上，Leader/新人导师 带领新人熟悉公司周边环境，一起工作餐



入门（入职第一天 ～ 第二天）

入门部分由新人导师执行

1. 对所有产品线的产品/项目介绍

2. 系统架构讲解

3. 辅助熟悉工作流和规范和常用工具

4. 导师分配小任务，实操入门



进阶（入职第一周）

进阶部分由导师&项目经理执行

1. 进入项目

2. 项目经理对新人进行项目背景/愿景做介绍

3. 正式承担项目任务



跟进（试用期）

跟进部分由导师执行

1. 入职一周后，导师沟通近期状况

2. 工作遇到的难点

3. 明确新人有待提高的不足

4. 以上要聊到具体细节

5. 入职1个月/2个月/3个月的月度沟通