技术部门 Leader 与团队那些事

不知不觉中，已经进入IT圈子五个多年头了，短短五年，却是人生最美好的五年，这五年中经历了塞班的没落到消失，经历了移动互联网的兴起、疯狂到理性发展，这五年中也接触了太多的人，形形色色、稂莠不齐，有行业的顶级大牛，也有工作八九年却只有两三年经验的水平。带了几年团队后，才发现的发现，即使你是千里马，如果不能遇到你的伯乐，你可能一辈子都是拉车的骡子。

1、招人过程中的一些要素

这几年中，当面试官和被面试都好多次，总的来说，在我面试别人的时候，能方便他人都会尽量去方便，面试过程中，尽量营造一个轻松的气氛，比如聊一些别人的强项，总是抓住别人薄弱点不放，把气氛搞得很尴尬，真的没必要，我所在的团队，需要招的可以是偏才，我并不在乎是不是全才，就算是钻研多年，也不可能做到样样精通，而我自己，薄弱的地方也很多，这些都是很现实的事情摆在眼前，能帮忙多争取点薪资，尽量去争取了，直白点，在不压薪资的基础上，在争取多一点薪资，队友会更加努力的工作，更有激情去完成每一次挑战，再说了，老板能接受15k一个月，一般17k也是能接受的。

接下来就说下在组建团队的过程中，我所关注的点。

· 逻辑思维

为啥我把逻辑放在招人第一位，而不是首先看技术。没有一个好的逻辑，代码会显得杂乱无章，工作中，比较反感一类人，看到需求文档拿过来就写，不懂的人看到这情况，也许会觉得工作效率好高，实则不然，这样的代码，通常是很难维护的。如果仅仅是某个功能写错了，出了bug 很容易去修复，但是一旦逻辑出问题了，这个灾难可能是灭顶的，大到整个功能可能需要推倒重做。在没理清思路的情况下就去写代码，当发现文档没读清或者中途部分需求改变的情况下，边写边添加、修改功能，几次迭代，再想使用的时候，发现已经没法维护了，当队友想使用这块内容的时候，发现修改的成本远远大于重构，这就给团队带来了不该有的麻烦，严重拉低了效率。

建议：理清思路的方式有很多，如果功能确实很复杂，推荐先画图，一图胜千言。

· 沟通能力

谈完了逻辑，接下来会是看技术吗？非也。在我看来，如果没有一个好的沟通能力，谈吐不清，会给队友或者其它部门同事带来很多不必要的麻烦。一个简单的功能，说的不明不白，协作者也是一种痛苦，一个好的谈吐能力，可以营造更加高效的工作环境，同时也能营造更好的气氛，使得身边人更愉快的工作。相信在日常工作中，因为没表达清楚造成一些不必要的麻烦，这肯定是一个普遍现象，而不是个例。

之前同学在微软的时候，有一句话他们那边经常提到，“绝大部分的失败，都可以以归咎于没有沟通好”。

· 团队精神

说到团队精神，这是我三年多前开始带团队和招人的过程中一点点学会的，或许这是我来上海后，第一家公司领导对我一个比较重要的影响。真有那么重要吗？这是肯定的，有一次招人，面试过程中，面试者的技术、逻辑都很好，谈吐说不上好或者不好，那时候没关注那么多，直接就是一轮技术面试，面完了后就给领导汇报，领导又下去聊了一会，回来就找我谈话，觉得怎么样？我说技术还挺好，领导又问了一句，那别的呢？瞬间懵逼，我们找技术，不就是看技术吗？别的指的是啥？领导和我说了一句话，“如果他加入，可能会影响到团队，很难融入我们的团队中，我们要的不仅仅是技术过硬，团队更重要”，就这么简单的一句话，我却思考了好久，是的，我们不是一个人在战斗，不能因为一个不合适的人影响到整个团队的氛围。

后来带团队而过程中，我也时常把团队放在首位，我们是一个团队，不能因为仅仅站在自己的角度考虑问题，该提取的要提取，该抽象的药抽象，完成自己的同时，尽可能方便他人，公共类和父类的修改，不可以影响到别人的功能，更不能因为自己使别人产生不必要的闪退。尽可能把代码的可扩展性、可维护性、可重用性、灵活性做得更好，高内聚低耦合，细节决定成败，只会写功能的，那只是码农，处处为团队考虑的，那是最起码的领袖气质，不想当 Leader 的程序员，不是好的工程师。

· 技术能力

好了，终于谈到了技术，这块放到最后，并不是说不重要，这要看公司要招的职位了，如果仅仅是招初级开发，只要掌握基础就可以了，没必要问得太深入，如果一个一年工作经验的，架构设计的很好，那何必还要招一些五年及以上的，反过来说，用五年经验的或者三年经验的去要求工作一年左右的，这有点扯淡，招人没诚意。有了扎实的基础，学东西事半功倍，下层基础决定上层建筑。对于中级，可以适当问一些设计模式，或者平时所用到的一些优化或者处理问题的方式，当然，基础也必须扎实，不管哪一阶段，基础都是重中之重，这个是硬性要求，决不妥协。对于高级或者资深，根据对方的强项，一个问题可以探讨个大半小时，从表面到底层、从应用到源码，问题不在于多而在于精，还有就是一些解决问题的方式，多个解决方案，那种最优。

· 补充

我在招人的过程中，一般都是按照以上几点去招人，像那些故意用一些项目中用不到的技术来压工资，这些方式都是无耻的，比如有的项目，现在和以后都用不到蓝牙开发，却不停的问一些蓝牙的协议，何必呢？一个非音视频的产品，不断地问 FFmpeg，真没必要。码农何必为难码农。每一个来面试的人，在没有被pass掉之前，都可能会成为你的队友，该怎么去处理这层关系，这对于团队以后的发展是很重要的。

2、对于接手新项目的一些判断

这个标题可能有点歧义，我想说的是入职新公司，接手公司之前的一个项目，对于自己来说，这就是一个新项目。

对于这个问题，其实讨论的就是重构和再利用的这层关系，在分析源码后，在过完项目需求后，在排期出来后，对于新接手的项目，到底该重构还是再利用，这是做为 Leader 该慎重考虑的问题，如果直接推倒重做，那之前的很多工作就会随着项目的推倒而付诸东流，可利用的代码也会少之又少，甚至几乎都用不到了。这其中还要考虑到团队的作战能力、时间的紧迫性、推倒重做的可行性。如果不推倒重做，在原有基础上的维护，成本会不会大于推倒重做的成本，项目上线后的维护是不是灾难性的。

去年在联想控股的时候，接手一个供应链金融的项目，这个项目在我来之前是两个非 Android 同事写的，虽然这两位同事代码质量都是非常高，水平高但不一定能写的好，因为他们是站在非 Android 的基础上考虑问题的，也是在非 Android 的基础上写的代码。入职的时候，只有一个半月的时间，要做一个大版本，采用封闭式开发，团队是新组建的，几十页的需求文档，评审就过了两天，金融项目本来逻辑就很复杂，从业务经理到最后的放款，角色有十几个，从申请贷款到最后提货或者逾期平仓，这个过程中的状态也有十几个。之前负责的同事也和我做了简单的沟通，建议在原有的基础上在开发，毕竟之前一些功能还是可以用的，而且大家都是新来的，对我们这批新人的不放心应该也是有考虑的。是的，在原有的基础上开发，这个方式确实比较稳当，但稳当的背后是需要付出代价的，在顺利完成任务后，后期出现了很多不该有的bug。封闭式开发后，接下来的版本，时间没那么紧迫，对项目又一点点的进行了重构，这个过程也是挺痛苦的。

对于后来的这些痛苦，并不认为是当初判断出了错，在那样庞大的需求面前，不了解同事的情况下，只能求稳避险，让项目按时上线才是第一要素，对于后来的一些重构，封闭式开发结束后有更多的时间去优化和重构代码，充分利用好这些时间，项目代码还是可以达到高质量的水准。

再后来来到这个新公司，也是接手一个新项目，一个新的团队，之前的代码看了下，对于新版本来说，完全可以干掉重做，之前的项目代码量太少，质量也差强人意，在这之前，一直在修复bug的过程中，在这个基础上继续开发，得不偿失。虽然又是遇到了封闭式开发，但这次做出的决定和上一次完全不同，直白点说，就算我一个人单扛这个项目，虽然有压力，但也是可以按时保质完成的，为了以后更愉快的开发，这次不再是求稳避险而是稳操胜券，选择了重构，对于这次的选择，至今依然觉得对正确的，几个队友也觉得比之前写起来更舒服。

总结：对于新接手的老项目，到底该如何选择去留，这并不是看心情所能决定的，一旦判断错误，这将可能是没日没夜的加班，根据需求，合理的把控时间节点，给自己多几分把握。对于新团队，可以通过平时聊天和观察队友的长处与短板，合理安排任务，对项目进度事半功倍，顺利取得按时保质的上线。

3、对于队友的培养和提高

“闻道有先后，术业有专攻”。这几年带团队过程中，有刚入行的小鲜肉，也有工作四五年的世外高人，有激情澎湃的激战分子，也有功力深厚却混吃等死的小伙伴，再说了，不可能每个团队里面的人才都是一个样，各有所长是很正常的现象，对于每个不同的团队，做为一个Leader该如何去提高培养和提高同事？

队友的培养和提高，不仅仅是技术上的，有些团队的技术大牛远远强于 Leader，这也是非常常见的，然而作为一个合格的 Leader 也不仅仅有过人的技术，还有让队友俯首是瞻的气质。

· 对于新手的建议

对于新手，此时处于萌芽阶段，最主要的就是指明一个方向，比如面向接口编程而不是面向实现编程，比如六大基本原则熟记在心，比如不要重复造轮子。对于一些事故多发地带，适当提醒下，即使不小心入坑了，也能快速找到原因并从坑中爬出。在项目时间宽松的时候，可以多给新手点机会，哪怕类似的功能，不同的人思考的方式是不同的，随着代码量的提升，使用的实现方式也是不同的，采用的架构设计也会是不同的，新手很需要代码量的提升，此处说的代码量是思考后的代码，不包括单纯的复制粘贴。

对于新手，个人不建议早早接触太多高深的技术，稳扎稳打才是正确的方式。在没有熟悉一门语言之前，没必要多门语言同事学习，一旦不经常去写，很容易被遗忘。虚心接受过来人的建议，并不是每个人都有必要去指点你。

· 进阶的建议

有些工作好多年的，同样一个功能、流程，已经走了好多遍，比如注册、登录，都是大同小异，达芬奇密码下面是啥？当然是达芬奇验证码了。对于这样的队友，代码量还是挺丰富的，应该把更多的时间放在源码分析、性能优化、架构设计。对于登录、注册，资深和新手写出来明显是不一样的，新手会把更多的时间放在功能的实现，而作为经验丰富的你，是否更应该把多考虑可扩展性和灵活性，比如以后增加了第三方登录了，比如增加了邮箱登录了，是否可以在不改变或者几乎不改动原有代码的基础上，无缝添加这些新的功能，而不是一味地修修补补，最后迫不得已就重构。在对接一个第三方的时候，比如接了百度地图，当日后需要用高德地图替换掉百度地图的时候，是否可以做到一键替换？

学而不思则罔，思而不学则殆，边走边看，边看边思考，高效的代码是90%的时间在思考，10%的时间在coding，把修改bug的时间用在思考，而不是日后的修修补补。

· 资深的建议

这个阶段，应该更好地提高其它编程语言，或者提高技术之外的能力，往往通过一门语言去达到登峰造极的程度，这是很难的，一门语言所接触到的编程思想毕竟有限，可以通过更多的技术来学习更好的思想，从而大大的提高编程效率。现在很多语言建也是相互借鉴，最初的时候，微软的C#更多的借鉴java的一些编程思想，但java的响应式编程和lambda又是从别的语言借鉴而来。

在这个阶段，技术之外更有必要去提升，比如带新人、带团队，我算是比较幸运的，在工作不满一年的时候就开始带新人，工作不满两年的时候就开始主导项目，现在想起来都觉得惭愧，自己啥都不会的情况下，公司就赶鸭子上架，哈哈。虽值得欣慰的是，每任领导对我的工作还是比较认可的，因为接触带团队比较早，作为过来人，对于早期的问题或许会更加清晰一点，经过几年的积累，更加游刃有余，知人善用，方可事半功倍。

对于工作多年没带过团队的朋友，在合适的时机，可以主动请缨，毛遂自荐，机会是留给有所准备的人，在这之前，逻辑思维、表达能力、团队精神和技术能力都需要得到公司的认可，公司也可以更放心把团队交给你，这也是我为啥招人的时候，非常看重这几点，我也希望有一天我的小伙伴离开团队出去找工作，都能独当一面，成为当前公司的技术型管理。

· 补充建议

人们经常说程序员是青春饭，或许这句话是没错的，也经常看到XX公司35岁后被辞退，不管这新闻是否属实，我们都应该未雨绸缪。coding是不能一辈子的，61 岁的 Java 之父 James Gosling 在 Facebook 上发表了他所遭遇的年龄歧视：“通常我们不招你这种年龄的程序员，但你的情况特殊（指的是他 Java 之父的身份），所以对你特殊考虑。”做为程序员，我们未来的选择无非就是从技术转管理、创业或者转行，到底该怎么选择，这将根据自己的兴趣爱好和需要，在此不做阐述。

4、发现问题与解决问题

对于一个 Leader，发现问题这是很重要的，这将包括产品问题、团队问题、代码质量问题，下面将分别阐述。

· 产品问题

曾经一个朋友跟我说过一件面试中的小事，一个技术官问他：

甲：“你是怎么定位自己的？”
乙：“我在上家公司的的offer是资深开发，在公司是团队Leader”。
甲：“我问的是你怎么定位自己？或者说，你是把自己定位成开发还是开发加产品”
乙：“抱歉，这个问题我之前没考虑太多，平时开发中，我更多的时间关注的是代码质量和用户体验”

对于以上的事情，我相信这是一个很普遍的现象，细节，真的决定着成败，站在产品的角度考虑问题，更有助于理清产品思路。之前在过完需求后，第一时间想到的就是我该如何去更好的实现这个功能，从程序员的角度出发，这是没任何错误的，但是从一个 Leader 的角度出发，这就是一个错误。

· 团队问题

这个问题，片面点说，这就是一个民主与集权的问题，因人而异，对不同的人不同的对待。工作中的队友一般分为两种，一种不指派任务就会忙自己的事，看书、看新闻、逛帖子，一种是做完事情后主动请缨，能否为公司、为团队多做一点，从而更快的提升自己，对于第二种，这样的队友很容易打理，可以实现过度民主，因为他知道自己该干嘛，会竭尽所能去多做点事，对于第一种，如果在项目进度宽松的时候，可以适当民主，每个人都有自己的爱好和业余生活，拓展一些其它技能也在所难免，在项目紧张的时候，过于民主可能会影响公司进度，因人而异，因地制宜。

· 代码质量问题

这个嘛，之前写过一些博客，分析了为什么有些人不适合重构代码，杂乱无章的写法，重构后不久，可能又面临着无法维护，还需要再次重构，恶性循环，当误了时间，降低了效率。做为 Leader，很有必要制定一些准则和规范，对于字段的命名统一规范，对于一些必要地方的注释，一些不必要的地方滥用注释，好的命名方式，可以减少很多不必要的注释，过多的注释或者错误的注释，会严重影响开发效率，误导他人或者自己。接下来就是一些可重用的代码，方便自己也方便他人。

对于代码质量，我认为应该不定期的 review，对于新加入的同事，可以抽出更多地时间去审阅代码，指出一些不足和不规范。对于一些老队友，在时间充足的情况下，可以互相审阅，互相批评指正，互相学习共勉，达到共同进步。

5、结尾

最后我想说，作为一个团队的Leader，别拿自己当回事，其实就是一个打杂的，团队内各种琐事都需要去处理、去沟通，有功一起分享，有事自己扛。作为一个团队的Leader，真不能不把自己当回事，因为你的一个行为判断，这可能会影响一个团队的运作。做好眼前事，珍惜眼前人。

6、推荐

• 第一篇：勿忘初心，继续coding
• 第二篇：编程路上，送给处于迷茫中的你和自己
• 第三篇：编程路上，对于迷失者的一些小小建议
• 第四篇：如果不从事编程，我可以做什么？
• 第五篇：给最真的自己加上static final

---

微信扫我