这是我做的一次内部分享，回顾一个项目的心得。项目是音频直播间，用户可以实时听到不同嘉宾访谈。多位嘉宾通过电话会议直播交流。一些内部资料图做了模糊处理。
我今天想分享的是App功能开发完成，也测试的差不多了，到第一场线上直播正式开始之前的故事。
通常这个阶段时间是非常短的，但直播间发生了很多故事。我从头开始说。
一 测试阶段的启示
1. 测试像打开俄罗斯套娃
当一个还不算小的版本上线前，产品经理一般会经历这么一个阶段。测出了一堆bug，有些是高优先级的必须改掉，有些是还可以忍的。通常产品经理会不断降低自己的预期，出来一个还算满意的版本。
当有了这个版本之后，可以上线了吗？
直播间和一般的功能不同。实际直播的流程除了App的部分，还依赖其他的硬件。直播时，嘉宾身处不同的地方，通过电话会议交流，他们的声音通过设备传入电脑，利用电脑上的OBS（这是一个公开的录制直播的软件）到达App。这些硬件音质如何，测过了吗？
OK，于是开始安排硬件测试。中间经历了一些波折，相关同事尝试了不同的硬件。总算我们有了一个还算满意的音质。
App测过没什么问题，音质也还算满意，可以上线了吗？
有一天突然想到，我们还没有模拟线上真实的流程测过啊。平时都是用的自己的笔记本上安装的OBS，随便放首歌，连通硬件测试。可线上用的是会议室的电脑，接的是电话会议；而且，平时都是看能连通就OK了，但是真实的场景，用户是连续听1-2个小时。
于是我想，那就模拟真实场景都走一遍，老老实实听个几小时，如果没有问题，就可以上线了呗。我们这么测完了，可以上线了吗？你们一定猜到了，还不能上线。
问题是，这回更严重，这一轮测完，我简直崩溃了。
我们当时发现一个问题，iOS掉线。就是说，你听着听着，突然声音没了，需要退出重进直播间恢复。
iOS掉线！这意味着什么？
这意味着我们前面做了那么多的努力，那么多的测试，但是都等于0；意味着上线前和开发这么纠结撕X，说什么直播时进度条没有用那么丑得拿掉，但回放时得有..UI什么地方丑..并因此一次次推迟上线时间...而那些都没有意义；这意味着大家可能会质疑，你们测了那么久，这么严重的问题，难道一开始没有发现吗？还真发现不了，因为一开始你测试的重心不在这里。
所幸我们还有些时间。和开发团队商量了，觉得这可能和两个因素有关，一是网速，二是iOS到后台有可能杀进程。
于是我就做了一下实验。这张图是某个周六下午做的一个实验，那时我的手机屏还是碎的。
左边3台苹果先在同样的网络环境下播放40分钟；然后碎屏这台切换到更差些的网速再播放40分钟；之后右边这两台切到后台，中间这台不动，同时碎屏机还在操作各种其他App，再放40分钟。
这个实验做完后我就更崩溃了。因为并没有发现什么结论，掉线的情况似乎和那两个因素都没什么关系。
但在这个过程中有几点比较欣慰的发现，使得我们最终决定上线，这里不做详细叙述。而我们线上几次直播并未出现掉线问题。
2. 启示
这是整个测试阶段发生的事，这中间给了我几点启示。
一是永远不要对复杂的问题抱有短视的预期，认为自己所见所知范围内没什么问题就不会有大问题。不要把解决方案当做是终点。一个问题有了解决方案后也可能有其他的问题。
当你抱有这样的预期的时候，一来当你遇到困难的时候不至于太崩溃，因为你对困难是有预期的。二来正因为你有预期，才会尽早的去发现问题解决问题，而不会想法安逸，行动太晚。
尤其是当你以体验派的方式了解事物的时候更需要这样。
我对OBS、硬件等一开始是不了解的，我是以体验派的方式去了解的。
什么是体验派？举个例子。
在早几年，我还年轻的时候，那时候对琳琅满目的化妆品很不了解。化妆品有很多的种类，也有很多的牌子，哪种有什么作用，不同品牌有什么差异都是不了解的。这时候我发现市面上介绍化妆品的资料分两种。一种是大S、牛尔等明星写的。他们了解的方法是，把所有化妆品都体验一遍，然后告诉你每种用起来是什么感觉，皮肤有什么变化。他们用的就是体验派的方法。
而市面上还有一类书，像右边这本是一个叫张丽卿的人写的。她是一个化学博士。她会告诉你过氧化苯有杀菌的作用，十二烷基硫酸钠能去脂。她是从化学成分的角度，用一种解构的方式了解事物。
我一开始对OBS、硬件不了解，就一遍遍的体验，而体验派的方式，由于不能把所有可能都体验到，永远要准备着遇到问题。而更好的其实是用解构的方式去了解它们。
另一个心得是重压之下，方知极致用户体验。
在整个测试过程，我听了10多个小时的音频。我听的是蜻蜓FM的节目。这10多个小时之后，我终于知道了蜻蜓FM里声音最好听的节目是哪个。
我一开始听的是高晓松的《晓说》，因为我个人比较喜欢他。但是发现他的声音多听几个小时真是受不了。
我们的用户来直播间，固然是来听内容的。我们的嘉宾请的是否牛X，讲的是否精彩当然是最重要的。但是音质，不说噪音，就是嘉宾的声音对用户的感觉、体验实际上也是有刺激的。虽然我们不会要求用户10多个小时地听，但如果我们追求极致用户体验的话，音质也是需要有高要求的。
这里我想到了另外一个事。前阵子我家的网速特别慢，在线看视频很卡。几乎所有的App都会卡顿，爱奇艺、搜狐、乐视等等。只有一个App可以顺畅播放，是腾讯视频。从此我成了腾讯视频的真爱粉。所以我想在最差的情况下，还可以让用户能用，甚至给他还不错的体验，这就是极致的用户体验吧。
二 庞杂流程如何迅速完善？
整个测试阶段结束之后，我想一切总该结束了吧？但是却发现，还有一个更大的坑….
我们第一场直播，主持人和两个嘉宾都在场外，三个不同的地方，有一个还在国外。
如果直播过程中，有一个人声音突然变小，怎么提醒他？如果有人突然断线了呢？国外的哥们是凌晨5点开始，如果他睡过头了呢？那场直播前，iOS还没有审核上线，如果没有审核通过呢？事实上也确实没过。那就得用文字版，是不是得有人听录？我自己试过听录一会，发现一个人是完全来不及的，那就要至少安排2个 人，2个人3个嘉宾怎么分工呢？更别提直播过程中如果有各种意外呢？
于是我把直播前要做的事大概列了下。看到这张表就傻眼了，如果每次直播都要做这么多事，那以后产品还做不做了？
幸好之前衣总有关照过协调的事可以交接给峰兄。但是怎么交接呢？说一遍吗？那下次直播呢？如果忘了呢？如果峰兄不做了换一个人，还要再从头到尾带一遍吗？
于是这张表在设计的时候我做了两件事情。
一是时间这块，这场直播20:40开始，我设计的时候并没有考虑20:00做什么，20:30做什么。 而是考虑提前1小时做什么，提前半小时做什么，后来这张表做了一个公式，只要填开始时间，就能自动出来每个任务对应的时间点。
第一场直播有给每个人分配任务，知遥做什么，大为做什么，大红做什么。但是如果每次都是告诉不同的人你应该做什么事情，下一次，来不同的人，又要费脑安排下哪些人做什么事。所以设计表格的时候并没有写谁谁谁做什么，而是把角色抽象了出来，例如这里的测试人员、硬件监控人员等。不同的事情按角色分配。那么下次，只要指定好谁是什么角色，每个人就能迅速了解自己要做的事。
这样以后峰兄只要根据每次直播的实际情况调整流程，完善这张表，流程很快能跑起来。
第一次直播为了保证顺畅进行，有问题及时处理，我把所有对直播流程比较了解的人都留了下来，大为、知遥、大红。但是，难道每次这几个人都要在吗？
直播中最严重的突发是没声音。于是我做了没声音排查的流程，并逼着负责硬件的同学做了硬件排查流程图。当协调同学学会排查流的问题，就把大为解放出来了；当他学会排查设备问题，就把知遥解放出来了。
有了这些图，下次，我们也可以找其他同学来做这些工作。
所以总结一下，流程设计要想的不仅仅是眼前的这次直播，永远要想下一次呢？第N次呢？
这就是我今天想分享的。人生不只有眼前的苟且，没有诗和远方，只有下一个苟且，谢谢！
