对新人来说,早期多学到点东西,比多一点工资重要得多。我带过很多新人,他们在工作中确实出现了很多低级错误,人为提醒或者帮助其改正效果并不好。最后我总结了一套通用流程来管理。
首先,我们得明确一个道理,成长是自己的事情,管理者只能做引导。最终学习的效果,还是得看个人。有些流程规范你制定了,他不遵守,那说明他不适合这家公司。我们能做的是总结出一套通用的流程来帮助新人解决一些共性问题。
从哪里着手?从培训入手。现在很多大学应届生缺乏工作常识,尤其是业务流程和工作方法。这两块在正式编码前就要做好培训工作,这样能减少很多问题。
在公司里对于新员工,一般先从熟悉业务开始。讲明白一件事:我们的目标用户是谁、解决的什么问题、如何解决的以及目前的现状,市场上有哪些竞品,各自的优劣势等。
程序员要懂业务吗?要!
前期准备:使用工具的账号。
跟工作相关的工具。比如我们做研发的时候会用到:
很多习惯的养成,需要外部的压力。虽然公司制定了很多规范,但是却不关注新人有没有真的去执行。所以要把这个写在编码规范里,并且要让其他同事随机抽查。检测的标准就是:代码要能运行且其他同事能够根据方法名、注释看懂代码逻辑。
先讲一下整体的结构逻辑。然后再讲不同业务的代码分布。标记一些重点观察的代码文件
2.2.1 先看公用的封装好的代码。比如工具类库,联网请求这类代码文件。
代码如果很多,要优先看公共方法。这些在项目里都是唯一的,被多个地方调用。你在做新需求后,如果需要用到,直接可以拿来用。不需要你重新做。而且一般公共使用的代码,都是经过团队完善的,里面bug少,逻辑清晰。从中可以学到很多编程思维。
2.2.2 再看需要负责的最核心业务的代码。
比如新人是负责购物类App的开发,那么先熟悉关键的选购商品 - 提交订单 - 支付这个环节。在讲解的过程中,先记录自己问题列,然后统一问。事后自己去调试一下,调试的时候可以按照测试用例来调,测试各种异常情况。一般等你全部调试一遍,你大概能理解现在的代码是个什么情况了。
很多优秀的程序员精进的方式是在github上找开源代码。看懂了就尝试提交代码,一般最开始肯定会被拒绝,因为你写得不够简单,高效。但只要你持续地看和写,持续地提交,总有一天你会收到开源项目管理者的反馈。当有一天,你提交的代码,在开源项目里运行时,你就已经是一个非常厉害的程序员了。
当然刚刚入职的话,可能没有那么多时间用在学习github的开源代码上。还有个方法就是读你们团队里最厉害的那个人的代码。既能了解业务,还能学习编码思维。这个方法并不难,适用于各个行业,亲测有效!
2.2.3 请教同事
请教之前,请先告诉对方你做了哪些尝试。如果调试出问题,自己解决不了的话,那就要去找同事请教。但在请教之前,先把问题梳理清楚,看看问题是在什么情况下发生的,传入参数有没有问题等等。别遇到一个小问题就去请教一次,自己先琢磨思考,再统一一个时间去请教。
要引导新人自己确定自己的目标。转正之前你觉得自己能要达到什么样的标准?公司对你又是一个怎样的标准。两个标准要一致。这里一定不能讲虚的,要用事实来决定结果。这里我会根据公司的量化考核来和新人达成共识。比如这位新员工沟通理解能力较差,无法融入团队。那么试用期一定要提高到正常水平。而这个正常水平,要量化为,可以正常听懂产品经理的需求描述,并复述自己的理解。
达成共识后,就是拆解目标。试用期的目标尽量简单,因为试用期时间有限。管理者要帮助员工做目标拆解。每周都可以对目标进行一次复盘。每次复盘都要明确结果。新员工哪里做的好,哪里做的不好都要明确。
对新人来说,在试用期里就确定其是否符合预期。管理者一定要勇于让不合适的员工离开,这是对他好,也是对公司的负责。一般在第二个月结束时就要有一个明确的预期。大多数员工能力行不行,适不适合公司在前面两个月都能得到结果。第三个月一般只是确认结果。
管理者在这个阶段容易犯一个错误就是,因为项目紧急,需要这样一个人做事,会选择把不合适的人留下。这种做法最大的问题在于,你破坏了自己的规则。如果双方达成的共识能随意破坏,团队里就没人相信这个管理者做的共识管理了。
最后,别人的经验只能做参考,适合自己的才最重要。就像有些公司推崇271末位淘汰,这个制度有其好处,但前提是你能招到足够多的人,对很多公司来说,如果没有这个条件,那就不适合。