《程序员》杂志：小公司如何建设技术中层

程序员》杂志：小公司如何建设技术中层

 

  从字面上看，CTO（Chief Technology Officer，首席技术官）有三层含义。首先，工作范围是技术部门；其次，工作性质是技术部门中的管理者；最后是技术部门管理者中的最高管理者。从这三个层次就可以明确CTO的主要职责：管理技术部门中的中层管理者，以满足技术部门的管理需求。因此，CTO应该避免几个误区，在公司内部为主，而不是以外包为主开展技术工作，外包是CIO的职责；通过培养中层管理者来满足工作要求，而不是在外部招募高手来解决工作问题，招募是HR的职责；预备适量的冗余人员规避员工的流动风险，而不是在减少员工、压缩成本的同时增加风险，平衡公司的风险与成本是CEO的职责。当CTO不再陷入上述误区时，就会选择通过培养中层管理者来建设技术团队，中层管理者是技术部门的“骨干”，是新员工的“模板”，是以“敏捷”方式工作的主体。本文尝试分析小公司技术部门的工作特点，向小公司的CTO提出一些建设技术中层方面的建议，并分享几位CTO的成功经验。

有价值的人≠“骨干”

    如果说CTO是技术部门的“大脑”，那么中层管理者就是技术部门的“骨干”。CTO的工作离不开“骨干”，因为CTO也常常会误认为有价值的人就是“骨干”。

　　外聘“高手”不会成为“骨干”。大多数CTO都是先成为技术高手，然后被提拔为CTO，因此，CTO常常会有一个思维惯性，会认为技术部门的价值来源于“高手”，所以在负责技术部门之后，会花费相当的时间和成本在招聘“高手”以及稳定已经到岗的“高手”。然而，在实践过程中会发现这样做效果常常不尽如人意。“高手”的数量相对较少，而且目前仍有大量的IT公司缺乏胜任CTO的人选，因此“挖”来的“高手”会常常被“挖”走。所以CTO对于“高手”应尽量采用临时聘用的方式。

　　“不稳定”难以培养成为“骨干”。目前IT人才的流动性相对其他行业明显偏高，在中小型公司中，年离职率常常会超过30%，因此IT部门就需要一定数量的冗余人员来避免离职造成的困扰。对于基层组员来说，通过冗余人员能减轻员工离职造成的困扰，而对于组长来说，每个组长都在负责某一方面的工作，互相之间难以直接替代，因此当组长离职后，通常是在该小组的成员中，提拔新的组长，此时，整个小组的工作都会受到严重的影响。因此选拔“不稳定”的组长时，短期上能创造价值，但是在长期上会造成更大的损失。

　　5年前创办清北DIY俱乐部的清华大学学生叶炜，在创业之初曾力邀清华大学电子系的硬件高手担任技术总监，但时间不久就离职了。之后转变了经营思路，5年后的今天不仅规模达到了30名员工，而且自创的“清北”品牌在北京各大高校科研院所有了相当大的影响力，而与此同时大多数学生创业花费很大的精力和财力邀请专家高手，反而夭折了。

“骨干”从哪里来？

　　既然有价值的人不一定都会成为“骨干”，那么CTO也就会有这样的困扰：“骨干”从哪里来？

　　按“职业规划”任用“骨干”。在提拔任用组长时，首先需要了解候选人的职业规划。越来越多的人才会给自己设定职业规划，然后寻找相应的工作。因此，在技术部门内部选拔时，也需要了解其职业规划，应当让职位尽量符合候选人的职业规划；当职位和职业规划不一致时，既便能胜任新的职位，也应当充分征求候选人意见。如果职业规划的目标是其不能胜任的职位，则应当延缓任用。

　　“少年老成”是“骨干”的重要特征。虽然直接任用年长的员工为组长是比较常用的做法，但是从长期上看，年长的员工获得进一步晋升的可能性也更大，如果公司难以满足其职业需求，年长的员工反而会“不稳定”。因此应当寻找“少年老成”的组员作为组长的候选人，他们担任组长的时间将会长得多。创造自由发表意见的渠道是判断“少年老成”的有效方式之一，对于那些能提出独到见解而又能付诸实施的组员，则可以作为组长的人选。

　　从开源社区中寻找适合的“骨干”。虽然不必外聘“高手”，但是CTO还应多参与开源社区，目前的软件开发过程中越来越多的使用开源软件，因此CTO参与开源社区不仅能获取所有技术的前沿进展，还可以通过观察发现开源社区中的活跃用户，寻找自己所需要的人才，例如在XOOPS开源社区中，就经常有活跃用户被采用XOOPS技术的公司招聘，入职后很快就成为技术骨干。

“骨干”不是“大脑”

　　在任用“骨干”之后，CTO就会面临另一个问题：“骨干”该做些什么？

　　将“不可能完成的任务”留给CTO自己。技术部门的工作有着较为严格的时间约束，同时在工作中还常常有很多不可预知的情况，如果将所有任务直接分配给组长，那么CTO就只有在进度延误时才会知道组长无法完成某项任务，如果碰巧是关键任务，将严重影响整体进度。因此CTO在每件任务面前，都需要考虑这样一件事：这是属于“大脑”的任务，还是属于“骨干”的任务。而且对于已分配的任务，CTO还要和组长逐项核对是否有把握完成，对于组长没有把握的任务，CTO应采取重新分配、外包或者亲自处理。

　　将“成就感”留给“骨干”。职业规划、物质财富和成就感是员工跳槽的几个重要原因，职业规划和物质财富受到技术部门实际情况的制约，难以满足每个员工的需求，因此成就感就成为避免组长跳槽的重要手段。CTO在各种场合中，都应尽量把决定权留给组长，一方面组长是小组的直接负责人，他的判断代表了小组的判断，另一方面，参与决定的过程还会让组长产生责任感，进而通过完成任务而获得成就感。

　　协助“骨干”实现职业规划。在“成就感”之外，CTO应协助组长实现职业规划，积极讨论职业规划有助于让CTO了解组长适合的工作内容。在实践中，一方面由于CTO的工作繁忙，另一方面直接的上下级关系难以了解真实的想法，此时可以考虑外聘专家负责这项工作。例如，某资深技术培训顾问长期协助中小IT公司CTO进行这项工作，不仅减轻了CTO的工作压力，而且为减少了公司对组长的直接物质激励支出，提高了成本竞争力。

和“模板”创建“文档”一样培养新员工

　　现代企业在工作中离不开办公软件，而技术部门更会有大量的文档工作，为了便捷地制作文档，避免重复劳动，都会将经常使用的文档类型制作成模板，而现如今的办公软件也都支持了模板功能。当办公软件刚出现的时候，还没有图形界面，即便这样，已能令使用者欣喜若狂。而现如今，不支持模板功能的办公软件在现在是不可想象的。

　　IT行业的人员流动性大，因此培养新组员迅速胜任岗位就是技术部门的主要职责之一。新组员进入工作状态的速度越快，在控制技术部门风险的前提下，技术部门为员工流动而预备的冗余人员就越少，也就为公司降低了成本。在工作中，与新组员接触时间最长的就是组长，所以不仅组长要承担新组员的培训工作，还要在工作中为新组员树立表率。通过组长树立表率来带动新组员就像用“模板”创建“文档”一样，制作一个模板不会直接创建文档，但是会大大加快未来创建文档的速度。同样，对组长的培养也会大大加快新组员胜任岗位的速度。

　　CTO通过组长培养新组员时，首先要从招聘开始，让组长自己负责招聘新组员，和应聘者联系，安排面试等等，对组长充分放权。在招聘后，对于培养新组员的所有任务，都尽量由组长亲自执行，CTO应发挥自己的管理经验优势协助组长完成培养工作，而不是技术优势。既要相信组长通过自身的努力能够覆盖新组员所需要学习的技术，也要随时发现组长在培养新组员时遇到的各种问题，协助组长完成培养工作。

　　通过授权组长培养新组员，可以让新组员感受到自己的职业规划受到公司的重视，建立组长与新组员伙伴式的忠诚关系，还能及时发现组员的离职倾向。在实践中，为了进一步减轻组长的工作负担，可以选用基于知识管理的开发套件，例如TechExcel DevSuite，组长通过工具就可以将当前组员的知识归纳整理成新组员的培训资料，就像用“模板”创建“文档”一样简单。

“敏捷”的组长

　　敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。由于机构组织形式的千差万别，技术部门要按照所属机构的特点进行组织，所以常常不能采用敏捷软件开发的工作方式，但是在技术中层的建设上，却可以充分借鉴敏捷的原则，既使技术部门在整体上采用其他的工作方式，敏捷的原则仍有助于改进组长间的工作配合。

　　“以交付而不是构造为核心”，组长要树立交付意识，理解自己承担的职责是交付工作成果，应当把构造的工作分担给组员，在交付工期紧张时，应当首要选择临时扩充小组规模的方式分担工作量，而组长的注意力则集中在交付有价值的工作成果，如果组长将精力投入在分担工作量上，则可能仅按照最开始的工作计划交付工作成果，而不是有价值的工作成果。

　　“面对面沟通”，组长要时刻准备着面对面沟通，在任何需要沟通的情况下，组长就应当直接和其他组长面对面沟通，必要时召集更多的组长以及各自小组的组员，以期在发现问题的同时就解决问题，如果组长到每周的工作例会时才提出这些问题，那么不仅延误解决问题的时间，而且其他的小组可能需要重新审视自己的工作内容。

　　“迭代交付新版本”，在交付周期上，CTO应授权组长自行决定迭代周期，并随时按照其他小组的需要交付中间迭代版本，减少因为小组之间互相等待新版本而耗费的时间，以期减少预先制订计划的负面影响。如果小组按预先制订计划的时间交付新版本，那么不仅其他小组会因为等待而浪费时间，而且会影响交付前的迭代次数。

　　在实践中，清华大学Web与软件研究中心CTO王津先生通过借鉴“敏捷”的原则，把全职和学生松散结合的团队打造成了“紧凑而自我组织型的团队”，把自己从日常的协调工作中解放出来。