关于别组提出想“帮助”我们组把我们的成果变成shared library

某组，是在同一个 director 下面的、跟我们有launch竞争关系的组，经常keep an eye on我们组提交的code给他们“查漏补缺”，还经常给director吹耳边风说他们launch很快。

最近我们组加班加点实现了一个重要功能，是我们新项目launch必备的。某组也要launch一个项目并需要类似的功能，他们的manager就提出我们组把这个功能做成一个shared library。因为我们组staff太短缺暂时木有人有bandwidth去做这件事，某组manager就让他下面的人开始搞。

这正常吗？如何才能claim ownership？

谢谢大家！

补充内容 (2023-04-15 00:05 +8:00):
其实大家回复还挺中肯的。。

唉有时候在大厂，尤其是做production的，慢慢开始跟老板学搞 ZZ 斗争了，也挺不好的。。

你们这些小兵真是一个个都不省心，从公司角度来看，这shared library当然是有利啊。难道让每个组花时间搞一套一样的东西？

他们弄成shared library的时候说不定还能加新的feature或者发现你们的bug呢。至于ownership，owner都是公司，你们急个啥。

哦，是你们没时间弄这事儿人家才要弄得，你们要是不愿意就自己花时间弄呗

这种事很微妙。如果你从对方角度来看，大家都喜欢做全新的东西，如果有别的选择的话也没人愿意在别人的基础上修修改改。最好的情况就是做成双赢，X组和Y组合作搞了个大新闻，降低cost / 增加营收 多少多少。看你们领导之间关系，还有你们的领导和他们的领导之间的关系怎么样了。如果之前一直是竞争关系，那搞不好会撕逼。

banana-republic 发表于 2023-04-14 07:30:55
这种事很微妙。如果你从对方角度来看，大家都喜欢做全新的东西，如果有别的选择的话也没人愿意在别人的基础上修修改改。最好的情况就是做成双赢，X组和Y组合作搞了个大新闻，降低cost / 增加营收 多少多少

我们两组领导之间关系老差了 lol

这不是很符合项目规划逻辑吗，做一样的事情没必要重复造轮子，更何况share library能扩大你们的scope，底层的core代码逻是你们掌握着，丝毫没看出take credit。。。

匿名用户 发表于 2023-04-14 07:33:39
这不是很符合项目规划逻辑吗，做一样的事情没必要重复造轮子，更何况share library能扩大你们的scope，底层的core代码逻是你们掌握着，丝毫没看出take credit。。。

做feature的没有什么底层代码啊，而且代码也不是我们掌握了，直接全部copy到他们创建的一个新路径下面了……

学到了，以后我也要这么搞别的组

匿名用户 发表于 2023-04-14 08:44:50
你们这些小兵真是一个个都不省心，从公司角度来看，这shared library当然是有利啊。难道让每个组花时间搞一套一样的东西？

他们弄成shared library的时候说不定还能加新的featu

虽然批评了我，但是其实好像挺有道理的。。。

唉大厂就政治斗争多嘛，有时候也是被manager带着搞斗争，身不由己….

直接把你老板拉进来讨论就好了

老板问你 你就说 这种事我没有经验 我都听你的
对方老板问你 你就说我考虑一下 然后去请示你老板

是两老板关系不好 小兵就没必要掺和了
好的领导都自己就搞定了 根本不会把搞定的压力给到下属 下属只要保持对外意见跟老板一致就可以了

变成shared library是好事啊，reusable，避免重复/tech debt，增加你们组的影响力。按理说，从刚开始设计的时候就应该尽量想到如何design以便日后更加extensible，变成shared library，增大scope。给别人画大饼才可以更好的support你们的项目。至于ownership，底层实现技术/business expert还是你们，不会有问题的。至于说代码copy去哪，爱copy去哪就去哪。shared library最好是你们自己搞，但如果没capacity，就只能交给别人了。