1. 不要做多余的需求，抓重点；
e.g：
不要纠结于样式好不好看 （分情况，尤其相比之前很low的排版方式的话，有用）；
有的时候，太过在意用户体验的时候，会比较容易陷入一些细节的需求，做出来其实本身的价值点不大（可能视觉好，但数据不一定好；另外视觉这种东西，更容易见仁见智，非常不讨好）；
2.对运营反馈问题的态度标准：是bug，解决；是新需求，排期。
另外，遇到bug的时候，往往开发手上还有正常进行中的工作，手上的任务和修复bug如何协调，个人觉得可以先去判断bug的紧急程度，标准可以参考：
- 影响范围是否广 （bug波及的用户数）
- 是否是普遍性的报错（因为有可能是偶发性，不易复现 - 意味着开发解决问题的成本增加）
以上如果是，那么一定要立马修复，如果否，可再进行以下两点的判断：
- 解决bug需要的时间
- 当前手上任务的优先级程度
如果耗时少，那么可以和开发沟通看是否可以进行修复；如果耗时>0.5天，且手上任务优先级较高，可以暂缓修复，巴特！ 要提供其他的解决方案或者说明情况和解决的时间，不能不管！
但是有的时候，这几点都不是特别满足的时候，还是有些bug需要马上解决，比如政府正好在用你们的系统发活动.... 这就很尴尬了... 和官方打交道很烦，事儿多没道理
3. 关于参与活动时的用户心理揣摩
目前在做活动方面的工作，会有点频繁的去刷一些活动集合的网站。包括也会去参加一些线上/线下的活动，会很关注自己内心的想法和变化，总结如下：
- 参与的活动很少，但是因为知道某某网站上的活动很多，而且曾在这个网站上参与过活动，还是会比较频繁的光临某个网站；
- 用户其实挺好被吸引的，奖品丰厚，操作简单，公平（每个人看似势均力敌，所以刷票神马的尽量杜绝）
- 线下的活动，报名一时爽（冲动），真到活动时间的时候，参与率可能会降低不少（因为惰性以及时间方面的不可控）
- 念念不忘，有没有回想不知道。线上参与了某个活动之后，尤其是涉及排名的，在活动结束前，恨不得一天打开八遍 —— 日活妥妥的。另外，偶然发现自己的票数涨了，就会很好奇，谁啊，这么有眼光给我投了一票 —— 如果这是大众心理，做个轻社交也不错，万一促成了一对......好朋友
以上。
未完待续 欢迎补充 ：）
