人们总是害怕不确定的东西。
比如等公交车，如果公交和地铁一样，每趟车有固定的时间，等公交的时候，烦躁的感觉可能会降低很多。
但是每趟车有固定的时间，很难达到，因为发车时间可能是固定的，但是路况很复杂，说不定会遇到什么样的情况，到达你所在的那一站的时间没有办法保证。
那么退而求其次，能知道下趟车到底什么时候到也是很好的。
这样的话，如果时间不是很充裕，并且知道下趟车可能不会那么快来，就可以果断选择打的等其他交通方式。
减少了“我是打的呢，还是等车呢”的纠结。所以，譬如车来了的app就诞生了。
工作中其实也是如此。
最近接触的工作中，越来越体会到反馈的重要性。
公司的工作流程大概是这样的，业务部提需求--->产品部接到需求，判断是否需要出样式，如需要，设计样式---->技术部实施修改
我所在的部门是技术部。
新公司，新项目，沟通尤为重要。
新系统刚上线，bug和新需求再所难免。
我和我的小伙伴都干劲十足，bug对应很快，新需求也很积极的修改。
但是两周后，用户反馈并不好，用户是兄弟部门，兄弟部门领导狂喷。
我立马反思，是我做的不够好么，到底是哪里不好，以后改进。
在我反思的过程中，我发现我两周的工作量并不少。但是为什么用户还是不满意呢？
我发现，用户部门领导并没有收到好的反馈。
用户提出需求有很多，比如有10个，这个版本我们改了5个，
我们上线后，没有人告诉他，哪些是改好了的，哪些是还没有好的。剩余5个的什么时候改好。
用户部门的操作人员，在遇到问题的时候，会找领导。但是这个问题好了，基本不会告诉领导。
而我们的反馈，只给了产品部，用户领导没有收到好的反馈，so。。。
发现问题，和产品部沟通，改进沟通模式后，效果果然好了很多。
从此事件中总结几点关于沟通的事儿：
1.需求、bug 不管问题的难易，及时给用户答复。有大概的时间，告诉用户，这个事情我们在解决。
2.已完成的工作及时反馈，未完成的工作也要说清楚。不要让用户那里的信息都是一团。将信息屡清楚。
3.沟通的对象，尽量不要是一对多的关系。用户那里最好有一个整理的，整理好让用户领导过目。
这样提的需求比较谨慎，不是随口就来。而且内部有不同意见可以统一。减少不必要的工作量。
大概就是如此。
那么问题来了，如果客户不确定呢，比如网站。
客户觉得不好用，可能也不会反馈给你，直接弃用。
这样的用户体验怎么管理，怎么搜集，容我再想想。