关于 微软必应词典客户端 的案例分析
【第一部分】 调研，评测
一、用户采访
1) 介绍采访对象的背景和需求：
被采访同学是马来西亚华裔叶能端同学，由于此前在马来西亚英语是第二语言，因此经常需要使用字典查阅单词。
2) 让采访对象使用10-30分钟必应词典的功能（附上能端同学美照一张lol）
3) 描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
根据能端同学的原话：“在用的过程中，我在yahoo new选了一篇文章的一句话翻译了一下，结果是可想而知的失望。”
“这结果对一个学习过双语（中英）的人来说关键字都出现在内容，但词句排法错误造成翻译错误。
这UI不错，是我喜欢的简约风。在其他的应用我使用了感觉很智能的语音分析“我爱说英语”但是结果让我不敢相信，后来才发现每次测试前必须听已设置好的语音，然后照着他的“旋律”就能获得高分。
语音分析这东西有待加强。。”
“关于bug的发现在 taught，became这些irregular verb 的past tense 自动转跳到infinitive verb。虽然注明了“XXX 是XXX的过去式”，但是用的方式不一样。还有bin，这字和本拉登没太大关系。。。
在过程中发现该软件的名词在翻译句子的中英对照的准确率很高，但是形容词和助词方面不是很理想。”
4) 用户对产品有什么改进意见？
“改进的地方有点多，句子翻译时中英对照有些字对不上，还有前面说的那几个都是要改进的。
这软件解决了在没有网络的情况下可以查阅。”
二、软件的BUG、功能评测
1）软件的BUG
① 功能BUG：例句中英对应出错
该BUG应该是测试中最明显也最严重的一个BUG，我强烈建议软件开发人员能够对这种BUG负责。
如图中所示，第一个例句“And he'll never be able to emerge from his bathos of coarseness and ignorance”，
此句中的bathos应该和trite一个意思，即为后面coarseness的paraphrase，而软件却将其和“那”这一明显意思不同的中文相联系。
在这里我可能查了较偏的文学词汇“bathos”，但是其它常用单词也经常出现这种情况。
尤其考虑到必应词典是一款学习工具，正因为它的职责才需要开发者不能误导使用者。
第二个例句中bathos明显对应中文释意中的“虚伪”，但软件却没有给出指示。
②功能BUG：OCR强力取词
开启了屏幕取词后，打开一篇pdf文档（图片格式），获取到的解释不准确。
测试时，鼠标停留在"those initial sentences later"附近，但程序却给了"and"的翻译。
可见OCR技术还需要进一步加强。
另外，在网上浏览一些带链接的图片时，将鼠标移至图片上的英文不会显示释义。
③软件本身UI错位
笔者测试环境为：win7旗舰版，出现了如上的UI错位问题。
④软件运行导致状态栏错位
该问题出现在打开Bing OCR强力取词的时候，在此之前状态栏排布一切正常。
当打开OCR取词后，状态栏开始错位。
结论：经过这么多工作，你一定有充分的理由给这个软件下一个评价：
经过一系列测试和调研，我对该软件的推荐程度是：一般
Bing比较适合日常生活中上网时查查生词，但绝对不是一个理想的英语学习软件。
第二部分 分析
(参考 8.6 节 对工作的估计， 和14.1 节 软件工程的质量)
1）使用此软件的所有功能（包括必应词典背单词, 单词挑战，口语练习等），联系第二部分的分析，估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）。
在个人设想，若六个人这样分配：1人PM，3人为程序员（熟悉网络编程，其中两人需要承担架构师的工作，一人需要另外承担测试员的工作），2人UI（一人负责代码，一人负责美工设计）。
按照这样的设想，以及正常计算机大学毕业生的水平，对开发流程做如下规划：
1. 产品市场需求调研，功能调研与设计，可行性分析，团队职责划分，规范确立。 1.5week
2. 词典数据库整理，在线数据挖掘算法设计，对应UI框架设计。2weeks
3. 基础查词、查例句、翻译等功能的实现，UI框架代码实现，UI框架和后端代码的耦合。1.5week
4. 部分拓展功能，如：屏幕取词，OCR取词功能等的完成，对应UI框架设计及耦合。1.5week
5. 单机功能，必应生词本、必应背单词、必应电台（单机部分）的完成，对应UI设计及耦合。2weeks
6. 在线功能，完善必应电台，我爱说英语，对应UI设计与耦合。1.5week
7. 全部功能的整合，与后期测试。2weeks
根据上述估计，我设想中的开发周期是12weeks，约三个月左右。
2）分析这个软件目前的优劣（和类似软件相比）
就目前手头在用的我个人认为最好的一款词典软件——Lingoes，两者就如下几个方面进行对比：
此处故意不用有道比较，因为有道太渣，和它比较没有任何意义（曾把我写的文翻译成鬼话，为了保持对Bing的好感，我还未把这个文交给Bing翻译）
1. 核心功能：查词的准确性和全面性
在经过对一些日常常用单词的查取，普通的屏幕取词，图片清晰的OCR取词，Bing词典的表现都算十分不错。
但还是避免不了计算机技术在自然语言处理上的不足，如，查询assume这个单词。
我们将Bing的结果和最具权威的韦氏大学词典放在一起比较，即可发现Bing翻译的不够全面。
针对assume这个单词，Bing缺少了“穿衣(don)” 和神学(Theology)中的"assume to heaven"的意思
PS: Bing依赖于网络信息，而Lingoes的离线功能十分方便。
2. 可拓展性比较
在可拓展性这个方面，两者均有各自的利弊。
Lingoes采用的是词典数据库的方式，需要用户自行导入词库，但正因此它的可拓展性十分高。
而Bing采用的是自身词库（不可拓展），结合网络释义，虽然网络的力量之大可以轻易囊括所有信息，但是要从这些无数的信息中找到合适的并不容易。
因此Bing的拓展性会受到错误信息的限制。
3. 拓展功能比较
Bing词典有点让我非常喜欢，即它根据遗忘曲线科学定制的背单词功能（但还是受限于单词释义的不准确性，我不敢使用）
还有很多有趣的学单词功能，如词缀背单词，口语练习等。这些在Lingoes这款单调的软件上都没有。
同时，我也十分喜欢Bing的OCR图片取词功能。
虽然Bing和Lingoes都有屏幕取词、屏幕划词功能，但是Bing多了一个OCR取词让它一下子出彩不少。
3）推理出团队在软件工程方面可以提高的一个重要部分（具体建议）
从上述分析来看，团队对功能的基本实现都很到位，但是缺乏深入的市场调研，对面向的用户群体把握不是很准。
由于Bing词典的面世较晚，我甚至怀疑它只是对大部分现有词典的借鉴与拼凑。
就目前Bing词典的功能来看，它的查词功能差强人意，并非那么专业准确，但其拓展功能又是面向英语学习者的，这就使得软件的功能自相矛盾。
因此我建议Bing词典的开发团队需要重新审视这款软件的定位，它是仅着眼于日常需求或者专业需求，
还是全面（适合英语学习人士、专业英语从业者与日常用户需求）？
在定位好软件的受众后，可以考虑在团队中加入一些语言学家，虽然语言学家大多数情况下较为刁钻会对软件指出许多不满（深有体会。。语言学家就是种神奇的生物。。）
但若能够经受得住他们的考验，这个软件在专业性上就有了保障。
三、 建议和规划
(参考《构建之法》第8章 功能的定位和优先级；第9章 项目经理)
1. 这个软件有很多可以提高的部分，如果你是项目经理，如何提高从而在竞争中胜出？
作为项目经理用户需求分析和市场调研是必不可少的一环责任。为了履行好这一职责，我会将大部分时间花在市场调查上。
综合地域、教育水平、性格特征、学习目标等多种因素，通过各种因素的组合，进行市场问卷调查和软件试用，并收集反馈。
并以换位思考的方式将自己置于消费者角度进行思考。
2. 目前市场上有什么样的产品了？你要设计什么样的功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用 NABCD 分析。
根据百度软件排行版以及360软件管家两个用户群较大的评价机制得到的结果如下：
可见当前市面上的主要竞争对手是：1. 有道词典（微软认真做的话完全可以比它好不知多少倍吧。。鄙视有道。。） 2. 金山词霸（没用过，不予评论） 3. Lingoes（英语学习阶段强烈推荐）
综合身边同学使用词典的习惯而言，Bing词典完全可以在此基础上引入众多词典的数据库（如果需要收费，可以推出付费服务）。
除了网络释义和本身词库的意思外，必应需要多参考专业的解释，并引入一些特色功能，如引入每个单词的词源历史，每个单词的词根词缀，并根据同义反义关系，词源同宗关系构建知识图谱。
这一功能是当前任何一个软件都没有的！而经过实践证明，这种记忆和学习单词的方式比刷词汇或者Bing里的拓展功能单词本要高效得多！
举个简单的例子：assume = *ad- + *em-，其中*ad- = towards，*em-经过辅音化变成当前的词根sume-意为"拿取"，因此assume的意思可以理解为“向前把...拿取过来”。
经过这样的解释后再来看先前提过的assume所有词义，是不是都觉得能够解释得通也没那么难记了？
assume ：承担（即将责任拿过来）；采用（将采用的东西拿过来）；穿衣（将衣服拿过来披身上）；夺取（将别人的东西拿过来）；上任（将职权拿过来）；（神学）接入天国（将天国拿到自己面前）
除此之外，assume还能和同源词进行同族谱构建联系，如：presume, consume, resume, subsume，鉴于这是软工作业。。这些单词不再一一解释。。
做这一功能最重要的一点是根据我自身和其它同学的体验，发现了这种英语学习方式是很值得提倡的，但当前市面上完全没有此类软件能提供单词的图谱关系。
这导致背单词变成1-1的死板记忆过程，虽然这样可能能在短期内掌握一定量词汇，但远不如通过图谱在长期建立指数型爆炸数量的单词来得划算。
而用户选择我们的理由很简单，第一，我们在基础翻译部分并不比其它软件要差，希望按照常规学单词的用户可以放心选择。而希望尝试不同途径的，我们又有图谱记忆法，拓宽了用户选择范围。
根据NABCD模型：
N：解决的需求很明确，除了常规用户的需求外，提供了新型的学习方式供用户选择。
A：做法即和专业的语言学家合作，并且建立初期试用群体，做产品试用报告，并将结果用于宣传推广，进一步拓宽用户群。
B：提供了一种更高效，不再死记硬背的学习英语方式，并且在市面上任何其它软件上都找不到该功能。
C：就目前调研来看，该市场无人竞争。
D：通过初期用户试用，将其结果作为宣传材料。
3. 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
人员分配：3人为程序员（其中两人需要承担架构师的工作，一人需要另外承担测试员的工作），2人UI（一人负责代码，一人负责美工设计）。
4. 描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件。
1. 产品市场需求调研，功能调研与设计，与语言学家建立合作关系。 2week
2. 词典数据库整理，与语言学家合作整理现有图谱关系；同时UI进行界面美工设计和开发。4weeks
3. 图谱知识库初具规模，进行图谱构建算法的研究；同时UI进行界面美工设计和开发；PM负责开始确定初期试用用户。4week
4. 开始具体实现算法，进行前后端的耦合。2week
5. 拓展功能，将图谱关系和在线功能相结合，增强用户间的交互性。2weeks
7. 全部功能的整合，与后期测试，发布软件并交给初期用户试用。2weeks