|
高速成长的创业企业，经常不过几年时间，就从三五条枪扩张到几十、几百人甚至更大的队伍。其间的项目尝试和取舍，用我一位同事的一句玩笑话形容颇为恰切，“像UFO一样，不知道什么时候来，也不知道什么时候走”。这是创业成长型企业的常态，也要求研发团队具有能力柔性，可快速应变。 CEO，特别是非技术出身的CEO，往往希望技术团队尽善尽美。优秀技术团队的词典里没有“做不到”，只要无止境地要求自己。然而，哪怕是很小问题的解决都需要时间和精力，甚至创造性。因此，一个合格的CTO（首席技术官）应该与CEO、业务团队达成共识：今天能付出、愿意付出多大代价，解决多大的技术问题。创业早期的CTO应有的核心追求是：让公司技术实力、研发效率、研发质量或研发成本管控，与同业相比有优势。一定要去思考和寻找，到底哪个（些）要素作为优势更靠谱，对公司和业务更有价值。 早期：绝不浪费 规模小，资源极度匮乏，人力资源严重不足—三五个人，未必认识技术高人，认识也未必愿意冒风险加盟……这是创业企业，特别是互联网业成长型企业早期最基本的特征。在此阶段，CTO的基本思路是把团队的力量用到极致，绝不浪费，哪怕某个人只会写文档。 CTO要让技术团队明白，公司不是请你来搞纯技术研发的，个别人可以纯技术导向，但整个团队的目标是用技术能力实现某个特性的产品，为用户和客户创造价值。 认清团队能力的极限 一方面，CTO要看清业务的需求（如前所述，它在不断变化），知悉“做什么”；另一方面，CTO也要评估现有技术团队的能力极限，与管理团队、业务团队进行充分的沟通。否则，好高骛远去构想，不仅使团队能力难以充分发挥，甚至会负效果，费力不讨好、瞎折腾。 认清极限除了要用到极致，更重要的是做好规划。对于基础架构和基本效率这种“牵一发而动全身”的关键问题，CTO务必要对现有团队能力作精准的评估，能不能在合理期限内解决它？如果不能，就要争取资源，恰如其分地构建团队，分配好各个职能、角色的比例。其次，要根据业务发展可能的方向规划技术能力建设，比如，弄清楚若业务按月30%的速度成长，3个月后对技术的要求是什么。 别掉链子 有规划不等于没有突发状况。早期评判技术团队成败最核心、最关键的标准，就是不要掉链子。 我们有个“问题不过夜”的原则，否则不知道明天会发生什么。比如，支付系统堵塞，务必要在当日基本确定问题的关键原因。技术手段治本有其自身规律，该多久就多久，休克疗法很可能适得其反。不过，治本之前可以先隔离它，弱化其影响，或至少通知业务团队，这个问题会“problem once more”，某指标到某个水平就会发生。这样业务团队可发布公告，降低用户预期，最大限度减弱冲击。 CTO要更多把自己视为创业者，而非程序员、科学家，要为业务成败而非团队能力的自豪感负责，最怕技术管理者认定非得我搞定不可，对借助外力有抵触，不愿向他人咨询、请教，结果不仅误了自己的大好时间，也“凉拌”公司业务。 快速学习能力是基本功 做C++就不能、也不想做网页，这对早期技术团队，尤其是十人以内的公司来说，是不可接受的。早期技术团队成员无论从心态和行动都应该是“需要做什么我就做什么；就是没有学过，给我两个星期，基本上能干活；一个月后是熟练工，两个月后就是高手”。快速学习能力是优秀技术人员的基本功。 即使问题的解决并非某个技术人员的专长，但问题无人解决，用户就会认为该公司有问题。有创业精神意味着，不介意用很笨、很手工、很累的方法去解决问题，确保产品、公司有更佳的声誉，业务能良性成长。 维系高性价比团队 对效率、价值的贡献有多大，是评价技术管理者能力、水平的关键点。譬如，某同事说谷歌刚做了一个分布开发语言，有很多好处，至少应该学习。然而，作为创业公司的CTO，更要问：新技术到底有什么好处？能省1天时间？能使质量提高10%？切勿花拳绣腿、跟风赶时髦。如果技术人员有太多闲情逸致，说明技术团队占用了过多资源。 凝聚共识 愿意来创业的技术人员，往往自己有一套想法，而且差异很大。CTO如何凝聚共识？首先要沟通目标，以业务为导向，你始终无法留住对目标不认同的技术人员；然后判断，什么样的技术方案能更有效地达到目标，如果各执一词，先按我思路来，但保留对同侪的尊重。等到资源相对丰富、实力更大、机会更多时，允许你去实验和比较。第三，明确什么问题可以自作主张。 成长期：创业精神制度化 到了成长期，研发团队往往有种跟不上的感觉，始终处于救火的状态。 业务猛增，对技术团队的直接含义是：加班，加班！首先，CTO要告诉技术团队，这是好事一桩。但疲于奔命就永远处于被动，CTO须按对业务影响和冲击程度，区分出可能的关键问题，未雨绸缪，让团队对最严重问题具有突击应对的能力。 另一方面，十人之内的小团队，喜怒哀乐都是你知我知；当到了三十人时，有些人一个星期就见一两面；三百人时，不少人根本就不认识……需要想办法延续创业时积累的文化，制度化是必需。 不贰过，积累竞争优势 在创业早期追求研发的竞争优势可能多为期望；但到了成长阶段，就要在事实上建立和积累优势。 CTO要看清业务模式是运营主导还是技术主导。如果是前者，就要为产品做好服务；后者，就要当仁不让地把技术优势做出来。然而，就算业务是运营主导，也可建立技术优势。比如代理游戏，技术工作包括服务器部署、运维、监控等，CTO可以追求在所有运营类企业里，技术团队效率最高、质量问题最少、成本最低、人头最少。 如何建立和积累这种优势？不犯重复的错误，争取不贰过，再三就属失误和责任问题了—要么是能力不济，要么是缺乏责任心，团队领导是不是识错人、用错人了？一个问题一个问题地解决下来，假如一个月解决10个问题，一年120个问题，其中60个是竞争对手没解决的，技术壁垒就建立起来了。 人员招聘勿以快为纲 业务扩张，风投入账，创业企业终于从捉襟见肘到“大肆招兵买马”了。然而，在时间压力下招募到足额合适的人是一项严峻挑战。 我们有一个看上去根本不像经验的经验是：用上所有渠道，包括内部人推荐。某季度或半年推荐入职最多的同事，即使本职工作不算突出，也可谓功臣。人手不足、虚席以待的问题很突出，那就应该花一半以上的时间去搜寻或者研究如何招聘。 其次，切忌以快为纲，融合是大问题。因为经验表明，观念很难改变，不是不能沟通，而是对某个问题的认识基于不同的事实和逻辑。因此，人员招募不能能力合格就“上车”，要把认同和价值观当作非常关键的标准，职位越高越是如此。如果业务发展形势要求需要短平快的招聘，那就要确保管理一定要跟得上。 人多了，就要拆分为小团队，需要明确各个小团队的具体使命和责任。CTO要给各个团队讲清楚未来6个月、1年甚至2年的使命和目标，未来成长之路是什么，团队负责人自己怎么发展，团队成员怎么发展，小团队怎么建设，绩效怎么考核，怎么奖励……总之，要确保扩张而不脱节。 制度深化和明文化 规章制度在三五人时也有，不过多为基本精神和非明文规定。人员扩张之后，就要使基本精神深化、明文化。 比如回顾制度，早期很可能是出了问题再回顾。但成长期要更有序、条目更细致、信息更详细。需要过渡到每周回顾、每月回顾，要更规范—问题怎么发生的？在什么范围发生的？与上一层级有什么关系？……这些制度在成长期基本上要慢慢建立起来。 在这个过程中，有些技术人员会不适应甚至反感。比如写技术文档，“哪来那么多啰嗦事，把活干完了就行了”。在早期，管理者可能会妥协，毕竟小公司找个能人不容易。到了成长期，技术管理者就要问他：如果你被调到某个重大而紧急的项目组，之前的项目出了问题，你该如何做？技术人员往往都能理解和认同团队相互备份的合理性。机制要适应团队的变化，勿要过早把过重的机制套在团队身上；但用管三五个人的方法应付三五百人，也行不通。 管理与技术分离 一般而言，技术和管理同时擅长的比较少，所以要区分角色、厘定责任、相互协同。创业早期常见的做法是，大家一起商量好了，找一个人负责进度即可。到了成长期，技术团队内部，技术和管理就要分离出来。 分离，不仅仅要把管理者遴选出来，更要让技术人员有尊严。首先，在传统文化里，技术只是雕虫小技，所以中国业内很少有60岁的程序员。很多有才华的技术人员，辛苦三五年有一些成就后，就成天想着能不能做一个项目，能不能转产品，能不能转管理，能不能做一个赚钱的业务……总之，不愿意继续写代码。第二，技术人员相轻也在一定程度上存在。第三，缺乏一个合理的、循环正反馈机制，用合理的回报让技术人员更投入、更专业、更用心研究技术。这些都是培养卓越技术人才的天敌。 要确立技术线，与管理线等高。我们从八九十人开始建立技术评级制度：民主竞选评审委员会制定标准和程序；第一次真正评级则是从一百四五十人时开始的。员工主动报名参加评选—三年还原地踏步，就会被认为缺乏技术潜力，影响发展。技术评级体系既促进组织学习，也建立成长通道，还是考核的一部分。我们提倡惺惺相惜的文化。“事不经历不知难”，成熟优秀的技术人员，知己不易，更应感谢、承认他人的辛苦和创造。 授权，让团队共舞 技术管理者自身也要成长。只有放权，团队才能做更大更多的事情。放权，既有管理上的放权，也有技术上的放权。既然定位为技术管理者，就不要把自己当技术权威和专家，要站在边上，把舞台让给技术人员；管理上要给各个层级的管理者空间。技术人员出身的管理者爱管事、责任心强、追求完美，团队没有空间，路就越走越窄。 作为CTO，对隔级的下级团队的日常管理、考核不直接介入，但参加一些象征性的活动也有必要，比如偶尔与新招募的应届毕业生或优秀基层团队一起吃顿饭，给予团队有效的激励和鼓舞。 允许试错+用数据说话 当融资不断涌入时，顶尖的技术人员也不再求之不得，但团队融合的挑战越加凸显。高人入帐，可能开口闭口就是“你们不懂质量控制、敏捷开发”，甚至“你们的文化根本不是技术文化”。我们有个极端案例，某技术达人离开时忿然说道：“我就不希望跟这样的技术人员一起工作。” 相对于泥腿子、草台班子、游击队，新人多是正规军。但企业竞争是百米赛跑，正步走得好有用吗？CTO要不厌其烦地灌输目标是赢比赛，而不是走正步。 至于技术方案的莫衷一是，随着团队成长，可以允许一些试错。管理者不认可方案C，项目责任人不赞同A，可以在容许范围内给一定的人、一定的时间尝试，然后愿赌服输。 技术团队的沟通要以事实、数据、结果、成效为指标。很好、相当好、特别好这样的形容词，要给客观、量化、趋势等让道。技术成果在最终评价价值时，要回到业务和用户：省了（多少）时间？提高了质量？创造了新价值让用户更高兴？从某一个时刻（明天或者半年后）起，用户能感觉到的变化是什么？ 横向组织建设 团队规模更大之后，横向交流减少，横向组织建设非常有必要。首先，技术团队比较特殊，共通性非常多，能沟通。其次，整个技术团队大到一定程度，不同子团队的横向交流、横向比较以及横向管理，对整个组织的健康、活跃、成长、考核、人才识别大有裨益。我们建立了技术委员会，讨论技术和技术管理、技术组织建设，有技术高度同时有一定管理意识（不需要特别管理能力）的同事可进入这些委员会。 制度建设不是要放弃创业精神，成长不是去除优秀的创业基因。团队大了，但我们仍然提倡“有问题自己解决”、责任覆盖。问题找到了我，不管它的原初责任人是谁，现在我负责解决，未必需要亲自动手，但不可拖延；同侪出了差池，我来补位。这些创业精神和责任，不能因为制度化管理而淡化，反而要通过制度继承发扬。 |
|
|
