APP案例分析

標籤：火車站   簡約   網路拓撲   live   原型設計   簡便   不同的   軟體工程   應該   

今天探討的APP是：鐵路12306。

選擇這個APP,是因為使用了很多年，很有感觸。

 

第一部分：調研、評測：

1、下載軟體並使用起來，描述最簡單直觀的個人第一次上手體驗。

第一次安裝這個軟體的時候，是三年多前，為了購買學生票，在那個時候，鐵路12306APP經常會出現卡頓狀態，遠比現在差很遠。隨著這幾年不斷的更新變化，從驗證碼的圖片選擇，系統的不斷完善，改善了很多，但是還是有不足的地方。

 

2、按照《構建之法》13.1節描述的 bug 定義, 找出幾個功能性的比較嚴重的 bug。

（1）軟體流暢性不好，經常卡頓。

（2）今天是9月30日，明天就是國慶。發來簡訊說到期時間，還下載失敗，無疑增加乘客的憂慮，然後乘客只好登入鐵路12306APP查詢車票，訂單查詢分為已完成訂單和未完成訂單，已完成訂單還分為今日訂單、未出行訂單和曆史訂單。曆史訂單應該包括今日訂單之前的訂單才對，然而並不是這樣，它只是包含了曆史已出行的訂單，難道未出行的訂單就不是（之前訂好的訂單）嗎？總之查詢訂單做得比較不好，介面文字不夠直譯。

（3）就是學生票問題，由於是學生，所以在自己的這一欄就是學生狀態。在買票的過程中，除了假期能買學生票之外，其他時間段都不行，系統不會自動改為成人票，不是學生票區間，提示學生票需要證件，然後點擊轉換成成人票時，經常出現卡頓狀態，然後顯示成人票，也可能購買成學生票，就經常會買成學生票，然後改成全票很麻煩，如果沒有票的情況下，退票就直接沒有票了，這時候只能去火車站售票點改全票，十分麻煩（因為改簽人特別的多）。所以如果不是要買學生票的情況下，我想大多數人都會通過攜程之類的平台購買了。

　　以上這些只能說是問題，或者邏輯不對，至於嚴重性的Bug,倒是沒有那麼嚴重。

3、用專業的語言描述 (每個bug 不少於 40字)，如有必要, 配圖更佳。

（1）癥狀：輸入出發點查詢後，時不時卡頓。

程式錯誤：應該是資料量太大，讀取資料的時間就非常慢，資料庫的檢索功能不好。

根本原因：一直在就緒狀態，沒有得到執行。（我猜的），雖然也經常提示網路連接問題，但是別的軟體又不會。

（2）癥狀：查詢車票太繁瑣，不明確。

程式錯誤：分得太繁瑣，導致程式也得相對應的寫很多不需要的東西。

根本原因：設計邏輯不好，因為是登入後的，所以可以直接顯示本人未出行訂單，然後所有的訂單都放在曆史訂單裡面，至於其他人的才更改預設使用者姓名進行搜尋就可以了。

4、選擇一個朋友（使用者）進行採訪，並加以記載。

採訪同為學生的L同學，通過鐵路12306APP購買動車票的體驗。

5、提示: 採訪提要

（1）介紹採訪對象的背景和需求。

採訪對象：周邊的人（學生居多，因為有購買學生票的事）。

需求：需要訂購動車票。

（2）讓採訪對象使用該產品的功能。

（3）描述使用者使用這個產品的過程，使用者的問題解決了嗎？軟體在資料量/介面/功能/準確度上各有什麼優缺點？使用者體驗方面有問題嗎？

使用者使用這個APP的過程，卡頓現象還是時常發生。資料量肯定是完善的，介面很簡單（其實可以增加很多方便使用者查詢的介面）。功能上來說，查詢不夠直接，需要改進，還可增加出發點和終點大眾運輸路線等等功能。根據地點還有時間段，把學生的學生票選項直接變成成人票。體驗方面，卡頓狀態能去除最好。

（4）使用者對產品有什麼改進意見？

提高APP流暢度，完善查詢功能。

（5）結論：經過這麼多工作，你一定有充分的理由給這個軟體下一個評價:

一般。

 

 

第二部分 分析

 

1、儘可能地使用軟體的所有功能 。

 

主要功能為：登入（實名認證）、車票預定、訂單查詢、查正晚點等等。

 

2、分析這個軟體目前的優劣 (和類似軟體相比)， 推理出這個軟體團隊在軟體工程方面可以提高的重要方面 (具體建議)。要求把對比的結果列出一個表格，對比每個軟體各自的優點和缺點。

	鐵路12306	攜程旅行	去哪兒旅行
流暢度	最卡	最流暢	中等
介面	簡約	花俏	花俏
功能	少	多	多
廣告	有	有	有
優惠券	無	有	有
優點	介面簡單，操作較為方便， 火車站官方APP	流暢度很好	問題查詢方便，有很多問題的總結
缺點	流暢度太低，功能比較少，查詢不夠方便	功能太多，介面太花俏	功能太多，介面太花俏

 

 

3、針對不同的維度評分，對使用者體驗方面、UI介面美觀度、核心功能，分別打分

維度	評分	評分原因
使用者體驗	8分	系統經常卡頓-2分  驗證碼+1分 查詢問題-1分
UI介面美觀度	9分	介面較為簡單清爽（相比其它是加分項）
核心功能	7分	學生票問題-1分 車票查詢-1分 無線上客服-1分
個人化	9分	增加了商旅服務（訂餐、約車等）

 

第三部分 建議和規劃

1、如果你是專案經理，如何提高從而在競爭中勝出？

利用這個火車站官方APP的優勢，努力把軟體流暢度提升起來（最重要），增加查詢的一些功能，比如常見問題總結、訂單查詢需要更加的直譯等等。

 

2、目前市場上有什麼樣的產品了？

購買火車票已經有很多網站，用得較多的有攜程旅行、高鐵管家、去哪兒旅行和同城旅行等等，這些購買火車票都很方便。

 

3、你要設計什麼樣的功能？

設計常見問題總結欄，完善訂單查詢介面以及相關功能和學生票的功能完善，還有就是購買哪趟車提醒的功能。有些軟體有搶票的功能，這個行為不是太好。

 

4、為何要做這個功能，而不是其他功能？

因為學生票的關係，長期使用這個軟體購買車票，對這些功能很有感觸。有相關問題總結欄，可以方便購買者瀏覽，出了問題，自己有個怎樣行動的方法，不然還要去網頁查詢或者詢問他人等等，很麻煩，訂單查詢功能，現在的也不是不好，不夠直接，還有就是不是很方便，因為已經登入過自己帳號了，查詢的話還要分欄目，日期什麼的查詢，有些不好。因為車票都是提前購買，所以有個提醒功能的話，就會更加的完美。至於搶票的功能，覺得這是沒辦法的情況下，才需要的，已經有別的軟體實現了，自己沒有必要這麼做。

 

5、為什麼使用者會用你的產品/功能？

因為這是從使用者的體驗出發，這些功能都是使用者最長遇到的，反感的東西，現在有了這些功能，相信使用者會感到十分的人性化設計。

 

6、你的創新在哪裡? 請使用 NABCD 分析

（1）N（Need需求）

解決了問題出現時，有個快速尋找的解決問題流程的方案，讓使用者更加放心使用，這是原本軟體沒有的地方。解決了使用者查詢訂單的麻煩，因為每個使用者都有自己的帳號，每次登入該APP都會登入賬戶，查詢訂單應該更加的簡便（原來的查詢訂單就像文章上部分講的不夠直譯，還有功能不是很完善）。解決了學生票的不完善。解決了忘記第一時間購買的車票（雖然使用者可以自己用手機備忘錄實現，但是APP實現這個功能的話，使用者肯定會覺得這個APP更加的人性化，因為自己設定備忘錄，還要去算日期的，並不是很方便，而且每趟車的起售時間也是不確定的，這點APP來實現的話，效果更加好）。當然，重中之重的應該是完善這個軟體的流暢性。

（2）A (Approach做法)

對於問題欄的做法，這個比較簡單，通過對資料的增刪改查就可以了。

對於使用者查詢訂單，這個需要重新設計頁面，原來的比較的繁瑣。所以這個需要更改原來的代碼，但還是類似的，需要先把前端的介面設計好，改掉原來分很細的地方。只不過查詢訂單時，預設是使用者人自己，然後近期的未出行的訂單直接顯示出來，一般都是查詢未出行訂單的人數多，對於完成訂單的（不管出行不出行），全部存在曆史訂單裡面匯總。

對於提醒預定的功能，這個需要全新的介面，需要使用者自己填寫出發時間，還有車次，所以要有車次的查詢功能，然後自己對售票前多久提醒自己來定義。

一個剛開始的團隊，需要先瞭解每個人的強處。根據功能點來分配給對應最佳的人選，當然需要一個人來查看進度，測試各自功能點的實現，小問題，少數人商量解決，大問題，整個團隊開會協商（這是目前自己的見解）。

（3）B (Benefit好處)

解決了目前系統存在幾個較為嚴重的問題。更加的完善該系統，更加的人性化，對於同類型的APP，存在的最大優勢在於，很多其它APP也是要匯入12306的資料，然後其它APP還有很多其它無關的功能點，佔用系統的資源，當這個鐵路12306APP流暢性得以解決，功能更加的完善，相信更多的人會選擇這個，畢竟這個才是官方的購票軟體。

（4）C (Competitors競爭)

如Benefit好處所說的一樣，這個是單純的購買火車票的官方APP，雖然現在也在增加商旅服務（約車服務、訂餐服務），但是這些都是自身功能不足的完善點，而且是官方的APP，其它軟體也是基於這個平台的資料，所以提高軟體流暢性，完善功能之後，這個軟體必然是使用者的首選用來購買火車票，對此，對競爭十分有信心。

（5）D (Delivery 交付) 

需要通過大量的測試，不同的人群，不同的年齡，發布測試版，根據回饋的意見，做出相關的改進。

 

7、如果你來領導這個團隊，會有什麼不一樣？

只能說，更加的照顧團隊，關注團隊的每一個人狀況，相信當團隊人心一致的時候，就是發揮最大能力的時候。

 

8、如果你的團隊有5個人, 4個月的時間，你作為專案經理，應該如何配置角色（開發，測試，美工等等）？

第1~2周：調研、可行性分析和原型設計，制定專案計劃

第3周：需求分析和定義。

 

第4周：系統設計。確定系統總體架構，確定開發工具等，對應用系統關係進行架構性設計，用圖的方式描述出使用者和各子系統或模組的全域視圖，以及和其他系統的關係，也就是搞清楚系統的邊界問題。概要設計中高層架構設計、設計網路拓撲圖和系統部署圖。對子系統、模組進行合理的劃分。同時確定模組的名稱。

第5—10周：軟體編碼。一開始美工2人，開發2人，測試1人，然後一個美工轉開發，另一個兼顧測試。一開始的測試人員需要兼顧全域，需要給一個能力較強的人員來當。

第11周：5人內部瘋狂測試，壓力測試，美化介面，改掉不足，還有規範代碼。

第12周：第一次軟體小型使用者測試，收集使用者反饋的意見。

第13周：根據使用者的反饋意見做出正確的修改。

第14周：第二次軟體大型使用者測試，同樣收集使用者反饋的意見。

第15周：同樣根據使用者的反饋做出正確的修改。

第16周：美化介面，多次進行測試、壓力測試，規範代碼。

第17周：軟體發布。

 

APP案例分析