这一周在做天气应用的改进方案。一个小的体验问题，原本不应该花这么久来解决的；但中间走了些弯路，没有在最开始去洞察问题，忽视了基于数据/证据来决定方案，导致了无意义的纠结和讨论时间。
做事的日志如下：
1. 接收到问题：天气应用，存在IP定位不准的情况
2. 粗略了解问题。了解到IP定位不准是IP定位的天然缺陷。尝试了解错误率，但是这个不能从后台数据看出，于是我询问技术同学、上网查，仍然无法预估，只被告知在<10% （❌：轻易满足于一个不具体的数字；因为后台没有现成的统计数据，就不愿意花时间去看原始的用户数据，急于求成了）
3. 试想方案。开始找老板、设计师、产品交流方案。在平衡1）问题严重程度、2）方案解决度、3）解决成本，这3点之间陷入纠结。
4. 和设计师发生激烈争论，发现谁也说服不了谁。被问到具体的数字，说不上来，顿时心虚。（❌：不用数据来辅助观点输出）
5. 接受教训。拉出相关数据，一条一条人工判断，抽样审查。此时，竟然发现了和IP相关的另一个更为严重的问题。（❌：一开始了解问题不够）
6. 就纠结点，展开快速的用户测试。
7. 根据线上用户数据和用户调研结果，选择出一个方案，并说服了设计师。
8. 和研发沟通的同时，一个系统的同事找到我，告诉我一个新的更优的方案（❌：为什么没在一开始广泛地调研解决方案有哪些）
9. 对更优的方案发起了技术评估，准备立项
经过反思，我认为一个更好的流程如下：
1. 花足够的时间研究问题。问题是什么？问题有多严重？优先级如何？具体到精确的数字。如果不能精确评估，可以采取快速抽样、调研的方式，得到能足够表达问题的数据。
2. 充分暴露问题、寻求解决方案。多找可能相关的产品、研发同学，了解他们所知到的可行方案；将问题清晰阐述，通过内部邮件、微信发出来，寻求可能的帮助。
3. 确定方案决策的标准
4. 平衡方案，根据标准来决定。在这个过程中，及时和研发沟通，看有没有坑，要给时间进行技术评估。
5. 确定方案后，多和别人讨论，接受挑战和质疑。如果有不能确定的地方，及时找用户做测试。
6. 第4步-第5步循环，直至最终方案确定
