■ 方案阶段：
- 项目目标：无论多急，都需要在置身大背景的前提下，想清楚产品的目标，解决了什么问题
- 完整的需求
0）方案：分析问题阶段可以多参考竞品，寻求最优，了解和准备充分。【带着自己的理解和思路】去跟同僚、leaders、潜在用户们去碰撞，“让乱石成为圆圆的光滑的石头”，PK最大的意义不在于说服，而在于验证和完善。尽量不要去创造新的流程、逻辑，而是在原来的基础上修改完善或者嫁接分支，这样才能让架构优美。
1）主流程：即使是前端产品，也是有主流程的。要在大的业务背景之下梳理清晰，如果产品不是从0到1地去建议一个主流程，它也总会依附于一个主流程当中，需要找到它。不同的是，交易类产品往往“完成主流程”最高优先级，对于在既有主流程上做优化的产品来说，主流程不一定是最高优先级，而是作为让思路串起来的辅助工具，也作为用户有稳定预期需要考虑的上下文关系。
2）需求拆解：其实是一样的，去过一遍主流程里每个环节每个页面中的每个模块，哪些是被你改变的，哪些是需要考虑冲突的等等，这样就不会漏掉。原理是一样的。
需要注意的是，在一个体量较大、较为复杂的产品中，不单要考虑主流程，还需要考虑各种分支的情况。
3）优先级：交易产品的优先级很容易可以转化为“这里会影响到多少流水”，但对于难以量化的用户体验，也是可以【针对目标】，用直觉中大致的“用户量x严重性”来判断。例如首页之类的脸面，是任何用户都能看到的，就绝对重要了。
■ 推进阶段：
1）抓大放小：用户体验看起来是很多零零碎碎的东西。但当你认为你所面对的都是“琐碎”，证明你心目中对于“什么才是最重要的”不是那么的清晰，所以还是回到优先级上，QA或自己或别人报出来的问题也是需要优先级的，对于这些问题的影响面快速进行判断，【只把精力和时间留在最重要的事情上】，其它叫人帮忙或者直接放掉。
2）一定要争取：用户体验的东西很难说“影响到订单量”，而且较为主观，因此在说服别人做一件事情时，人人都可以以假装自己是一个用户的角度去推脱。如果自己在这点上比对方更有把握，一定要坚定且强势地捍卫自己的观点，因为如果你都不捍卫，谁还能捍卫用户可怜的感受？
但是，大前提是，你如何【在这点上比对方更有把握】？还是那点，基于调研、熟悉业务、了解用户场景、实际需求，并在心目中有明确的【优先级】。
综上，其实我依然认为，所有项目经验总结的【术】，都会回到【道】上，那就是：对需求是否了如指掌。当做到了这点，其它都是通用和水到渠成的小技能而已。
