技术团队管理
对于非创业阶段的公司，业务相对稳定，公司发展的目标、计划也比较明确，公司一般很重视产品技术团队的建设；在这样的环境下，研发团队应该如何发展呢？笔者准备从以下几个角度，来探讨技术团队的综合管理。
- 招聘
- 人员培养
- 团队文化、氛围
- 技术栈、技术架构
- 项目管理
- 晋升
招聘
每个公司对引入合适的人才，都逐渐形成自己的人才观和人事方面的方法论。大部分团队的负责人和leader，也接受过公司关于人才招聘方面的培训。我们如何去寻找到合适的人才呢？请看下面这张图。【来自百度百科：人才冰山模型】
对一个候选人，我们的面试过程，也是从这几个方面进行考察。稍微和上面有一些差异。
知识： 在专业知识方面考察时，需要注意的是让至少高于候选人两个级别的人来面试，从而能准确的评价候选人的知识。如果让低P的人来面试，很可能会因为面试官没听懂候选人的回答，而早早误杀掉。
对于技术团队，在知识上，一般考察的是算法、数据结构、常用技术栈和数据库等方面的、有一致理解的“知识”。
经验： 在考察一个人的经验时，首先看的是他的简历，这样能快速的对一个人的经验做出判断。这个“速读”不能很深入的理解一个人的实际深度；做过一个项目、使用过一个技术，做的好不好、专业不专业，是看不出来的。
在面试过程中，可以挑一两个中型的项目，让候选人用十分钟来说一下当时做的情况，使用的主要的框架、部分难点攻关的细节。
素质： 这里是很容易发生误判的一个环节。不同的面试官面试同一个人，对一个人的素质判断可能会差异很大。这方面我使用的方法，是聚焦一下关键素质，包括：智商（逻辑思维能力、结构化思维能力）、情商（情绪控制能力、感染他人能力）。
动机： 一个人的动机判断，在面试阶段很难判断的出来，我自己在这方面也做的不好。我会去看一下这个人是不是比较善良，眼神里透露的是不是纯净，判断他的心态、工作和生活态度；以此来估计候选的动机是不是正能量。【这也许是个很差劲的方法】
以上说明了考察的几个主要方面。那么面试过程中，如何有效的和候选人沟通，获得这方面的信息，以做出对候选人素质的判断呢？我认为最重要的，是让候选人讲出实际的case，举例和讲解他在以往工作里做出的实际行动、项目、技术。从这些实际发生的客观事实里，联系到知识、经验、素质和动机上来，以做出比较好的判断。
作为技术团队，对候选人的智商考察，是很重要的。技术工作有一定的智商门槛。这里强调一下，做技术工作，不是智商越高越好，而是过了门槛就好。到了实际工作里，只要智商达到一定水平，具体的工作贡献，和个人的情商、动机关联更高。工作做的更好、发展更快的，往往是那些情商更高的人。
招聘过程中，还有一个现象，就是在招聘压力比较大的时候，面试官或部门负责人，会一定程度上放水，体现在对候选人的要求降低，或对候选的定级上放松。这方面比较有效的实践，是做跨事业部复试，对候选人的能力、级别进行公司层面的拉齐。
最后，在面试中和面试结束后，如果有好的建议给候选人，也可以跟候选人交流一下。我的实践是，候选人一般都会对真心的、客观的建议表示感激，在HR回访候选人时，也会体现出较高的面试过程满意度。
人员培养
人才是选出来的，不是培养出来的。这是人才的一个基本理念。人才选拔招聘这一环节，是非常重要的。但是，培训依然非常重要。
培训的内容，不仅仅有专业知识、业务知识的培训，还有公司文化、环境的培训，还有公司的价值观的培训，培训的内容分类，可以说是丰富多彩。我比较喜欢贝壳的领导力培训体系，覆盖了招聘、绩效考核、团队管理等一系列的课程。薪酬绩效部分的培训，是当时的CHO郑云端先生亲自上阵，让鄙人受益匪浅。
培训的价值，我认为是把各式各样背景的人才，通过培训的方式，在某些方面（比如管理、价值观），形成一致的认识，能够让完全不同的人，能够按一致的方式来思考、处理某类问题。比如在招聘的理解和实操上，能够把公司的招聘策略、方法和要求，一致性的传达给所有的部门负责人、面试官。这对公司整体的人才选拔，有很大的助力。
在研发团队内，培训主要分成这几个方向：
- 专业技术培训
- 行业知识培训
- 技术分享
- 价值观培训
专业技术培训，主要是对技术人员进行一些软件开发、系统架构方面的知识培训。比如对微服务架构、DDD领域设计、大数据分析方面的培训。团队内人才结构按梯度分布，不同梯度的人才，所接受的专业技术培训，也是不同的。我们一般是在公司内部寻找专业知识培训资源。
行业知识培训，主要是对团队所建设的领域，进行知识培训。比如我现在贝壳负责的人事、财务领域，在2019年组织了几场系列的人事、财务专业知识培训，请我们的HR、财务总监，来给我们讲课。这样的行业知识，能够让技术团队在后续的工作里，更快的理解业务需求，做项目的过程中，及时发现一些专业问题。
技术分享，主要是团队内的技术分享。团队成员完成了一个项目，作为一种知识扩散和团队互相交流的形式，给大家讲自己做项目过程的收获、体会，使用的方法、技术。技术分享主要的目的，是增进团队成员之间的互相了解，互通有无；其营造文化氛围方面的作用，超过技术传播方面的作用。
价值观培训，主要是团队内对文化价值观进行交流。价值观这个事情，就得一遍一遍的说，说到团队能记住了，不知不觉的影响了自己的行为即可。具体的方式，是一遍一遍的讲价值观的事例，对模范事情进行表彰，对不符合价值观实践进行刨析。价值观培训是个持续的过程，一个慢慢影响组织、渐渐发生物理变化的过程。
人员培养不止培训，还有另外一个维度，对潜在后继人员、潜在晋升人员进行培养。对于部门负责人来说这是很重要的事情，就是在团队里发现那些具备后继任潜力、晋升潜力的人，提前通过工作任务安排、项目安排和技术攻关，来让他们加速提高。这方面我们的研发团队做的很好，每个研发总监都有、而且在培养自己的后继任人。
团队文化、氛围
对于一个规模比较大的研发团队（50～200人），团队的文化、氛围，对团队的正向发展，变得非常重要。我分为以下几个方面，来探讨团队文化和氛围。
- 技术民主的决策环境
- 适度自由的工作氛围
- 富有挑战的工作内容
- 鼓励创新的文化
- 积极互助的同事关系
技术民主的决策环境： 在技术栈选型、技术架构设计、技术方案评审方面，推崇技术民主的文化，支持任何人提出自己的观点、发表意见，并客观的评估提出的观点、意见，如果是更合适的、或是纠正现在的错误的，那就积极采用、支持落地，并对提出者给予公开的表扬。如果不采用，反馈不采用的原因，不得以批评、指责的方式打压提出观点、意见的人。
团队leader需要清楚的知道，在技术上，自己不一定是最强的人，甚至要引进技术比自己强的人，而和更强的人一起合作的方法，就是对对方意见和建议的尊重，采纳正确的方案。
即使是团队内技术不如自己的同事，因自己在设计上会有不完善或思考不周的地方，有纰漏和缺陷也很常见。审慎的对待每个提出的意见，尊重、感谢提出意见的同事，是避免出现线上大坑的有效方法。
民主的技术决策环境，体现的是对伙伴的尊重，对群体智慧的应用。
适度自由的工作氛围： 一般来讲，团队的成员请假，我基本都会批准。技术团队的加班加点是比较多的，在公司、团队的项目比较忙时，我们需要团队成员付出额外的时间是来投入工作；当员工遇到生活上的问题时，无论是生病、家中琐事、朋友来访还是亲人关怀，作为leader一样要给予方便。
有时部分同事为了安静的完成项目任务，提出在家“闭关”几天，我也会支持。项目的需求明确了，技术方案确定了，他自己的任务也清晰了，如果在家能够更安心高效的完成任务，减少上下班通勤时间，做到更好的交付，也是对公司、团队有益的。
当然，“自由”是适度的，是对那些平时工作积极、勤奋的同学才会是开始放的。这个自由，不能成为团队部分成员散漫的缺口，leader需要把握住。
富有挑战的工作内容： 对于做技术工作的同学来说，克服技术难题，实现以往自己做不到的事情，是个有莫大自豪感、成就感和快乐的事情。这种快乐，也许只有酒鬼遇到酒时，才能理解。【鄙人体会过前者，未体会过后者】。克服技术难题，做挑战性的项目，能激发起团队成员的斗志。
对于公司来说，对于能够完成挑战性任务的团队，自然也是另眼相看。但是做挑战性的项目，自然失败或延期交付的概率也高一些。团队的负责人在此时，需要及时的和公司沟通，同时积极鼓励团队加速攻关，而不是批评打压。
贝壳的UC系统，在 2019年上半年以前，稳定性只有2个9，A级故障频发。也被公司的技术委员会、合作团队多有诟病、评判。在我列入部门OKR、尚未安排启动时，我们部门的一个研发leader，已经自己组织了团队，每周六加班一天，用了2个月的时间，重构系统，把性能提高了10倍，稳定性达到4个9。
这样的创新、挑战行为，我是非常支持的，在年终的大会上，对这个项目和团队，给予了很高的评价。
一个没有挑战性工作的团队，是没有生命力的，优秀的人会逐渐流失。
鼓励创新的文化： 技术工程师团体一般比较年轻，思维活跃，敢于尝试，这是非常优秀的品质。对于他们在一些技术项目上，做一些“离经叛道”的尝试，应予以鼓励。但是对这样的创新的项目，团队的架构师和技术负责人，在确定能发布之前，必须严格的评审、review，防止给线上服务带来严重影响。
当前很多公司都在推统一的技术架构、统一的技术栈，以提高研发的效率。这是一个正确的事情，能够提高研发效率、交付质量、降低运维成本。但是同时也会带来相应的负面的影响，公司内对不同技术栈的研究不足，对日新月异的技术发展跟进不足。技术团队应该对新生事物保持好奇，保持探索的精神。
积极互助的同事关系： 作为技术团队，每天在公司的时间，一般都超过10个小时，也就是说，我们和同事相处的时间，大部分超过和我们的家人、朋友相处的时间。如果公司的同事之间，关系比较紧张，那么内心是很压抑的，在压抑的环境下，智力工作的效率是很低的。
作为团队的leader，需要主动去营造一个互助的氛围。积极和同事沟通，进行工作和非工作的交流，熟悉每个人的性格、特点、近况，做到即是工作上的leader，也是生活上的朋友。让团队内的气氛轻松，拉近团队的距离，让团队的沟通成本降低。
作为leader，尊重每个同事，欣赏每个同事，是和谐的团队关系的前提。曾经我一度误以为，严格的领导风格，对团队效率更高；对同事的缺点、项目的问题进行直接、严苛的批评，但是会逐渐发现，问题解决了，人心却散了。严格的批评、指责，是很容易滑向不尊重的，会非常伤害同事。后来我换了一个方法，在保持尊重和有礼的态度下，语气平和的指出问题和改进方法，团队成员表现出来的是更多的配合、感谢和持续提升。
技术栈、技术架构
很多公司都经历过技术栈、技术架构统一的过程，形成公司内研发组织统一的选型和强制标准。这是一个非常有利的事情，能带来以下好处：
- 在公司的不同团队、项目上，技术人员复用性更强
- 有利于公司在选定的技术栈和技术架构上，深入挖掘，形成自己的最佳实践
- 公司的运维体系统一，有效提高线上运维的一致性，降低运维成本
- 不同团队所研发的基础服务或组件，能够在公司内低成本复用
- 不同的系统之间，集成成本低，甚至相当“自然”
我曾经经历过一次合并收购的公司，使用的开发语言是PHP，而公司的主流开发语言是JAVA；引发了一系列的实际困难，最终用了一年的时间，才把技术栈切换过来。具体遇到的困难是：
- 收购的业务已经在线，已经有用户使用；因业务发展需要，新的需求和迭代，依然在不断发生。
- 对于新收购的业务，在人员扩充上，进入两难境地。一方面知道未来肯定要切换到JAVA语言，另一方面眼前只能招PHP的技术人员，来解决研发资源问题。当开发语言完成切换后，这些PHP工程师怎么办？
- 定级、晋升体系出现困难，由于PHP技术很少，在工程师定级、工程师晋升评审上，不好客观比较、匹配。
- 运维需要独立一套体系，不能融入现有的运维体系。导致线上故障的发现、处理效率，相对公司整体水平偏低。
对于这种困境，解决的过程也是很煎熬的，逐渐把新的服务开发向JAVA语言转换，过程中团队内PHP工程师安全感低，人员流失严重，团队文化氛围差；Leader需要做很多安抚和培训，对一部分价值观正、学习能力强的人，进行JAVA技术培训，以期以后能够转换到JAVA序列。
鉴于技术栈统一的优点，大部分公司发展到一定阶段，都会开始做技术栈的整合、统一，笔者认为此事非常正确。但是也需要正视带来的负面影响，采取一些行动，来降低负面影响。我认为负面的影响如下：
- 在人才招聘上，可能会因为候选人的技术栈不同，而错过一些优秀的人才。如果候选人的经验、学习能力很好，那么他是有能力用几个月的时间，掌握、切换到新的技术栈上；但是在面试时，因为面试官对于技术栈的偏好和熟悉度，很可能会降低候选人的表现和评价。
- 技术团队不能有效发现其他技术栈的优点； 团队对选定的技术栈钻研比较深，而对其它的技术栈、新的技术栈探索的比较浅，不能有效发现其他技术栈的优点，在当前技术栈逐渐衰老、退出行业舞台时，进行调整变化的节奏慢。
- 技术人员本身的技术视角的广度可能会受到限制，一些更有效、更优美的解决办法，会被错过。
鉴于这种情况，建议技术团队的负责人，在一些不关键的项目、工具上，允许甚至鼓励团队尝试一下新技术栈，但一定不要“传染”到公司的主要对外服务的线上系统里。保持团队的好奇心、创新性，留给技术人员接触、使用、和研究不同技术栈的“试验田”、“自留地”。
项目管理
自移动互联网爆发后，项目经理的岗位几乎在互联网里消失，项目经理的职责里，仅剩的项目进度跟进，被产品经理“兼职”了。2015年到2018年之间，项目经理的发展空间是大幅度萎缩的。以前高德CTO杨永琦说过，移动互联网就是要不断试错，不断把想法变成产品，推到用户那里，让用户投票，用户不用就下掉，用户喜欢就继续加码。
这样的背景下，产品迭代的速度，就成了各个互联网公司比拼的重要内功，甚至成为一种“竞争力”。能够让公司在还看不清楚的时候，就进行低成本的市场验证，进行“火力侦察”。用户的APP频繁升级，甚至成了提高用户活跃度的手段。这种背景下，重要的是产品经理又有了什么点子去让用户快速验证，只要撒对一个“idea”，用户就留存了，资本就欢喜了。
但是自2017年，王兴提出“互联网下半场”的节点后，“供给侧改革”为代表的B端服务兴起。项目逐渐变成需求复杂、交付周期长、质量要求高，产品经理的重心在需求的分析和理解上，在行业实践的探索上，而保障交付、保障质量的职责，重新回到了项目管理的维度上。B端服务的特征是专业知识门槛高、用户试错容忍度低、获客成本高，这些都为项目经理的重要性重新归来，奠定了前提条件。
我们团队自2019年重新建立了PMO团队，来跟进部门的项目，解决项目是否要做、参与项目各方的目标、资源、进度和交付问题。
项目管理第一个要解决的问题，是“项目值不值得做”的问题。 提出需求的部门、产品经理，必须能够讲的清楚，这个项目能给公司、用户带来什么价值，通过运营，最终实现什么样的结果。我们做了太多看似有用、实则可有可无的系统：有了没什么坏处，没有的话也没有什么痛。
项目管理第二个要解决的问题，是多部门、跨团队的协调问题。 大的组织里，每个部门都有自己的主攻方向和OKR（KPI），正常情况下各团队都以自己的部门OKR为重。这导致跨部门、跨团队的项目组织非常困难，由于目标、专业技能的不一致，项目的进展和实际结果，和开始的预期相差很远。项目经理必须能够清楚的理解项目的价值，并且传递给多个部门、团队的负责人，引导参与方对价值、优先级认知一致，在此基础上，制定出跨部门的整体计划来。
项目经理需要有足够的授权，如果项目经理只能是辅助角色，支持立项流程、跟进实施进度、协调各团队配合协作，那是体现不了项目经理的价值的。项目经理需要对项目的结果（业务结果）负责，以拿到业务结果为目标，组织公司的资源，实施项目过程。因此项目经理的人选，也是非常苛刻的，除了PMO外，项目经理大都是需求部门的负责人来兼任的角色。
晋升
为了给技术人员、除了管理这个“独木桥“外的晋升空间，大部分公司都建立了技术专业职级的制度，鼓励技术人员在专业能力上，持续发展、晋升。这满足了技术人员在职业上进行持续发展的需要，促进了技术团队的持续发展、稳定。
那么在技术人员晋升上，需要注意什么呢？笔者认为最重要的是公平性、公开性和看重直接领导意见。同时也要避开一个误区，那就是技术人员达到一个“级别标准”，即可晋级。（每次做晋升评审后，我在团队里进行晋升结果沟通时，都会遇到这样的情况，论实际的工作能力、掌握的技能，不比其他高级别的差，为啥有的人没有晋升成功呢？）
实际在各个公司的晋升评审中，可能每个评审官手里都一个职级能力标准；但是实际进行晋升评审时，往往只是作为“参考”。甚至到了最后阶段，是把大家打分的结果，拿出来“排序”，排序在前的几个人通过。这些情况反映了晋升评审的困难：到了一定级别，每个人的优点、个性都很明确，缺点也很明确，所做的工作内容可能差异也很大，不同领域的知识跨界很难，不同的人之间进行比较，要做到很客观是有困难的。
在这里，我需要重点提一下，晋升评审中，直接leader的意见很重要，每个人的能力、素质是不一样的，部分人就是不擅长言辞、临场发言（比如在下…），在晋升评审里，不能把自己的优点、做的东西讲出来。直接leader有责任、有义务通过更客观的数据、评价，提交给评审组，对他的晋升进行支持。
晋升是需要有比例限制的；一方面大部分公司的晋升和调薪都是挂钩的，出于成本的控制，有限制晋升比例的动力；另一方面，各团队都希望自己部门晋升的人多一些，如果没有限制，会出现职级晋升放水。
晋升政策上，还需要关注一个问题，部分员工做的贡献很大，但是技术（专业能力）并不是很强，或者因为所做的项目，是需求复杂性、行业知识难的项目，而不是技术有挑战的项目。这方面笔者倾向于支持行业知识要求高的候选人晋升、需求复杂度高的不晋升（主要专业能力体现在产品经理身上）；但是在绩效奖金、调薪上，应该对贡献大予以支持。不能因为晋升不成功，影响这些贡献比较大的人的调薪空间（目前很多公司在这两方面，是进行了绑定），从而影响这些人的稳定性，形成谁都不愿意做的“黑暗系统”。
