背景
最近我所在的财务开发组的又是格外的热闹，原因是我们的开票在准备开具多税率的发票时，我们给钱的甲方爸爸的财务给出了明确的指示，所有上个月的准备开具的发票的多税率的具体金额合计金额必须每月的月初给到对方的财务，而这个急活却遇到了不少的问题：
- 跨组数据散落在我们的订单系统，以及甲方一个供管环境，最后为获取用户数据，但由于目前需要提早获得数据，所有整个的问题就变成了如何提早获取数据，以及整理提供到业务 2.由于甲方技术团的设置的不太理想，引发的第二个问题就是明细是数据需要核对时，技术侧并没有将导出加工后的实际数据进进行缓存，导致只能通过接口调用获取实际的明细数据
总结
1.有逻辑的配置最好和产品进行沟通，我们是否真的需要这样的配置？ 2.有时我们的很多思路都是站在自己职业的一个立场上，可是实际上我们换个角度或者站在更高的角度去看一些问题时,可能答案就呼之欲出了 3.文中还有一点是没有分享到的，就是虽然为了这个通用化的设计，引发了很多交流的讨论，收获了新的思路和方案，但是项目进展中途改方案真的是大忌，我为此付出了巨大的代价，真的是为自己狠狠的上了一课
总的来书，主要想表达的就是： 1.以前的我们通过职责划分我们所有负责处理的任务，对于一个实际开发来说足够，但对于现在的我来说不够 2.很多时候，我们一个技术团队确实无法实现所有功能，需要和别的团队进行合作，所以针对此我们要进行评估
a).这个内容最终会影响到我们自己，出了问题对我们影响巨大，此时即使是对方负责，我们也需要努力跟踪对方的进度，实现等各种细节 b).这个内容最终对我们影响不大，则我们自己管好自己的部分即可
3.同样的，当我们接收来自对方的需求时，也需要有相应的评估，对方的需求如果实现难度较大，同时对我们自身风险巨大时，我们就要想办法了放弃该需求了
