️This article has been over 2 years since the last update.
本文标题党了，但是适用于有一定技术能力，又打算兼任项目进度的读者。主要讲了如何从培训到干活的流程，并讨论了项目风险控制，自动化工具使用等方法论。
- 本文的背景是由于你个人开发能力较强，管理者希望让你去当包工头，你在接手小组后对团队进行改进的过程。
- 本文仅适用于开发兼任初级管理者的启动过程，是自下而上的改进，非专业管理。
是否接这个活
首先，需要评测一下你自己本身是否有意愿去兼任或者全职带领团队
风险:
- 新人熟练度低，能力不齐，代码质量难以控制。比如碰到培训班这样的代码
- 团队人数过多，交付压力大，经常陷入电话会议与通宵背锅的泥潭
- 自己本身的技术专家路线规划被打乱
- 最差的结果是带队失败，公司损失，自己跑路
收益:
- 团队带的好，当然KPI/工资/上升渠道，甚至下家跳槽都被优先考虑。
- 公司平台大，组织完成一个项目很有挑战性
- 最完美结果是实现小组无效加班最少，自己也有时间看书自学。
- 避免局限于技术，天天与人打交道才是正常人
如果你认为风险大于收益的话，就没有必要接着看了，老老实实当码农等着34岁被干掉；反之可以听一下我个人的经验，以我个人的结果来看，是收益远大于风险的
以下将从技能培训与筛选，风险与进度控制，DevOps自动化使用这三个方面来讨论实现方法
技能筛选与培训
说到培训，这个词的范围实在太大了，培训内容根据公司的体量也有所不同。有的公司是带两三个应届生精英，而在有时却是一人带9～15人进行工厂式开发。
首先需要明确本文讲的不是带自己招的人，而是带外包(X软,X宝,XS)。虽然现在外包的工资也有上万，甚至学历都要求211，但是基础的确还是相当一般。因此短期月度目标就是提高熟练度，也就是提高工具与独立分析能力。
我个人的筛选标准:
- 到我这里的需要二次面试，砍一半指标也很正常，不会给面子
- 培训班/简历造假的一律不要，很多培训班连List与Object都分不清
- 不主动报风险/问题没下文的试用期换掉
- 自学能力差/跟不上进度的试用期换掉
对于持有“再给一次机会呗/给同事个面子呗”这种观点的读者，多加几次班就能治好
1. 培训总体流程
先上结论吧，两周流程如下
- 第一天进行摸底，主要考核Git, Shell, js/Java, 工具能力, 工作经验，并进行加权打分(此部分可以参考领导或者其它组的标准)
- 提供文档资料等Demo，告知下次考核时间，给一个练手项目，放羊自学3天～7天，平时走过去看下情况，并进行简单答疑
- 花一天时间依次看输出成果答辩，优先考核定位能力，自学能力，再考核技术能力，并进行打分排序(这里很重要)，并进行判断接下来是大锅饭还是少而精培训。
- 通过考核的开始进一步培训，并开始接一些简单的需求。没有通过考核的再给3天的时间
- 两周结束，上报两次打分对比结果(事实上就是一定百分比的淘汰)
上面其实也是残酷的选拔制，公司不是培训班，如果最终的人员不能帮助分担工作甚至让你加班帮其重构擦屁股，比如参考这个V站贴，“晚上我加班帮他把这个重写了一遍，产品那边急着要上线，没办法”，对你自己与其他努力的人都不公平。千万不要认为自己招的人辞退是被“打脸”了，否则后期扛不住。
2. 技术培训分解
虽然招聘需求上要求各种造火箭，但是大部分公司的最终要求却是修螺丝，比如填接口，然后写改删查转换，因此就算基础差，也是可以给机会的(反正人都招进来了)。
经过经验总结，我个人对能力的要求排序如下，此部分不区分语言框架，每人都要会。
2.1. 定位能力
指从前台(网页,XHR请求等)报错到后台日志，最后定位到实际业务代码行的能力
举个例子，比如给某人一个前台网页地址与后台Shell环境，让他去定位当前index.html在后台环境中的位置。或者点击前台的搜索按钮，结果报错500，让他去定位日志。这里作为培训者，可以先演示一遍，然后让其照着搞，并输出文档。
此处涉及到Chrome调试窗口的使用，后台cat/tailf/grep/sed等Shell命令，以及分析Stacktrace的能力，如果会vi就更好了(有很多人通过ftp下载到桌面然后用notepad查看，简直是拙急啊)
2.2. 模仿能力
模仿能力，也就是在现有项目的基础上，能够二次开发抄他人的代码。
2.2.1. 源码到最终部署是如何对应的
大部分项目都不能做到完全封装底层，很多码农都不知道代码位置与中间件，后期肯定完蛋。举个例子，比如Java代码如何对应最终war包，Android源码如何对应APK中的文件夹，前台如何静态化Angular，服务端JSP与Action，这些文件映射关系的掌握比学会这个技能本身更重要。
- 前台代码: 一般为HTML+JS，要求能够使用SFTP同步工具修改服务器中的代码
- 后台代码: 需要给各个入口打上debug，并掌握如何阅读日志，以及常见的Shell命令
此部分培训完成后，进度快的人就可以用sftp，甚至直接vi修改文件了，以后一定省心！
2.2.2. 写改删查
指能够使用函数式(ES6, Java8)操作对业务【写改删查】进行封装，此部分公司/项目组一般都有积累工具类，一般照着文档搞，并答疑即可。
值得强调的是，上面的每一个都要有交付成果，让每个人懂得求助是要有代价的，包括但不限于分享文档，小工具。懂得总结分享的人值得进一步培养。
培养到这个地步，一般需要半个月。主要目的就是以后出现问题可以自己定位，防止晚上一个电话叫你过来亲自背锅。
2.3. 自学/求助能力
指给一个Shell/Ant/Java代码，可以自己查资料去看懂。这个作为项目组织者，需要完善求助渠道，打通消息，比如
- 提供内网WIKI，文档地址，接口人同事等，引导出“搜索WIKI-求助同事-求助接口人-求助上游”的流程，避免出现伸手党。
- 培训者在完成培训后，一定要强制被培训者输出文档，并作为考评依据，写得好的文档就可以流传下来给下一波人使用，你自己也不需要耗费时间一对一重复培训了(这就是所谓的动态规划算法)。
3. 最终能力评价
本文比较特殊，是以培训为主，一个人带10多个人，而不是带3，4个人做项目。在这种情况下，主要就是与摸底能力进行对比，并进行划分与评级，打分权重可以参考其它组
举个例子，比如开始给了你18个人，经过两周的培训后，按照二八定律，可以选出
- 优秀的奋斗者：占20%～30%，能够跟得上进度，有自学能力，懂得求助，团队协作强
- 沉默的大多数：占70%～80%，能力平庸，但是挤牙膏催一催还是可以搞出来东西；或者技术吃力，但是仍然向上爬的；这样的都可以接受，毕竟工资低嘛。
- 糟糕的老油条：类似这样的培训班代码，以及不负责，没下文的，这样人的尽快用新人换掉
- 重复培训新人: 反复淘汰是一件很正常的事情，因此需要不断补充新人
我个人的权重是：在满足写改删查读日志等基本编码能力后，非技术能力越高越好，远高于技术能力。
风险管理
培训完成后，分配任务了，就要考虑未雨绸缪，提前做好背锅解决方案了。当遇到“锅”时，首先判断问题——需要加人数，加班与还是需要拉通？
1. 通过堆人数解决问题
说到堆人数干活，就不得不提人月神话了，书上说过堆人数反而会降低开发效率。不过在日常的开发中，工作量却是这样的流程：上级通过发布时间的deadline反推出工期，算出工作量，然后通过除法分给几个人去实现。
有些简单的问题通过加人就可以解决问题，比如前端按图抠静态网页，业务通过文档写改删查。但是很多问题是不行的，它取决于可以并行的比例，比如和第三方联调，某个复杂的前后端业务，改BUG等。
在多线程开发中，也有类似的定律: 就算不考虑线程调度损失(拉通/会议)的理想情况，它最终也是取决于代码中可以并行运算的程序比例，详见阿姆达尔定律
2. 通过加班救火
通过加班救火时，一般碰到坑了，而且新手无法搞定的情况。这种情况一般都还是可以搞定问题的，但是非常打击士气，一定要回溯追责与AAR，避免重复失误。
如何处理“能者反而多劳”的问题？
在实际项目中，有人出工不出力，有人挖出一堆坑。这是你和你优秀的下属前来救火，而挖坑的人反而早早下班。这时会出现“能力强反而要加班”这种反差，此时要
- 在能者多劳的情况下，要实现对应地多劳多得(分配考核指标优先考虑)，或者安排调休抵扣
- 能力不足者，如果是新人可以再给一次机会，并反思自己招聘/培训流程是否有误
- 如果是反复出现的老油条，就给他干杂活或者把他换掉
3. 推动拉通才能解决的问题(如何求助阻塞问题)
部门墙是大公司中强KPI考核下趋利避害自然而然出现的。任何人都是部门墙的扮演者——其它部门通过求助我加班少了，我这边加班就要变多。
那么都在部门墙难打开的现状下，如何处理开发中的阻塞问题呢？
- 选择比努力更重要: 优先争取到独立的，不依赖他人的工作内容，一步正确，后续轻松。
- 通过正规求助渠道: 虽然部门墙很严重，但是任何部门都对外有支撑渠道，比如issues, 内部群或论坛等，这些支撑人员的支撑记录将计入KPI考核的，他们自然乐意在这里进行回答
- 通过源码进行求助: 直接通过stacktrace去找到报错位置，然后看提交记录找到对方的开发者，这样定位速度一般非常快，配合1再提个issues后写个感谢，效果非常好。
- 通过领导上升: 及时告知风险，不要自己闷着
4. 如何了解项目进度
目前主流的方法就是邮件与晨会。
- 邮件/Rally等管理软件: 如何写邮件网上已经有很多所谓的“职场心得”了，但是实际使用我并不是特别认同。主要记住一点，要求成员汇报进度时不要有废话，要使用KPT原则(昨天干了什么，结果怎么样，今天打算什么)
- 晨会: 自己要作为主持人，以项目为维度，按照项目去提问“包工头”，并找出风险(比如技术，阻塞，发布等)，5分钟开完，剩下通过邮件分配任务
- 周报/日报: 其实这个我本身也不喜欢，它一般只用于培训期间，用来区分出工作态度。
某些开发组晨会能开半小时，所有人围一圈依次说自己干了啥，这样效率非常低，不推荐。建议自己直接作为主持人。
善于自动化DevOps
此部分需要专门选出一个人，给予他较少的开发工作量，而用来维护下面内容
1. 开发环境
开发环境不稳定，与生产环境不一致是个大痛点，需要单独培养1～2个熟悉Linux与Shell的专人去维护所有环境(大约10台)，并通过自动化保证环境与最终测试环境的一致性(rsync, sql备份等，可以直接硬编码Shell实现)
统一的Postman/Swagger等RESTful请求配置也很重要
2. 持续集成
持续集成，也就是CI，现在用的比较多的是Jenkins/TFS，它有着丰富的插件系统，而且本身体积也不大。网上已经有很多配置了，这里我推荐Groovy的DSL脚本插件，它显然比XML的信息量更大，而且跨平台方便维护。
3. 代码搜索
代码搜索主要是能够借助索引，实现代码的快速搜索，以方便新手进行抄代码。
代码搜索工具
- Intellij(可以搜索jar包)
- docfetcher(比everyThing好用)
- zipgrep/grep命令(在服务器上搜索，记得加上–color=auto)
4. 服务端Shell工具类
这里指自己封装的dotfile，类似于自己定制的myZsh，可以专门建立一个内源库，供小组内使用。比如日志、重启、搜索、同步等命令，可以通过alias或者function进行封装的。
此部分投入产出非常高，非常建议每个小组搞一个
通过上面的自动化配置，小组可以减少很多杂活，减少加班量。
上述的工具主要用于巨型卖盒子类型的项目，如果本身项目较小，可以考虑使用Docker封装配置
总结
对小组进行团队管理还是比较难的，总结如下
- 技能培训: 要明确公司提供的短期技能培训是选拔制，而不是培训制。选择与放弃才是最难的，一个人的能力与精力最多能带领培训3～6人，剩下的就是放羊了。
- 定位能力: 培训出成员的定位修复，自学总结，文档输出能力。作为组织者需要做好知识管理复用的工作，避免重复教学(类似于函数式编程中的记忆化)。
- 风险处理: 本质就是拉通推动，争取资源，需要按照“加人力”，“加班”，"拉通阻塞"三种维度处理风险。
- 自动化: 及时培养1～2名成员进行项目自动化建设，减小单点故障与加班
总的来说是一门很深的学问，目前还是按照代码工厂的管理方法，虽然已经有了很大优化，还有提高的空间
成果展示
与其它组横向对比:
- 通过首轮培训，并强制写文档/Wiki并审核，后续新员工不需要单独一对一培训
- 通过培训代码定位，并提供求助渠道，很多杂乱的问题不再需要亲自处理
- 通过提供DevOps自动化，转测节点因版本环境不匹配而导致通宵时间次数减少
最终小组相互对比，我所在的团队无效加班与主动离职率是最少的
回顾无效加班原因:
- 没有坚持代码审核: 众所周知，合作方写的代码功能虽然能用，但是很难维护。需要你与其它专业同事审查代码，并提出改进建议，这步非常耗费时间且不可用工具替代。在此项目中，初期抓的比较严(抓质量)，后面稍微放松一点(抓进度)，等到过点时才发现代码写的一团糟。
- 没有及时清理培训班/老油条: 上级领导按照(总人数*人天)分配工作，由于这边吃空饷的过多，凭空为他们多加了很多班。一定不要心软，及时释放人力。
6. 附录
1. 一些捷径与红线
大部分搞代码的管理者也都是普通人，下面是一些双赢的方法
要提高自己的知名度: 比如主动承担工作，主动负责包办某事，这样会影响上层的决策优先级。先不要担心自己是否多劳而“吃亏”了。现在的工作就已经决定了几个月后的KPI(提高自己不可替代性)。
要及时汇报进度: 项目进展/风险/转测试时抄送领导即可，点到为止。千万不要隐藏风险，隐藏风险意味着将有人通宵为你当冤大头，你可能以后再也没法接手重要的项目了。
要经常输出: 在项目中，分配时间输出文档，经验，小工具。即提高了团队整体技术氛围与效率，自己也有工作亮点(工作内容相同的两人，有输出的肯定更有亮点)。
要慎重提问: 提问前一定要自己尝试过，并给出自己的分析过程，然后把你的分析过程与问题一起向他人提问。经常这样随意提问会被扣上伸手党的印象
千万不要简历/学历造假: 特别是培训班的，这个下场就是被HR辞退，领导也保不了你，而且没有N+1。
2. 提问的方法论
关于提问，推荐用5WS来实现。
比如有人问我: 前台有个按钮点不动，那么你就要连续问多个:
Q: 在Chrome下F12看看是前台console报空指针还是请求报错？
A: 是请求报错500
Q: 哪个请求
A: 是查询余额的请求
Q: 重新请求看下后台日志
A: 是系统内部错误
Q: Fxxk，我当然知道是系统内部错误，我要看堆栈报错日志
A: 是XX行代码抛出来的，好像是拒绝接受空参数
这类问题就是所谓的挤牙膏，一定要纠正过来
3. 焦虑的中年码农
有很多中年同事刚为国接盘，背着房贷，住着城中村，过着9106的生活，一个月回一次家，身体一天不如一天。在工作上，技术逐渐脱节，陷入管理与电话会议中，却仍然不敢辞职，甚至不敢生病——因为在外边已经没有竞争力了，辞职后现金流马上中断。
某乎上有大V说程序员不是青春饭，我认为大V说的只是个例。大部分码农都是平庸之人做平庸之事，被榨成甘蔗渣辞退的人并不会有空在网上发帖点赞的。
我认为解决此问题的方法
- 投资(比如不动产，货币基金，国债)实现被动收入，降低贬值，并保证有现金流
- 一定要为自己购买重疾险(纯保险，不是那种余额宝的性质，这个日后我会考察一下)
- 随着IAAS与SAAS的发展，码农一定要在掌握中间件的基础上，能够将领域问题转为实际代码的能力。
- 如果技术(与业余时间持续投入)达不到顶尖架构高手，攒够钱后趁早转行或者转管理，出国考研，去艰苦一线等等。
- 作为IT从业者，每个年龄都有自己的最低要求，比如25至少要达到P6，30岁前至少能站稳部门，否则就被性价比更高的应届生淘汰了。
4. 技术还没深入就接手小型团队好不好？
因为【非技术】的管理占用了【纯技术】的工作，这样深入技术的时间就没有了吗？经过实践发现，的确是这样的，但是总工作时间基本没有改变。
- 作为负责人，白天不断地电话会议，推动争取资源，晚上加班才有时间写代码，能力变生疏是注定的。
- 深入研究技术本身就需要工作外的时间，也就是娱乐社交时间(程序员职业的必然性)。
看到这里，想必读者也有一个基本的印象了吧，我推荐每个程序员都积极尝试管理工作，对自己也有很大的收获。另外后续文章将接着讲项目人员工作内容分配，组织氛围建设，绩效激励，人力管理，以及个人品牌建设，金融基础等知识。