尝试create tech team

自从上一家公司之后，我很少有机会去带一些新人（公司一般都招一些技术独立性的工程师），特别是经验不是特别多的新小伙伴。在如今管理扁平化的公司，我正逐渐搭建自己的小team，并试图让团队成员快速融入并成长。整理了一下最近实践的经验，我采用的方式如下：

1.文档化

其实说这个文档化，相当一部分人是反感或者不屑的，每个人对这个项目或者一系列接口都是希望有详尽的文档，而当需要自己去写的时候就显得十分抗拒。但是当项目成员逐渐增加，当项目代码量和业务复杂度规模逐渐壮大，如果还是没有一份靠谱的文档来支撑，我想新来的研发人员应该会看着庞然大物一般的代码而笑容逐渐消失。

文档的好处，不必说能更快让成员有依据的了解代码逻辑，也是对写文档的人一次归纳总结的提升。当然文档也不局限于项目整理或者业务逻辑整理，也可以是一些工作流、代码规范相关的约束性的文档，这对整个项目的规范化和工作协同的一致性有着非常重要的影响。文档的形式也不仅局限于文字，也可以是图表，甚至视频。

我开始的时候还是采用尽可能文档化来让新成员更快了解现有项目，尽量做到可以通过文档独立（脱离人工引导）去熟悉项目的代码结构，敲黑板，划重点，并且留出一些预留的期望任务。对于不同的人可以从同一份文档理解不同层次的要求。对自己无要求或者要求不高的，我只能要求他能顺利fix bug，不会因为改动而影响到相关的功能或者代码块。对于一些有想法和能力的，我会提一些新的要求，比如去提前熟悉一些功能，试着去优化原有逻辑，甚至改造底层框架。

不同的人，不同的性格，应该用不同的方式去沟通，给予的预设期望也是不同的。不以物喜不以己悲，淡然地面对不同的人来人往。

我觉得最好看出一个人是否对代码严谨并有编码能力，就是从现有项目中发现不足且提出自己的想法。例如，我让w同学在熟悉项目后，试着去增加中间件支持到框架流程中（之前老项目缺失对中间件良好导入的支持）。也许有人会说，我平时根本就用不着去关心已经搭建好的框架，我只需要天天curd，天天copy paste之前的业务再改改，天天能跑通就得了。这可能就是有的人工作了三年还是用一年的经验去做事的原因吧。

2.代码规范

其实对于一些非静态类的自由度高的编程语言，比如:javascript、php等，由于语言本身的自由度和开发人员的水平不同，代码量和协同开发人数一增加，代码风格就很难统一，各种各样的写法会逐步蔓延到整个项目代码逻辑中。初期不管，可能只是辣眼睛，后期不管可能拖垮整个相关功能甚至项目。所以在早期的时候就要尽量规范代码，一起协商出一个通用性的代码规范，统一所有人的代码风格。

代码规范大致分成两大部分，第一部分是代码格式，第二部分是编程规范。代码格式php方面有code sniffer，nodejs则可以用eslint去做强制规范。至于编程规范可以根据项目之前的风格和一些通用性的规则来约束，比如变量名，函数名的可读性，通用功能的封装，面向对象的规范等等。

所谓：没有规矩，不成方圆。统一的好处在于工程师们能更好地理解代码，提高工作效率，减少不必要的误解。

 

3.规范工作习惯

 

这个内容认真讲起来几乎和“怎么成为一个优秀的工程师”一样宽泛，我这里主要是讲的解决问题和处理问题方式。比如我们往往在开发的过程中会遇到一些让人长时间阻塞的bug或者业务逻辑，我们是否总是选择死磕到底，耗尽deadline也没有找到确切的解决方案？

我个人的建议是给自己解决一个问题设置一个deadline，可以是30分钟，也可以是一个小时，由自己来定。一旦超过了这个期限，那么就必须果断去寻求帮助。有相当一部分工程师会觉得向他人寻求帮助是很羞耻的一件事，然而这通常只是face的问题，寻求外部资源和帮助是一个非常高效的解决途径。

 

3.属于自己的团队反馈

 

做产品或者运营的人是最能理解反馈的重要，同样的团队建设里面队员们的反馈也是不断改进的源头。我采用的是不定期地沟通，随时跟进各个小伙伴的进度，遇到怎样的问题，是否需要外部的支持。也会相互做一些头脑风暴，或者结对编程来解决一些单人局限思维的问题。在每周五也会有小组范围的review会，用来对本周或近阶段来总结反思。

人和代码一样，如果不定时地去review，也会在不知不觉地滋生一些bad smell。比如某小伙伴状态不太up，是否是给他/她分配的任务过于繁杂，是否是技术方面有倦怠感。在能力和资源所及的范围内尽可能让每个人找到自己所喜欢的事物，能在繁重的工作之余，也能有一些成长和收获。

 

目前我还在做更多的尝试，利用敏捷开发的一些原理，慢慢让自己和小组一起成长，变得更优秀。