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

2019-2-26 上海圭步CTO、TGO会员胡键 你好，我是上海圭步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，开发相关的琐碎事项可以直接写入到此，但从可维护性角度来 讲，我们倾向于将其直接作为项目文档纳入到版本控制中来，方便版本库的迁移。 有人或许觉得这种稀疏寻常的事情不值得去强调，但我却发现不少创业公司不要说部署整个 开发基础设施了，就连最基础的版本控制都不见得能保证。这样的公司或许可以很快拿出可 用的原型产品，但是能够走多远，让我很怀疑。 这里我再强调一遍，不要以创业公司人少好协调为借口，将这些本该从公司创立第一天就做 的事情一拖再拖。在我看来，这种事情恰恰就应该从人少的时候抓起，从一开始就培养好团 队的优良习惯，再将后来者不断同化。如果等到人多的时候再做，反而成本更高，推进更 慢，因为“人多嘴杂”。 最后，让我们来说说一些常用的团队管理辅助工具。这里事先声明，下面讲到的这些工具并 不是一份完整的辅助工具列表，而且我相信这份列表永远也无法完整。之所以列出它们，只 是因为我个人经常使用而已，带有强烈的个 彩。 虽说谈钱很俗，但这是一个绕不过的话题，因为它将兑现你所有的“待人诚意”。就我的做 法而言，我喜欢： 结合行业标准和个人能力来评定，工作年限只做作为参考。比如，某人号称在某领域中有3 年工作经验，但经考察发现其只有1年工作经验，后两年只不过是重复前面的经验毫无进 步，此时只能等同1年工作经验来对待了。 基本工资和绩效工资相结合，多劳多得，但此处的“多劳”并不单指“工作时长”，更侧 重“工作结果”。在实际操作过程中，可以让绩效工资远超基本工资，同时跟项目的贡献 度挂钩。所谓贡献度可以是类似“利用自动化手段大幅提高效率”或“最佳助人为乐”等 等，对团队或项目产生直接可见的效果。这种薪酬机制有点类似销售市场的模式，好处显 然易见，就是工资直接与公司的财务状况挂钩，避免团队内部出现“南郭先生”，能撑下 来的不论从心态还是从能力来看都可谓强大。当然，不利之处也很突出，容易引起某些研 发人员的误