每日英语阅读
需要增加阅读次数，消耗时间预计30分钟
1）做题前 至少阅读2次
2）做题后 看一篇讲义
3）再阅读一次（带着讲义和问题）
每日理财课程
相当于对以前课程的一个大回顾/串讲。
建了一个委托想把部分黄金卖出
回想了一下卖出的原则，把单子撤销啦。
逐步建立起自己的原则，从实践中去验证和完善。
身体调理
调理师对方案做了稍微的改动，为的是改善睡眠。3月份整体上来讲睡眠质量不好，4点多醒来最多，看书的量和睡眠是成反比的，理想是早上6点钟醒来。
工作
演示demo 的事情 每次以为做完了，其实还会有后续。
需求一：要导数据（电影、电视剧、图片数据、展示栏目、模版），导入新dcms_demo
做的：导了云demo上nc 移动的后台数据
需求二：要部署一套EPG
做的：用dcms_demo对应的一套e p g，做了部署。因研发刚提交的代码，未经测试，遇到问题和花的时间多。
需求三：要再EPG上看到一套电信的演示数据
做的：配合导模版，做配置。
问题：在后台发布后，电信epg 上绑的都是电信的内容，因此图片和内容对不上。
疑问：我没有导电信的编排关系到epg，那么这个是怎么出来，而又是怎么证明图片和内容对不上？
需求三：图片和内容对应上
做的：因图片较大和多，所以先做的是根据数据去和图片做匹配。
重导了nc移动的数据，再补充了一部分图片。
需求四：说要一套n c的apk，要优先要apk对应的展示栏目和编排
做的：搭建apk环境，重新导展示栏目和编排的数据（正常流程：一套后台对应一个前台）
问题：原电信e p g的数据要重新绑定，展示栏目和编排要重新发布。
需求四：apk上部分数据看不到，跑来说数据不对
做的：帮忙导了一套epg库的数据（正常流程是做发布）
问题：因内容没有从dcms发布到e p g,无法到详情页。
需求五：刷数据
做的：使用已有的快捷接口发布（刷数据脚步错误，bf改代码）
问题：e p g中存在多条一样的数据
需求六：去掉重复的数据
做的：去重（正常流程：数据不可能会重复）
需求七：要节目单的数据
做的：更改节目单时间（正常流程：节目单实时更新）
需求八：说原来好的编排推荐位，现在发布后没效果，需要我去排查问题
做的：发现是看错了推荐位。
需求九：说推荐位中 没有可用 视频窗 展示类型，少了enum数据，让我去加。
做的：排查了数据库后发现 不是enum,而是代码模版中写死的，让研发去改。
需求十：说点击发布后无反应，需要去排查问题
做的：发现是推荐位里面的推荐元素不存在导致的，帮她把推荐元素重新设置 发布ok。
这个过程带来了非常大的厌烦感，大家都不高兴，都觉得自己被坑。
产品经理：就是把原两个后台的数据 导入到一个库中而已，都是自己的系统，怎么会有问题呢？
实际：两个后台的数据 根据无法同时导入。（主键冲突）
表面行为的问题：
1）没有去问最终目标。 每次来都是帮个忙的形式，说要什么就给什么。
2）不认为这件事情自己有多大的责任。提供对方要的，怎么用不负责。
3）最后才意识到他们对这个系统不熟悉。
研发刚接收的后台-到前台有没有展示，为什么没有展示完全不知道，需要通过看代码来定位，时间消耗多。
产品经理虽演示过多次，但只会简单的操作，对于是如何编排的，有几个环节到epg，没有相应的概念
于是一出错来找我排错时给的描述和现象 是对不上的，消耗的时间较多。
心里层面的问题：不情愿，且带有排斥
虽然对方要求的都做了，不是因为自己乐意才做的，而是因工作才做的。
为什么会不情愿：历史问题带来的心理影响
现在整个部门的人没有一个人愿意去做这种demo配合，需求来的突然，时间要求紧，而要求却特别的多／奇葩，要负责到底，但因需求不一致，每次即使都做了检查，在对方演示时还是会出各种各样的问题，当被问责时莫名地有火气，就比如：对方只出10块来换你价值1000块的东西一样，不给还是你没理。
解决方案：
1）产品部的人--学会怎么灵活使用，并可处理常见的问题。
2）给他们部门招一个人-专职给他们做demo和维护。
依旧是排斥的心里，但不想改变去接受。