2016.8
1.后台做不做，先考虑使用频率。如果基本不需要运营，就不要急着做后台原型，把规则写清楚给后端就好了。
2.换个思路考虑问题，如果认为某个事情因为价值不高没有必要做，那是否可以想看看怎么提高这件事的价值。
3.分清主次，学习时间不够的情况下，有些任务还是要交由测试、运营，不应该顾此失彼。
2016.7
1.需求要及时更新，不是只跟开发说就好了，还要知会测试，还要留Tower需求备份。
2.搜索数据整理，仅仅分析某一块的数据是不够的。还要站在更高的层面去看整体的数据是否异常。一眼就能被看出来的东西，自己却没发现。发现以后也没有及时推动理清数据出错的来源。比较好的方式应该是及时拉相关人员搭一个小组，将问题描述清楚，再一对一找人跟进，让大家在群里及时反馈，才能快速解决问题。如果不把大家聚在一起，私底下一个个找人，没搞清楚问题所在，非相关人员很难找到原因，致使任务一拖再拖，不该！
3.不定义清楚热区，让开发人员凭感觉做触控范围，容易与实际需求不一致，还增加沟通成本。
4.给开发看的原型需要详细包含各种情况。但是产品评审之类的情况，还是要以简洁为主，介绍清楚关键点。
5.要及时汇报进展，不要憋大招，不到最后不给方案，这样容易导致什么都没做成。每天的工作任务要清晰具体可衡量。
6.不要事无巨细。汇报时要先简明扼要地提炼最值得关注的点，再展开。
