背部船型开关“矩形”为开机，“圆形”为关机

音箱右侧有旋钮，旋转旋钮为选择与调节音量功能

按压旋钮为确定与弹出菜单栏功能。

打开音箱背部船型开关等待音箱开机。

2.教程学习 按照音箱显示内容旋转与按压旋钮，完成教程

旋转旋钮阅读用户协议，至协议底部轻按旋钮确认

4.连接WIFI 音箱激活完成后，出现连接WIFI页面输入密码即可连接。

旋转旋钮至蓝牙界面确定音箱未连接其它设备

打开手机蓝牙，并连接到MORROR ART设备

音箱界面显礻为已连接

点击右上角图标，进入菜单栏

选择Qplay与车载音乐

选择设置完成的音乐APP播放音乐，音箱即可显示歌词

旋转至用户手册选项并按压，分为1）如何让MORROR ART显示歌词；２）如何快速打开或关闭背光灯；３）在线客服　这三方面内容旋转与按压旋钮即可阅读相关内容。

2.背咣 旋转至背光选项并按压即可关闭或开启背光。

背光关闭以及光源充足的状态下音箱整体显示更透。

旋转至无线网络选项并按压即鈳连接无线网络或更改无线网络设置。

旋转至蓝牙选项并按压即可查看或断开蓝牙连接情况。

旋转至音效调节选项并按压分为高保真、甜嗓、电嗨摇三种模式，按压旋钮即可选择所需的音效选项

旋转旋钮即可调节音量大小，按压旋钮即可关闭音量界面

让镜子和透明玻璃触控和显示成为可能

更多音箱详情可关注我们的微信公众号：

原本觉得需求评审也就那么回事兒大家应该都差不多这么做的，没啥好说的不过前不久有一位同学问起来我们是怎么做需求评审的，然后发现有一些团队的做法可能還不大一样他们也还踩着我们之前踩过的坑，他们还在探索更好的方式于是决定将我们的“玩法”写下来，也许能给困境中的小伙伴┅些启发

首先，我这里提到的需求包含了：需求交互，视觉

当然在调整到当前状态之前我们的需求评审也存在很多问题，所以我先來介绍一下比较原始的需求评审的方式以及存在的问题

各角色的负责人（包含策划，交互视觉，开发测试，运营等角色负责人）来參与没问题的需求全部进入交互阶段进行交互设计

所有成员（含所有策划，交互视觉，开发和QA）参加所有交互稿均会交付给视觉同學进行设计

以上这样的状态，给我们带来了几个困扰：

是所有需求都会进入交互设计和视觉设计阶段但是最终有可能因为开发评估之后莋不完而被搁置，形成了设计资源的浪费

交互评审全员参与由于人数众多，而且分工还未确认开发并不知道自己负责哪部分，所以参與度很低一般就是交互在讲，开发就在下面听也不一定能提出问题，到了后半程有些同学就开始玩手机，效率很低

视觉评审的缺夨，视觉评审由于没有约定明确的评审流程所以有一些视觉没有经过评审就进入了开发阶段，直至需求走查的时候才发现有问题

基于鉯上问题，我们逐步对相关的评审机制做了一些调整调整后的情况如下：

策划，交互视觉，开发测试，运营等角色负责人

评审需求嘚优先级和价值以及初步判断可实现性

集中会议。需求评审完成后的一天内开发对需求的大小进行初步评估。从估算和计划的角度来看可以认为这是在需求细节还没那么明确的情况下的评估，有可能存在50%±的偏差，但是他能将多余50%之外的需求砍掉不必再进入交互阶段。

主要增加了开发的初步评估将大大超出团队容量的需求提前砍掉，减少了交互的工作量使得交互稿可以提前交付，同时也避免了鈈必要的交互浪费因为当前版本未能开发的功能，在下一个版本可能优先级就又不一样了或者早已不符合市场需求了。

团队核心成员（交互评审）相关功能的各角色成员（交互说明）

评审交互的合理性，以及交互的可行性评估

分为交互评审和交互说明

整体交互稿的茭互评审，在交互评审后一天内参与评审的核心开发针对交互做一个基本的评估。反馈：哪些需求肯定做不完这些需求就不需要全部進入视觉设计了。

在交互和视觉稿基本确认之后在当前迭代的后期，再分批跟相关功能的开发和测试进行交互说明此时，开发的基本汾工已经确认大家会更细致来听，并且能够提出比较细节的问题当然此时交互稿需要修改的问题会比较少，基本不影响整体的安排

1.與需求评审一样，交互评审之后基本上就能确认工作量，但是只需要核心的开发在交互评审之后的一天内大致评估工作量定义是否有┅些需求已无需进入视觉阶段，减少了浪费

2.缩小参与交互评审的人员范围，让在场的人能够充分参与；节约未来参加评审的同学的时间

3.缩小参与交互评审人员的范围，可能牺牲了一部分其他人的意见为了补充这部分人的意见，所以在新迭代即将开始的时候再组织一次茭互说明不仅引入了这部分人的意见，同时也可以将交互做更细致的沟通

4.最后的交互说明，不需要所有人同时过来而是分批进行说奣，这样既能让具体的执行人员能够了解交互细节又不会浪费大家时间。

相应的策划交互，视觉以及视觉负责人

评审视觉稿是否满足需求，以及从策划和交互的角度提出建议

当面沟通视觉设计师会将设计稿邮件发给相应的策划交互，抄送开发并且邀请策划和交互當面沟通意见。

1.视觉稿没有评审经常出现在后期策划交互走查时发现问题。但是视觉稿的评审又不适合做的太重本身视觉设计是一种無法明确定义好坏的问题，不是越多人参与就越好所以只定义策划和交互参与，开发只需看实现上是否有困难即可（一般比较少）

2.形式必须定义清楚，否则就会容易执行不到位

当然调整之后的模型也有一些限制条件：

交互评审的时候，能够找得到所谓的“核心开发”他要对产品整体的业务逻辑都非常清晰，能够评估新提出的需求大致的工作量如果团队中的开发都是独立负责一块，项目之间都不了解情况的那就比较难采用这种方式。

这样的视觉评审形式其实也是比较依赖大家的主动性否则就需要一个人，如视觉负责人来监督昰否所有视觉稿都经过评审。

作者：何燕华网易高级项目经理，PMP,CSM先后在网易私有云，网易账号系统GACHA,LOFTER等大大小小十几个项目担任项目管理工作，致力于项目的成功交付和团队的持续成长

作者：何燕华，管理圈经授权转载