驭人术:招聘、培养以及团队管理
前言
写这篇东西的动机是最近被任命为小组长，想着虽然不喜欢管理，喜欢当专家，但在这个精英也得团队合作的时代，怎么也得至少懂得管5个人以下的小团队吧，而且自己老大说试用期是3个月，那就试试呗，失败了也不吃亏，就看看能学习到什么和能搭建一个怎样的管理系统，权当是一个为期3个月的管理实验。
但是开始管以后才意识到，老大这次任命同时包含了两个任务，明面上是管理团队，暗地里还塞了一个培养新人的任务，我瞬间就爆炸了。后面专门研究了一下才发现原来招聘，培养和团队管理是三个不同的工作。
招聘
招聘是驭人术里面最难的，毕竟得有一眼从马群里面找出千里马的能力，这要求自己也非常优秀，但是也是最有价值最重要的一环，如果能招到好的人，那么管理就事半功倍，而且还可能带来超额收益。在开始对外发出招聘启事之前，首先要明确招聘坑位的要求是怎样的，特别的考虑招聘校招生新人，还得知道自己团队是否有闲暇的资源把校招生新人带起来
招聘就得朝着优秀的优质的精英招(基本专业技能，做事的态度，是否关注业务，沟通能力，抗压能力等，下面有说优秀的人的特征)，然后才是对的人，因为「优秀的人」学东西领悟特别快，而且视野比较宽阔，所以很容易成为「对味的人」。而对味的人则能让你省心，因为心齐，大家都往一个地方走，所以沟通起来很舒服，有些事情也不用自己使劲推他们也能往目标前进，而且人才留存率也会很高，降低了招聘成本，毕竟招聘无论是招到好的人，还是随便招一个成本都很高。
记住「HireSlow，FireFast」，有时间精力情况下「宁缺毋滥」
优秀的人的特征
- 对自己的职业有兴趣和热情
- 专业靠谱，如数家珍(软硬能力优秀，外加一点责任心)
- 有明确的职业发展规划，有野心，视野站得高看得远
- 对行业，公司，项目熟悉
软能力
面试过程中都是覆盖硬能力为主，软能力少有覆盖且很难短时间看出来，一般都是试用期全面考察;
- 靠谱:主动反馈汇报进度和遇到的困难，超过1小时都解决不了的可以把问题抛出来，不要害怕被骂就藏着，越藏着问题增长就会变成指数级。对提问要及时回复，做到事事有回音。
- 独立解决问题能力:积极主动发现问题，并能独立或寻求资源解决问题。知道如何「科学地」「拆分(分而治之)」「循序渐进」解决原因已知问题甚至是原因未知问题，即基于数据大胆假设然后小心求证;
- 提问：学会准确描述问题，学会提问前使用搜索引擎解决80%问题，问别人知道怎么回答的问题(站在别人的角度思考)，问问题时候带解决方案，不管多烂，至少要有两个。请教问题尽量在沟通软件上先沟通，而不是突然出现在别人身后请教问题，容易打断别人
- 快速学习能力:是否具备知识迁移能力，能否短期(1-2周)内上手项目业务和技术栈，并且能分担开发压力;
- 沟通协调能力:快速描述自己的内容以及快速听懂别人的内容，甚至是准确地转述事实也很重要，如果懂得不同类型的人用不同的频道对话是最好的(换位思考)，全局范围多想几步，谁都不喜欢”挤牙膏”式沟通;
- 协同合作能力:与他人协同合作开发时，需要切分可交付任务，不要写到哪里算哪里，保持专注，每次只关注修改一个点，解决一个问题，不要觉得顺手就把周围相关的不相关的都改了
- 总结复盘能力:是否会自觉去总结反思，打造完善自己流程和系统，避免下次犯同样的错;
- 时间管理规划能力:如何处理优先级和准确估时(进一步考察任务切分粒度) => 按天(有能力按小时)记录安排好自己的事情，分清轻重缓急;
- (Advanced)产品市场能力:能否透过现象看本质，思考用户痛点，主动思考产品的市场和解决的问题，主动发现产品的问题;
- (Advanced)领导能力:能否站在更高的上下文全局地思考问题(传说中的想领导所想，但是做小兵该做的)，能否能在群龙无主的时候跳出来带节奏，独挡一面，有自己的气场;
P.s.其它一些新人须知
1.公司雇佣你来是为了解决问题，即便有安排人带你，带你的人也是只想花最少时间，所以唯一的依靠就是”自学能力”，没有什么问题是不能通过”独立思考”和”学习”解决的；
2.任何时候都不要迟到，哪怕是弹性工作制，「弹性只是对于牛人而言的」
3.发现问题一般是从「效率优化和流程优化」两方面，同样地需要附上解决方案
4.发现自己效率低下，可以停下来花点时间分析下效率低下原因在哪里
硬能力
这里用后台开发工程师举例
- (必须)CS四件套: 算法数据结构 + 计算机系统 + 计算机网络 + 计算机语言(编译原理);
- (必须)Web六件套: 框架 + WebServer + RDBMS + Cache + Search + Queue;
- (必须)建模抽象，系统设计，设计模式;
- (优先)对代码有洁癖的人，以及对测试质量有要求的人
- (优先)高并发经验，大数据处理经验;
- (优先)相关行业和项目经验;
培养
新人培养，这里新人是新入职的人，在符合要求的基础上可能某方面能力上会比招聘他的同事强，但是综合能力不会超过招聘者，因为招聘不会招一个自己都Hold不住的人。
另外，Leader本身也要有意识培养自己接班人作为互备，内部培养起来比直接招聘空降的要好，前提是招聘是按照上面那样严格筛选过的。
新人培养
即「如何确定新人熟悉到可以独立开发项目需求的程度了?」
1.Leader确定新人职责，要负责的项目和领域
2.分配项目熟悉者去带新人熟悉项目，熟悉者需提供项目相关资料(比如产品后台+业务文档+技术文档+接口文档+代码等)，并说明所解决的问题、关键点(核心与局部)、优先级以及需要补充的知识技能(比如可以维护一份新人须知文档来培训)，以便新人快速了解项目。
P.s.这也要求项目本身要简化上手难度，比如详尽的入门文档，容易搭建的开发测试环境，简洁易懂且统一的代码等，都需要平时不断迭代中保持和维护的，无法一朝一夕就赶出来的
3.新人了解项目后，设立验收任务(明确产出结果+开发计划)，给一定时间(不要太长，一般3~5天，一长就容易走偏，而且得每天跟进)熟悉到一定程度后让新人对任务估期，开始开发后，项目熟悉者要定期跟进(这时候可以不用每天跟进，但是至少每3天要跟进一次)，Leader也得半周到一周跟进一次，最后考察任务输出确定是否值得进一步培养。
4.对于不同类型的新人投入时间精力是不同的， 试用期 > 转正 > 实习期。
在职员工培养
比新人培养成本低一点，不用一直盯着和跟进，对于在职员工可以提供有挑战的问题、任务和项目，提供学习培训资金和资源，因为本身在职的员工本身已经是老手，知道怎么去学习和独立解决问题，所以只需要提供伸手能够得着的挑战的环境和土壤即可。
团队管理
团队管理最好有招聘和培养带人的基础再做比较无痛，直接任命给我团队管理的工作我非常吃不消。团队管理就是处理人与人，人与事的关系，团队存在的目的是为了成事。
下面所说的都是基于精英团队的，如果不是，就参考招聘和培养转提高人才密度变为精英团队。特别的，对于技术团队，那么作为Leader之前需要在技术上可以覆盖团队全部所用到技术栈。技术Leader和其他职业的Leader不一样的地方是没有办法完全抛开技术只做管理，永远是都得兼顾技术和管理，甚至有时候为了技术要弱化管理的角色
学习团队管理可以从学习谷歌的扁平化、OKR、20%工作时间，到学习网飞的自由与责任，人才密度理论，网飞的管理策略是有它的适用场景的，那就是强调创新的上下文，在把控住招聘只招最优秀人来维持且提高人才密度的大前提下，然后信息保持透明，最后向下放权让员工做决策
目标制定
定目标、建团队、立规矩(流程SOP/制度=奖惩+薪级/规范)、拿结果。
先定事情:
- 团队目标(画的饼)首先得能挣钱，其次要足够大，有意义，最好有一定难度(包括年度、季度、月目标)
- 分阶段靠近目标，每个阶段内资源和注意力要集中在一个点上，分散注意力容易破产
- 公司盈利的分红奖金切忌太公分猪肉——干多干少都一样，须奖罚分明，不断提供福利方可留住人才
- 定期对事情和人做团队层面的复盘
再管人:
- 向内—管理自己:怎么规划和提升自己，怎么处理自己情绪和压力
- 向上—管理上司:管理期望和定期主动汇报
- 水平—管理平级:沟通协调以及利用
- 向外—管理客户/供应商等外部利益相关者:沟通、协商、安抚以及洞察需求与痛点
- 向下—管理下属:知人善用、验收、培养、饱和度把控、进度把控、情绪状态把控等等
- 最好管人前要做到前面4点比较优秀晋升后才没有那么痛苦，因为第5点的信息量远大于上面4点之和
团队搭建:
- 职责分明，知人善用，要知道每个人特点分配擅长的活
- 学会尊重与放权给人才精英做决定(让他们有参与感，归属感以及成就感)，相信他们，允许组员某方面成长比你还强大，定大方向目标后，阶段性检查 —— 头条的话说就是”让全身细胞一起思考”
- 建立文档知识库，完善制度/流程/规范，减少人才流失带来的损失
- 建立人才梯队(1-2名”英雄”[个人能力强而且有团队意识] + 20%”独狼”[个人能力强但是对团队兴趣不大] + 80%”农民”[个人能力及格的齿轮人])，定期培训让不想死的”农民”能跟上公司的发展速度，同一业务/项目至少要有2人互备
- 成为榜样:以身作则，提高工作专业能力，增强判断力，不在工作中带入私人情绪，不抱怨，有信念并能坚持
- 学会保护团队成员，给与足够的支持和陪伴，给他们抵挡干扰，也要主动扛责任，顶压力，背锅挡枪
- 鼓励团队内主题与工作相关的分享。比如，把每周团队中遇到的问题，进行整理在团队内部进行分享。一个人踩坑，多人受益，切记为了分享而分享，容易走形式主义。
- 如果一名团队成员在你不太方便的时间来找你聊天，一定要先把手上的工作放下，专心跟他交流，因为大概率可以减轻一些糟糕的事情的伤害
- 每周下午茶，每月聚餐，季度团建，年度海外旅游等这些工资以外的福利是锦上添花而非雪中送炭，必须得把上面这些点做好，工资以外的福利才有意义，如果上面占据每周至少40个小时的工作都做的不爽，再多福利也留不住人，甚至还会被人诟病:”工作时间外的团建就是变相加班”
任务安排
1.待排期要划排一个礼拜的任务量(超过的一个礼拜的量会造成组员心理负担);
2.安排的任务需要非常清晰不能模糊的部分，安排之前我要自己过一次我自己怎么做(如果我自己都不是100%清楚「首先-然后-最后」自己是怎么做的，组员也会懵逼，一懵逼就找你，你也哑口无言);
3.如果是组员没做过的没经验的任务，我得以我的估时作为基础填上去作为组员估时的参考;
4.不确定耗时的，需要让组员估计的任务，任务的估时填0.1h即可，表示由组员给出估时(如果直接填确定的时间组员会认为是我这边估计好的ddl，而估多了组员不会退回来);
5.然后再逐个任务和组员沟通确认优先级和完成先后顺序后再提单;
6.开会前提前同步会议进程，问题以及涉及的要阅读的材料，提前让会议参与者消化掉
验收考核
安排好了任务以后当然就是需要跟进每个人的完成情况，确定好验收方法，包括是否按时，按质交付等等。
另一方面考核评估也是必须的，毕竟“分赃“需要依据，而考核的这个过程也是不断了解每个组员各方面特质的重要途径。
评估方法
绩效 = 成绩 + 人效 - 损失
成长类型 成长效果 判断依据 打分范围
+成绩+
「突破」 难点解决，挑战达成 上级和你都觉得挺难完成，但你通过努力完成了 ABCD
「创新」 带头完成了某个领域从0->1，并产出很大价值 高度自驱，并付出巨大精力 ABCD
「贡献」 氛围提升；节假日紧急加班或值班；成本下降等 上级评定，公开同步 ABCD
+人效+
「能力」 通过能力的提升，增加了工作输出 看量化，查验细节，经得起各方面查证 ABCD
「时间」 通过时间的投入，增加了工作输出 看量化，查验细节，经得起各方面查证 ABCD
+损失+
「事故」 因事故，造成了公司损失 参见故障惩罚措施 一级二级三级
「人为」 因个人原因，造成部门或公司损失 如：临时不参加既定活动，损失定金 一级二级三级
基于当前职级进行评估，A很大，B较大，C较小，D无；损失定级参考事故
评估流程
定期待：写月报前，主动找上级沟通，一起确认绩效期望。（可参考问题池，挑战池，目标池）
抓落实：每周省察进度，及时反馈情况，必要时及时调整。
看结果：通过月报形式汇报成绩，直属上级进行复盘和沟通。
出成绩：上级每月3号前同步结果给部门负责人，部门负责人进行复盘，同步绩效结果。
人员治理
1.尽可能系统化平台化，不然不好离职，没办法系统平台化的是沟通和开窍能力
2.像管理脾气比较冲的人需要引导和影响，而不能直接掰(你无法改变一个人，但是却可以让一个人自己改变自己，那就是让他开窍)，影响是指自己要一直keep住对的习惯，直到有一天他被朋友、亲人怼了，然后意识到我这么做是对的就会开始自我改变
3.因为自我要求高而难抓痛脚的人，一旦抓住一个点的话就要毫不留情地说她
4.不能3分承担责任，7分推卸责任
5.管理犹如君王，必须懂看人，懂用人，可以驾驭不同性格特点的人，能轻松指点出每个人的特点，人不能像机器机器
6.推进事情要获得上级支持，有些事情就是顺利，背靠资源&背靠团队，一个团队需要不同方面性格特点的人才
7.工作中要不就是要钱，要么就是要成长，不然就是成就，都不要的就是在混日子
8.会有领导会care员工是不是和自己一条心，但是我觉得pro就好了，事情做的漂亮就无所谓
团建活动
我以为组织一场季度的团建活动，和每周下午茶以及每月聚餐一样简单，没想到参加别人组织好的团建活动，和自己亲手来组织是两码事，就算有经费也是，太难了！
团建组织一共两种:一种是团队人齐优先，另一种是兴趣优先
一、经费前提下团队活动 => 以提高团队凝聚力为目的 => 热情不会很高，但是有经费支持
1.搜集每个人的意见;
2.汇总后给出两道选择题，一道时间，一道项目;(做2轮就能非常具体了)
二、兴趣导向 => 以满足兴趣为目的 => 热情会高涨些，但是没有赞助的话就只能AA平摊
1.发起活动
2.征集感兴趣的人报名
见附录2 某次成功的团建
年终汇报
PPT先弄文字版确保没有遗漏，再精炼删减后转化为PPT，PPT内容都通过图表展示，减少文字量，最好每个点只有1-2句作为启示，才能留着Audience的注意力。PPT的特点就是抓大放小，和1个小时电影的台词文本其实没有多少，但你还是觉得电影精彩是一个道理。
完成ppt后预演一次去估计调整时间，然后得休息好，不然讲解的时候会没有足够精力演绎
Example:
- 4点要求:
1.可以量化的均「量化」展示，借用「图表」
2.特别突出的成绩「单独」模块展示
3.进步，不足等跟之前「对比」展示，拉出往年总结
4.计划跟部门目标「对齐」展示，一个方向发力
- 第1次修订:
1.增加了游戏概况统计，还没转成柱状图;
2.项目对应的加了截图;
3.增加了组员的个人页(3页);
4.目标加了如何对齐了部门目标描述;
- 第2次修订:
1.游戏概况统计数据转成了柱状图;
2.纯文字的做了图状分类提炼关键字(分别是P43,P44,P50,P51页);
3.增加了事故页;
4.排版美化调整
月度汇报:
1.先摆结论后给过程证明
2.踩中老板能理解的点「成本」「高可用」「高性能」「高效率」
3.补上人效
4.补上缺失的「未来如何避免」
离职
无论一个人是再怎么喜欢一个公司或者一个团队，短则3年，长则5年，总会有遇到离职的情况。对于一个团队而言对待离职就得和对待招聘一样重视。离职一定要做好离职面谈，包括对离职者的，以及和离职者关联的同事之间，要深挖离职原因，如果是团队出现问题一定要及时发现且修复掉。
奈飞:「离职员工只是和岗位不匹配，而无关乎个人失败」
离职管理ABC:
一.立即通知上级领导和HR，根据离职者的价值判断挽留与否;
二.离职沟通(20 - 40min): => 找出管理和制度上的问题，避免未来的人才进一步流失
- 离职原因？钱不够还是受委屈？你是深思熟虑过了么？
- 你觉得同事交流如何？业务强度难度如何？后台组还有什么问题？
- 你要离职了，可否给我或者小组一些改进工作建议？
- 接下来的打算？高就？就业关注的方面？
三.其他问题参考:
1.你为什么想要寻找新工作?
2.最终导致你决定去其他公司工作的原因是什么？
3.你觉得在目前这份工作中最大的难点是什么？
4.你如何描述我们公司的文化的？
5.公司可以做些什么来让你愿意继续在这里工作？
6.你是否在离开前与公司任何人分享过你的疑虑？
7.如果你可以改变你的工作或公司任何事情，你会改变什么？
8.你对管理方式满意么？
难题
1.如何评估「不熟悉」的项目任务拆分和估时你组员给的都是合理的？=> 一定得熟悉才能解?但是这么多项目这么多年的积累迭代，熟悉成本需要很大，而且后面还得几拨人同时继续迭代，精力消耗巨大到光是徒劳且疲劳地跟进罢了
2.怎么验收和评价你「不熟悉」的项目内组员的任务完成质量？ => 如果是你熟悉的项目你又如何验收和评价组员的完成质量 => Review设计是否精简，代码风格是否优雅和测试是否到位
P.s. 不懂的话其实是不好管的，特别是攻坚推动技术难题的时候，安排下去下属推不动还是得找你，你也不懂的话，那这件事就推不动的了
3.如何给新人安排熟悉你「不熟悉」的项目以及安排任务？=> 找熟悉的人呗
结论:现在的初级管理者一般都是技术和管理双身份，一边处理部分业务技术问题另外一边兼顾管理的工作，所以需要本身素质上已经是该行业或者领域的”老油条”了，对各种情况基本上都有解决方案，而像对于上面出现的各种「不熟悉」其实是自己不适合领导团队的警钟了，要不就短期内熟悉起来Cover掉，要不就主动退位。
实验记录
(20200709)以前最底层管好自己就够了，现在升级一级别做了小组长，管理四个人，以为只是上升一层而且只是管理4个人没差太多，但是差别还是足以引起我的混乱的，从最终端底层，上升到领导管理层级以后，多了:
1.培养新人(安排任务，跟进，验收，评价，而且业务自己还不一定熟悉)
2.对上汇报(本来就有但是上下文变大了，而且除了自己的进度以外还得包括其他人进度，汇总后提炼最重要的一个)
3.平级沟通协调(要知道其他平级组织资源情况)
4.对下负责(要同步信息和收集每个人信息和工作饱和度)
5.原本只是安排自己这周干啥，最多是下周干啥，现在除了自己还得安排下面每个人这周干啥，下周干啥，甚至还得安排下个月的项目，考虑优先级，饱和度，需求信息的同步，协调沟通确定估时等，我自己估自己的时都不准的说…我还得估计其他的时间，尽管是粗估。真是年纪越大，位置越高，越要预计划越远的未来，怪不得老板开口都是明年后年最近三年的事情
(20200720)
1.刚到这个位置真的一个月内自己原本井井有条的任务会瞬间变得混乱，而且基本是完不成的，因为「多了很多沟通协调」的事情占用时间。而且处理不好上级会叼，下面的也会叼，夹心饼，你要硬起来推进就变成了自己前面一直吐槽的傻逼领导，你要软下来聆听接受，你就得头秃脑壳疼地接受处理原本4-5倍的信息。而且会议汇报，沟通和理解的时间比例会增多30%左右，要注意专门优化，我预计我能承受的直接带领的人5个人就是极限了
2.「情绪管理」要求进一步提高了，因为经常有并发事件发生，或者别人情绪会不负责地倾泄到你身上，为了推进解决问题，必须要瞬间冷静，压住情绪，冷静去理解和消化，至今为止我已经有好几次都在爆发和崩溃的边缘，都得沉默10多秒，不然我怕骂娘的话喷出来。BTW,真的一升一级自动和原本的同事瞬间疏远，无论原本关系多好
3.从完全的解决问题者进化为发现问题和分解问题以及解决问题的领导者
(20200815)管理者角色: => 需要把组员「安排的明明白白」
1.协助领导定未来发展方向提供建议，协助审核上头定的流程和规范，每个礼拜还多一个管理层会议，要对当前管辖的所有项目轻重和未来布局有清晰的规划;
2.日常得给组员(3个人)安排分配任务，协调内外需求排优先级(下周和下月)，没排期的人还得我来找活安排插入技术任务，熟悉型项目需要帮他们切割小目标和验收标准以及估计他们熟悉期长度(简直就在设计游戏的新人成长关卡，老玩家和新玩家新手期长度不一样);
3.培养毕业生新人得准备随时被打断然后回复问题，花时间验收，2-3天跟进一，真去Reveiw他的代码花了30min却没有办法写入任务单;
4.开发者:上面以外才是我作为工程师的开发时间:领任务，估期，设计，开发，测试，回归，汇报
(20200901)全局进度把控问题
1.一个任务每天验收直到验收关闭才算结束
2.重点关注重要的时间节点，比如开始，测试，上线。特别是项目经验比较少的新人
3.Review给的时间多不代表可以没有计划
Ref
关于团队管理的强烈推荐去看看2019年韩剧「棒球大联盟」，个人职场的话可以看看韩剧「未生」
接口开发流程
后端开发一个需求步骤: 需求评审(基于原型图和需求列表) -> 建模设计(产出数据库的ERD/面向对象的UML) -> 接口设计(产出接口文档) -> 估时 -> 技术评审(分别对建模设计、接口设计和估时做后台团队Review) -> 给前台提供接口文档 -> 和前台一起做接口评审 -> 给产品拆解与估时 -> 给前台提供假接口 -> 开发环境编码实现 -> 编写接口测试与单元测试 -> CodeReview -> 上QA环境 -> 前后端联调对接 -> 产品QA环境验收 -> 接口压力测试 -> 渗透安全测试 -> 灰度环境 -> 上线(正式环境)
出好一个接口 = 建模设计 + 接口设计 + 估时 + 编写接口文档 + 给前台提供假接口 + 开发环境编码实现 + 编写接口测试和单元测试 + CodeReview + 上QA环境 + 接口压力测试
Code Review
- Review流程v1(Old)
- 代码作者发起到master主分支的合并请求(MR/PR)并指定和通知评审者(Reviewer)，合并请求单做详细描述方便评审者获取上下文，更快地进入状态
- 评审者安排时间(计入排期，响应期不超过0.5天，建议不用打断自己的开发节奏，合理安排时间评审)Review提交的合并请求，提出评论意见，代码作者需具体详实有根据地回复每一条评论(响应期同样不超过0.5天)，和评审者讨论后，决定好修改方向
- 代码作者修改好后通知评审者进行继续Review和讨论，若有问题继续重复第2和第3步(若遇到持久不可解的争论，可以拉入更多人进行讨论，必要时可拉入Leader一起讨论决定)
- 评审者通过后即可合并到master主分支
- Review流程v2(New)
- Review过程:
- 结对两人互相指定对方作为Review的评审者(Reviewer)来提交合并请求MergeRequest(后简称MR)，合并请求单做详细描述方便评审者获取上下文，更快地进入状态，代码开发者应主动推进合并请求的进行
- 评审者安排时间(计入排期，响应期不超过0.5天，建议不用打断自己的开发节奏，合理安排时间评审)Review提交的合并请求，提出评论意见，代码作者需具体详实有根据地回复每一条评论(响应期同样不超过0.5天)，和评审者讨论后，决定好修改方向
- 讨论修改过后，如果不确定是不是OK或者遇到持久不可解的争论，可以拉上组长加入讨论裁定或者指给组长来做二次Review审核，如果确定OK(合并请求如果没有讨论或者评论的，必须要留下「LGTM」或者「已阅」代表评审者会为此次合并负责)且有权限合并的的可自行Merge合并（没有合并权限则指给组长来Merge合并），确认不OK的可以直接驳回关闭合并MR;
- Review方式:
- 小步迭代，通过切分成小任务的commit提交到feature-xxx分支后，几次相关提交后向develop分支提交合并请求MR并指定审核人进行Review，不要堆到上线前一口气提合并请求，量太大;
- 如果开发量少可以直接提交到develop分支，然后发起向master分支的合并请求MR，并指定审核人进行Review;
- 推荐建立和关联issue问题解决问题，但issue是可选的，不强制，Teambition工作台也足够了;
- Review过程:
- 粒度(时间越充分越往下面的阶段进行，但至少覆盖第一到第三阶段)
- 第一阶段(必须)：「目录」目录结构是否合理；
- 第二阶段(必须)：「命名」文件、类、方法、函数、变量命名是否符合规范，是否见名知意，是否符合业务领域命名习惯；
- 第三阶段(必须)：「注释-风格」注释是否简洁直观，代码风格是否和原项目规范保持一致；
- 第四阶段：「正确性-测试」业务逻辑是否考虑周全，是否带上测试或者修改的地方是否有对应的测试修改，测试是否能覆盖接口/类/方法/函数输入和返回的所有情况;
- 第五阶段：「单一职责-复用-耦合」类/方法/函数是否保持单一职责，是否存在没有抽出来的可复用逻辑，是否忽视已有的公共方法自己造轮子，是否存在高耦合代码；
- 第六阶段：「性能」是否存在性能问题，数据结构是否合理，实现上是否优雅；
- 养成一个好的代码品味能提高代码质量和以及帮助在Review中快速识别代码的坏味道，推荐阅读：代码整洁之道
- 评论记号
- [blocker] : 在评论前面加上一个[blocker]标记，表示这个代码行的问题必须修改
- [optional] : 在评论前面加上一个[optional]标记，表示这个代码行的问题可改可不改
- [question] : 在评论前面加上一个[question]标记，表示对这个代码行不理解，有问题需要问，被审查者需要针对问题进行回复澄清
- 注意
- 上下文：评审者需要对代码所在项目和对应业务有所了解，能参与项目早期的评审会议，需要给评审者提供需求文档，预留出评审时间，提供设计思路或当面讲下更好
- 公共项目和公共文件修改要考虑兼容，以及通知相关的开发者
- 和现存项目整体规范一致，而不是另起一套
- 对于Reviewer审核者而言，提高自己对代码品味，对代码坏味道的敏感度是提升Review效率的关键，不然Review真的很烧时间，看着看着都不知道自己在看什么，要看出点问题还得从头到尾理解一遍
- Refefrence
1.Google How to do a code review
2.[译]Google 官方文章——如何去做code review
附录
附录1 团队协作摘抄
摘抄自极客时间<从企业IM谈团队协作>: 移动设备是一种「重消费、轻生产」的终端，我们在手机上浏览和获取信息非常方便，但是产出内容不如大屏幕 + 键盘 + 鼠标有效率 (移动端输入，PC输出，移动端还是替代不了PC，相反他们是互补的存在)
「根据熵增定律，企业的业务会越来越复杂，业务复杂，不得不引入管理和流程，管理和流程会导致高绩效人才的流失」。
高绩效人才之所以流失，是因为他们会在工作中被流程束缚，这种束缚其实也是协作最大的敌人。
达成高效协作，有三个关键的要素:
1.分解
协作中最大的问题是消减噪音。虽然沟通非常重要，但是如果每天团队都被大量的信息淹没，那每个人的效率会因此变得十分低下。
解决这个问题最有效的手段之一就是分拆团队。
企业在增长过程中，不可避免的会涉及人员的膨胀，员工越多，企业的组织越复杂，协作的成本越高，效率越低。根据具体的业务方向或者产品分拆团队，可以把信息限制在一个较小的范围里，这样自然就可以降低无效信息噪音对其他成员的打扰。
另外一个分解方式是团队内的项目拆解。
不要让所有人都在同一个项目里，除非你能确保这个项目里的内容是全部成员都应该知道的。应该仔细评估团队当前最重要的目标，根据这些目标拆分项目，并且只让相关的成员进入项目进行协作。
2.专注
在和客户以及自己团队协作的过程中，我们会发现，事情总是做不完的。所以 Tower 里的成员很容易点开自己的任务页面，发现一堆已经挂红的任务，你可能发现自己，或者是团队的其他同事，每天都被淹没在大量的任务中。
这个时候，你需要帮助团队里的成员保持专注，最好的办法是对身上的任务做减法。产品之神张小龙说过一句话，叫做「90% 的需求都是没有用的」，可以把这句话用来检验每个成员负责的任务，看看是不是也符合这个原理，大胆的帮助帮助他们削减掉身上的任务 ，是保持专注的第一步。
第二件重要的事情是让成员对任务进行分解。比如开发一个功能，尽量让工程师把任务拆解成按小时计量的子任务。这个过程中，工程师可以专注的对需要完成的任务进行仔细评估，而不是只凭自己的直觉设置任务的完成时间，我们都知道，几乎所有的计划最后都会发生变化，如果一开始对任务拆解不足，这种误差就会越大，协作就容易失控。
3.合适的人
「如果你有合适的人在车上的话，那么如何激励和管理他们就不再是问题。合适的人是不需要严加管理或勉励的；他们会因为内在的驱动而自我调整，以期取得最大的成功，并成为创造卓越业绩的一部分」
附录2 某次成功的团建
今天公司团建，举行了射箭对抗赛，规则不复杂，就是在有掩体的前提下，尽可能在规定时间内消灭敌方有生力量，也看到了老板亲自上场，原本以为老板是一个油腻的中年人，但是亲自同场一队以后，我的想法就改变了，老板是一个有独特见解的一个人，和一般刻板印象的老板不太一样，更加有活力。
或许你们觉得团建应该组团去欧洲或者日本旅游才算合格的团建，但是讲真，就团建的目的而言，去旅游的效果并不会比这次比赛的成员之间的协作，对抗好多少
好的团建真的需要花时间调查和设计，首先是调查团队成员的偏好，再调查团建内容，接下来安排时间和落实一系列比如餐饮，交通，休息等，得像一个项目一样推进…
咳咳，扯远了，其实是活动之后，尽管不是领导，不过就我个人而言，通过团建的确能更加亲和团队，所以这次团建的目的达到了，那么如果反过来从领导角度思考或者从其他角度思考又会怎样了，所以才会有了以下的一些思考:
1.射箭最关键的一步是松开弓箭那一刻是否能命中目标，而不管你上箭速度，你射的再快也是白搭，由此引发的思考就是，究竟什么才是直击痛点的工作，是否自己在工作中做了太多不impact或者没有hit中痛点的活儿，自己是否想清楚事情的本质再行动，还是说，上来只是知道熟练射箭，如何快速上箭或者如何在上箭时候可以躲箭，这些只是增加生存几率，但是结果要的是有效消灭敌军数量，如果到头来你射了很多，上箭速度也很快，但是一个敌军都没有带走，那么你的价值就是0，尽管你的技术很牛逼;
2.有计划地进攻和防守，比一味地进攻或者防守更容易赢得胜利。就好比人生，就像一个sin曲线，起起伏伏，突然加速和减速，才有意思，才有惊喜，有时候需要有承担风险去获取收益的决心;
3.团队合作就是角色分配，而角色其实就是各有所长的人，如果协同节奏更不上，就错失进攻良机会;
4.每个月一次的部门或者小组的团建，和每个季度/半年一次的大规模跨部门小组的团建，是一个不多不少的团建节奏。团建多了会使团队成员厌烦，因为一般团建都会占用私人时间，少了又疏远了团队成员和团队的关系，适当的特别的时间节点会让团队成员更加亲和团队，从而调动人的主观积极性，开心也是工作，愁眉苦脸也是工作，为什么不开心的工作呢？
5.团建内容以团建成员互动类或者协作类为佳，反面例子就是组织看电影。只能算是福利，但是对于团建成员之间的关系和默契帮助不大，因为缺少全过程的互动，更多的只是和电影的互动，正面例子，定向越野或者攻防对抗赛之类的运动为佳;
附录3 技术面试
0.有可能会在技术面的时候问上一家公司的离职原因
“现在的工作做了一段时间，已经没有多少激情，因此想寻找一份更有挑战的工作”
为什么厌倦现在这个职位?为什么会对面试的职位感兴趣?
1.自我介绍(占时5%):
自己是如何开始编程的，从开始编程到现在的一个基调，以及未来规划。(过去/现在/未来)
爱折腾，整理控，拥有打破砂锅问到底的好奇心。(你是一个怎样的人?)
P.s.最近发现自己喜欢探讨方法论…
2.挑技术点来考察CV中的项目(占时90%):
你做了什么? => 遇到什么难点? => 你如何解决？
Hint:考察解决问题的路径和思考方式，而无非就是先Google(正确理解问题和搜索姿势)，再分解(这一步自己的知识积累很重要，积累越多越能给你带来不同角度对问题的分析和理解)，最后通过人来解决
注意防备面试官往某个技术点细了地问，比如为什么选型这个，解决什么问题，有什么好坏，和xx区别等
3.最后你还有什么要问的么?(占时5%)
对于开发级别:
1.你是怎么知道和安排每天的工作内容的?
2.版本控制工具?
3.CI?
4.写测试么?为什么写测试?
5.都会评估那些参数?
6.你是如何分析,找到并修复bug的?
7.协作工具(内部沟通/Code Review/Bug Report)
8.Set up 好一个开发环境要多久?
9.你最喜欢在这里工作的什么?
对于组长级别:
1.你是怎么成为组长的?
2.你的组员是怎么知道每天要干什么?
3.你们小组最近遇到的最大的困难是什么?
4.你是如何评估每个人的效率和产出的?
5.你们做例行的效率指导和培训么?
6.你们多久做一次回顾?
7.你们做每月的工资提升么?
对于CTO级别:
1.你是如何融资的?
2.项目盈利么?
3.你对外包的看法?
4.公司的文化?
5.你认为是什么能保证公司的成功?
6.汇报的流程和结构是怎样的?