1998 年的谷歌和今天的谷歌相差甚远，他们也是利用了一定技巧和捷径才走到今天的位置。
谷歌也曾从小鱼慢慢发展为庞然大物。如果没有强大的开发军团，就做不了在全球部署的产品。公司规模的不同，决定了技术决策的不同。
我的大部分职业生涯是在小公司度过的。我之前是初创公司 Housekeep 的 CTO，这家公司给了我 6 年宝贵的经验，我将在这篇文章里逐一分享。这些策略虽然有些反直觉，但它们最终让 Housekeep 走到了现在的位置，已经提供了超过 260 万个小时的清洁服务。
如果你想要成为下一个谷歌，请记住以下 8 个策略。
使用不那么酷的技术
当开发人员碰到彼此，他们总爱聊一个话题：你们用的是什么技术栈？技术栈就是他们为交付产品而使用的所有技术的集合，是技术层面的地基、墙壁、窗户和屋顶。
谷歌的技术栈令人惊叹不已，从物理建筑一直到在浏览器中运行的代码，涉及到的每一个元素它们都包含了。谷歌拥有一切，而且一切都很酷。
作为一家初创公司，你应该找到一种更好的方法来解决与人有关的问题。这需要很酷的方法，很酷的思维，很酷的流程。
但 99% 的初创公司不会只是提供技术，他们会借助技术来提供解决方案。这意味着你应该将所有精力集中在较高的层次上。同时，所有的基础层都应该使用不那么酷但可能很安全的技术。
不那么酷的技术有已知的缺陷和权衡，但它们已经存在了足够长的时间，拥有庞大的用户群，这些用户已经发现了大多数严重漏洞。你可以很容易找到具备多年经验的开发人员。相比之下，很酷的新技术存在更多未知的缺陷，它们可能在不经意的时候蹦出来吓你一跳。
如何招聘
问题是，开发人员更容易为新技术感到兴奋。他们还知道，新框架或数据库可能意味着更高的薪水。这就导致了冲突的出现：开发人员倾向于采用令人兴奋的新技术，这样他们就可以借机体验，并利用这些体验在其他地方找到薪水更高的工作。
你必须意识到这一点，并确保他们的技术栈选型不会在日后给你带来麻烦。谷歌可以招聘纯技术驱动的开发人员，因为它有最酷的技术栈。但你没有，所以你不能像谷歌一样。你需要的是真正能够解决问题和交付好产品的开发人员。
拉近开发人员和用户的距离
要看开发人员是否对解决问题感兴趣，可以看看他们是否愿意花时间与用户呆在一起。
谷歌像结茧一样把开发人员放在一个安静而宽敞的茧房里，让他们只专注于开发系统，而你应该让你的开发人员深入了解用户。
在 Housekeep 成立早期，我们还没有为顾客和清洁工提供完整的 App——我们通过电话和电子邮件与他们沟通。我们系统的唯一直接用户就是我们的客服主管。在那个时候，我们安排开发人员与客服人员坐在一起。20% 是出于策略方面的考虑，80% 是因为我们租用办公室是按照桌子数量来付费的。
事实证明，这是一个很好的做法。开发人员能够知道客服主管遇到了什么问题，并且在问题解决之后可以立即得到他们的反馈。如果修改的代码导致速度变慢或出现 bug，开发人员可以快速采取行动。
随着团队的成长，我们将其作为办公室文化的指导原则。开发人员应该能够在用户提交错误报告之前发现问题并修复它们。但这个策略不会一直有效——我们后来制定了更多具有战略意义的流程。但早期的这些经历对后期文化的形成提供了参考：开发人员在解决实际用户问题时可以立即得到积极的反馈。
谷歌有大量的员工致力于收集用户反馈，并将其转化为开发人员的行动。你也可以通过恰当的招聘和座位安排来达到同样的效果。
你可以决定什么时候开始遵循最佳实践
谷歌的系统必须全天候在线，他们的系统设计水平达到了极致。当你还没有达到谷歌的规模时，不用完全遵循这个规则。
当然，开发人员也不能打破所有的规则。毕竟，你将公司愿景的控制权交给了写代码的人，并且相信他们能够开发出高规格的系统。
我们以自动化测试为例。自动化测试意味着开发人员除了写代码实现功能，还需要写代码来检查功能是否正常。我在面试技术人员时总是会问到测试方法，如果对方告诉我他们不相信测试，那面试就结束了。
但从另一方面看，做正确的事情是很耗时的。如果你所在的是一家年轻的公司，你的产品在不断变化，旧功能不断被新功能取代，你会发现代码库里的大部分代码过不了多久就会被丢弃。
最好的策略是使用混合策略。有时候你确实要非常严格，比如我们的账单和支付系统一直都要经过全面测试。但在早期，纯粹用于向用户展示内容的代码都没有经过自动化测试。用户会向我们反馈问题，然后我们再解决。此外，我们知道用户体验会快速发生变化，测试只会碍手碍脚。
处于这两个极端之间的一切都由团队成员来做出判断。理想的初创公司工程师应该知道遵循最佳实践的重要性，但也知道何时何地可以打破规则。
向未来借时间
留着系统的一部分不做测试，是一种典型的技术债务：为了速度而抄捷径，并且知道需要在未来的某个时间点回过头来解决遗留问题。
你和开发人员之间应该会存在一种“健康”的紧张关系。他们会说“我们想要仔细开发这个功能，这样它就能用上 10 年”，而你会说“快做好，这样我们就能知道是否有人真的想要这个功能”。每次你赢了，就欠下了技术债。随着抄捷径次数增多，技术债就会堆积起来。
相关的讨论需要公开进行。公司应该使用问题跟踪软件来记录想要开发的功能和因为抄捷径而遗留下来的问题。当你在未来回过头来想解决遗留问题时，这些记录就变得至关重要。
出点故障也没事
如果 Gmail 宕机十分钟，好像整个世界都会陷入恐慌。相比之下，初创公司用户基数小，产品也相对简单，所以可以承担一定程度的风险。快速迭代可能会破坏一些东西，但结果尚可承受。
但如果你一直靠近风头，冒着偶尔翻船的风险，就必须有一个可以快速纠正航向的系统。
CI/CD 工具能够获取代码、构建产品、执行测试，并将产品部署到服务器上。这样只需要一个步骤就可以快速轻松地发布新版本。如果你选对了工具，还可以进行“回滚”。在部署新版本时，先看看它是否有 bug，如果有，就恢复到以前的状态。你可以自由地做出修改，更好地应对负面后果。
如果你面临的是更严重的宕机风险，该怎么办？这取决于你的产品，你可能还是要冒险一试。如果公司规模足够小，在出现故障时，你可以亲自联系关键用户。如果你能够恰到好处地解释故障缘由，你甚至会发现早期用户为能够成为新产品的用户而感到庆幸。
你可以惹恼用户
规模小意味着你需要笃定地考虑一些事情的优先级。很快，你会发现自己会优先考虑某些用户的幸福感。
在 Housekeep，我们很早就意识到，提升清洁工的幸福感是我们最重要的目标。一个沮丧的清洁工离开我们的平台，可能会让 20 个或更多的客户感到挫败。
同时，我们必须为客户提供“足够好”的在线体验。只要得到好的服务，一般客户就可以忍受不完善的用户界面。
我们的内部用户充当了炮灰，我们为他们开发的工具很粗糙，系统体验也不好。不过我们“逃过一劫”，部分原因是因为我们坐在他们旁边，他们可以看到我们正在努力解决问题。
我们的客服和运营团队具有极高的容忍度。他们知道我们在帮他们解决问题，他们遇到的系统问题正是我们要解决的问题。
你可以把产品控制权交给用户
当我们让内部用户使用笨拙的系统时，我们向他们传达了这样的想法：事情不会总是这样的。
当有新员工加入客服团队时，我们让他们务必在第一周拿出一个产品改进方案。开发人员会尝试在他们的第一周结束之前实现改进方案。
这原本只是出于好心，让客服团队感觉到他们的意见被重视。但随着时间的推移，我们被这些用户的参与度和他们提出的产品创意所折服。
我们从一开始就告诉他们，他们目前使用的系统是可以改进的，这改变了他们的思考方式。他们知道，他们使用的系统不是固定不变的，而是可以变成任何他们想要的样子。
先囤积数据，再挖掘价值
在成立 Housekeep 之初，我收到了一个很好的建议，虽然听起来很奇怪：“数据的成熟过程就像葡萄酒，代码的成熟过程就像鱼”。
最终我明白了这句话的含义。随着产品的演化，应用程序代码需要被重构和重写，但是我们在 2013 年收集的数据在 10 年后仍然有用。
在早期，我们记录了客户、清洁工或工作人员在系统中操作的日期、时间和内容——开始或完成一项工作、预订新工作、更改日程安排。我大约花了两天时间开发日志系统，从那时起，它就默默地在后台把所有的数据都记录下来。
一开始我们没有去查看或分析这些数据，只是把数据默默地添加到数据库中。过了一段时间之后，我们有了一个匿名用户行为数据的宝库——数据“成熟”了。时间越长，数据集增长得就越多，我们能够从中提取的价值也就越多。
小结
如果你的团队规模还很小，产品也还在演化中，那么这些建议值得参考。但要注意，随着公司规模增长，盲从这些建议的风险就会变大。
当团队规模比较大的时候（比如每个团队都有 50 个人），你就不能让开发人员和客服人员坐在一起了。开发人员会因为噪音而感到沮丧，而且并不是每个客服人员提出的产品想法都是积极有用的。
当 10 分钟的宕机时间意味着损失 1 万美元收入时，你就不能继续对产品保持漫不经心的态度。
当每天都有 1000 个新客户加入时，你也不能再随意惹恼他们。
上述这些建议只是生存策略，为你争取时间，让你的公司变得足够强大，能够“正确地”做事情。你不是谷歌，不过你要知道，1998 年的谷歌和今天的谷歌相差甚远，他们也是利用了一定技巧和捷径才走到了今天的位置。
原文链接：
https://medium.com/dev-genius/the-advantages-of-not-being-google-5b1c4454d0da
