=.=最近一直疲于优化语标平台的用户体验内容，深深感觉到没有产品在场的绝望感。
语音标注平台，也就是这差不多几个月来我在公司的主要工作。但是由于其实是一款对内使用的产品（虽然宣传长远发展来看是对外外包平台），再加上公司现在业务发展太快，很多时候分配到业务前线的资源都不足够，那就更别提对于基础架构方面的关注了。自然，整个项目启动之初就只有我和付总进行整个项目的设计探讨，实现的话前后端都是由我独自进行实现。虽然启动之初，稍微花费了点时间去探索各大平台的设计思路，但是由于自己其实在这些平台看到的都是从一个外来的标注人员的角度，更何况很多此类平台对外程度并不大…更加严重地导致你没办法全面地把控这么一个系统要如何设计。
于是很大程度上都依赖于自己对系统的探索和思考，为了尽可能地避免后期的推倒重来，所以一开始在设计之初就花费了很多时间进行架构流程的设计探索，但是最近随着语音组对标注数据逐渐地扩大要求以及再加上标注组的人员扩张，平台的功能缺乏以及设计缺陷疯狂暴露，于是乎这几周都是忙于添这个功能删那个功能的。趁着有空，想总结一下这次经历的一些所得吧。
了解需求，剖析
首先，在接到一个需求任务的时候，千万不要动手实现代码。学会去剖析需求，理解需求，然后反馈探讨再反馈。简单而言，先从大局入手从宏观的角度进行脑海编程，不考虑细节处理，只考虑大体的逻辑架构。对于不清晰的部分，果断上网查是否有已经完成的技术方案可以借鉴参考。例如这次一开始接到标注平台的需求，我第一反应就是算法组的同事低估了这套系统的复杂性。当时提出的要求就是可以标注音频的文本，然后得到正确答案让他们进行模型训练，的确从系统的主要功能来看真的是一个特别简单的甚至谈不上是系统只是个工具。但是加上对标注员的管理，对标注结果的管理（审核、反馈），针对不同标注任务的扩展性…等等考虑之后整个系统的复杂性就蹭蹭往上走…再加上我身为一个实习生，交给我去设计这么一套系统真的没有信心能从开头就设计得好不留下任何坑，以后不欠技术债。但是没办法，既然来任务了就得认真去执行嘛。
于是第一时间，我就开始上网找是否有已经存在的技术方案，参考了有关接触了解了讯飞标注平台、海天瑞声等标注软件的实现逻辑，从页面的一些功能点显示了解到了整套系统大概的技术实现。但是正如上文所提到从一个使用者的角度来看，其实只是管中窥豹没办法从管理员的角度更别说一个技术人员的角度来思考这个问题。
及时反馈，多多探索
由于我和付总都不是一个有设计一套系统经验的人，但是付总身为一个最终的需求方，对最终的数据要求其实是有一定程度上的了解的。所以在设计之初，我拿到一个大体的解决方案之后就找付总对清楚了他的需求从而确保平台最终输出结果是正确的。
但是很快我就犯了一个严重的错误，不论是我还是付总，其实我们俩都不是一个平台使用者，我只能从页面操作上给予建议设计以及实现。付老师只能知道他需要拿到什么数据，乍一看好像这中间完全没毛病，我来设计系统的操作，然后保证输出的结果符合数据组的要求。但是我强行架空了平台使用方，平台管理维护人员对平台的需求。（这有一点原因是因为数据组的大佬很忙并不是特别有空和我们对接这件事，另外一个重要的原因还是我没有主动去理清楚这个需求导致的），身为平台的管理者他需要什么信息，已经管理过标注团队的领导其实很清晰自己的需求，但是我却忽略了这一点只是单纯地从自己的角度出发来看这个问题，从而埋下了很多雷。比如，当时我认为平台要求数据的准确率应该设置一个阈值，但是数据组那边给出的要求是对于训练模型数据要求正确率能达到100%，于是做了一个近乎白痴的决定“数据标注没有达到100%正确率必须走打回逻辑。”这显然是不合适的。这就是没有及时反馈对接导致的严重错误
不要害怕设计，试错然后迭代
诚然，我承认由于自己的疏忽，前期导致系统设计上很多问题。但是其实更多问题是出在项目进行时暴露出来的问题。这一款产品，对于整个市场可能是一块已经被摸索透的领域（但是由于没有有相关经验的产品以及市场上的封闭性）其实开发这么一套系统我们还是一个初学者。这时候不能期盼自己能一步到位，相反要学会将以后此功能能方便移除接入的角度来考虑问题。设计上要尽可能地足够扩展性，拥抱变化快速迭代。当然其实这方面我做的真的不足够的好，很多时候加一个功能都会对前面有兼容性的冲突。
最后再总结一下语标平台的一些我觉得值得注意的功能点。
- 按照时间领取派发以及标注，乍一看所有音频派发到平台上其实是按照一条一条的内容来派发，直观地感受你会认为领取任务应该按照条数领取。但是对于管理者而言，一条音频时间可能会1秒到30秒不等（也有可能是我们语音组这边对音频处理的不同逻辑），这样派发的结果会导致工作量不可预估。
- 速度而言，应该减少数据流的链路。设计之初，标注员、审核员、管理员三个角色，标注员负责数据的标注，审核员只负责审核数据是否标注通过，而管理员可以最终把控数据是否标注正确特殊情况下可以进行修改操作，更多情况下标注不正确直接打回到标注员身上。这样的角色设计乍一看职责清晰，有问题必须给到标注员进行反馈修正。如果按照理想的流程，数据流可能就三步走。但是更多情况，数据流可能会在审核员和标注员之间疯狂死循环。这对于急着拿一批数据来使用的平台是显然不合理的。在新的设计上，审核员审核不通过后要求主动修改正确答案，这样虽然加重了审核员的负担，但是却可以减少打回的时间链路然后在审核员层面做出一个比较彻底的质量把控。
- 数据统计，字错误率，废弃率等有关语音识别相关的数值要学会去统计衡量数据质量。也就是专有的领域有必要去提供该领域下的知识。
- 做好对平台管理者和最终交付方两方面需求的考虑满足。缺乏任何一方都是不合理的。
- 明确的优先级需求并督促相关人员务必查阅并给出优先级建议。不要自己擅自决定优先级顺序，结果交付时候有重要功能却没有上线。
大概这么多吧，其实感悟还有很多，但是emm 可能太久没写文章了，大概总结到一半就有点弄不出东西来了。 就酱，继续加油吧~！