第177讲 | 胡键：创业公司如何打造高凝聚力高绩效的技术团队：工具篇

你好，我是上海圭步CTO胡键，今天我们继续聊聊创业公司如何打造一支高凝聚力、高绩效技术团队，由于篇幅过长，我将这个话题分成了上下两篇来探讨，因为内容互相关联，感兴趣的话可以点击链接阅读上篇文章。在上篇“组织篇”里，我们拿系统架构设计来做类比，重点探讨了成功组织的关键前提：团队架构和带头大哥，将它们分别类比为系统的架构范式和关键对象。正如一个成功的系统除了有好的架构和关键对象设计外，还需要有清晰明确的协作系统和好用的辅助工具一样，要想打造成功高效的组织也离不开好的基础设施和必要的辅助工具，

基础设施

选好团队带头人是否就万事大吉了呢？当然不是！你还得提供相应的基础，为这些带头大哥的工作提供支持，同时也要保证不同大哥之间能够相互配合，合作无间。前文谈到的三观测试只是解决了主观层面的问题，保证大家性情相投，愿意合作共事。但这还不够，为了给我们的事业提供多一份保障，还需要客观层面的基础设施。

这些基础设施典型包括：版本控制、问题跟踪、持续集成、部署流水线。它们为整个公司的开发过程提供了自动化的基础，同时也通过各个系统将开发实践和要求固化，保证整个开发团队都按照同一标准去做事和协作。以我们公司为例，目前所有的研发都围绕gitlab + Jenkins的方式完成：

每一项任务（feature或Bug）都会有相对应的issue，对于每类issue有建议但非强制的格式要求。
代码管理则采用“主/从库”结构，所有开发将各自代码以Merge Request的方式向主库提交。对于每个MR，会先经过自动化测试流水线，成功之后，经专人Review合并，正式版本只从服务器的主库编译产生。
代码要求写自动化单元测试，同时有建议非强制的git log格式，但强制要求在提交时关联对应的issue号。Gitlab会自动在当前commit和issue之间建立关联，在页面浏览commit时可以方便查阅对应的issue。
对于涉及数据库的后端，要求提供DB Migration脚本，促进发布和测试的自动化。
分支模型采用“branch-per-feature”模式，但Merge Request只向主库的Master分支提交，并且只从Master分支编译。
集成流水线围绕jenkins打造，也有团队直接使用gitlab的pipeline，主要完成：自动化测试（发生在MR时和合并进入主库后）和部署（人工触发）。
由于gitlab本身也支持wiki，开发相关的琐碎事项可以直接写入到此，但从可维护性角度来讲，我们倾向于将其直接作为项目文档纳入到版本控制中来，方便版本库的迁移。

有人或许觉得这种稀疏寻常的事情不值得去强调，但我却发现不少创业公司不要说部署整个开发基础设施了，就连最基础的版本控制都不见得能保证。这样的公司或许可以很快拿出可用的原型产品，但是能够走多远，让我很怀疑。

这里我再强调一遍，不要以创业公司人少好协调为借口，将这些本该从公司创立第一天就做的事情一拖再拖。在我看来，这种事情恰恰就应该从人少的时候抓起，从一开始就培养好团队的优良习惯，再将后来者不断同化。如果等到人多的时候再做，反而成本更高，推进更慢，因为“人多嘴杂”。

辅助工具

最后，让我们来说说一些常用的团队管理辅助工具。这里事先声明，下面讲到的这些工具并不是一份完整的辅助工具列表，而且我相信这份列表永远也无法完整。之所以列出它们，只是因为我个人经常使用而已，带有强烈的个人色彩。

1.经济手段

虽说谈钱很俗，但这是一个绕不过的话题，因为它将兑现你所有的“待人诚意”。就我的做法而言，我喜欢：

结合行业标准和个人能力来评定，工作年限只做作为参考。比如，某人号称在某领域中有3年工作经验，但经考察发现其只有1年工作经验，后两年只不过是重复前面的经验毫无进步，此时只能等同1年工作经验来对待了。
基本工资和绩效工资相结合，多劳多得，但此处的“多劳”并不单指“工作时长”，更侧重“工作结果”。在实际操作过程中，可以让绩效工资远超基本工资，同时跟项目的贡献度挂钩。所谓贡献度可以是类似“利用自动化手段大幅提高效率”或“最佳助人为乐”等等，对团队或项目产生直接可见的效果。这种薪酬机制有点类似销售市场的模式，好处显然易见，就是工资直接与公司的财务状况挂钩，避免团队内部出现“南郭先生”，能撑下来的不论从心态还是从能力来看都可谓强大。当然，不利之处也很突出，容易引起某些研发人员的误解和反感。但是，创业公司招人不就是一个认同和被认同的过程么？相比起所得的好处来讲，一点点误解和反感不算什么，只要能够在后续的工作中持续让大家拿到满意的薪资，建立了信任感和信心，其余的问题都好解决。

另外，我不建议开出超待遇的条件，即使你非常希望候选人加入。一方面是没有必要，因为这个世界总能找到替代品；另一方面，单纯靠金钱吸引过来的人往往是最早离开的。对于只认钱的候选人，我宁可外包，而不是考虑共事。或许有人会感到很疑惑，觉得跟上面说的自相矛盾，但你若放在“创业公司”的背景下就很容易理解了：

首先，创业公司永远都处于资金紧张的状态。如果拿薪资跟其他大公司硬碰硬，是以己之短对他人之长。
其次，我上面所谓的超待遇一词仅限于薪资而言，而对于候选人本身擅长的领域，当许以充分的自由度。而这种自由度往往是大公司体制下无法获得的，恰恰是创业公司之长。
再次，创业公司吸引人才不能不谈待遇，但也不能光谈待遇。只要创始人魅力足够，公司的愿景足够诱人，吸引合适的候选人并非困难。

鉴于以上的原因，创始人更应该去用心琢磨公司的业务和前景，以此为王牌去帮助公司吸引各式各样的人才。摆在眼前的一个耳熟能详的例子就是当年蔡崇信放下上百万年薪跟着马云只拿500块钱工资一起创业的故事。而且，我相信在收听极客时间的技术合伙人中也有不少是离开待遇不错的老东家，自降工资跟着现有公司老大把业务做起来的。

2.复盘

在我不靠谱的印象里，复盘一词的流行跟朋友圈中那些神话某些成功公司管理方式的言论有关系。但我最早接触到类似概念则是敏捷方法论中的“回顾”。就其本质来讲，他们其实都是一码事，都强调客观地按时间线复现关键动作，最终进行总结。在敏捷方法中，则落实到：好的实践（应该发扬）和坏的实践（应该避免）。

我个人比较喜欢这种不那么正式的方式，简单有效，如果能持之以恒，累积效果会很惊人。但假若急于求成，一次想改进的东西太多，则可能造成期望和实际落差太大，适得其反，进而怀疑这种方式的效果。这在实践中需要避免。

3.团队建设

团队建设的方式依据公司所处的阶段不同而不同。对于刚起步的公司，吃吃喝喝可能就够了。因为此时公司人也不多，酒桌完全可以担当起拉近人与人之间距离和统一大家思想战线的作用。至于上规模的公司，选择面就更多了。但总的原则仍然不变：促进团队合作，提高大家彼此的认同感。

4.新陈代谢

关于人员管理，外面已经有很多不错的文章和实践，这里我只想强调几点：

第一，尽快淘汰不认可公司价值观的员工，不论职位高低。因为他们的存在对于整个团队士气有不可估量的后果，职位越高，后果越严重。
第二，对于希望挽留的员工，考虑感情留人、事业留人和待遇留人。但说实话，很多时候这已经属于事后补救措施，效果有限。站在公司角度，管理者更需要思考的是为什么会走到这一步？
第三，新挑战是除了经济手段之外最好的激励手段。对于有自驱力的员工，他不会满足于不断自我复制，希望能不断成长迎接挑战。这些新挑战在我看来有两种：一种是在项目中尝试新技术；另一种则是采用老技术将项目升级到新形态，典型的比如，原来的业务逻辑都是硬编码到系统中，是否可能通过重构系统的方式对其进行优化，分拆成基础平台和业务实施平台呢？技术人员往往对第一种重视有加，但对于第二种重视不足。

总结

至此，三篇关于我个人在创业过程中所收获的组织管理经验的文章在《技术领导力300讲》就告一段落了，它们记录了创业这几年我最大的感悟，其重要程度远胜于技术经验的增加。在我看来：

1.打造一个团队，首先应该关注于凝聚力，然后才是团队绩效，而目前的技术团队管理方面的文章对此强调较少。
2.打造组织的过程跟搭建系统有异曲同工之妙，都是先确定整体结构，再确定相互交互，最后辅以若干工具的过程。只是在组织搭建的过程中关注的对象是活生生的人，而不是冰冷的组件和对象。
3.和软件架构一样，组织的结构也需要根据组织本身的发展不断进化，妄想一步到位必将自食恶果。在不同的阶段，需要采用不同的结构。
4.没有最好，只有最适合，各个公司有各个公司的企业文化和发展历史，生搬硬套既是一种懒汉思维，也不会成功，所有其他公司的组织结构和搭建方法都只是参考。

最后，感谢《技术领导力300讲》的邀稿，让我有机会跟各位优秀的读者进行交流，谢谢！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

胡键，上海圭步CTO，TGO鲲鹏会会员，前InfoQ中文站SOA社区首席编辑。超过 15 年软件研发经验，先后任职于中兴和 SAP，现专注于工业物联网创业，具有丰富的产品研发和项目实施经验，擅长围绕设备资产和生产管理提供物联网端到端解决方案。他同时还是 CSM 和活跃的社区活动组织者，在西安组织过多场 HiBlock 区块链技术社区活动并做分享。

11 KiB Raw Permalink Blame History Unescape Escape