作者面对面 | 创业中的程序媛
「作者面对面 (Chat Chat)」是 GitChat 团队出品的一档对话技术写作者的栏目。我们希望通过展示更多 Chat 作者的视角，来分享程序员关于生活和工作的态度，以及学习和成长的经历。立足于写作，但不限于写作。
本期 GitChat 作者面对面，我们专访的作者是场量科技的创始人「加兴」。加兴 自 2017 年就开始在 GitChat 输出技术管理与敏捷相关的内容，获得了不少订阅。如果用一句话来描述加兴，我想应该是：“不会编程的 CEO 不是一个好的程序媛”。
创业初期的加兴充当着全能选手，从定方案、画原型、搭架构、写代码、建队伍、跑销售、签合同……头顶脚踢，什么都做。
这一次面对面，我们与加兴一起聊聊创业中的她如何带团队、如何面试，当然还有她的写作历程。
能否介绍一下你自己和你正在做的事？
大家好，我是陈加兴。无论在生活中还是工作中，我都是一个充满好奇心、不断探索问题本质的人，我喜欢追问真相、构建更好的解决方案，并使之体系化。这些个人特质让我有机会去尝试一些全新的事物、解决复杂问题，并让更多的人受益。
这些年在敏捷咨询领域，我用我的热情和专业能力，帮助很多客户从犹豫不决到敢想敢做，并取得了成果，在复杂的商用系统交付中构建起了快速迭代的机制。这些经历促使我想开创更大的事业并把价值带给更多人，所以我创立了场量科技，一家帮助企业提升产品研发效能的服务商。在创业初期我充当了全能选手，从定方案、画原型、搭架构、写代码、建队伍、跑销售、签合同……头顶脚踢，什么都干。
你在 GitChat 上创作了 Chat《创业小团队的技术实践》，你希望通过这篇 Chat 或这个专栏向读者传递什么？从你的角度看，你的收获是什么？
普通的公司创造产品，伟大的公司创造思想。创业以来，我的目标不是仅仅开发一些产品出来交给用户，因为世界上做产品、提供服务的公司已经够多了。仅仅设定这个目标，那就不是我了。我们是先行者，我们会去走一些前人未走过的路，留下一些标记，为后来者作出铺垫，帮助他们更快地去实现自己的目标。哪怕我们的作用只是一块小小的垫脚石，也是有意义的。
《创业小团队的技术实践》试图解决的问题是：技术管理的经验是需要通过管理本身来获取的，而创业公司，要么缺乏有经验的管理人才，要么管理经验来自于大公司，需要太高的管理投入。我们有大公司的管理咨询背景，又在自己创业公司摸索出了成功套路，好的经验就需要分享出来。
在这篇文章里，我介绍了一些适用于小团队产品研发的框架体系，覆盖了研发过程、自动化、工具和技术选型几大方面，这些框架体系都围绕小团队进行了裁剪，在时间、管理等投入上进行了充分的权衡，能够帮助创业公司的技术负责人在短时间内低成本地搭起架子，支撑好研发工作。
另一点是，我们的技术实践有非常强的实时性和前瞻性。比如文章里提到的 VSCode，我们比较早以前就将其作为开发工具，因为它有一个非常强大的优势：跨语言开发。开发者只需要专注在一个 IDE 中工作，不需要安装很多不同的 IDE 在开发过程中到处切换。我判断未来的趋势是，软件系统会拥有更大的多样性，而不是单一语言构成的。现在 Facebook 等大企业也采用了 VSCode，验证了我们作为先行者的敏锐直觉。
事实上，我们的模式已经被多家创业公司借鉴，甚至有的公司的创始人在和我们开会时提出：“全面对标场量科技的研发模式”。这是对我们的认可，我很感激。
普通的公司赚取利润，伟大的公司赚取信任。创造思想，赚取信任，这是我的经营之道。这些分享是我们在研发、经营过程中的必然输出。在做这些事时我也没想过要有什么收获，读者有收获，而且真正从这些实践中获得帮助，就是我最大的收获。
以上说的是如何在创业团队进行技术实践，你觉得如果上升到大公司层面，这种实践应该如何落地？
这篇文章的读者有不少都是大企业的管理者，从他们对我的文章的持续订阅来看，他们确实也比较关注如何使大企业获得创业公司的灵活性。
成熟企业和创业公司最大的不同是对风险的偏好和抵抗力。创业公司在早期为了避开竞争，会选择一些高风险、市场规模小的领域。因为竞争者少，作好自身管理，存活下来就有机会。成熟企业市场规模大、风险抵抗力强，但因为市场规模大、用户波及面广，风险的影响会扩散得很广。
所以大企业的各种决策需要内外部的复杂权衡，改变的阻力比创业公司更大。如果大企业想采纳这些实践，他们可以选择一些边缘地带。比如 MongoDB 数据库，在早期市场尚未接受 NoSQL 时，一些新技术的早期采纳者利用 MongoDB 写入快、结构可改变的特点，将其作为日志系统的数据库。等使用熟悉后，再用于用户帐户等业务系统。技术实践也是这样，大企业先选择一些影响面小的系统去尝试，再慢慢扩散。
当然我们以前做咨询的实际情况是，在边缘地带即使成功了，大企业也会说，这个成功没有代表性，因为这个系统/团队不够典型。这时候我们更多就是找出同行参考和未来发展趋势，告诉大企业如果这时候不做某些事，在行业水平和行业时机上，会错过哪些东西。
比如说 2016 年我给某大型通信公司的 IT 部门的第一个建议是让他们使用 DDD 对现有的系统进行全新开发（之前他们在使用 IBM 4 in 1 视图进行设计）。第二年 DDD 就在他们那得到全面采纳了。现在整个业界，DDD 都是最火的名词之一，许多企业和技术人员都在学习 DDD。而我们的客户在适当的时间进行了正确的选择，就能先行一步建立技术优势。
在过去的咨询行业，只能靠顾问的经验和履历来证明这些说法是否靠谱，主观性强。而现在我们利用数据来构建行业指标，未来，我们会用指标告诉客户，哪些实践你如果不做，就会落后于整个行业。
创业团队离不开组织团队，作为创始人，你是怎么面试候选人？又是如何管理技术团队的？
从申请到入职，我们有很严格的流程，录用率很低，说是 1/200 都不夸张。有时候由于急需人才，也会放宽标准或省略流程，最后效果都不好，所以在今年我制定了书面的《录用标准》，来严格约束招聘过程不受主观判断的影响。
候选人在到达面试环节之前，就已经经过了以下几个阶段：
首先是对投递简历的初筛。初筛条件是相对的，主要是看教育背景和资格证书。本科教育放宽、根据分数填报志愿后，大学确实把人才初步划分了等级，在好学校更容易找到好的人才，这是现在你不得不承认的一条规律。
通过初筛后，我会向应聘者发送职位申请表。这个环节主要是淘汰掉一些海投者，判断应聘者是否有明确的求职动机。申请表的顶部醒目地说明了我们公司从申请到入职的流程，帮助申请者了解当前所处阶段和进展。接下来比较重要的申请信息包括：候选的大学成绩单（我们主要是校园招聘）、获得的重要奖项/成果、学习新知识的方法，以及正在持续做的事情。对于一些成绩不太好的同学，就只能遗憾了。没有学习方法积累的同学，也无法通过。因为即使来了，在我们这里工作压力也会很大。
面试环节也很复杂，笔试包括 70% 的语法加 30% 的简单编程，还有翻译和一些解决问题的考察题目。最后我会问候选人在简历上列出的经历，设置一些有难度的场景看他的处理方法。
整个面试过程不会特别舒服，但这是我们公司的特点决定的。我们的产品在开发过程中，几乎没有能通过 Google、百度搜索到的现行解决方案，我们要通过看官方文档、看标准，然后做设计，设计方案通过后进行编码。对编写软件没有兴趣和一定基础的人，很难静下心来完成这一过程。
这种招聘方式的效果也是显著的，完全新人始终保持 955 的工作模式下，我们的产品开发效率非常高，我对团队成员也非常满意。
团队管理上，作为创始人，我的贡献是建立了一套公平透明的机制。每个人都明确目标是什么、为什么，以及怎么做；我们的团队是高度授权的，每个人都有机会做一些管理工作，换个视角来看待自己日常的工作。这其中基本的做事原则就是消除那些无意义的工作，关注自己的产出。
另一个重要原则就是以身作则。每个开发人员，天生都不太爱写测试代码，因为开发和测试的思维是相互批判的，一般人往往只具备一种视角。在团队里，我不会强制大家都写测试，但我写的重要功能代码都是测试驱动的。有一次我在生产环境上制造了一个低级 bug，把一个属性 days 写成了day ，然后因为人在飞机上，整个产品网站挂了超过六个小时。回来后我就在会上说，不管你多有经验、多牛，都会写出 bug，我这个 bug，就是因为没有遵守流程。然后大家都只有一个大写的服，把代码质量视为重要工作来做。虽然我们的团队都是才毕业不久的学生，但是面对与规则冲突的事件，无论是谁，都能够马上指出。
有一次我负责一个导入字典数据的任务，头天发布生产环境，然后我忘了做这件事。刚好第二天一早我坐飞机出差，团队开完早会后就发来微信问，数据导入的工作你做了吗？
在客户来访后，有了对比参照，我们团队每个人感受到的都是自豪，认为自己是在很棒的公司工作。虽然我们没有最好的工作环境，但我们有最好的工作方式。大家都在做一些总结和输出，可以帮助同龄人。
在你的学习或职业生涯中，遇到的最大挑战是什么？你是如何克服的？
主要的挑战来源于资源的短缺。我做的大部分事情都可以定位成一种理论向应用的转化，个人精力、时间分配甚至成本管理，都需要很精细地操作。我采取的是一种类似于“对冲”的机制，来降低整体风险。比如我现在既在创业，又在读商学院；既投资了公司，又投资了房产；既做大客户，也做小企业；既开发商业版，也推行社区版。而我的资源是极为有限的，这是一件在很多人看来都极为矛盾的事。当然，事情还没到终点，我也不能说这一定是对的，是最好的，只能说，这一直以来都是我的选择和我的方式。
另一个挑战是我的目标超越了周围绝大多数人的目标，这在一定程度上给我制造了很多摩擦。他们认为我偏离了他们的期望，会想办法让我觉得不舒服，让我得不到需要的支持。这时候，我会去主动筛选，找到真正可以信任和认可的人，加强与他们的联系。我也会给麻烦制造者有力的回击，这是一个公司创始人必须具备的力量。
你平时写作使用哪些工具？
我比较喜欢能够快速排版、所见即可得的写作工具，因为良好的排版带给我舒适的体验。写作本身是创作的过程，良好的感官体验能促进创作灵感。
时间不太充足的情况下，如果写作的范围比较固定，我就用 Markdown 工具（我自己搭了一个 Ghost 博客）来写作。如果写作的范围不固定，我会先用 XMind Zen 来组织一下内容，从逻辑关联、故事性、全面性等几个方面评估，剪裁之后写作。写作过程中，我会继续进行一些裁剪，我的绝大部分工作都是删除。因为我会顺手写大量关联不紧密的文字作为备用，删到不能再删的时候，我就觉得可以成文了。这个过程有点像原材料准备、制造和组装。
如果时间很充足，我就会打腹稿，通常需要两三天。几千字的文章，我会在头脑里来来回回地打磨、反复在心里诵读，直到我觉得好为止。然后找一个上午/下午，更多的时候是一个深夜，泡一杯热咖啡，一气呵成。
诗歌散文（现在已经很少写了）通常不用工具或事先准备，而是突发灵感，几秒内随口就念出来了，然后写下来。
聊完工具，我们再聊一下内容，你觉得如何才能写好一篇技术文章？
我写文章更多是从创作本身去考虑，很少去定位目标受众。所以“如何写好技术文章”，对我而言是比较陌生的概念。在这种情况下我会去参考好的范例，事实上我并没有查到，所以我可以参考打造一个好内容产品的模式，给一些建议。
先是定位目标受众，内容创作如果要商品化，靠“作者”这个资源无疑就是散户制作手工艺品。需要有专门的内容营销团队去进行市场调查、细分、选择目标市场，并确定要创作什么样的内容产品出来。而不是去找作者，让作者根据自己的兴趣和业余时间去写文章。
有了目标市场和定位，接下来就是好内容的构成要素，主要可以分为：知识学习型、进阶突破型和经验分享型。
知识学习类的，建议可以少一些概念，多一些示例和题目。
进阶突破可以适当增加概念和原理解释，围绕一个中型项目的开展来讲。比如我刚学编程时，有一个微软红皮书系列，每本书就是一个项目，照着书学完了就开发出来一个系统，有的是电商、有的是博客，对没有项目经验的人来说很有帮助，完全替代了培训。
经验分享型适合专家来写作，创作主题要有一定的独特性，最好讲别人没有讲过的问题。随后是背景陈述，说明适用范围。接下来列出主要的观点，以层层展开的方式进行说明，最好把过程中遇到的问题、失败点也列出来。很多技术文章最后的总结只有成功路径，没有说明过程中的问题，然后别人一套用就走不通。
对其他学习或奋斗中的人，你有什么建议？
多向别人学习，认真听取每一个不同的意见。因为每个人都有自己的局限性，通过不同的视角看待事物，可以获得更加全面完整的信息。
结交有益的朋友，也让自己成为一个有益的人。
点击阅读原文，关注加兴