团队建设

 
 

介绍

做很多事情，都是需要一个团队的。我主要介绍的是如何才能打造一个有自己文化的越来越好的软件研发团队。这里涉及到了三个问题：为什么需要打造、什么是团队文化、好团队的标准。


 
 

 
 

打造

首先，我不认为花钱把一堆人招聘过来，然后每天拼命地加班干活，就算是一个团队了。尤其对于新组建，或者是队伍中新加入的成员比较多的情况，“团队建设”就是一件非常重要的事情。对，我认为团队是“建设”起来的，而不是“买”来，更加不是通过“伞兵空降”来的。而建设这个词，大家应该多少有点认识吧，绝非是一朝一夕来的——即使是3D打印技术也是要一个一个部件来打印的。

一把好剑，是打铁匠一锤一锤地用心打造出来的。这样的剑，锋利无比；这样的剑，能在关键时刻发挥应有的作用；这样的剑，是受众人的肯定的。一个好的团队，同样是需要Leader带领每个成员一同打造的。这样的团队中，每个成员之间都不仅仅是工作和任务的关系；这样的团队中，每个成员都是有其重要的位置；这样的团队中，每个成员都尽可能快乐地得到成长；这样的团队中，每个成员都是在积极主动地向前奔跑；这样的团队中，自己的文化不会丢失。

每个年轻的团队，都会有很多值得改进和提升的地方。而什么的团队，是我这里说的“年轻”的团队呢？某个公司成立十年，而某个项目组又是从一开始就存在的；这样的团队就一定不是年轻的团队吗？我这里的“年轻”更加强调的是——幼稚、没有形成自己的做事风格。每个团队，都会有人员的变动；如果变动的过于频繁，也是“年轻”的一个体现。这里简单地引入一个思考：如果一个新加入的成员，效率或者态度让人有点不满意，那我们该怎么办，直接抛弃呢还是任其发展呢？

 
 

文化

什么是文化呢？这个问题很难回答，只能是谈一点自己的认识。有自己文化的团队，并不需要依靠公司制度、强制加班等等生硬的东西来改造成员。文化应该是能够在团队中每个人的一言一行中传播的，是熏陶出来，不是加工好的。

强迫大家每天加班到很晚是一个件非常自私的事情（排除公司制度要求的情况），这完全是Leader害怕完成不了项目而出的下下策。在绝大多数情况下，必须通过加班才能搞定的事情，其实不加班也能搞定。那么，你有没有反复地思考这个问题呢？怎么样才能不加班就把“活儿”干完呢？

如何才能做到团队成员之间沟通交流都比较Open，想要说、敢说、会说意见或者建议。这是Leader每天都应该思考的问题。没有了平等、积极的沟通，团队就是一潭死水。

 
 

标准

每时每刻，每人都应该在积极主动地思考：如何才能进一步提高工作效率（我这里的效率，当然是建立在高质量的基础上）。这是我所认为的好团队，这样的团队不是只会搞定上面分配的任务，而会有团队内部的沉淀，是有自己文化的团队。

对团队成员整体研发素质的提高，减少木桶效应带来的问题。是Leader或者团队中的技术达人所值得思考的问题。自己能够在不断地成长，很简单；能带领整个团队一起成长才是件有挑战的事情。

让大家的基础技术能力、意识保持在一个比较均衡的状态。

利用一个工具来来做到能对团队成员的技能分布有个清晰的认识。人类之所以伟大的一个特点，就在于学会了使用工具。工欲善其事必先利其器，没有一整套高效率的工具的支撑，那么你的团队还处在并将长期处在原始阶段。

 
 

测试人员

测试人员不能仅仅停留在手工测试，看功能能不能完成、有没有页面上的错误提示等。

程序或者系统、工具，开发完成后，都是要实施的，仅仅把功能测试完成并不算结束。在实施和运维的阶段，也可能会出现很多问题。所以，我的想法是要让测试人员提前介入到这些阶段。

测试还要对系统的部署过程进行测试。例如：要学会安装程序、数据库使用、服务的启动和停止等。

系统运行起来后，最好要查看日志文件中是否有不应该出现的异常、报错，浏览器控制台是否有错误信息，是否有无法加载的js、css、image等资源。

 
 

开发人员

很多开发人员，只知道Coding，对Web应用部署、Jenkins持续构建工具、Linux操作系统等都不了解。这是非常不应该的——如果连自己写的系统或者程序都不会部署，怎么能说的过去呢。

 
 

资产沉淀

对一个团队来说，一定会有很多资产需要持续地积累、沉淀，包括：制度、开发规范、项目文档、技术资料等等。那么用什么形式来维护比较好呢，word是我不推荐的一种方式。

我维护过的一些帮助文档，有一些是非常大的，可能会有几十甚至上百页，每次修改都是很痛苦的。除了它的笨重以外，还有很多致命的缺点：无法多人协作、难以进行版本维护、难以检索。经验证明，难用的文档就约等于没有。wiki这种web的形式就是非常好的，还可以生成多种格式的文档。

 
 

分享

在团队中，每个人的具体职责不同，所专长的领域也不同。我们应该逐渐建立起来成员之间热衷于分享的精神。

对于开发人员来说，每当解决一个较大模块的问题时，就可以给其他人做个分享。第一，可以检验自己对这个问题理解的是否够清楚明白；第二，其他人再次遇到这类问题时，就可以减少不必要的重复劳动，当然会提高效率。

更多有关分享的介绍，请参考《Java开发成长之路第七年》。

查看原文：http://surenpi.com/2017/01/01/team_build/