这个是曾经发生过的一个真实case，要做一个类似 问卷星的矩阵组件
沟通分歧1：图标
下图中的图标，前端找产品同学，希望设计师提供一个图标； 产品：这次需求没有设计师参与，前端同学这边可以找一个
- 如果是一个比较临时的需求，或者是一个没有设计支撑，前端直接整活的团队，没有大问题。（背景是：当前阶段已经有中后台设计团队，在统一推进中后台的设计标准化了）
- 前端临时找的，可能后期在统一改造的时候，还会需要再下掉，重新使用设计提供的新图标
- 前端如果是一个新同学，可能并不一定知道去哪里去找这个图标，以及还需要和产品反复沟通这个图标寓意和这个场景是否匹配
如果在的一个中型的产研团队的话，大家彼此各司其职是最好的，这样专业的同学也会给出专业的建议。减少彼此的沟通成本甚至是不必要的沟通
沟通分歧2：结果验收
- 看似上述过程中，大家沟通比较流畅顺利，其中也是有很多风险
- 项目的上下时间点是：周三
- 周一下午，测试和产品询问效果是否OK？
- 周一晚上10点，产品询问业务效果是否OK？
- 周二上午业务答复效果OK
- 如果上述过程中
- 沟通成本极高 => 业务或者产品恢复比较缓慢（已经出现了）
- 如何确保几方快速对效果达成一致？ => 业务或者产品觉得效果不OK，那么前端就需要与产品、业务沟通，想要啥效果
- 中间会有沟通成本，说不定上线的前一天晚上还在不停调整效果 => 视觉、交互层面，研发和业务沟通未达成一致，可能会有信息差，需要线下沟通
- 编辑成本高 => 假设沟通达成一致，那么前端也需要调整效果，截图发给产品、业务，产品、业务反馈测试回归。这个里面每个人都会比较痛苦，前端尤甚，因为涉及到改代码、调效果、自测、截图、发测试版给测试等等。。
前端/测试问产品 ：「看下这个样式能接受吗？」，这个情况实际不应该发生，这个应该是：
- 设计师提前出设计稿
- 业务确认设计稿效果
- 前端按照设计稿实现
- 设计师验收
综上： C端App 页面，需求预审/评审阶段，就让设计师参与，或者要一个设计师对口人，防止中途或者后期出现设计诉求
以后，「C端App 页面，如果产品说没有设计师，或者不需要设计的话」，可以直接发这篇文章给产品
