管理的主要职责就是管人、管事、管优先级，只要能达成目标就算合格的管理者。管理一个技术团队、一个商务团队甚至是一家公司，这都是基本要求，不同的管理者会有不同的管理方法，对不同的团队管理方式也会不一样，今天我以个人经历和理解聊一下技术研发团队的管理中关键因素有哪些。
为什么说技术团队的管理跟其他的会不一样呢？做个简单的对比，对于商务团队来说，管理者不停地对他们洗脑并且以足够的物质回报来刺激，这个商务团队就能嗷嗷叫。但技术人员要单纯得多，需要让技术人员对公司所做的事情产生认同感，然后很大一部分技术人员是考虑我在公司能否学到新技术、团队氛围是否轻松融洽、办公环境是否人性化等等，甚至办公电脑是否为Mac都会成为技术人员做选择的一个因素。
一、团队建设——招聘和培养
技术管理在管人上，就是团队建设，如何招聘和培养技术成员。技术人员的招聘跟普通商务人员是不太一样的，我记得在壹康复的时候，我们的HR说招聘市场、商务人员太容易了，基本上我们制定出了人员规划和业务需求之后，HR小组能在一周之内组建一个20人的合格市场销售队伍，因为很简单把规则讲清楚，去干就行了，看结果说话，销售的结果非常好衡量。制定的业绩目标和淘汰策略，有足够的新人加入，完全可以按业绩进行讨论替换，确保业绩目标的达成。
技术人员就没那么容易。
首先是技术人员的薪资相对市场销售人员较高，而且基本是底薪制，无法像销售人员那样很低的底薪加提成。也就是技术人员的成本高，同样是三个月试用期，一个市场销售人员业绩不合格带来的损失就是他的底薪，而一个技术人员不合格，三个月试用期的底薪成本就已经很高了。
其次技术的岗位非常多，常规一个满员的技术团队不同的岗位就有几十个，对于初创团队基本上是一个萝卜一个坑，招聘的时候就得非常仔细了，因为如果招聘到不合格的技术人员到只有一个人的岗位上，那么这个岗位的质量不合格，整体软件产品就会出问题的，跟前面那条有对应关系，不合格的时候产生的沉没成本非常高，再重新招一个在时间上的损失非常大。
因此招聘技术人员会更困难，很难短期内组建完整的团队，需要明确岗位职责和对候选人的画像，可以看到很多招聘网站上对技术不同岗位的JD要求，会写得非常细，但在面试的时候，不仅仅要看这些硬杠杆，还有很多软性的东西需要通过面试交流过程中去把控，以及要看出来候选人的实际能力跟简历上写的是否一致。我面试过太多的技术高级岗位的候选人，很多都是简历很漂亮，但实际能力跟简历描写的相差甚远，如果是非技术人员来面试把关，很多都根本问不出来的，一旦招进来损失就更大。（可参考我的另一篇文章：如何避免创业过程中技术相关的“坑”？）
技术人员招进来之后，除了要让他认同公司的目标和理念，更重要的是要给他成长的机会和空间，大部分技术人员选择一家公司，成长是最大的因素。我在创业的时候招聘过一个技术人员，他有4年的工作经验，在上一家公司就是被用作一个技术人员来完成任务的，也没有人管他，老板只是要求结果，他自身能力其实很不错的，做东西速度特别快，但因为没有好的团队和Leader，自己也不知道该怎么走，只是觉得给的待遇还不错。我跟他聊完后知道他内心的想法，而且当时我发现了他的几个毛病，如果这些毛病不改正，就是他成长最大的障碍，而且这几个毛病会对团队和产品带来较大风险的，我当时跟他明确说了这几个问题，而且明确说我能帮他解决这些问题，他也被说服了同意加入，当然待遇上会比他之前的公司低不少（大概低了30%左右）。当时我把这个想法跟CEO沟通的时候，CEO是强烈反对的，说人的习惯是改不了的，我再努力也很难去改变一个人。我说按市场价来说，这个是非常合适的，而且我有80%以上的把握帮他改掉这些毛病，可以在半年之内成长为合格的高级工程师。经过我的游说CEO也同意让我试试，说就给三个月试用期时间，如果达不到要求就赶紧换人。结果如我所愿，这位同学在几个月内“改邪归正”了，成长非常快，半年之后CEO就同意给他加薪到原公司的标准，现在是一家估值过十亿的创业公司技术主管。
二、达成公司的目标
不管何种团队，都是必须要有自己的目标去完成的。技术团队也一样，对于互联网相关的企业，技术产品是核心的东西，这块达不成公司要求的目标，那么对于管理者来说就是不合格，任何解释都是惨白的。技术跟商务不一样，逻辑性和产出都是很严谨的，1就是1，2就是2，来不得半点虚假。因此管理者要带领团队达成目标，是容不得半点伪装的，可能当时无法察觉，等到察觉能力不行或者进度落后的时候，就已经晚了。
作为技术管理者，首先需要做的是建立研发管理制度，明确目标和确定计划，根据业务和技术的综合来管理任务的优先级。制度规范在确立的时候不能太教条化，要考虑团队的实际情况和环境因素。
在研发管理上，很多CEO都希望能有量化的考核方式，毕竟管理团队总是要有评价的，怎么才算做得好呢。研发工作还真的很难量化管理，都是从结果上来看好坏。但问题是如果研发过程没有管理好，结果基本上都是不好的。我见过CEO要求研发团队出绩效报告的，要求按照每个人写的代码行数作为重要考核指标的，只能说是很无知。我也能理解他们这么做的原因，因为很无助。
在壹康复的时候整个团队的目标都是能做到思想统一，还是要看谁的绩效好谁在偷懒不是。我们制定了一套积分制度，根据团队协作、个人质量、团队贡献等不同的维度进行打分，有加分有扣分等各种规则，为团队鼓励的行为加分，不鼓励的行为扣分，从而能得到较为公正的正态分布排名，这个排名将作为最终绩效考核的重要参考依据。
积分制度的规则举例如下：
1、每次项目结束后召开项目总结会，会上所有参与同学投票这次项目中做得最好的30%人员，A类项目每位积分+2，B/C类项目每位积分+5
2、按要求组织召开需求评审、测试评审、设计评审之后，仍旧有需求变更、设计变更的，产品经理积分-1，项目积分-1
3、项目没能按时提测，每延迟一天，开发责任人积分-2，开发主管和产品经理积分-1，项目积分-1；
4、冒烟测试每打回一次，开发责任人积分-5，开发主管和产品经理积分-2；
5、每次项目结束后，测试组出具的测试报告中，开发责任人名下的reopen累计次数超过2次将被扣除积分，从第3次到第10次，每增加1次积分-1，从第11次开始，每增加1次积分-2
6、每次项目提测并冒烟一次性通过，产品经理及全体参与开发的同学都将获得积分奖励，A类项目积分+2，B/C类项目积分+5；
我们总共设置了将近30条规则，而且针对这个规则做了积分统计系统，系统会自动根据研发过程管理软件中的数据进行加减分计算，自动算出每个人成员的得分和排名，基于这种方式我们做到了量化的绩效考核，整个团队都会朝着我们鼓励的行为去行动，而不鼓励的行为就得想办法去避免。
三、跟技术人员沟通
好的技术管理者肯定是技术线出来的，比较容易理解和懂得技术人员的思维和想法，一般来说沟通不会有太大的障碍，但日程管理中会碰到很多非技术人员跟技术团队的沟通，例如产品经理、业务方甚至是CEO都会直接跟技术团队沟通，提出需求等，这个时候最大的问题是非技术人员无法评估需求的难易程度，而普通技术人员的沟通能力不强很难将技术难易程度用通俗易懂的说法给他们讲清楚，这里的矛盾就会产生而激化。作为技术管理者，就必须要对这种情况做到心中有数，如何去解决每个人有每个人自己的思路和方法，这里就不展开了。
举个例子就是非技术人员跟技术人员沟通要注意的点。例如CEO说收费用户和免费用户看到的内容是不一样的，要做好区分。如果仅凭这个需求给到技术人员，那么做出来的东西是无法理解和使用的。而要想办法使用技术人员看得懂的语言，将收费用户看到的内容和跳转的步骤一一写下来，甚至使用原型页面的方式，清晰地表达清楚才可以。这些活在现在的互联网时代，是由产品经理来干的，所以产品经理其实是非常苦逼的一群人，夹在CEO/业务方和技术团队之间，很多时候会有生不如死的感觉。当然做得好的产品经理就非常有价值，而且非常值钱。
能做好产品经理的人，真的是非常厉害，我自己打心里敬佩的一群人。
以上是我自己经历和感受非常深刻的几点，关于技术人员的选、育、用、留也是一门艺术，后面我专门针对这几个方面来写几篇我的感受。
你在跟技术人员沟通的时候，是否也碰到过无法理解的时刻？欢迎留言来一起探讨。
