作为一名软件工程师打破这个概念的所有权
在许多公司中，软件工程师的所有权概念有点模糊，但我会尽力解构这个概念。所有权是高级软件工程师和想要成为高级开发人员的软件工程师必须知道或掌握这个概念的要求。
所有权的简单解释
当你拥有你关心的东西时。例如，如果您拥有一台不错的笔记本电脑，您将尽最大努力不损坏它并始终保持最新状态以避免出现安全问题。如果您有一个博客网站，并且您想继续发布帖子、修复性能和安全问题，确保为您的受众提供好的内容，那么这也是有效的。
如果你拥有一辆好车，你会确保它运转良好，你还会给油箱加满油，保持清洁，并且可能会做一些改进。简单地说，当你拥有某物时，你不需要等待别人来解决你的问题。你采取行动，你就完成了事情。在汽车的例子中，假设你的汽车坏了，你有责任把你的汽车送到机械师那里修理。这就是所有权的概念，您要确保无论您拥有什么，都以最适合您和其他人的需求的方式运作。
市场上的实际所有权情况
在现实世界中，有几种情况会发生所有权。我将列出您可以使用所有权的几种情况：
- 当你接到任务
- 当你在开会时
- 当您创建微服务架构时
- 当您看到公司的流程问题时
- 当您看到会影响公司利润和生产力的代码问题时
- 当您发现公司长期目标存在问题时
让我们在以下主题中详细了解这些要点。
取得任务的所有权
当你接到一项任务时，你有责任从头到尾完成它。承担这项任务意味着您将与您的团队进行足够频繁的沟通，以便您能够降低在合理时间内无法完成任务的风险。
假设您要完成一项艰巨的微服务，那么您有责任将复杂性分解为较小的任务，了解全局场景。你必须向你的利益相关者提出问题，可以是产品人员、你的软件工程师同事，任何能让你清楚地完成任务所需的人。
您必须确保您对以下问题有答案：
– 为什么我需要创建这个微服务？它的目的是什么？
– 我需要什么来完成这个微服务？
– 我将使用的技术架构/策略是什么？
– 不完成这项任务的可能风险是什么？
– 我的微服务如何适应公司的大局产品？
– 我的微服务的商业价值是什么？
创建一个文档来回答我上面提到的所有问题，这一点非常重要。这将极大地帮助您了解任务的全局。完成此文档后，如果您认为有必要在会议中或在您的聊天服务（例如Slack）上共享该文档，就可以让您和您的团队对自己和您的团队负责。要决定是在会议中还是在聊天中共享文档，您可以通过询问自己是否真的需要会议来判断。
如果您觉得有很多问题和合理的背景需要为您的团队解释，您可以同时使用两者。您可以使用任务的大图视图共享您的文档，还可以安排与您的团队的会议，以便您可以展示和讨论文档中的策略。在这一点上，确保您理解您在文档上写的内容非常重要，如果有任何不清楚的地方，请重新查看您的文档，向您的利益相关者提出问题，并尽一切努力使其清楚。通过这样做，您将从会议中获得最大价值，因为您将为重要的讨论做好准备。
如果您觉得不必创建会议来讨论文档的想法，换句话说，如果您的文档足够简单，那么您只需在您知道可以找到的空间中的聊天服务上共享它您的软件工程师同事。
在集中位置创建文档的另一个好处是每个人都可以看到它，它也是您为公司生成的工件。因此，您可以让其他人也更容易了解您的任务背景，并且在您生病或离开公司的情况下，其他人将能够继续您的工作。
在会议中取得所有权
当你在开会时，你必须确保你了解你的队友所做的事情的背景。那是因为如果你不明白所解释的内容，迟早你会受到影响。有时会议可能很无聊，很难保持注意力。幸运的是，您可以使用一些技巧和策略通过以下方式更好地理解会议内容：
- 参与会议：尝试提出一个可能有助于您了解全局的问题。不过要小心你的问题，如果你觉得你的问题太基本并且你已经知道上下文，你可能会受到队友的负面评价，你也可以去掉上下文的重点来回答你的问题。因此，如果您觉得可以在 Google 上寻找答案，或者如果您的问题仅针对公司上下文，请尝试在会后联系某人并澄清您的疑问。通过这样做，您将节省其他人的时间，您将展示所有权，因为您正在寻找所需的知识。
- 做笔记：当你没有太多关于会议的背景时，甚至很难提出问题。如果您不提出问题或不参加会议，您很可能会被其他事情分心。一种非常有用和强大的技巧是对所说的内容做笔记，你不需要对所有事情做笔记，只需要对正在讨论的要点做笔记。通过对此采取行动，您了解上下文的机会将大大增加，您不会分心，而且您还可以与您的团队分享您的笔记。这是一种展示所有权的方式，因为您表明您对会议感兴趣，您与您的团队分享价值，因为他们可能忘记了一些细节，最重要的是，您可以更好地理解所讨论的概念。
- 在发现风险时大声疾呼：通常情况下，您会根据自己的经验注意到，如果将会议的决定应用于公司，可能会发生一些不好的事情。因此，作为一名软件工程师，你的工作是指出什么是风险，避免风险的解决方案是什么，对你来说，尝试变得富有同情心和说服力，记住大多数人不喜欢被告诉我该怎么做。他们更喜欢你提出一个深思熟虑的问题，以便他们自己得出结论。
同样重要的是要了解，您无需在会议中谈论任何事情只是为了表明存在感。在会议中制造噪音通常毫无价值，只会占用每个人的宝贵时间。因此，你在会议上说的任何话，都尽量通过问题、建议、意见和健康的讨论来创造价值。
创建可靠的微服务架构
如今，有了微服务，所有权文化比以往任何时候都更加普遍。那是因为服务通常是相互分离的，开发人员也必须确保他们的微服务正常工作，提供预期的价值。
当你在做微服务架构的过程中，你可以采取一些行动：
- 与往常一样，通过创建包含宏观问题的文档，确保您了解全局问题：
- 谁是这个微服务的用户？
- 有多少用户将访问此微服务？
- 这个微服务的业务流程是什么？
- 这个微服务需要高度可扩展吗？
- 什么是 SLA（服务水平协议）、SLO（服务水平目标）和 SLI（服务水平指标）？
- 贵公司是否有构建微服务的标准框架？如果是这样，你会使用它吗？如果不是，为什么？
一旦您对架构设计有了一个高层次的看法，那么您就可以与您的团队分享您的想法，并讨论使用您决定的架构可能存在的风险。可能的风险是您的架构可能过于复杂、不可扩展、不可维护，或者在公司流程方面可能存在某些问题。有时，对于公司政策，我们无法使用某些技术，因此，任务会复杂得多，因为您必须说服高层管理人员使用该技术，而这很容易需要数月时间才能完成。
在公司的流程问题中取得所有权
许多公司仍然在流程中失败，有些公司过于杂乱无章，没有完成工作的框架，在这里你有两种选择，要么拥有所有权并寻找解决方案，要么抱怨和抱怨。因此，最好是想出一个解决方案来解决公司中的这个问题并拥有它的所有权。
假设以下场景，公司刚在一个国家起步，很难有明确的要求，你必须联系其他国家的外部团队，你不知道确切地与谁交谈，还有时区的挑战.
要联系外部团队，您必须工作到很晚或很早起床。但随后您会发现，在其他国家/地区成立的办事处并没有经历与您的办事处成立时相同的挑战。因此，需要采取的一项明显行动是询问这些办公室的团队他们做了哪些工作以提出明确的要求。当您采取此行动时，您就拥有了所有权。作为一名软件工程师，您甚至不希望采取此行动，但这没关系，您的目标是解决公司中真正严重的问题。您不需要头衔即可成为领导者或拥有所有权。
然后您可能会发现您办公室中缺少的差距是您的团队中没有处于战略时区位置的技术项目经理，因此需要经常收集并在您的办公室和外部办公室之间同步。该技术项目经理的另一个重要角色是，她将找出对您的任务实施至关重要的联系点。
公司中有更多常见的流程问题。另一个严重的问题是当安全性受到威胁并且没有采取任何措施来减轻这种风险时。您对此负责的一个例子是确定这些问题并提出解决这些问题的行动计划。安全问题可能会使公司破产或受到严重损害。
当公司的文化有毒时，这是一个非常严重的问题。您还可以拥有所有权并向管理层提出建议，以减少公司的毒性。这是获得所有权的另一个例子，例如，您提出了一种知识共享的文化。通过这样做，您可以减少不健康的竞争，也可以减少人们对被解雇的恐惧。
修复不良代码和不良做法
不幸的是，许多公司都存在糟糕的代码、糟糕的架构和糟糕的实践。一些公司仍在使用非常旧版本的软件、过时的框架，或者更糟的是，使用公司维护的内部工具。通过创建内部框架来重新发明轮子通常是一个坏主意，因为公司必须维护该工具。
糟糕的代码通常是由公司流程中的问题引起的，有时对开发人员施加了很短的截止日期，他们无论如何都必须交付。在这种情况下，您也可以拥有所有权并说不，您拒绝创建低质量的一次性项目只是为了创造数字。你这样做不是因为你想创建高质量的代码，而是因为你知道这对公司有害，你知道公司流程中存在问题。当您看到软件工程师压力重重，经理们急于交付功能时，您就知道出了什么问题。
你必须努力提高你的说服技巧，你必须了解公司正在发生的事情的大局。你必须弄清楚这个问题的根本原因是什么。如果您注意到问题出在 CEO 级别，那么这是一个非常难以解决的问题，但您仍然可以尝试解决它。您可以创建详细的演示解释为什么这对公司有害，显示数字，有多少优秀的开发人员离开公司，团队的压力水平，错误的数量，开发人员解决错误的付费小时数……你必须提出你的理由来说服你的经理、CTO、CEO，这正在损害公司的利润，公司的长期增长肯定会受到损害。
综上所述
要成为一名高级软件工程师，在你的脑海中清晰地拥有所有权的概念是非常重要的。我解构了许多情况，在这些情况下，您可以应用表明您拥有所有权的行动。换句话说，拥有所有权意味着成为领导者并完成工作。通过采取我解释过的行动，你肯定会更好地掌握所有权，并能够在你的职业生涯中更上一层楼。