Join us on Thursday, April 18th, at 9am BST / 10am CEST / 1:30pm IST / 6pm AEST, when Mishari Muqbil, from Zymple/Bitergia, will discuss Transforming MLOps Culture with InnerSource Principles
Join us on Tuesday, 30th April, at 3pm BST / 4pm CEST / 9am CDT / 7am PDT to hear Florence Rolland, from Novo Nordisk, and Laura Jeffords Greenberg, from Worksome, discuss

Mastering Open Source: Balancing the Code Supply Chain, IP, and Legal Considerations

InnerSource 中内建的主要收益

InnerSource Commons中,我们将基于我们在开源中学习到的经验讨论_open_的概念,以及如何在企业环境中应用我们的所知或所学。 让我从经理的角度逐步讲解其中的一些内容。我将谈论他们如何使我作为总监和我的产品经理受益,这就是我们在PayPal所称的产品所有者。

首先是_open code_。开放代码是什么意思?基本上,该代码对所有公司都是可见的,并且其他开发人员可以通过一个过程在其他代码库上提交拉取请求(pull request)并使它们被接受。要了解更多信息,请参阅有关 Trusted Committers的文章,以及有关更多有关贡献相关的细节。

对于经理来说开放代码也意味着您无需再等待或上升问题就可以修复错误或在其他团队的代码库上实现功能。 您可以开始更高效地实施和计划。 通常,您团队的问题(或功能)可能不是该其他团队的最高优先级的问题。 您不再需要依靠把问题上升到高层管理人员和政治手段来来与支持团队进行沟通。 相反,您拥有更大的权力在你的团队的确定问题优先级并减少对他人的依赖。 有时由于学习曲线而可能需要更长的时间。但是,作为一个团队,这是一直需要突破瓶颈。这样您可以从容地完成那些积压了多年的用户故事。

开放计划(Open planning) 每个人都可以在这里以开放和标准化的方式发布其计划过程。 在PayPal,我们拥有UPE标准。它代表统一产品体验。 它包括一个技术中心,所有团队均可在其中发布路线图和进行冲刺计划的电子表格。每个人都知道这些文档在各个产品中的位置。

其中的一些好处是,它可以帮助您和您的团队因完成的工作而获得声誉。当您知道其他团队正在做什么以及他们当前正在优先考虑什么时,您还可以更有效地进行跨团队协作。开放式计划可使团队之间进行更有效的谈判。

开放文档(Open documentation) 是我们在InnerSource中经常处理的事情之一。这包括规划过程,标准,这类事情。 其中的一个关键因素是可检索性,以及一定程度的集中化,这样每个人都知道在哪里可以找到文档以弄清楚如何与您更好地合作。

它对您的成功有很多好处。 其中一些是开放计划和开放标准,以便您可以更好地协作。 但是,在信誉方面,高层管理人员可能看到的是您正在经历的不同路径,也就是说只看到您现在的进展,而不是相比项目以往的情况,您推动了这些(僵持)住的项目。

乍一看似乎比较耗时,但是当您拥有开放的流程,开放的标准和开放的文档时,协作将变得更加有效。 这些文件需要在标准化的地方公开发布。 这使它们可以被发现。 也可以通过标准或良好的搜索引擎来检索它们。

好处是-您和您的团队对完成的工作有更多的信誉。 您也有明显的历史记录。优先级改变的原因是显而易见的。 这对于我们之前讨论的有关中层管理者压力的信誉问题大有帮助。

它还可以提高协作速度。您可以轻松地研究您想协作的团队,并可以了解他们的工作方式。 这些都是最大的负担—​它减少了部落的知识并有助于打破信息孤岛。 如果团队难以协作,那么这种变化就更容易显现。有时文档也可能过于复杂,限制性或不准确,会使得协作效率慢得多。有时它们有充分的理由,例如脆弱的旧代码库,但是现在高层管理者可以更清楚地了解为什么在资源方面可能需要对重构进行优先级排序。

合作和谈判:中层管理人员通常没有能力使用其领导技能。 中层管理人员以前曾提出过的前五项投诉中提到了这一点。 在InnerSource流程中,这些技能(例如协作和谈判)变得至关重要。当您清楚地说明了这些内容后,在团队中设定期望就变得容易得多。 您甚至可以帮助其他团队来帮助您创建文档和标准。 我发现,大多数时候,人们希望提供意见,尤其是在标准制定过程方面。这也是让这些团队首次合作时起步的一种好方法,有时也是安全的方法。

示例

我有三个很棒的例子

第一个示例-付款

第一个是付款。付款需要重构和模块化。 我与支付团队和其他五个团队一起设计了八个月的新InnerSource流程。

我们能够选择一支80%受到中断驱动的团队进行最终重构。 其他团队则能够摆脱积压多年的功能需求。 最后,主管告诉我,如果没有这五个团队在InnerSource流程和简化过程中提供的投入,我们将无法正确理解新支付模块的重构和模块化。

第二个示例-ALM

第二个是ALM或应用程序生命周期管理过程。 该团队负责协调从代码创建到生产的所有工具。 我们不仅可以在不到一年的时间内实现15个主要功能,包括容器化和数据库即服务,而且还能够开始重构ALM以过渡到平台即服务。 在与各个团队合作之后,该团队创建了一些令人惊奇的开放标准文档, 让我们看到开放文档带来的效率提升。

第三个例子-FDI

第三个示例是FDI,代表开发人员交互失败。 我们成立了开发人员标准委员会来帮助开发开放标准。 毕竟,与按小时直接受到影响的开发人员相比,谁能更好地确定什么是FDI或失败的开发人员交互作用?

这也有助于解决一些政治问题,因为以前每个团队都有不同的方式来衡量失败。不用说,在某些情况下,开发人员不同意。 但是,通过公开讨论,我想相信我们能够创建比以前更准确的标准。

这些示例表明,如果开放流程做得好,它将改变中层管理人员的面貌。 中层管理者角色发生变化。 产品负责人必须在团队之间进行更多协商。 产品所有者必须将更多精力放在协作上。 但是,如果做得好,所有团队都可以更多地参与企业愿景。

最好是将这种开放式计划一路推向顶峰。 通常,这意味着产品所有者可能需要在谈判中进行其他培训和指导。 但这确实解决了中层管理者关于没有能力的主要抱怨。

Contributors