背景介绍
公司每年新加入的同事越来越多，产品技术团队在帮助新人如何做事情方面的经验不足。之前也没有给各位导师统一过思想，在做导师方面也没有明确的要求，所以每个小组的做法不一样，效果全靠Leader自己来带。外加项目时间紧开发任务重，在新人的培养方面长期被忽略，所以梳理下导师培训计划。
什么样的人能入选导师计划？
1、须是TL或能力在团队被认可，且本人乐意帮助他人成事，喜欢说Yes And的人。
乐于帮助他人成事，特别是遇到其他同事的求助，乐于说Yes And，会从愿意配合他人的工作开始。如有困难，会给出有条件的方案，如：是否可以多给我一些时间来开发，或是否可以多给我点时间想想，充分思考后可以给出合理的方案。
2、做事守时且高效，例如：
- 是一个愿意遵守约定，且为约定买单的人，承诺了就要全力以赴去达成。
- 是一个自燃型的人，例如，主动反馈任务完成过程中的进度。因为你的反馈会提高团队的效率，甚至会影响产品的决策。
- 是一个会自我管理的人，做事有计划性。例如会做月、周计划的人，每周会对自己的工作进行总结，每天上班前想想今天做什么。
- 是一个会”少“做事情的人，这与我们大部分人提倡的多做事有点不一样，我们软件开发过程中更好的不是多做事，而是少做事，把每一件事情做好。比如在实际开发过程中，当我们想用一个新服务替代一个老服务的时候，只有这个老服务顺利下线，且新服务正常运行才算是把事情做完。不把一件事情做完，又去开始新的任务和项目，大概率是会给团队挖更多的坑。
3、是一个做事闭环的人，像4x100比赛一样，保证队友接住了才能放手。以下做法符合闭环表现。
- 休假前，会提前对工作进行交接，收到反馈第一时间给反馈，哪怕一个简单的一句”收到“。
- 在项目进展达到某个里程碑的节点、出现风险或故障等的情况下，及时周知相关同事。
- 作为一个IT从业人员，我们提倡多给有倾向性的结论，能有数据支撑的就一定要有。如果结论是需要启动一个新的计划来推进，一定要附带上新的执行计划 。
4、是一个重视技术的人
工作中会出现由于排期的原因，选择了容易实现但有技术债务债务的方案，在短期行得通，但长期肯定行不通。技术债就像高率贷款一样，久而久之利息成本会越滚越滚高，需要根据情况及时还清，否则你将会以计划外的工作来偿还。例如：线上故障，会打断正在进行的开发计划。
教会新人****3****件事情
1、如何承接一个需求？
教会新人如何拆解需求，目的是让我们围绕「目标」做事情，不是围绕「人」在做事情。
首先，需求至少包括三个方面，功能、质量和限制条件「先记住了」。
功能，就不赘述。
质量，包括运行时质量和非运行时质量，如：QPS/RT，非运行时质量方面，例如，架构设计在未来需求变动情况下，是否容易扩展。
限制条件，包括完成这件事情需要哪些资源来支持，例如上线前需要内容运营或产品提前准备哪些资源？
第1步，在承接需求时要主动多问Why。例如：需求真实诉求是什么？是为了达成什么目的？识别产品给的需求是否是一个建议方案，是否忽略了背后的原因。没有彻底理解需求，就直接Coding可能会犯X-Y Problem问题。确认完需求后，还一定要问新人是否理解，如果他自己来做，是否有好的建议和想法。根据实际情况，决定是否需要新人来进行需求反述，加深对需求的理解。
第2步，确认完需求之后，就是对需求进行合理拆分，并进行实现方案设计，且列出每个子目标或任务的验收标准，以及潜在风险点和规避方案。一定要让新人组织一次对实现方案进评审的会议，可以叫上直属TL参加。
第3步，需求拆分成任务后，依照里程碑来进行排期。实施过程中，及时提醒新人在关键节点要有进度条反馈。例如，项目进展到里程碑节点、进度出现风险或故障、阶段性的讨论结论等。
如果，所带新人是一个老兵，我们建议直接给目标，如果是新人直接给任务。
无论给目标还是任务都要符合SMART原则。在动手Coding之前，同样讨论出验收标准，以及潜在风险是什么，完成这个目标需要什么资源，确认时间期限。
提示1：对需求进行拆解的动作非常重要，因为只有拆解到细节才能了解本质，有了细节才具备执行力，进而开发的排期相对来说，也是务实的，对工作效率的提升是巨大。
提示2：每周至少一次面谈反馈。阶段性与新人沟通工作中遇到的问题。在发起沟通时，尽量不谈感受，而是针对行为提出明确改进意见或要求。
2、如何组织会议?
我们是一家不提倡开会的公司，如有必要组织会议，会前务必准备议题，提前通知所有参会人，需要大家了解的东西预先通知。另外，会议的目的是快速讨论出结论，而不是脑暴。不要为了信息同步就拉上所有人参会，只邀请须参加的人参加即可。新人组织会议前，一定要提醒做如下准备。
- 有主题
- 有记录
- 有场控
- 有决策
- 有落实、有检查
不良好的会议表现，如：
会议前的准备度不够，导致开会陷入不必要的争论，浪费了很多人的时间。 开会迟到、低头玩手机等。
高效的会议组织方式：
- 书写 wiki 文档，并对会议内容进行整理，包括：会议的议题，需要达成的共识目标等；
- 提前24小时将 wiki 文档发到群里并通知相关人员，所有讨论可以通过回复的方式进行互动，并形成一致结论；
- 会议时间控制在15至30分钟，避免会议中进行脑爆或细节方面的讨论，问题与方案需要在会议前确认好；
- 会议完结后及时将会议结论同步至 wiki 中；
以上方式的优点，在于发起人通过整理文字提前梳理自己的思路，同时也可以将讨论的问题以文字的方式留存在 wiki 中，也便于后续相关问题的追溯。
3、基础的软件工程能力
在我们团队，作为技术同学，为了更好展开工作，软件工程的基础知识是必备的技能。在新人入职的第一天，一定要让新人刻意去学习和掌握，避免在技术设计方案评审环节，出现文档不规范，甚至不会画流程图，分不清楚什么结构图、架构图等问题。所以，在试用期，一定要让新人加强这些方面知识的积累，否则无法高效展开工作，更做不到长期敏捷。
小结
帮助新人成长是投入产出比最高的工作，属于重要紧急的事情，一定要成你为长期计划内的事情。如果因为项目紧急就忽略，新人就会成为团队的“技术债务”，例如：一些不好的编程习惯或做事方式，会在今后的工作中，以不同的形式反应出来，那样子就得花更多时间成本来纠正，情况严重了也可能无法纠正。
