[架构之路-264]：个性特征 - 到底什么才是工程师文化？

创新和实践：工程师文化强调解决问题的能力和创新精神。工程师们擅长将理论和概念转化为实际的解决方案，并通过实践不断优化和改进。
追求卓越：工程师文化鼓励个人和团队追求卓越。工程师们追求高标准的工作质量，始终努力提供最佳解决方案，确保产品和服务的可靠性和优良性能。
合作和知识共享：工程师文化强调合作和知识共享。工程师们经常在团队中紧密合作，分享技术和经验，相互学习和提升。
持续学习和技术发展：工程师文化鼓励持续学习和技术发展。工程师们始终保持对新技术和趋势的关注，并积极学习和掌握新知识，以应对快速变化的技术环境。
自主和自我管理：工程师文化通常鼓励个体的自主性和自我管理能力。工程师们在解决问题和完成任务时，通常被赋予一定的自主权和责任，以便灵活应对挑战。

????????这些特征共同构成了工程师文化的基本元素，然而，不同的组织和行业可能对工程师文化有着不同的侧重点和特点。

三、工程师文化特征解读2：自由生长

（1）创新

工程师文化首先强调解决问题的能力和创新精神。

工程师们擅长将理论和概念转化为实际的解决方案，并通过实践不断优化和改进。

创新是工程师文化中非常重要的一项价值观和行为准则。工程师文化鼓励工程师们勇于挑战现状，推动技术的不断进步和创新。

以下是工程师文化中创新的几个关键方面：

探索新领域和技术：工程师文化鼓励工程师们积极主动地探索新领域和技术。他们对新技术趋势和前沿领域保持敏感，并主动获取和应用新的知识，以推动创新。
提出新观点和解决方案：工程师文化鼓励工程师们独立思考和提出新的观点和解决方案。他们对问题进行细致的分析，寻找创造性的解决方法，并勇于尝试不同的思路和实践。
探索未知领域和挑战传统：工程师文化鼓励工程师们勇于探索未知领域和挑战传统观念。他们在面对困难和复杂的问题时，不畏艰险，敢于创新和试错，以找到最佳的解决方案。
鼓励跨学科合作和思维：工程师文化倡导跨学科合作和思维。工程师们与其他领域的专家和团队密切合作，共同解决复杂的问题，并从不同领域的知识和经验中获得灵感和启示。
共享和传承经验：工程师文化鼓励工程师们共享和传承经验。他们通过知识的共享和交流，促进创新的传承和发展，避免重复劳动，并为组织和行业的技术进步做出贡献。

总之，创新是工程师文化的核心价值之一。在这种文化中，工程师们被鼓励不断寻求突破和改进，以满足不断变化的需求和挑战。通过持续的创新，工程师们为社会、行业和组织带来积极的变革和发展。

（2）自由

工程师文化首先意味着创新文化。因为工程师都是有创新冲动的人，而创新的源泉来源于精神的解放，精神自由才会引发各式各样的奇思怪想。因此他们才会有常人觉得不可能的疯狂想法和想象力，而这些想法和想象力导致了创新。

精神上的自由具体表现在以下六个方面：

1. 自我驱动。自己管理自己是最好的管理，最失败的管理是家长和保姆式的管理，从兴趣出发的工作才可能迸发出真正的动力。

2. 灵活的工作时间和地点。工程师们的工作更多的是脑力工作，而不是体力工作，工作上时间和地点的自由安排可以让工程师们的脑力工作更有效。

Remote（远程办公）是一个很不错的工作方式，开源社区基本上都是使用这钟方式。

3. 信息平等。这意味着，全体员工得到的是原始信息，而不是被管理者们层层加工消化后的信息，信息的屏蔽很容易造成误解和完全错误的行为。

信息的平等，既包括战略、方向、目标、财务等大信息，也包括文档、代码和知识的共享等小信息。

同样，平等也表现在意见表达上，任何人都有表达自己的意见和建议的平等机会，这样才会激发出更多的思路和思辩，从而才会有更多更好的思路出现。

在 Google，除了代码全员共享，还有 Thanks God, It’s Friday 的文化，每周五高管们会和员工在一起，面对面回答员工提出的各种尖锐问题；在 Amazon，代码和文档基本上对全员开放，包括财务报表也对员工开放。

另外，亚马逊所有最牛的 Principle SDE（资深技术专家）隔三岔五都会有一个 Principle Talk（有很多 Talk 相当令人开脑洞）。

还有 Amazon 内部每年会选出一批公司最聪明最有想法的人开会，讨论公司下一步的发展战略，并可以把相应的 KPI 直接传递给 Senior VP。

4. 不害怕错误。处理错误的正确姿势是分析和总结教训，而不是惩罚犯错人。前者让人改善进步，后者让人萎缩不前。工程师最大的错误就是不敢犯错，最大的问题就是不敢直面问题。

5. 宽松的审批系统甚至没有审批系统。

审批通常暗示着三件事：

对人的不完全信任
繁琐的流程
思维上的束缚

这些都是创新和想象力的天敌。一个公司的监管、审批、流程越重，这个公司的活力也就越差。

6. 20% 的自由时间。

这是 Google 提出来的，员工有 20% 自由的时间做自己想做的项目，Gmail 就是这么诞生的。

（3）效率

工程师天生是追求效率的。有人说认为程序员花大量的时间做自动化的工具，还不如人肉的效率高。

比如写自动化的脚本花 5 个小时，而重复做这件事 200 次只花 3 个小时。有这样的理解的人根本不懂工程师和工程。

一方面，这个工具可以共享重复使用，更多的人可以从中受益。更重要的是，这是一种提高效率的文化，它会鼓励和激发出更多这样的事情发生。

如果公司管理者因为一个程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，并且对他批评甚至惩罚的话，那么这个管理者就完全扼杀了提高效率的文化。

人类之所以比别的动物聪明就是会使用和发明工具，而古语也有云：“工欲善其事，必先利其器”。

看看美军的装备你就知道战争工具的好坏有多重要了，一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。

对于工程师文化来说，尤其是在软件工程领域，提升工程效率具体表现在如下七个方面：

1. 简化。

简化不是简陋，简单的东西通常意味着用户更好理解，也意味着更容易的维护和运维。

就像阿里推行的“小而美”、乔布期推崇的“没有产品手册简单易用的产品”、Amazon 推行的 Working Backwards 里说的那样。

一个新的产品或功能，产品经理需要写三个文档：媒体公关文、用户手册、常见问题，三个文档总共加起来不超过两页 A4 纸，且不准用任何图片说明，目的就是为了让产品简化和容易使用。

2. 残酷无情的推行自动化。

编写程序的最本质的目的就是自动化，对于自动化来说，不仅仅只是消除人肉的重复劳动，更重要的是，很多事情人的力量完全比不上机器。

比如：增加一台机器，程序运算在秒级就可以完成，而人是永远不可能达到这样的速度。

再比如：电商中用程序管理数量巨大的订单自动化系统，增加再多的人都不可能像机器那样完成的又好又快。

自动化需要大力开发提高生产力的工具，比如：持续集成，持续部署，自动化运维，基础自动化运维，甚至自动化的运营工具。

3.避免无效率的组织架构和无效率的管理。

这体现在以下这些方面：

扁平化的组织架构。
努力用自动化工具取代支持型的工作。
不超过 10 个人的全栈小团队。
不按人员的技能分工而是按其负责的产品或功能分工。
开会不是解决问题，开会是表决提案。
通过产品的目标或信条来减少沟通和决策过程。

比如，Amazon 里的每个部门、每个团队、每个产品都有自己的信条，这个信条标明了要什么不要什么，这样可以避免很多扯皮和难缠的选择。

我们来看看 AWS 的几个信条：运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能被工程团队拒掉。

Throughput & Latency（吞吐量和延迟）不能更差——这意味着功能要为性能让路，因为性能变差了，用户就要购买更多的资源。

4.正确的组件抽象。

抽象是简化的一部份，最重要的是，抽象意味着技术能力的输出，无论是内部的其他团队还是外部的团队。

比如：Google 的 MapReduce/BigTable/ProtoBuffer，FaceBook 的 Thrift，还有 Amazon 内部的 Web Service 框架 Coral Service、处理日志监控的 Timber，以及全线 AWS 产品都用到的 Amazon Lock Framework（一个分布式锁框架）……

5.开发高质量的产品。

因为高质量的代码，不但可以易于修改和维护，还可以因为较少处理线上故障，从而有更多的时间去为未来做更多创造性的工作。

这意味着需要有非常严谨的 Design Review，Code Review，以及测试。

6.不断的提高标准以及招聘最好的人。

如果一个公司或一个团队想变得越来越好、越来越强大的话，就必须要不断提高自己的工作标准。

提高工作标准意味着要不断地培养和招聘更好的人才。在 Amazon 和 Google 的招聘系统中都有一个叫 Bar Rasier 的职位，这个职位就是为了提高招聘标准而设立的。

7.创建一个持续改善的文化。

一个好的组织和团队，需要全体员工一起不断反思前进。

在微观层面上，在项目做完后需要有一个总结会分析项目中的得失，在故障出现后，需要有故障分析会。

在 Amazon，严重的故障需要写一个 COE（Correction of Errors）的文档，其中有一节叫“Ask 5 Whys”，让你问自己关于这个故障至少 5 个为什么。

在宏观层面上，一家公司每年都应该做一定的工作数据分析或是员工调查。比如，是否招聘到了不错的人、工作的投入产出比、员工在哪些地方花费时间等等，然后不断的用技术手段来改善。

Amazon 每年的工程师员工调查表是我见过的最细的调查表了，表中的问题除了针对公司、管理层、文化等方面。

还包括日常工作、开发环境、持续集成、测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司对工程的投资方向。

四、工程师文化如何落地？

4.1 主要考虑

落地工程师文化需要以下几个方面的考虑：

1.建立明确的价值观：建立明确的公司或团队的价值观，以便所有成员都了解文化的目标和愿景，并努力落实，例如团队合作、创新能力、持续学习、客户导向等。

2.培养开放的沟通和协作：建立开放且透明的沟通渠道，让成员们自由地分享自己的意见和观点，以及在工作中遇到的问题和挑战。而团队成员之间的相互理解和支持、协作能力的提升，都能够促进工程师文化的落地。

3.激励技术创新和学习：为了落地工程师文化，应该提供探索新技术和新工具的机会，并在一定程度上容忍失败，鼓励员工快速试错。同时，也应该要建设和提供相应的学习资源，以便员工不断提升自己的技能和知识水平。

4.关注员工福利：有吸引力的薪酬福利待遇是吸引和留住优秀工程师的必要条件，例如弹性工作制度、职业培训计划、健康福利计划、公司文化建设方案等等。可以激发员工的工作热情，进而促进工程师文化的落地。

总之，落地工程师文化需要领导者树立积极的例子，员工积极参与，不断地优化和完善，让文化不断地发展和演变。

4.2 其他手段

如果你要让一种企业文化在公司内得到执行，有下面几个手段可以选择：

“政治”手段

招聘、绩效考核和升职。比如，你要落地工程师文化中的简化和自动化，那你在招聘的时候，需要把懂简化和喜欢自动化的人招进来。

然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？如果没有，不但不能升职，绩效还可能不达标。

“经济”手段

让不做这件事的成本 > 要做这件事的成本。然后，正常的人类都会选择成本低的方案。

比如，如果你要推行 Design/Code Review/UT 以提高质量，你就把 QA 和 Ops 团队全挪到一边去，让 Dev 团队自己测试，自己负责。

这样等这些 Dev 重复多次手动测试，处理多次线上的弱智故障，他们就会自然而然的写自动化测试和做 Code Review 了。

而 QA 和 Ops 团队只是帮 Dev 你做工具罢了，而测试和运维的事全是你 Dev 的 Ownership，出了故障也是 Dev 自己负责。

于是，他们就会发现，不做 Code Review 和 UT 的成本远远大于做 Code Review/UT 的成本，他们就会去做成本低的事了。

最后，工程师文化要落地，还有几个小条件：

团队要小，Ownership 很重要，Eat Your Own Dog Food。没有人帮你擦屁股，自己的屎自己吃，没有痛苦，不会产生想进步的动力。
热爱学习和尝试。学习尝试新的技术，开拓眼界，学习尝试新的思维方式。否则，原有的思维方式只会让你在原地打转。
老板更多的相信技术而不是管理。相信技术会用技术来解决问题，而只相信管理，那就只会用制度、流程和价值观来解决问题。

五、工程师文化的组织，管理者的角色定位

5.1?工程师文化的组织，管理者的作用

在建立和组织工程师文化中，管理者起着至关重要的作用。以下是管理者在促进工程师文化的组织中的几个重要作用：

1.设定和传达工程师文化的愿景和价值观：管理者应该明确工程师文化的目标和价值观，并将其传达给团队成员。这需要管理者与团队共同讨论并制定共识，确保每个人都理解、接受并致力于这些共同价值观。

2.营造支持和激励的环境：管理者应该创造一种支持和激励工程师文化的工作环境。这包括提供必要的资源和支持，鼓励探索和创新，重视员工的意见和建议，并确保他们能够在整个组织中得到认可和奖励。

3.提供职业发展和学习机会：管理者应该关注员工的职业发展，并提供相关的学习和发展机会，以帮助他们不断提升技术能力和知识水平。这不仅鼓励员工投入工作，还能保持他们的激情和动力。

4.促进团队合作和知识共享：管理者应该促进团队之间的合作和知识共享。通过组织团队内外的交流和分享，管理者可以帮助团队成员从彼此的经验和专长中受益，并鼓励他们协作解决问题和取得成果。

5.树立榜样和引领变革：管理者应该成为工程师文化的榜样，通过自身的行为和态度来鼓励和影响团队成员。此外，管理者也应该主导组织内的变革，推动工程师文化的落地和发展。

综上所述，管理者在组织和落地工程师文化中扮演着重要的角色，他们通过设定愿景、创造环境、提供机会和引领变革来塑造和推动工程师文化的发展。他们的努力将有助于建立一个积极、创新和协作的工程师文化。

5.2?工程师文化与传统企业文化在管理上的区别

工程师文化与传统企业文化在管理上存在一些区别，主要体现在以下几个方面：

激励和激励机制的不同：工程师文化注重技术创新和技术成就，因此管理者需要提供挑战性的项目和任务，以激发工程师的创造力和自主性。传统企业文化则更注重绩效和目标的达成，通常会采用目标管理和奖励制度来激励员工。
开放沟通和协作：工程师文化鼓励开放和透明的沟通，并倡导横向和跨团队的协作。传统企业文化可能更加侧重于垂直沟通和层级管理，在权威性和决策集中方面存在一定差异。
员工发展和学习机会：在工程师文化中，管理者通常会关注员工的技术发展和学习机会，鼓励他们不断学习和提升技能。传统企业文化则更关注员工的职业发展和管理能力的提升。
创新倡导和风险容忍度：工程师文化鼓励员工积极追求创新和试错，管理者需要容忍失败并从中学习。传统企业文化可能对风险持谨慎态度，更注重稳定性和可预测性。
横向晋升和技术路径：在工程师文化中，管理者通常会提供横向晋升和技术专家路径，以鼓励员工在技术方向上的成长和发展。传统企业文化则可能更注重管理层级的晋升和职务的变化。

要成功管理工程师文化，管理者需要理解和尊重工程师的价值观和动机，提供适当的支持和发展机会，同时为他们创造一个积极创新的工作环境。

六、谨防工程师文化被滥用

6.1 滥用的表现

如果工程师文化被滥用，可能会出现以下一些表现：

过度的工作压力：滥用工程师文化的管理者可能会对工程师施加过度的工作压力，要求他们在短时间内完成大量任务并忽视工作与生活的平衡。
缺乏决策权和自主性：如果管理者不给予工程师足够的决策权和自主性，而过度干预和微管理他们的工作过程，这可能限制了工程师的创造力和发展。
忽视团队合作和创新：工程师文化注重团队合作和技术创新，但如果管理者将其滥用为执行机器，而忽视团队合作和创新的重要性，这将阻碍团队的发展和成长。
缺乏发展机会：滥用工程师文化的管理者可能会忽视员工的个人和职业发展，不提供学习和成长的机会，使得工程师的能力得不到充分发挥。
忽视员工的福利和待遇：管理者不合理地压缩工程师的薪酬和福利待遇，或者忽视工作条件和健康安全等方面的问题，对员工的福祉漠视不顾。
忽视员工意见和反馈：滥用工程师文化的管理者可能会忽视员工的意见和反馈，不充分听取他们的声音，从而无法积极应对问题和提供改进。

这些都是工程师文化被滥用的一些可能表现，滥用工程师文化会导致员工的不满和离职率的上升，对组织的创新能力和竞争力产生负面影响。因此，管理者应该避免滥用工程师文化，而是为团队成员创造一个积极、创新和尊重的工作环境。

6.2 如何防止工程师文化被滥用

要确保工程师文化不被滥用，可以采取以下一些措施：

建立清晰的团队和组织价值观：在组织中明确宣传和强调团队和组织的价值观，确保成员能够在这个价值观的基础上参与到工作中，并将它转化为切实行动。
给予充分的自主权：鼓励员工尽可能地发挥他们的专业领域知识和技能，提供充足的自主权来制定解决方案，这不仅增强了员工责任感，也会促进创新。
实行透明和纵向沟通：强调管理层与下属之间的透明交流，促进流动、参与和开放的决策过程，让员工认为自己的想法得到了重视。
提供良好的工作条件和福利：提供适当的薪酬、福利和工作环境，让员工专注于处理工作事项而不是被劳动力压在身上。
利用反馈机制和用例：利用反馈机制，以视角为基础评估符合某人工作或团队的价值观，为员工提供改进和提高个人发展的机会，以此营造一个积极的工作氛围，并确保工程师文化的延续。

简言之，营造和维护工程师文化的持久性，需要组织高度重视，为员工创造一个平等、尊重和有利的工作环境，激励员工参与到组织决策中，一同创造企业的未来。

文章来源:https://blog.csdn.net/HiWangWenBing/article/details/135163409
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！