首页 > 其他分享 >为啥不适合,依然有很多人大张旗鼓搞企业内部开源?(下)

为啥不适合,依然有很多人大张旗鼓搞企业内部开源?(下)

时间:2022-11-14 12:25:55浏览次数:75  
标签:内部 项目 为啥 效能 大张旗鼓 开源 如果 团队

公司里做事无非「利益」二字。公司利益,团队利益和个人利益。如果三者能高度统一,那当然是好的。很多时候未必能完全统一,尤其是中间团队的利益,这个时候特别需要中间团队负责人的大局观。有的团队人浮于事,先把团队「吹起来」,然后再把事情「铺开来」,再把效果「美颜起来」,至于真实作用闭口不谈。根本没有一个长远目标和实现路径的规划。

从大局观去考量

集体利益和个体利益之间的差别。好的组织可以让大多数时候的集体利益覆盖个体利益,如果大多数时候个体利益凌驾集体利益之上,这个组织是存在问题的,直到问题积累越来越多,最后组织崩溃。

 

比如在公司基础设施还是刀耕火种的年代进行企业内部开源,尤其是很多基建都不行的时候还大张旗鼓的搞企业内部开源,不是傻就是坏。如果没意识,没法判断、错误跟风,我们没实力也就认了;如果明知不可为依然力挺,对大局的认知就有待商榷了。其实很多时候团队负责人是可以判断出来的。只不过公司不是自己开的,不想认真去思考这个问题。简单说如果你是产研100人的CEO,你会去做企业内部开源么?

为啥很多大公司在搞企业内部开源?

大公司的特点 1)团队多人多 2)分工细 3)内部卷。该占的坑都占了,升职加薪需要业绩;能体现业绩的坑都在那里,早来的都分完了。那咋办?如果已有的坑不满足,那我们就挖新坑。1)影响大 2)没人占 3)效果未知。企业内部开源就满足这些特点。扯虎皮拉大旗,先占上坑干起来再说。让全公司的人都知道我在干这事,成功与否管他呢?企业内部开源整体效能如何,管他呢?毕竟现在也没有一个统一的衡量标准在那里。如果企业内部开源还要有一个衡量标准,情怀呢?文化呢?很多人就开始毛了。衡量一下投入产出比,指定负责人、看下实际的效能还是需要的。

埃隆对于精简流程有很好的直觉。如果没有人强力驱动简化,一切都会变成委员会,公司内部的民主,流程,与利益相关者交谈,决策... 一切都会崩塌。设定非常雄心勃勃的目标,10倍问题并不代表着10倍难度。通常,10倍难度的问题,执行难度大概是2或3倍。

你看腾讯百度华为都在搞,怎么讲?这三家公司每年搞的东西很多,每年黄掉的项目更多。这三家做的很多项目有预研和探索的性质,毕竟是一线互联网公司,通常更激进一些。还有一点就是适合他们那个体量的未必适合我们。同样的一种药给大象可能是麻醉剂,给人用可能直接 gg。

企业内源衡量标准

如果真想做好一个企业内部开源项目/模块/产品,那我们先可以定一些衡量标准。先拿去跑一跑现在企业内部开源的项目,如果都达标了,我们可以继续往下跑,如果不成,立刻划分团队归属专人负责。

  1. 代码更新频率
  2. 代码和文档贡献的人员个数和趋势,人员所在部门分布及趋势,持续贡献的人数
  3. star、fork数量和趋势
  4. MR 数量、周期、comment 数量
  5. 打开的issue,关闭的issue,打开到关闭的时长
  6. 文档完善度:文档内容是否完善、文档内容和实际功能是否一致
  7. 发布频率和趋势

通过体检做决定

如果通过数据看到上面的人员过于集中,那么就应该划分到一个团队来负责;如果人员过于分散,那么就要思考下这是一个什么神仙级的项目,每个部门都在用且都在贡献代码,是功能严重缺失大家想集中完善,还是质量太差已经失控。

 

问:已有的内部项目团队可以只保留几个核心成员。其他的功能都开放给所有的人,需求任务领取,bug任务领取,文档任务领取等,全员都可以参与,PR或者文档编写之类;以开源的方式来运作。如果有好的需求也可以提,审核,开放,等着领取,如果大家都不参与就看如何运营?

答:关键是其他人为啥要参与进去?这是最需要想清楚的原因。

 

问:主动性、人脉、利益、成长,都是参加 github 的项目的理由。下次找工作,github一看就有背书了,交际认识了一群人,可以互相介绍了?个人能力提升了?
答:在开源世界中积攒的这些,会一直存续在开源社区,还有可能渗入到你的雇主;但是你在企业内部的人脉、利益、成长,无法「全部同步平移」到下家公司。

 

问:把局限在一个项目A项目B项目C的人,放在了公共的平台上展示自己的能力;算是证明自己的一个机会吧

答:在公司里完成你的现有工作是第一位的。比如去做好项目ABC这是你的本职工作,你就要首先做好;如果你还有空余时间那你再去做公共平台展示你的能力。不能为了展示你的工作能力去做公共平台了,项目ABC给耽误了,这就本末倒置了。

 

相关文章

乱谈开源社区、开源项目与企业内部开源(中)

从特拉斯辞职风波到研发效能中的荒唐事

孙荣辛 | 大数据穿针引线进阶必看——带你盘点那些必知必会的Google经典大数据论文

研发效能|DevOps 已死平台工程永存带来的焦虑

如何快速提升团队软件开发成熟度,提升研发效能?

 

感谢点赞、转载 关注我,了解研发效能发展动向 欢迎进入「DevOps研发效能群」一起探索

 

标签:内部,项目,为啥,效能,大张旗鼓,开源,如果,团队
From: https://www.cnblogs.com/laofo/p/16888627.html

相关文章

  • 实验5:开源控制器实践——POX
     一、实验目的能够理解POX控制器的工作原理;通过验证POX的forwarding.hub和forwarding.l2_learning模块,初步掌握POX控制器的使用方法;能够运用POX控制器编写自定义......
  • 阿里开源 Redis 数据迁移工具
    今天要推荐一个阿里巴巴开源工具redis-shake,一个Redis的数据迁移和清洗工具,工具使用起来比较简单,也经历过大厂的认证,正确性和稳定性都有保障。 Redis实例迁移到另一......
  • 盘点阿里、腾讯、百度大厂C#开源项目
    BAT作为互联网第一梯队的互联网公司,他们开源的项目都是发自内心地将踩过的坑和总结的经验融入到开源项目中,供业界所有人使用,希望帮助他人解决问题。目前互联网的大厂开源......
  • 国内开源erp的天花板是哪一款?
    在讨论国内开源erp的天花板之前我想探讨下什么才是ERP,什么才算ERP,如果只是打着“ERP”的名目,而未行“ERP”之实,开源的价值又何在?又有何意义。 ERP系统的核心就是用......
  • 实验6:开源控制器实践——RYU
    (一)基本要求1.搭建下图所示SDN拓扑,协议使用OpenFlow1.0,并连接Ryu控制器。 a.建立拓扑sudomn--topo=single,3--mac--controller=remote,ip=127.0.0.1,port=8080......
  • 实验5:开源控制器实践——POX
    一.基础要求1.使用命令创建拓扑:sudomn--topo=single,3--mac--controller=remote,ip=127.0.0.1,port=6633--switchovsk,protocols=OpenFlow102.Hub模块1)开启pox./p......
  • 分享Github上10个比较优秀的开源项目给大家收藏下!!!
    Web开发中几乎的平台都需要一个后台管理,但是从零开发一套后台控制面板并不容易,幸运的是有很多开源免费的后台控制面板可以给开发者使用,那么有哪些优秀的开源免费的控制面......
  • 一些开源协议的说明
    我一直以为关键有两点:开源并不反对你用于商业(不用于商业基本没人用)。你的修改要开源。 ......
  • 凯斯轴承数据故障诊断深度学习迁移学习元学习代码开源集合
    网上down的代码,很多人是不是读起来费劲,分析起来比较麻烦,每个人有每个人的风格,因此代码需要别人帮着才能读明白!深度学习调参很麻烦,很多人苦于调参,一调就是一个月,结果却稀......
  • opensd开源啦 !这套自动化部署OpenStack工具你值得拥有
    2022年8月,经openEuler开源社区技术委员会审议通过,联通数科正式将opensd开源至openEuler开源社区。opensd是联通数科为解决OpenStack企业级部署的复杂性,针对自身OpenStack产......