天天看點

第四次作業——個人作業——軟體案例分析

測試産品:必應詞典Win7用戶端,iPhone用戶端

Part 1.調研與評測

評測:與其說是找bug,不如說是找不合理的地方。

  • The first:

    在使用PC端時,上方的菜單欄同時存在詞典和例句兩個選項。在例句頁面下輸入需要查詢的語句後,如需要在某個句子中再細化查詢某個詞彙,點選後,自動跳轉到詞典頁面下,但傳回例句頁面後卻同樣顯示了需要查詢的詞彙,之前查詢的例句需重新輸入或通過傳回鍵傳回。

例如:查詢“好久不見”這個句子,需要細化查詢fortunately這個詞。如下圖:
第四次作業——個人作業——軟體案例分析
可以在詞典頁面下查詢,同時注意到此處已經顯示了例句:
第四次作業——個人作業——軟體案例分析
點選例句頁面,發現此處也查詢了fortunately,而之前的“好久不見”需要通過傳回找到:
第四次作業——個人作業——軟體案例分析
通過以上的例子,會發現似乎詞典與例句這兩項功能不需要細分。至于産品組的人設定這種區分的用意我想是希望PC端的使用者能夠更好地體驗例句這項功能,但個人認為在這點上的區分并沒有很成功。使用手機發現在ios端的确就是如此,如下圖,并未區分單詞查詢和句子查詢:
第四次作業——個人作業——軟體案例分析
  • The second:

    在使用必應電台時,當需要切換到新電台時,無法立即播放未下載下傳的電台,而是自動跳轉到播放清單中已下載下傳的電台進行播放。相對于酷狗音樂,網易雲音樂等音樂軟體可線上播放為下載下傳歌曲,這是一個問題。産品組人員或許已經了解了電台的使用流程,總是預設去下載下傳了想要聽的電台再播放,而是以忽略了線上播放。

例如:播放清單中《I Have A Dream》為已下載下傳電台,而《A Whisper of AIDS》為未下載下傳的電台,當點選播放《A Whisper of AIDS》時,無回應而自動轉去播放《I Have A Dream》。
第四次作業——個人作業——軟體案例分析

采訪:

使用者的背景及需求:受訪者是我們學院的一位學長,目前正在準備雅思考試同時對英語學習有一定興趣。這次試用的是必應詞典ios用戶端,此前習慣使用有道詞典。(接下來的内容為受訪者原話)

1.學習英語的目的:學英語為了興趣,還為了參加雅思考試。

2.用法及需求:一般是遇到生詞,或者忘記詞的意思會用手機查詞典,查詢單詞的意思,還要看看例句和近義替換詞,甚至反義詞。

3.使用過程:

   描述過程:打開app開始查詞,大部分問題都能解決。

   資料量:單詞本沒有雅思、BEC之類的詞彙

   功能:有個地方很尴尬,比如我查take,然後在詞組裡面選擇一個詞組就跳到take care的界面,點選傳回卻傳回了初始界面。

   準确度:個人英語實力還不夠,手上沒有權威的詞典不敢亂下定論。

   使用者體驗:界面挺簡潔,用了20分鐘也沒閃退卡頓之類的,想發現問題還需要長期使用吧。

第四次作業——個人作業——軟體案例分析

4.改進:針對使用過程提到的問題完善吧。

5.結論:推薦吧,其實主要還要看個人習慣,畢竟習慣使用一個軟體需要時間。

Part 2.分析

  • 項目用時預估

    《建構之法》中提到用時預估與項目的複雜程度相關。而項目的複雜程度則取決于需求複雜程度和技術的複雜程度。以上這些都與程式員的經驗息息相關。假設中計算機畢業生的項目經驗是未知的。若了解為這些畢業生隻有較少的項目經驗,或許隻經曆了我們的軟工實踐課程這類實踐。進而預估用時為6人,三到四個月完成該項目。

  • 優劣對比分析

優勢:1. 更多的拓展功能:必應擁有單詞挑戰、我愛說英語、必應電台等拓展應用,相對于有道,金山等可拓展功能更多,給使用者更多新鮮感。

   2. 更精确的發音:必應詞典擁有公認的準确發音,然而市場上其他詞典在發音方面或多或少存在着模糊或不準确等缺陷。

   3. 首頁資訊量大:必應首頁包括了句子、單詞、閱讀等内容,英文内容占有比例大于80%,且閱讀的文章出自各大英文主流媒體的新聞,有權威性與可讀性,同時廣告的植入較少。而有道詞典的首頁更多的是一些娛樂性的文章,對英文學習的幫助不大,也使學習者更容易分心。

劣勢:1. 無離線詞庫及發音庫:相對于有道詞典,金山詞霸等同類軟體都可下載下傳離線詞庫及發音庫,必應在這方面處于劣勢。當使用者關閉資料流量的情況下,查詢詞語就顯得不便。

   2. 無攝像頭取詞功能:目前有道,金山等都可通過手機攝像頭取詞識别并翻譯,但必應還缺乏這項功能。

   3. 移動端的翻譯僅限中英互譯:必應的翻譯功能僅限于中英文之間的翻譯,相對于有道,靈格斯等,提供了其他語種間的互譯,必應在這項功能上比較局限。

  • 團隊可提高部分

    團隊在軟體工程方面中可更注重使用者回報,通過設定回報信箱等回報管道,收集使用者回報。并提取關鍵字進行實時排名,檢視使用者最關注的問題及需求,重點在這些問題上改進,與使用者保持良好的交流,共同促進軟體更好發展更好為使用者提供便利與服務。

Part 3.建議與規劃

  • 如果你是項目經理,如何提高進而在競争中勝出?

根據功能分析的四個象限,針對軟體的殺手功能采取“差異化”辦法,全力投資于該領域;外圍功能及必要需求則采取“抵消”辦法,快速達到與同類産品齊平的程度;而輔助功能則采取“維持”辦法,以最低代價維持,進而實作資源最合理的運用。

同時引入權威詞典,必應詞典因其準确的翻譯以及清晰的發音為大多數人接收,通過引入權威詞典,無疑能夠吸引更多追求學習标準精确英語的使用者。

  • 目前市場上有什麼樣的産品了?
目前市場上的同類電子詞典大多支援查詢、翻譯、單詞本等功能,其中很大一部分支援取詞劃譯以及攝像頭取詞等拓展的查詢功能。
  • 你要設計什麼樣的功能?

1.在手機用戶端的首頁推薦的文章添加取詞劃譯功能,使用者可以導入本地檔案,将自己需要翻譯的文章或語段導入,實作實時的取詞劃譯,而無需手動查詢文章或段落中的某個詞彙。

2.拓展攝像頭取詞、離線詞庫及多語種翻譯功能。

  • 為何要做這個功能,而不是其他功能?

1.首先首頁推薦的文章或某些使用者想要學習的文章為純英文,許多初學者或英語水準的不高卻正緻力于學好英語的人,這些文章對于他們而言要閱讀下去較困難。若能提供實時的取詞劃譯功能就能幫助他們的閱讀,使得首頁的推薦對于他們而言是有意義的。

2.攝像頭取詞、離線詞庫等這些功能作為必要需求已經在同類産品中運用廣泛,我們需要通過“抵消”辦法,做到和競争對手做到差不多,而不讓這些功能成對對手的殺手功能。

  • 為什麼使用者會用你的産品/功能?
使用者使用詞典的第一需求就是查詢準确,其次是其他的拓展功能,輔助背單詞,閱讀英文文章等。我們的産品緻力于詞彙的精确,以及語音發音的準确清晰。我們的第一關注點就是使用者的第一需求。使用者可能會嘗試使用同類産品,但在對比後會發現我們的詞典最權威最準确。
  • 你的創新在哪裡?可以用 NABCD 分析。

采用NABC分析

Need:詞典的對于使用者的第一需求即查詢和翻譯。使用者需要翻譯大量句子時,需要手動完成或進行複制粘貼,同時不能選擇某個詞組進行實時的翻譯。在閱讀首頁的推薦文章時,對于不了解的詞彙也無法立即通過取詞劃譯查詢。(以上這些指的是手機端)

Approach:添加導入檔案和實時取詞劃譯功能,将存儲于本地的文章放在手機用戶端上翻譯。同時首頁推薦的文章也可實時取詞劃譯查詢。

Benefit:使用者不用手動在詞典中輸入文章中某個不懂詞彙進行查詢,避免了文章界面與詞典界面之間的切換,提高了閱讀效率。

Competitors:目前市場中的其他詞典也還不具有該功能,盡管可以用攝像頭直接對紙質文獻取詞,但存在光線降低識别率的外部因素。

  • 如果你來上司這個團隊,會有什麼不一樣?
更加注重團隊中每個人發表意見,擁抱每個人的差異,鼓勵每個人表達自己。當然最終需要PM來權衡利弊,擁有最終的決定權。我認為這樣的團隊更自由,使每個團隊成員都願意為項目提供自己的意見,使每個人有一種真切為自己和團隊而工作,而不是為别人或是機械的完成PM布置給自己的任務而已。
  • 如果你的團隊有5個人, 4個月的時間,你作為項目經理,應該如何配置角色(開發,測試,美工等等)?

開發人員2名,同時完成個人編碼期間的測試工作及文檔編寫。

測試人員1名,該測試人員為總的測試人員,負責量化的測試。

文檔人員1名,該文檔人員同測試類似,負責整個項目的文檔,整理歸檔所有文檔檔案。

  • 描述你的團隊在16 周期間每周都要做什麼,才能在第16周如期釋出軟體。
通過一個表格來說明:
時間 工作
1 分析需求,形成需求規格說明書
2 完善需求,完成需求規格說明書終闆
3 編碼規範,平台環境搭建,初步架構搭建
4 生成設計文檔
5-6 UI設計,架構設計,測試計劃
7-9 第一階段具體編碼,編碼、測試、項目管理、文檔同步進行
10 代碼複審,集中測試,形成第一版完整文檔
11 使用者試用回報,測試計劃改進
12-13 第二階段具體編碼,完善第一版本,編碼、測試、項目管理及文檔同步進行
14 第二版本完善,文檔人員整理形成初步使用者手冊
15 正式版本釋出
16 部署上線