DevOps｜从特拉斯辞职风波到研发效能中的不靠谱人干的荒唐事 _生活百科

今天发生了一件大事特拉斯辞任英国首相，我想借着这件事情说下我看到的一件研发效能的荒唐事，这其中的关联也许就是「都用了不靠谱的人」。
两件事情
今儿一早就听到，2022年10月20日英国第78任首相伊丽莎白·特拉斯宣布辞职。特拉斯上任后任命她的「密友克沃滕」出任财政部长推出「迷你预算」结果引来英国金融大震荡，英镑对美元汇率跌幅达3% ，股市和英国国债均大幅下挫。最后架不住投资者、保守党和民意，辞去英国保守党党首职务，自动卸任英国首相职务，任职45天，也是英国历史上任期最短的首相。
迷你预算这事干的真不靠谱，一发出来股市、汇市、国债齐跌。具体原因大家可以自行搜索，总之这就是不靠谱的人不专业的人才能捅出来的大窟窿，但凡有点花生米也不至于如此。我做研发效能这么多年，也见过一件只有不靠谱的研发效能团队才能干出的事。
这件事就是把全公司「90%」的代码仓库设置成全 internal。什么意思呢？只要你是 gitlab 的用户并且登录，那么公司除了少部分被设置成 private 的代码仓库，其它 90% 以上的仓库你都可读(可以克隆到本地）。当很多公司都在梳理仓库权限，建议把权限设置成 private 的时候，居然有人推动把公司的绝大部分仓库开放出去。我了解了一下，这样做的目的是项目公司内部开源。当时我内心的想法是「擦....老板又被不靠谱的人给忽悠了」。
内部开源(Inner Source)
我找了一些资料列下来。这也许就是他们忽悠老板的理由吧，可是仔细一看这些都站不住脚啊。

内部开源（Inner Source）简称内源，指把开发开源软件中学到的经验教训应用到公司或组织内部开发软件的实践。公司和组织可以在内部开源的同时开发专有软件。

荒唐做法理由之「开放式协作」

在推行内源的公司，所有员工都必须可以访问所有需要的开发制品（例如，代码、文档、问题跟踪等）。基于开放式协作的原则（平等的、精英领导的、自组织的），通常欢迎愿意为内源项目提供帮助的所有贡献者。
公开讨论决策时，开放式沟通也实现了精英制度。尽管组织不一定要变成彻底的自组织来适应内源，但是内源允许个人，组织单元和项目团体具有更高程度的自组织。

企业内部代码库全部内部开源，期待有人关心，感兴趣，看了代码后能帮修复个bug添加个功能，和原有负责团队一起讨论、形成方案。真的会出现这种情况么？
企业内部每个工程都是分工明确，职责清晰的团队在维护。内部公开后，真的有其它团队去看、克隆下来学习学习、有空的时候帮修复个bug添加个功能？没事干闲得慌了么？如果真的有这样的情况且这样的情况很多，我觉得我们更应该反思为啥有这样的情况出现。为啥有这么多闲着的人，不忙自己的业务，去跟其它的团队一起讨论功能、修bug、添加功能、保证质量。
荒唐做法理由之「开放式沟通」

开放式的沟通可以让内源项目和软件中的所有成员能够公开参与所有的交流互动。开放式沟通是公开的（在公司内部）、书面的、有存档且完整的。目的是允许与内源项目有关或感兴趣的任何个人或团体参与沟通。开放式沟通是会被存档的，软件的详细文档会被收集起来，团队可以回顾当时的讨论和决策。

公司内部的公共组件可以把自己的文档、源码公开这倒是没问题。本来有一些帮助文档也是要公开的，以便大家阅读。其它的真有必要么？比如平台的需求、PRD、设计稿、测试用例、程序代码、编译脚本.....其它团队真的想去插一脚？除非两个团队负责的系统之间有依赖或者协同，否则实际很少出现这种情况。即便系统之间有接口调用，也都是在接口维护平台上查看参数和文档，而不是去扒拉对方的代码。我就用一个接口，你让我了解你的平台，这效率也忒低了。
荒唐做法理由之「通过分离角色保证产品质量」