在产品的验收阶段，正式发布前一周，紧急动员全公司的人，对1万多本电子书进行人肉测试，
电子书籍质量保证事件分析交互设计
。我觉得这事儿真是有点儿意思。不知道各位怎么看？也许所有的公司或产品都有可能出现类似的状况，但是我想分析一下：为什么会出现这样的事件，有没有什么办法尽量避免出现类似的事情？故事的背景是，公司新研发的电子书设备发布在即；同时，为了丰富在设备上可以阅读的书籍的来源，也在接入一些其它公司的内容，其格式为PDF，而我们公司的电子书本来就是支持PDF阅读。
然而，当最近一周这些内容全部上线的时候，测试人员发现一些很严重的问题。比如：
部分书籍太大，有40-100M，设备表示压力很大，打开就需要1分钟，翻一页要10秒，或者干脆就死掉了。
PDF的排版是固定的，不像EPUB一样是流式的，可以运行时自动调整。而且多数PDF的排版目标是为了打印效果。所以在800*600分辨率的设备上阅读的时候相当吃力。（设备目前不支持触屏，不支持缩放。）
部分书籍含有乱码。
显然上述情况的存在，会严重影响新产品质量。甚至会影响新产品发布。像一开始说的，我们的做法是逐本人肉测试。做这个决定的时候，是一个周五下午5点。我们甚至连完整的书单都还没有。而计划是下一个周二时，第一轮验收要结束。再一个周二产品就要发布了。
动员全公司的人帮忙做测试的时候，很多人都想问事情怎么会发展到这种地步，其实我也想问这个问题。从接入其它公司内容这个想法出来，到找其它公司洽谈，到我们技术上实现接入。所有人似乎都只看到了一个美好的愿景，却对其中潜在的问题视而不见。当然，一开始也有人提到要找一些样书来看看，但是“看看”就够了吗？
什么样的书可以作为接入可行性的样书？各种类型、大小、编码、章节细分度、字体大小、图片多少、原生/扫描…等等…的组合？
样书拿来之后，用什么样的标准来判定？有多少指标？应该要有文档化吧。
样书判定不合格就不接入了吗？
设备还有没有优化的空间？让更多的书合格？
我们觉得合格了，最终用户觉得就是无法接受怎么办？
部分样书不合格，但是决定接入，那如何在所有书中找到所有不合格的书？
书籍合格性判定，能不能自动化？还是一定要人肉。
如果可以自动化，是不是要开发自动化工具，需要多少资源？
如果不能自动化，需要以什么样的方法判定？找实习生？临时工？他们的判定结果的质量如何控制？
其实上面这些问题我也是事后总结的。但是事前详细想想也是可以想到很多问题。但是在下面的形势面前：
接入的事情迫在眉睫
我们的设备本来就是支持PDF阅读的
公司战略目标就是要丰富内容。人家谈判那么久，你这那那这的，为什么不先花时间接入进来再说？
我们同时接入的第三方有很多。
当时的工作重点，是不惜一切代价地把内容接入进来。一切问题都可以认为是我们的问题。在这样的大环境下，内容接入以外的事情都是次要的。到了验收阶段，产品质量就成了主要矛盾，就需要花大力气解决了。听起来很合情合理。细想起来真是屎一样的逻辑，无脊椎动物的逻辑，
电脑资料
《电子书籍质量保证事件分析交互设计》(https://www.unjs.com)。产品质量监控应当贯穿于产品的每个阶段，每个环节。问题暴露得越早越好。这样做事情才像是发现问题，然后解决问题；而不是遇到问题，然后打补丁。理想状况下，二者最后结果可能会一样，但是过程却是完全不同的体验。在第一种环境下，只要你喜欢这份工作，你会乐在其中，享受过程；在第二种环境下，即使你喜欢这份工作，也会被搞得焦头烂额，身心俱疲，最后被补丁埋葬。
相对于写代码而言，尤其是已经有了设计的问题，想问题才真正属于脑力活。这里说的问题并不是指设计问题，软件设计也是脑力活，但是依然局限在某技术框架之中，有了经验，设计也是体力活。这里指的问题是整个产品的设计方向，整个公司的做事方式，市场永远是变化的，永远都有新的问题出现，永远是优胜劣汰。有人觉得这不是技术人员做的事情，此言差矣。像上面列出的一些问题，可以从技术上解决的就从技术上解决，但是很多问题不是单纯的技术问题，甚至可能会为公司引入一个新的部门，这不就是一个问题引发的工作机会吗。谁想到了这些问题，谁自然就有发言权（当然可能没有决策权）。
重要的是，是事前把问题提出来，并文艺地解决掉。还是等到用户投诉电话打来了，才发现自己要被领导骂成2B了？现实可能比较普通一些，也最普遍，问题非要到大规模测试的时候才能暴露出来，虽然能保证用户看不到问题了，我们也得累得和2B一样。但是这样的状态谁想要？
所以可能一些刚入行的程序员，常常抱怨自己的老大P事儿不干，就喜欢说大话。当然，我不否认很多老大的确是这样，但是一个称职的老大的确应该是P事儿都不干，代码一行不写。因为他有更重要的事情要做。他要想，应该做什么，不应该做什么，先做什么，后做什么，做到什么样是OK了，把什么事儿分给什么人做，做的过程中可能会出现什么问题，有什么应对的策略。总之一句话，能保证项目按时保质地完成，就是合格的老大；同时能让手下很文艺地工作，天天很Happy地回家，那他就是一个NB的老大。
所以老大的一个重要职责就应该是把工作给手下讲清楚，做什么，不做什么……，当然，老大如果充分信任自己的小弟，也可以让小弟自己全权负责。但是其实这个时候很容易出样下面这样的情况。
老大：我手上有200张票，明天的，你发一下。
小弟：好。
小弟想了想，为了让更多的人享受到这个福利，同时也做推广，决定以家庭为单位，一家一张。于是发给了200个人家。
小弟回来向老大汇报工作。
老大：我X，你为人家想想好不好，想去还再掏钱，你应该一家发三张，一般家庭都是三口之家。
小弟：……
大家也不用考虑应该怎么发票，这完全是我YY的情节，有些事情只关于做事的方法和理念，没有对错。每个人关注点不同，方法自然不同。也许所有事情都有个最佳方案，但是一般都需要一定的调研才能得出结论。比如上面的例子，如果想要知道哪种发法收益最大，恐怕要调研一家人拿到一张票时，有多少比例会去买，有多少直接放弃。和一般和是什么票有关系。但是首先要判断调研值不值？时间够不够？要效率还是要效果？多数情况下二者是难以兼得的。老大有自己的考虑，小弟也有自己的考量。谁对谁错？Who knows. I don’t care. 但是这时候，你觉得最重要的是什么呢？
从项目和公司的角度而言，最重要的就是事情有没有搞定。所以无论票怎么发，事情最终是搞定了，小弟也体验了把自己做主的感觉，过程也不错。只是老大觉得搞得不漂亮，然后小弟估计也开心不起来。说到这里，我觉得我的意思已经表达清楚了。
感觉说得有点儿远，其实说的是同一个事儿——为什么事情会发展到这种地步。当然，上面只是我个人的一点儿想法。我也还没有真正做过Leader，也许我做Leader之后会有更加不同的理解吧。