0、调用的时机不对，数据取错了怎么办？ 明显我们接口评估沟通有问题。

0、谁发消息，谁 提供数据。 避免接消息后反查。

1、跟你说过多少变了，不能直接拒绝需求。。

     需求哪有不合理的（产品驱动的公司里）

     我们要考虑的是这样的方案的风险是什么？会导致什么错误？会导致系统什么复杂度。

      你这样说 是不是说明你技术水准不够？找个能力水平高的是不是就能做了。

    - 你没时间，排期排不开。那就让别人来做。

    - 你说不会做，那就是技术水平不够。

1、调接口，可以。不是不让他调。

     但刁我门合理不合理。 （刚刚他说调我们用来做判断，就很有问题。）

    日后造成损失，很明显不光是他的责任，也有我们评估不到位，沟通有问题的责任问责。（不能推责任。）

    所以每个接入我们接口的应用，我们都要帮他评估（吊我们做判断）合理不合理。会不会有问题。

0、多问问，听听其他产品经理的点子，  我们那么多数据无法创作产品？？？

0、我们是中台提供方，提供数据支持，帮助你完成需求的。

1、计费？

     怎么记得费？用什么数据记得费？ （需求搞清楚）

     我们这是有这个数据，但你调错了怎么办？ 调用的时机不对怎么办？

     我们怎么帮你完成这个需求？

2、   我们如何帮助他，完成需求。

     - 这个数据我们是有，但他们调用的时机对不对。

     - 这点数据能否满足他的需求

     - 他们调我们出现错误，如何给对方解决

     这个你得弄清楚，重头谈一遍好吧。。。

2、 存储（hbase、zk、redis、db） tp 可用率要加

      核心业务，要加次数。            最多一分钟调1次

       rpc                                         tp 可用率要加

3、你不就是找死么？

      一行代码写错，损失多少钱知道么？

                              coupon用不了，多少用户去ali。

      做完了，双11要上大屏的。

     多删了一行代码，犯了低级错误。影响了优惠券使用。

4、中间件的事情多想想。我看到你的那个group了。我以为你是故意的。

5、报警怎么都不看？我们干嘛还花时间配呢？

---------------------------

5、博：这个上游更清楚，我这边只是中游，存储这些数据，他们可能有更好的办法。