今天来聊一下创始人的两个模式： 秋名山和路由器。
很多做产品研发的同事都吐槽公司的决策，我今天就来跟大家揭秘一下为什么有些事情这样的：
- 研发： 我觉得这个地方在这样重构一下，再模块化抽象一下肯定会更棒，为什么还没开始就又要去新的战场？ 创始人： 业务跑之前我已经想了很多，但是更多的方向要跑起来才能知道怎么改，有些研发认为需要重构的地方，其实根本就没有必要再投入资源去改了，因为代码不会跑，为什么？ 因为很多时候，创业是做实验，要边做边看，而不是提前优化那些根本用不到的代码。 创业者很大一部分精力就是阻止开发者去提前优化一些不需要优化的代码，因为开发者忍不住要把代码一定要弄得井井有条
- 研发： 我觉得根据头几次的经验和各种需求看，应该这里加一个抽象，重写这个底层模块就可以满足你们屌炸天的需求啦！ 创始人： 别着急，我们叫上产品、 研发、 测试，大家再一起讨论和梳理一下，真正的业务需求和流程是什么，讨论完删除部分代码就好了，因为删除代码就把 bug 删除了。 为什么？ 因为有时候，团队成员之间争执根本没有对错，有时候大家往往只是一起走错了岔路口，在错误的岔路口上说前方应该怎么走，其实有时候遇到剪不断理还乱的问题，回到本源问问自己，我们纠缠的问题是否真的存在？
- 产品： 我觉得逻辑很清晰呀，这样设计更理性，这样设计整个逻辑和 corner case 都覆盖到了，为什么要改成另外一个逻辑不是那么严谨的流程？ 创始人： 因为产品设计最忌讳的就是“创作者模式”，创作者因为参与整个系统的逻辑和架构设计，一遍又一遍的想，再别扭的逻辑想了 50 遍以上，自己都觉得合理了，但是真实的用户不会像创作者那样去思考。 所以，我们要根据用户反馈的问题，倒推用户的心理，真正好的产品流程是心理学研究后自然而然的成果，而不仅仅只是逻辑严谨，看不懂的逻辑才是最不理性的设计
- 设计： 这个不简单嘛，就是根据产品的流程和文案，堆控件嘛，为啥要改设计？ 创始人： 根据场景不同，用户心理不同，有些轻量化的场景，不需要那么重的控件，控件堆起来是严谨了，但是用户用起来累呀，我们所谓的控件规则有时候要打破一下，为用户的场景让路，为啥？ 因为软件本质上让人少点一步，少困惑一下，研发、 产品和设计这些岗位本质是 “难为自己，方便用户” 的服务岗位
- 测试： 今天太爽了，又搞到几个牛逼的 bug，研发那些小子要好好修 bug 了，为啥把我辛苦挖出来的 bug 关闭了，不是以质量为导向嘛？ 创始人： 是，产品质量很重要，但是要明白团队的资源永远都是有限的，产品就像亚马逊雨林，我们觉得用户会有时间去点所有按钮和菜单，但是其实大多数用户只走比例很小的大路，小路他们不会走，甚至一些卡 bug 的地方，用户没有那个水平，又不是打 CS。 我们应该把测试和研发资源投入到用户经常走的路上去，而不是为了测试而测试，为了卡 bug 而卡 bug
其实还有很多例子可以举，就不这样一直举例了，产品研发团队的‘恩怨’可以一直举到天亮去。
举这几个例子想说什么呢？ 其实每个岗位都希望通过长时间的工作找到工作的规律，希望工作越来越轻松，越来越顺畅，比如我们根据需求用 Rust 重写一下，肯定牛逼，你想想啊，需求确定了，Rust 重写一下，又稳定又快啊。 但是创始人知道，创业其实是开山路，虽然开山路有一定的技巧，但是不能变的是，每时每刻都要高度集中注意力，集中公司所有的资源去面对山路上的各种问题： 塌方、 落石、 来车、 雨天、 突然跳出的动物等等… 创始人知道需求和 bug 是没完没了的，每天唯一不变的就是面对客户的问题，其他的设计模式、 设计规范、 流程细节等都是可以打破的，因为每天遇到的问题肯定是不一样的，关键是努力的过程，而不是总结出什么 “固化的模式”，固化规律其实是一种 “稳定” 的战术勤奋，创业需要努力，更需要停下来问问自己的内心，战略大路在哪里？
创业者除了是秋名山车神以外，还是一个路由器，什么知识都要懂一点，要读很多书，知道前方路况后，要跟各路大神去沟通、 转换和翻译，大家都是各领域的大牛，但是让各位大牛一起工作，就要把客户的需求翻译成产品能够梳理的心理和逻辑，要把产品需求翻译成架构师能够理解的技术需求和项目经理能够分解的落地任务，能够在大家被产品细节磨的没脾气的时候加油打气，能够在测试狂魔虐研发的时候及时叫停，先发版本稳定军心… 这就是下一代先进‘人工’智能路由器，哈哈哈哈
现在你能够理解什么是‘秋名山和路由器’了吧？ 多一点相互理解，多知道一点创业背后的道理，也许大家就不会片面的看待很多问题，也少一点不必要的抱怨和生气，生气伤自己身体。