【心得体悟】第一次带团队 - 组织篇
需求
我们组的项目是 Java Based 的，其中使用了很多 Python 脚本以及 Shell 脚本。那么需求来了： Pyhon 目前开发和生产都是2.6.6版本，需要升级成3.7.9版本。
有以下几个难点：
- 自己单独开一个小队伍，带两个新人上手该项目。角色有所转变，从冲锋陷阵，变成统筹指挥。
- Python 脚本总共有约100+个，有一些是常用的，有一些是不常用的甚至是不用的。需要一个个进行分析。工作量大。
- Python 2 -> Python 3 升级中可能遇到的坑。
这一篇先说第一个点：带队伍。
快速上手
我们的项目本身非常复杂，新人上来啥也不懂直接埋头栽在一堆文档里面容易有挫败感。（并且文档也没有做得很完善，有很多已经过时了）
所以，我一上来安排了几个 session 专门给他们讲解：
- 系统的架构（常见的业务场景）
- 开发的流程（开发工具和基本使用）
- 测试的流程（如何部署各个模块并运行，监控）
- 未来的发展方向（接下来我们会做些什么）
除此之外，在日常的工作中，我也会提供指导与帮助：
- 搭建开发与测试的环境
- 配置需要的权限
经过大概1~2周的时间，新人终于差不多上手可以接一些活了。
在分配任务的时候，我特意挑了一些非常简单的活。并且，我自己也做了一部分，“打了个样”给他们作为参考。这样，实际上大大减轻了他们上手的压力。他们可以通过快速完成任务，积累经验。这也激励他们进一步深入了解系统。
另外，我还额外地要求他们在开发的同时进行完善文档的工作。因为这一方面对团队有益，另一方面也有助于新人学习过程中记录总结。
透明化
透明化，英文是 transparent 。这一点很重要。
举一个反例，大佬A派发下来一个任务X，小头目B不把X透露给开发C, D, E，而是把X拆解成y1, y2, y3，分别交代下去。这样等项目做完了，小头目B拿了头功，而开发C，D，E只是做了零散的工作。
关于这一点，我还有很多要学习和探索的。目前，我实践的原则是：尽量保持信息100%传达。比如，项目组未来的计划 planning ，里程碑 milestone ，表现 performance ，或者是对组员的评价 review 等等，都尽可能地让他们知道 / 参与讨论。
团队决策的时候需要有人最终拍板，但是这个过程中每个人的意见都需要得到聆听与考虑。
传授
做为一个开发，需要对技术更新保持高度敏感。
而作为一个技术出身的 leader ，更需要有前瞻意识，不断磨砺自己的技术。如果发现组员哪里有短板，想办法帮助他补齐。（站在组员的角度来想，每天勤勤恳恳地做事，一是为了绩效和奖金--钱，二是为了能学到些什么--能力。）
所以，分享知识一方面可以有利于他人，一方面也督促自己不断进步。
举例来说，一开始配置环境的时候，我给他们配了一个新的 Linux Server ，但是没有装 Python 3 。我让他们自己装一下。
过了一会，他们跑过来说， Python 3 装不了，试了以下的命令都不行。
$ sudo apt-get update
$ sudo apt-get install python3.6
$ sudo dnf install python3
“不行”的原因有两个:一是我们 dev 没有 root 权限（汗...），二是apt-get命令没有装。
为了解决，我做了两件事：
- 发邮件给 company server team 让他们去这台机器上装 Python 3。 （走流程，比较慢）
- 自己上 Python 官网下载 source code ，然后手动 build 安装。 （依旧没有 root 权限，但是可以暂时先用着）
经历过这个，我的组员以后出去，就不会说 Python 安装不上了。
激励
我理解的激励很简单，就是要把组员做的好的地方大声地说出来，让所有人知道。
举个例子，第一周结束，组员们把开发环境基本上设置好了，这个东西，说大不大，说小不小。但是鼓励很重要，我会在周五的 scrum meeting 上着重提一下这件事，并给与正面的评价。这样，也是给他们信心。
过了一段时间，两个人都熟门熟路了，这个时候，还是要夸奖，我会这样说，这一周，组员某某某完成了task 1, 2, 3，很棒。完了发一个总结的邮件给全组并抄送大老板。这也是告诉他，你的所有表现我都看在眼里，记在心里。（开发最害怕的事情之一，就是白干活，出了大力气老板没看见，慢慢地积极性就消耗没了）
启发
启发，英文是 inspire 。这一点比较难。
我理解有两层：
- 启发组员，做到他能力之外的事
- 启发组员，做到你能力之外的事
第一层还好，大不了手把手教一遍。第二层，真的是很难。
具体到实践中，可以适当给予组员自主性，给一个任务，但不要限制他具体怎么实现，说不定会给你惊喜。另外，对于某些任务，可以只从大局出发，宏观思考整个系统，而细节处放心让组员去实现。
举例，在脚本更新过程中，我发现有很多脚本的 path 都是 hard-code 的，甚至是把机器的名字也写死了。这样，换一台机器就完全不工作了。于是，我把这个问题提给了组员，看看他们有什么方法。
最终，形成的解决方案如下：
- 分析所有的脚本，统计并收集有类似问题的，写一个 list 出来
- 根据这个 list ，具体问题具体分析
- 有的脚本调用处在其它系统，修改运行参数不易，我们就设置一个 default 值
- 其它脚本调用处在我们自己系统的，统一改成传入参数模式，并在脚本上注释清楚传参的格式
- 补齐 Unit Test ，保证所有改动过的脚本测试通过
在这个例子中，我提了一个 open questions ，留了很多发挥余地给组员，而他们也没有让我失望。超出预期地完成了任务！
