方案制定的两难

最近，公司结构调整，所属管理的子系统由他人维护。人员也相应做了调整。

经过系统集成后，后续业务调整，新增了两项需求
1、切换子系统时，保留之前子系统的菜单
2、一个子系统挂接另一个子系统的菜单
由于，目前的集成方式，用户登录成功后跳转到其中一个默认的子系统中去。
（子系统用户相关的数据权限含在首次系统请求初始化，缓存子系统本地。）

领导们需要基础架构这边做一个方案。

曾经，年前讨论了很多次，都是没有答案，给出的一些选项也没多少回应。这次需求方又抛出了这些议题。

所以，接到这样的需求，直接依据目前的设计实现方式，给出了方案。兼顾开发，部署。

看上去，满足了需求，并且是符合事实的管理系统的常用做法。

但，一是方案中将改动一些实现。问题就出在这了。如是自己管辖，自己可以安排实现。如有其他项目组，

则需要协调。好吧，那就按流程走吧，先给出方案。评估方案。每个人都想着自己的一亩三分地，能不改就不改。

事实就在那。说出了谁的就伤害了谁。选择了哪个就会造成哪方面的反弹。

有时，我就在想，有什么样的方案，可以没有争论的呢，那就是不出方案。不出方案就是工作的失职。

问题是，方案可以出，但不需要选。将问题摆出来，让其他人选择好了。听上去这个办法不错。

但是，一旦一方占优，将一些次一些的方案选中实施以后，会产生什么样的结果呢？出了问题后，

方案是XXX出的，就是他的责任。

那最好的方式还是需要自己的选择。既是方案的给出者也是方案的推动者。整体来看，满足用户需求的同时，最大程度地减少对引入系统的增加的熵。

但这里，需要考虑领导们的感受么，领导们有自己的意见么？事先还是先做好沟通工作才是啊。

任何时候，都要依据事实。