互联网产品研发模式与效能提升指南 - 3.形而上
“形而上”谓之“道”，“形而下”谓之“器”。
工程师是崇尚科技、自由和创造的群体，技术的世界也本来如此（自由、开源[1]），大量的开源贡献在支撑着全世界99%的软件系统，这就是为什么我们编写一个庞大且完整的软件，可以不为知识花一分授权费的原因。
优秀的工程师不喜欢被各种规则束缚，被束缚的身体、意识也会同事束缚思考，也就束缚了工程师的创造性。优秀的科技公司，会遵循技术世界的规则，给予他们最大化的自由空间，这也是它们能够成为各自行业领域翘楚的重要原因之一。
有两种文化在软件工程领域具有较深的影响，一个是“工程师文化”，一个是“工匠精神”。
一个具备或注重打造“工程师文化”的团队，更具备活力，且会避免很多无用的、费时费力的额外事情（如：办公室政治、效率低下、结果不好、内驱力不足等）。而找到一个具备工匠精神的工程师（所谓的10倍工程师），营造工匠文化的团队，将会得到“锦上添花”、“事半功倍”的效果。
虽然，打造这些形而上的东西并不容易，且与很多因素相关，如：国家的意识形态、社会的发展阶段、人们的价值观、决策层的意识、团队成员的其它压力等等，但依然值得努力，因为这决定了企业如何思考（做正确的事）、如何行动（正确的做事）。
工程师文化
工程师文化，是为了更好的通过技术来驱动产品及业务发展，将技术放到较为重要的位置，赋能工程师作为主要驱动力量之一，从而围绕工程师建立鼓励创新、公平竞争、自由自律的组织环境，进而吸引更多的优秀人才（对于人才的选择，宁缺毋滥很重要），发挥其创造力和想象力，推进产品和业务发展的一种团队管理风格。
在一个典型的互联网公司里中，团队的主要人员组成是工程师，主要的产出是代码，用数据说话，以结果为导向。在工程师文化氛围浓重的团队中（一般高层为这个产品的第一任程序员），对工程师、代码成果管理和数据价值的重视程度会高于其它（先用对的方式做对的事情，而不是直接追求利益），且每个非技术岗位都需要了解技术领域的相关常识，知道如何通过技术手段解决问题，才能有利于岗位价值的输出。
某个技术解决方案大多数情况下，是为了解决某现实存在的业务领域问题，对于绝大多数的非技术为主驱动的互联网产品，99%以上需要解决的问题，都已经有了完整且可行的解决方案（即我们大多数是去应用技术，而非创造技术），有些解决方案甚至超越了现有的解决方案，研发人员在研究技术解决方案的同时会了解到业务领域的问题，且知道这一技术解决方案还满足了哪些其他的业务场景，并可通过行业间方案的对比，形成组合式的业务创新，从这个角度来说，研发人员在非技术为主要驱动力的公司，也具备一定的技术驱动产品及业务创新发展的能力和动机。
参考以下优质工程师的部分特质，在基于“形而上”打造“形而下”的机制时，也许能提升有效性：
认为技术是一件有趣的事情，追求通过技术手段达成结果后的内啡肽分泌（成就感）；
期望用技术改变世界，用技术来进行颠覆性的创新；
From Cool Shell —— 工程师都是有创新冲动的人，因为手里有创造技能的人通常都会有想创造点什么的冲动。而创新的源泉水来源于精神的解放，精神自由才会引发各式各样的奇思怪想，才会有常人觉得不可能的疯狂想法和想像力，而这些想法和想像力导致了创新。
会尽可能的用自动化技术来解放双手，“创造”时间，不愿重复做一件事情2次以上。对于了现实生活中的“痛点”，会思考如何通过技术手段进行优化或解决，渴望将一切系统化、自动化；
崇尚自由、透明、平等，不希望被束缚，被流程化；
乐于以结果（解决问题）为导向处理方式，喜欢把复杂的事情简单化，直奔结果；
相对单纯，不搞或不擅长搞办公室政治；
喜欢追求极致，虽然达到了目标，但会尝试挑战更高的标准（虽然有时会耽误一些时间，但不是必要的时候，就支持他们，从文化、氛围角度来看，这会带来一些远期的好结果）
追求真理，对工作中无价值的事情（管理、需求等）嗤之以鼻，不愿应付了事；
对于新事物接受度较高，喜欢了解或把玩新的、更流行的技术，当比现在用到的技术优秀（满足更好的非功能性需求、带来一些新的东西）时，会期望将其应用到实际工作中；
职业特性所致，学习能力一般都较强，在科技、产品（业务）领域涉猎较广，有较强的好奇心和想象力，又偏重于理性及逻辑思维，相信客观规律；
喜欢性抽象，乐于将事务抽象化，挖掘事务的本质。抽象意味着重用、通用，也意味着更高的扩展性，以适配各种可能性。具备一定资历的“程序员”，无论其从事的领域，通过之前的积累或兴趣所致，对其它的领域的工作都会有较多的理解，通常会在产品研发的各个环节提出有效见解，对行业变换的影响也较少；
有很多著名的科技公司创始人都是“工程师”，国外的像微软的Bill Gates、Google的Larry Page和Sergey Brin、Facebook的Mark Elliot Zuckerberg，国内的像腾讯的马化腾、百度的李彦宏、小米的雷军，当然还有很多推动技术发生颠覆性进步的幕后基础软件公司，如Linux的Linus Torvalds、PingCAP等等。
以下是以工程师文化为核心的公司文化建设案例：
- Google —— 《重新定义公司》
- Facebook —— 《打造Facebook》
- Netflix —— 《奈飞文化手册》
- 37Signals —— 《REWORK》
以下是一些营造工程师文化的公司的一些现象：
Google允许工程师利用其工作时间中的20%，进行与本职工作无关的项目。这项制度为Google打造了持续学习的氛围，促进了内部交流，促进了思考，也带来了许多创新，甚至有一些也演化为公司的重要产品（如：Gmail、广告算法）。
Google的管理层在一个产品生命周期的初期，会重点关注为用户提供优质产品，满足用户价值，而不会关注利益或以盈利驱动产品发展，相信一个好产品会顺利成长，而盈利只是产品成长过程中的副产品。
Netflix会在员工绩效不好，或者能力有问题时，认为走PIP（绩效改进计划）流程没有意义，提前让他们离开，对公司和“问题员工”来说，都是件好事。
严控招聘[2]，对于人才，宁缺毋滥，只用”最优秀”的人做事。优秀的人本身就有抱负、也足够自律、专业能力还强，也就不用在管理上花费大量的成本和精力或让团队陷入“管理僵局”中。成本角度来说，招1个人，干3个人的活，付2个人的成本，还降低了管理成本，总体成本是低的，而且这种团队还能带来大量的隐性收益。
这需要“契约精神”的支撑，而不是“买卖不成仁义在”这种重人情的风气。工作干的出色，你就会获得自由（物质、时间），否则什么也得不到。
会在社会和公司的角度，给工程师营造更多自由、包容、平等、开放的氛围。没有年龄歧视（与当地法律也有关系），扁平化管理，给到工程师个人或小团队更多的权利和责任，将公司信息尽可能的透明化，让他们作为公司的“主人”（具备主人翁意识），然后由他们来判定该如何做事。
Google 的工程师汤姆森，他 70 年代获得了计算机诺贝尔奖，而他今天还在写代码，因为他热爱技术，精益求精，且收入并不比任何一个公司的高管低。
Google会对其员工开放全部的源代码和文档，甚至会议，开放度达到99%以上，只有1%（重要配置的文件和机密的关键业务）进行访问限制，这一方面体现了Google对员工的信任，而更重要的原因是，Google认为，产品属于Google的同时也属于任何员工，建立内部的开源协作文化，任何人都有机会去改进产品，只要能够为用户提供价值，符合Google的价值观和目标，你的改进就可能被发布。
会允许员工在保障安全的情况下进行集会，以表达意见，表达想法，公司会持开放甚至鼓励的态度，并从中收集有价值的部分，进行改进，以保障公司可以持续发展。
大多数的意见表达方式还是比较平和的，像Google的Thanks God, It’s Friday，Amazon的Principle Talk，都会给大家平等发表意见和建议的机会，并将其声音放大。像Facebook、SpaceX也会提供“开放邮箱”，可以直接给CEO发邮件反馈问题。
Google会要求非技术岗位也对技术有较为深入的理解，知道他们在说什么、想什么、做什么，这样才能更好的完成非技术岗位的工作，才能够有利于于工程师文化的打造。
PingCAP不设上下班的时间限制，“Get Things Done” 是唯一的要求。
组织小团队，来解决大问题，硅谷里有一种说法叫“Pizza Team”，在公司加班时只需要点一个Pizza即可喂饱的团队，这个团队里的成员也一定都是精英。在Facebook，大多数的功能都是由3人左右的小团队完成的。这样的小团队敏捷、高效，降低了很多沟通、决策、管理的难度和成本。
以上这些现象看似都很好，但不要忘了，成功的人说什么都是对的，而正在走向成功的人要避免一味的模仿。对于那些已经成功的大公司所打造的文化，照搬不可取，但停滞、自负更可怕，打造适合团队的文化才是努力的方向。组织不同，文化所反映出来的现象、每个人的认知都不同，但如果都是围绕工程师的特质、满足工程师的心理和生理需求、解决工程师的问题来进行设计，会得到一个不错的结果。
更多的中小型科技公司的文化打造大多数会受Boss或技术Leader个人文化的影响，如果个人是一个优秀的人（例如Apple公司的Steve Jobs），那公司文化应该也差不到哪儿去。
工匠精神
概要来说，工匠精神代表着对品质有着完美追求并持之以恒的钻研一件事的一种做事态度。他们自带内驱力（兴趣驱动），工作起来会自然的投入进去，享受着这个过程，追求着他们认为优质的结果，并且乐在其中。
工匠精神更多是使用在传统的手艺人身上，软件工程师虽然是重度脑力劳动者，但其所构建的软件工程其实也是一个由一行行代码“编织”起来的作品，就像是写书卷一样，它可以平淡无奇，同样也可以妙笔生花。很多技艺高超的“软件工匠”会把每一行代码打磨的更优雅，把自己对解决方案的思考通过更优雅的代码呈现出来，编写出来的代码说它为艺术品也不为过，这些作品也确实被众多人传播、观摩、学习。
工匠精神更多的时候像是对工程师文化的补充，两者有很多相似的地方，比如都乐于追求极致、以结果为导向、追求本真、享受过程、乐于分享。反而一些过重的制度、流程和洗脑（价值观）对他们来说就成了枷锁，把工匠变成了机器人。“工匠精神”有些特质在前文“工程师文化”中有所涉猎，就不再赘述。对于本文来说，更多的是想用“工匠精神”强调兴趣、热爱和持之以恒的重要性。
很多人会想，在软件行业领域，快速解决问题是重要的，工匠精神是否意味着效能的降低，如何权衡它们之间的平衡？但确实有一些组织，尤其是有着长远规划，需要持续发展的头部产品，它们需要具备工匠精神的程序员，需要他们来编写出优雅的代码，这种“优雅”对于非功能性指标具有重要意义，同时也是支撑软件产品能够持续长远发展的重要底座，这个会留到以后再思考、整理。
我认为，大多数能够在技术领域从事多年，并且能力持续提升、能够跟上技术发展的人，首先是因为兴趣（认为技术是一件有趣的事情），其次才是物质。从事编程相关的工作有很多挑战，首先需要耐得住寂寞，大多数时间都是面对着没有情绪的屏幕；在编写一个产品功能时，会进入一段长时间的专注，需要让保持思路才能高效，被打断则需要重新整理思路；技术更新迭代快，需要持续的学习；还要时刻面对着需求的变化；接盘别人的代码，若结构混乱或注释不全，则需要一点点的梳理。上述的各种挑战对于一个人来说，如果不是热爱，不是兴趣，很难能够坚持下去，更不要说做到优秀了。我也会经常对想“转码”的人提起这些，如果大多数原因是因为这个行业挣钱，而对编码提不起兴趣，或找不到乐趣，会做的很痛苦。
几年前，ICT行业在中国被认为是青春饭，到了一定的年龄就不适合了，但现在来看，这些观念都在慢慢的被纠正。现在回过头来想，之所以有这些观点，其一是ICT行业在国内处于快速发展的初期，那些初期加入的、有经验的程序员被分配到管理角色（因为公司的发展策略不是通过技术手段建立壁垒，而是通过资本快速占领市场），或被创业机会吸引（之前多是市场驱动的产品，近期技术驱动的产品慢慢变多）。其二是国内所谓“铁饭碗”的体制观念（体制内的工作会把年龄要求卡在35岁以内）。
然而，去国外的技术论坛上看看，那些奔跑在一线的，有影响力的，促进技术发展的，大多数都是年龄不小的大胡子老头，他们在GitHub上贡献着思想和代码，在各种社区中发表着自己对技术的思考，在各种技术公司中担任“主程”，从而建立了技术基石，组成了推动人类技术进步、科技发展的中坚力量。这就是“匠人精神”中的持之以恒能够带来的，他们深入一个领域，不断积累，然后爆发。
这种持之以恒在中国是缺乏的，但我能感受到，阻止这种趋势的观念正不断被改变，虽然这个过程并不会那么顺利。
若将工匠精神结合到软件领域来说，可能具备以下特征的工程师，更能够成带来长期价值：
- 钻研，深入的钻研。
- 思考，深入的思考。思考的时间越多，写代码的时间越短（意思是这个意思，但也不能太绝对）
- 瞄准价值和时机（优先级），再出手。如果方向错误，你只会离价值越来越远，如果时机（过早或过晚）不合适，你将增加因此而来的机会成本
- 实用主义。先解决雪中送炭，再考虑锦上添花，太多花里胡哨、奇淫巧技的东西会分散自己和用户的注意力，也会拉长你输出最有效价值的周期，优先将实用做到极致。
- ……
另外，最近热炒的“10倍工程师”这个话题，这里也提一下。关于“10倍工程师”和“1倍工程师”，可以看这篇文章。
社区中出现了各种观点，褒贬不一，形成激烈的斗争，例如：
前 Netflix 和 Amazon 主管 Michael Lin：
10x 工程师是事实，最好的工程师比普通工程师好 10 倍。就像一支单人军队一样，他们自己提供的价值比一支初级工程师团队加起来的速度更快。
在我担任 Netflix 和 Amazon 的工程主管期间，我曾与两位刚毕业的实习生一起工作，一直到首席工程师（亚马逊的 L7 及以上），我可以证明确实存在 10 倍工程师。我也可以自信地说他们并不具备：打字速度快 10 倍、工作 10 倍的时间、编写 10 倍以上的代码，事实上，10 倍工程师可能会以一半的速度打字，一半的工作量，并花更多的时间删除代码而不是编写代码。
1x.engineer：
这不是由无能VC（投资人-指Shekhar Kirani）的目光短浅的Tweetstorms（推文风暴）来定义的。
Jason Crawford：
没有什么特别的技巧可以“发现”一个 10x 工程师（尽管奇怪、荒谬的 Twitter 帖子引发了当前的喋喋不休）。他们不是仙女或妖精，你无法通过终端的颜色、键盘上的磨损或任何其他任意的刻板印象来识别他们。
而我认为，虽然10倍工程师被很多人讽刺为投资人喜欢的，被压榨的对象，不懂生活，难以沟通，而1倍工程师更像是大家乐于接受的状态。但的确会有10倍工程师这样的人，正面来说，他们是真的因为热爱，而且我认为，如果真正热爱这个事情的人，他们会在一个阶段经历10倍工程师的状态，或阶段性的在10倍和1倍的状态下进行切换。
很难一概而论的去定义一群人，毕竟，只有少数人能够走到金字塔，而在金字塔尖的人却有着各种特质，剩下的人，都只是优秀一点或糟糕一点的一群奔跑或躺平的普通人。
本系列文章是一个不依赖实际产品、团队、技术架构的，进行了泛化、抽象化的一个指南性质的文章。将分几部分来阐述“互联网产品的研发模式和提升研发效能”这个主题的关键点及可行实践，意在抛砖引玉。在实际落地时，可参考此指南，根据组织、产品及团队的特性，进行组合或优化使用。
1.引言
2.几个重要的观念
3.形而上
4.设计组织架构
5.1.工作模式设计——需求处理
5.2.工作模式设计——迭代规划
5.3.工作模式设计——其它事务
6.建立可视化协作机制
7.进行评估和激励
8.附录