文中的“我”,其实不是一个单纯的角色,它可能会包含多层含义,不管是我作为一个团队的管理者,还是我作为一名技术团队的普通员工,都会对自己的团队有一些期许,一些定义,一些要求,而这就是今天我们要谈论的话题。希望这些思考能够对管理者或者求职者有些帮助。
团队的首先组成就是人,那我理想中的技术团队中的人应该是怎样的呢?作为团队的负责人,其实对于人这方面的把关我一直是非常严格的,对于进入到我团队里的成员,通常需要有以下品质,这就是我对技术人的理解。
1.好奇心。
你为什么做技术?一些人是为了糊口,一些人只是不知道自己能做什么,而另外一群人,则是因为好奇心,对未知领域的探索,用技术来做很多神奇的事情,例如炫酷的动画?碉炸的算法?人工智能?游戏?物理引擎?漂亮惊艳的页面?想想你是不是因为这些技术而义无反顾的冲入编程大军的。我觉得这种编程才能持续的做下去,而不是捞一笔就走的心态,或者想着靠编程实现财务自由。有些同学在做技术一段时间之后,会开始迷茫,我觉得这时候回过头去看看你的初衷非常重要,如果你的初衷是平庸的,那我觉得你不适合做这行,如果是你的初衷是用技术探索应用价值,那我觉得你可以顺着这个思路想一想你的现在的价值点在何处?对于这个问题,前几天我发的一个朋友圈挺有代表性,这里贴出来:
2.持之以恒的学习。
我面试的时候通常会特别关注这一点,有时候如果实在看不到一个人对于持续学习的热情,我甚至直接生硬的问对方,“你业余时间会做些什么跟技术相关的事情”,然后得到的回答,通常是“看书”“看论坛”“看源码”。其实这就是敷衍了事了,这些事情只是一个程序员最基本的一些学习方法,我其实想知道的是,你是如何“持续学习”的,你看过一篇文章之后,对于其中涉及的一些知识点,你如何去强化?如何去实践?甚至如何引入到工作中来?你的工作或者是项目都做得平平无奇,那你看书看论坛都是在看什么呢?看了之后又解决了什么问题?
3.分析解决问题的方式。
最基本的,你在遇到技术难题的时候,如何解决?google?爆栈网?这些是最基本的,你如何判别一个解决方案的正确性?你如何一步一步分析问题?如何debug你的代码?然后,解决问题之后,你做了什么思考?是否是你的知识面有问题,需要系统补充下某个方面的技术点?你是否研究了它周边的知识?写一篇博客,备忘顺便分享给网友?这里又涉及到知识管理的方面。总之每次遇到问题其实都是一次对你的知识面的扩充时机,最终这些都会变成你的经验。在工作多年之后,这些潜移默化的知识会让你能够快速对一个问题作出判断,会在你脑海中形成一套体系,帮助你快速分析和解决问题,不管是你的方向是架构师,还是业务leader,都需要这些能力。
通常,你做事的方式态度,就决定了你的未来。
为什么我们需要一个团队中的成员具备这些素质?最终目的都是通过这些细节发现一个人的潜力:好奇心决定了你能在技术这条道路上走多久;学习方式决定了你能够在这条道路上越走越高;而解决问题的方式则决定了你能否形成方法论,成为一位真正的资深工程师。
除了上述的三点,对于团队中的人,作为一名普通员工,我还期望有这些关键字:
•乐于分享,让我可以被动扩充知识面;
•和善真实,不为人情世故操心专心做个写代码的美男子;
•牛逼哄哄,让我大开眼界的牛人那是最好不过的,光听那些名词就足够我出去吹半天了,对于开阔思路视野有奇效;
人满足需求了,接着讲我理想中的团队是什么样的第二部分:事。
1.团队是否在朝着一个更好的方向成长?
我见过很多团队,基本没有“管理”。所谓管理,不是说有个老大管着你,指挥你做这个做那个,而是你这个团队是否有“目标”“规划”“预期”。就如最近面试的一些比较优秀的同学一样,他非常关注我们团队的“管理”,会提出一堆关于此方面的问题,这就是他对团队的一种期许,你的团队是单纯的实现业务?还是有所规划?你理想中的团队架构是如何的?人员分配如何?技术栈如何?规范如何?流程如何?现在有何不足,作何改进?这些其实就是对“管理”的拷问。一个有管理思路的团队,经得起这些拷问。而这些拷问,其实关注点主要就是你的团队是在健康成长,还是放养或者原地踏步?如果进入没有方向的团队,恐怕自身的成长也不会有大的进步。
2.团队做事方式是否规范?
近一年,我对团队管理最大的方法论也是指导方针,就是规范化。这里的规范化有几种含义。
•代码规范,这个不用多说,最基本也是最容易达成的,方法可以有eslint等,加上定期的代码review,以及团队内的规范文档等。
•方法规范,如何引入新技术?多人开发如何进行?如何保障代码可用性?如何保障发布安全?如何有效利用日志?等等,这些问题都需要形成方法论,有一套流程来保障。例如引入新技术,我们需要 调研试用 - 产出优劣报告 - 产出脚手架 - 多人review脚手架 - 分享+文档 - 新项目试验 - 问题总结分享 - 优化 - 全面投入使用,过程中会要求一些产出,目的都是为了评估好优劣,并且形成一套规范,而不是随意引入一些不可控的技术。上面提及的其他问题,我们都会形成自己的一套规范,落地分享和文档,跟踪执行。这就是团队规范的方法论。
•流程规范,一个需求如何产生?如何评估其用户价值和可行性?如何进入开发手中?如何排期?是否有完善的项目管理流程?测试发布如何进行?一个团队的开发如果是乱哄哄没有标准秩序的话,开发会很累,这些其实是项目经理的职责,从开始对需求的把关,到产品经理的把关,到交互视觉把关,到技术方案排期评估,到联调跟进测试发布。做好不易,做不好大家就会很累。
规范化的最终目的,一个是提高开发效率,另一个是确保团队开发的可持续性,减少“坑”出现的几率。这些问题通常是创业公司技术团队的通病。
3. 共同成长和价值定位
以我团队为例,最近在做一个事情,全公司公用组件的开发,这个事情我不准备让负责架构的同学去做,我将其分解为两部分: 架构组的事情:制定组件规范,制定脚手架,把关代码质量,出标准组件的实例,推动计划进行,文档和组件索引网站等。 业务组的事情:根据架构组的周边和规范分工实现组件。
我希望通过这样的分工达成两件事情:架构组发挥其作用让事情朝着正确的方向前进;业务组的每位同学都能知道一个标准组件是怎样产出的,都了解npm是如何管理组件的,组件的周期维护是如何的,更通过严格的review通过制度来让大家共同成长。 可以看到这件事情的三个意义:一,让大家共同成长;二,大家各司所致,找到自己在整件事情中的价值定位;三,事情本身推动了团队开发效率,这是其最基本的价值。
作为一个个人,其实对团队的期望大体还有:
•有足够的挑战,有机会接触各种问题并解决以此获得经验积累。
•团队认可我的价值,而不是把我当成工具来使用。
•团队有足够的成长空间,对自己有个清晰的定位。
结语
其实今天还跟大家讲,为什么做分享,很难做一些方法论或者是管理思路的分享?一个是因为还不够成熟,大家都在摸索;另一个重要的原因是,很多方法论其实就是一句话或者几句话,更重要的是执行到位,否则说出来都会很虚,但是团队到了一定阶段之后,一定要有目标和方法论,否则还是原始的行军状态,大家都会迷茫,内耗也会非常高。其实这些总结也是挺虚的,但是算是我内心对团队和人的一些见解。
深圳 · 龙岗 · 大运软件小镇22栋201
电话:400 182 8580
邮箱:szhulian@qq.com