我脑海中的优秀技术团队

当一个开发纠结于本身作的一些初级实现的事情的价值时，不如多思考对于团队和业务的价值。

文中的“我”，其实不是一个单纯的角色，它可能会包含多层含义，不论是我做为一个团队的管理者，仍是我做为一名技术团队的普通员工，都会对本身的团队有一些期许，一些定义，一些要求，而这就是今天咱们要谈论的话题。但愿这些思考可以对管理者或者求职者有些帮助。

 

团队的首先组成就是人，那我理想中的技术团队中的人应该是怎样的呢？做为团队的负责人，其实对于人这方面的把关我一直是很是严格的，对于进入到我团队里的成员，一般须要有如下品质，这就是我对技术人的理解。

1.好奇心。

你为何作技术？一些人是为了糊口，一些人只是不知道本身能作什么，而另一群人，则是由于好奇心，对未知领域的探索，用技术来作不少神奇的事情，例如炫酷的动画？碉炸的算法？人工智能？游戏？物理引擎？漂亮惊艳的页面？想一想你是否是由于这些技术而义无反顾的冲入编程大军的。我以为这种编程才能持续的作下去，而不是捞一笔就走的心态，或者想着靠编程实现财务自由。有些同窗在作技术一段时间以后，会开始迷茫，我以为这时候回过头去看看你的初衷很是重要，若是你的初衷是平庸的，那我以为你不适合作这行，若是是你的初衷是用技术探索应用价值，那我以为你能够顺着这个思路想想你的如今的价值点在何处？

 

2.锲而不舍的学习。

 

我面试的时候一般会特别关注这一点，有时候若是实在看不到一我的对于持续学习的热情，我甚至直接生硬的问对方，“你业余时间会作些什么跟技术相关的事情”，而后获得的回答，一般是“看书”“看论坛”“看源码”。其实这就是敷衍了事了，这些事情只是一个程序员最基本的一些学习方法，我其实想知道的是，你是如何“持续学习”的，你看过一篇文章以后，对于其中涉及的一些知识点，你如何去强化？如何去实践？甚至如何引入到工做中来？你的工做或者是项目都作得平平无奇，那你看书看论坛都是在看什么呢？看了以后又解决了什么问题？

3.分析解决问题的方式。

最基本的，你在遇到技术难题的时候，如何解决？google？爆栈网？这些是最基本的，你如何判别一个解决方案的正确性？你如何一步一步分析问题？如何debug你的代码？而后，解决问题以后，你作了什么思考？是不是你的知识面有问题，须要系统补充下某个方面的技术点？你是否研究了它周边的知识？写一篇博客，备忘顺便分享给网友？这里又涉及到知识管理的方面。总之每次遇到问题其实都是一次对你的知识面的扩充时机，最终这些都会变成你的经验。在工做多年以后，这些潜移默化的知识会让你可以快速对一个问题做出判断，会在你脑海中造成一套体系，帮助你快速分析和解决问题，不论是你的方向是架构师，仍是业务leader，都须要这些能力。

一般，你作事的方式态度，就决定了你的将来。

为何咱们须要一个团队中的成员具有这些素质？最终目的都是经过这些细节发现一我的的潜力：好奇心决定了你能在技术这条道路上走多久；学习方式决定了你可以在这条道路上越走越高；而解决问题的方式则决定了你可否造成方法论，成为一位真正的资深工程师。

除了上述的三点，对于团队中的人，做为一名普通员工，我还指望有这些关键字：

• 乐于分享，让我能够被动扩充知识面；

• 和蔼真实，不为人情世故操心专心作个写代码的美男子；

• 牛逼哄哄，让我大开眼界的牛人那是最好不过的，光听那些名词就足够我出去吹半天了，对于开阔思路视野有奇效；

人知足需求了，接着讲我理想中的团队是什么样的第二部分：事。

1.团队是否在朝着一个更好的方向成长？

我见过不少团队，基本没有“管理”。所谓管理，不是说有个老大管着你，指挥你作这个作那个，而是你这个团队是否有“目标”“规划”“预期”。就如最近面试的一些比较优秀的同窗同样，他很是关注咱们团队的“管理”，会提出一堆关于此方面的问题，这就是他对团队的一种期许，你的团队是单纯的实现业务？仍是有所规划？你理想中的团队架构是如何的？人员分配如何？技术栈如何？规范如何？流程如何？如今有何不足，做何改进？这些其实就是对“管理”的拷问。一个有管理思路的团队，经得起这些拷问。而这些拷问，其实关注点主要就是你的团队是在健康成长，仍是放养或者原地踏步？若是进入没有方向的团队，恐怕自身的成长也不会有大的进步。

2.团队作事方式是否规范？

近一年，我对团队管理最大的方法论也是指导方针，就是规范化。这里的规范化有几种含义。

• 代码规范，这个不用多说，最基本也是最容易达成的，方法能够有eslint等，加上按期的代码review，以及团队内的规范文档等。

• 方法规范，如何引入新技术？多人开发如何进行？如何保障代码可用性？如何保障发布安全？如何有效利用日志？等等，这些问题都须要造成方法论，有一套流程来保障。例如引入新技术，咱们须要 调研试用 - 产出优劣报告 - 产出脚手架 - 多人review脚手架 - 分享+文档 - 新项目试验 - 问题总结分享 - 优化 - 全面投入使用，过程当中会要求一些产出，目的都是为了评估好优劣，而且造成一套规范，而不是随意引入一些不可控的技术。上面说起的其余问题，咱们都会造成本身的一套规范，落地分享和文档，跟踪执行。这就是团队规范的方法论。

• 流程规范，一个需求如何产生？如何评估其用户价值和可行性？如何进入开发手中？如何排期？是否有完善的项目管理流程？测试发布如何进行？一个团队的开发若是是乱哄哄没有标准秩序的话，开发会很累，这些实际上是项目经理的职责，从开始对需求的把关，到产品经理的把关，到交互视觉把关，到技术方案排期评估，到联调跟进测试发布。作好不易，作很差你们就会很累。

规范化的最终目的，一个是提升开发效率，另外一个是确保团队开发的可持续性，减小“坑”出现的概率。这些问题一般是创业公司技术团队的通病。

3. 共同成长和价值定位

以我团队为例，最近在作一个事情，全公司公用组件的开发，这个事情我不许备让负责架构的同窗去作，我将其分解为两部分： 架构组的事情：制定组件规范，制定脚手架，把关代码质量，出标准组件的实例，推进计划进行，文档和组件索引网站等。 业务组的事情：根据架构组的周边和规范分工实现组件。

我但愿经过这样的分工达成两件事情：架构组发挥其做用让事情朝着正确的方向前进；业务组的每位同窗都能知道一个标准组件是怎样产出的，都了解npm是如何管理组件的，组件的周期维护是如何的，更经过严格的review经过制度来让你们共同成长。 能够看到这件事情的三个意义：一，让你们共同成长；二，你们各司所致，找到本身在整件事情中的价值定位；三，事情自己推进了团队开发效率，这是其最基本的价值。

做为一个我的，其实对团队的指望大致还有：

• 有足够的挑战，有机会接触各类问题并解决以此得到经验积累。

• 团队承认个人价值，而不是把我当成工具来使用。

• 团队有足够的成长空间，对本身有个清晰的定位。