不知不觉，今年的F1已经进入尾声，和前两年红牛极具统治力的表现不同的是，赛季后半段的红牛呈现出了两个完全不同的诡异局面：一号车手维斯塔潘，成绩依旧稳定，虽然不能继续场场冠军，但是整体下限依旧非常高；二号车手佩雷兹，成绩一落千丈，甚至在墨西哥主场成绩滑落到索伯之后。
奇怪吗？并不奇怪，这说明，红牛的赛车研发跑偏了。
跑偏的研发方向
正确的研发方向应该是什么？同一辆车，100分的车手可以开出100分的效果，90分的车手，可以开出95分的效果。比如舒马赫和巴里切罗，汉密尔顿和博塔斯，一号车手拿冠军，二号车手拿亚军。红牛现在研发出来的赛车，100分的车手可以开出95分的效果，90分的车手，只能开出70分的效果。
为什么红牛赛车会出现跑偏？因为维斯塔潘太强了，跑偏的研发方向被维斯塔潘无与伦比的驾驶技术抹平，让研发人员以为：研发方向是正确的，佩雷兹没跑出好成绩，那是因为他水平不够好。等到发现维斯塔潘开这辆车也跑不出好成绩的时候，已经晚了。
说这么多，大家可能又疑惑，这和数据库有关系吗？有。
作为数据库的预期使用对象，程序员和DBA是最重要的两个群体。而现实中，程序员和程序员之间的水平差异，DBA和DBA之间的水平差异，有时候比非计算机专业的人和计算机专业的人差异还要大。同一个产品，同一个功能，在不同水平的用户面前获得的反馈，可能是完全不同的。甚至在数据厂商内部，对数据库的理解和认知都存在着巨大差异。如果每个人都按照自己理解的方向去开发，大概率就会出现各个功能参差不齐的结果。而一旦这种情况达到一个临界点，产品很容易开发跑偏，要么是稳定性可靠性一塌糊涂，要么是开发出一些毫无意义的性能，要么是剑宗气宗什么都要什么都做不好，也不排除哪个坑都踩。
数据库开发跑偏，和赛车的跑偏结果一样可怕。赛车的动力单元、底盘、空气动力组件相辅相成互为依赖，一旦跑偏结果可能就是整个设计思路要推倒重来而不是局部调整就能修正。因此我们看到很多赛季后半段，就有一些车队彻底摆烂，因为这种修正的投入和预期收益，还不如推倒重来直接开始下赛季赛车的研发。而数据库研发跑偏的时候，有可能存储引擎、计算引擎、优化器都得重构。与其左右重构，不如直接上吊来个痛快。
如何匹配驾驶者
红牛所有的赛车研发，都是围绕着维斯塔潘展开的，这一点无可厚非，一号车手就是拥有更高优先级。法拉利当年也是围绕舒马赫，梅赛德斯也是围绕汉密尔顿。然而红牛这次的问题在于，维斯塔潘的驾驶习惯过于极端，而且二号车手佩雷兹又和他风格大相径庭。导致了红牛这台高性能赛车，除了维斯塔潘，再找不到第二个人能适配。
数据库如何匹配研发或者DBA，这也是个很难的抉择。尤其是一个新生的数据库，预期匹配那些有丰富经验的开发和DBA，还是初入行的萌新？匹配前者，不利于发展新鲜血液，匹配后者，丢失基本盘。两者能都匹配吗？理论上有可能，但是很难。
那么，作为产品经理，这部分要怎么处理？
作为曾经（失败的）产品经理，这个问题困扰了很久。在设计每个功能的使用和特性时，总想要找到一个最大公约数。最终的结果往往是两边不讨好。而我在这一年的时间里，跳出自己曾经的岗位职责，以及对其他产品的调研过程中，也找到了一些答案，不一定对，也许在未来的岁月里，又会被我自己推翻。
第一步，弄清楚预期的行业。不要指望你的产品能被全行业接受，即便是Oracle也不是每个行业都能支持。弄清楚预期的行业和场景，就是在射箭之前找到靶子。
第二步，深入调研行业的产品。比如工业物联网，时序用的多，那么主流的时序数据库在国内有什么样的特性需求、习惯和行业内规范，根据规范去做总体设计。
第三步，参考钉子造锤子。钉子什么样知道了，那就去做适配它的锤子。不要只关注某几个客户，而是要尽量提高样本的覆盖率。
第四步，逐步扩大。解决一类客户的需求之后，再逐步扩大其他行业的需求研发，而不是一开始就虚空打靶或者只适配某个客户。
实际上，红牛跑偏之处就在于，维斯塔潘的个人驾驶权重过重，而维斯塔潘又是一个不世出的驾驶天才，各种研发跑偏的点，都被他驾驶能力盖过。二号车手佩雷兹的反馈无法形成有效的校正，等到有一天跑偏到维斯塔潘都不能适应的时候，就已经晚了。
之所以写这篇文章，是因为最近看了不少产品的演进路线，以及红牛在本赛季两位车手匪夷所思的表现差距有感而发。
