如何有效push back老板不太合理的ad hoc需求

某中厂application platform组。组里正处于一个critical migration timeline上，就是把我们serve 的prod traffic 从老的架构migrate到新built的一个架构上来。最近一个customer组因为一些紧急需求偷偷在我们组老的codebase上加了一些非常short-term product-specific的业务逻辑 （他们的traffic 已经migrate 了一部分），然后发现需要在新的架构上加同样的feature 来实现它们parity. 这个customer组希望我们组出一个人做这个事。老板在完全不了解对方业务的情况下就答应了。然后找到我说希望我来干这个活。lz 想push back的原因如下：
1. 本身这个work工作量大概2-3周左右吧。但是lz最近也有另外一个重要的项目的ddl，时间本身就很紧。所以应该没有足够精力应付。用这个稍微push back了一下但老板貌似还是坚持让我做。
2. lz之前也在其他组遇到过同样情况。通常“护小弟”老板的做法是直接push back，再不济就让customer team来写，我们提供code review. 毕竟他们更熟悉业务。 但lz组老板新来，没啥经验，直接就认怂了，lz都不知道他有没有至少question一下对方老板。所以lz觉得值得对老板做一些manage up的工作？防止以后这种情况成为norm？

push back的顾虑如下：
1. 这个product 对公司还是比较critical 的。老板已经答应了然后我再push back，对我们组可能也不好 （毕竟组的perf直接影响个人绩效）？
2. lz知道很多人会劝lz跑路，但这个老板overall 还是比较trust我的。已经让lz负责今年的一个org level核心项目，毕竟lz也是刚进组，拿到这个好的项目也不容易。强硬push back后会伤害trust?

同意楼上的。 这里不是谈manage up 和push back的时候。一切都是看priority，哪个时间高就做哪个。不能因为是其他组提出的就一定push back，自己本来做的项目紧急吗，还是就是一个nice to have的feature。 如果不相信老板的判断，可以和skip或者tech leader讨论一下frankly。

为啥lz会自己觉得很多人会劝你跑路，这事老板做错啥了…lz要manage up什么，告诉老板“你得挡活儿，要多question对方老板，你要护小弟”？为什么老板不能选择对其他老板nice一点痛快答应下来，把活儿派给刚进组的小弟？他是新来的，接个活你就嫌弃他怂，能把活直接给你为啥要刚对面老板😂而且这工作你做完了也有成绩啊。
我的建议是首先double check一下谁是谁老板，然后商量一下原来核心项目的ddl要不要延长，然后听老板的决定。

认真说我之前见到的一个情况，一个组里两个人，也是ad hoc analysis ，一个人愿意做，一个人不愿意做，愿意做的那个跟product 那边有很多交流，年底的时候收到了很多非常好的feedback ，顺利升职了，不愿意做的，就现在打算开始做了

预估critital migration会拖延多久，让老板确认。新项目进度缓慢或者被block时候，及时escalate。所有这些发个announcement留paper trail。你和你老板关系究竟咋样，就要到这种有矛盾的时间才看的出来，不算坏事，但是也尽量保护自己吧。

retro，跟组里反应，大家一起push back

首先这事已经答应下来了，那你就不要试图反驳了，除非你有特别好的理由，比如手头的事情一天也不能耽搁，不然整个公司OKR完不成之类的。你可以做的有，
1）讲清楚这事影响手头项目，priority应该怎么排，新的timeline应该是什么样子的（这时候你可以提怎么改timeline，不然老板就拍一个了）
2）自己忙不过来了，能不能加个人（没人的话就残念了，自己想办法挪项目，腾时间吧）
3）现在的方案能不能改，改成你希望的design（如果你对这个技术方案本身没有意见，那就主要谈1和2）