我的做業——軟件產品案例分析

第一部分 調研，評測

評測：

1.下載並使用，描述最簡單直觀的我的第一次上手體驗。

IOS端：

• 首先打開註冊登陸頁面發現整個頁面很整潔，淡綠色背景看起來很清爽很舒服。
  

• 而後是註冊部分，點擊註冊後出現了以下狀況：
  

  沒錯，就是咱們比較煩的一個圈圈轉啊轉，速度方面確實有點慢。

• 而後是填寫註冊信息，平時在使用其餘APP時我通常會用一個固定的用戶名稱，比較方便也不用每次都去想一個用戶名，因此我常規輸入用戶名，出現這個提示：最短不能少於5個字符
  

  既然這樣，那行吧，我加一個字總能夠了，因而，又提示：只能包含字母、數字或-_字符。這就有點皮了，早說不就行了。。。這方面確實不夠人性化。
  

• 而後是登陸，在玩這個軟件時，我登陸退出來來回回好幾回，發現每次登陸都要從新輸入密碼，因此若是登陸方面我以爲若是有一個記住密碼的功能那就更棒了。

• 登陸進入APP後的印象是界面簡約美觀，第一印象挺好的。首先是項目部分，左上方有一個二維碼選項，我點擊進去並找了一個二維碼掃，驚奇的發現：無效的二維碼！WHAT？？？（尼克楊問號臉.jpg）
  

• 我嘗試着點擊進入項目並建立了新工做項，在建立工做項時，一個不溫馨的體驗仍是運行速度的問題，感受這方面確實是一個短板。如圖：
  

• 在我只建立了一兩個工做項時，條件反射的想採用左右滑動來切換上面的工做項類型，發現他的viewpager並無實現滑動，
  

  在我想吐槽時，我忽然想到工做項左拉後是有分享和刪除選項的，以下圖：
  

  因此當你工做項不少時，好比這樣：
  

  天然不能用滑動來切換工做項類型了，否則就跟工做項進行左拉選擇分享刪除衝突了，一時短路，慚愧慚愧。

• 而後是我在一個工做項裏面又建立了子工做項，可是在APP中顯示的時候卻沒有相關提示將他們關聯起來，我沒法從中知道，哪些工做項是父子關係，好比這個界面裏「阿森納」是「歐冠16郎」的父工做項，可是這個界面沒有任何提示他們的關係，甚至你點擊進去子工做項裏面也找不到父工做項的信息，有點皮。
  

• 再而後是上面也說了工做項是能夠刪除的，可是項目，找了很久也沒找到哪裏能夠刪除項目，這個地方確實有意思，不知道開發者的想法是什麼。

• 再有一個我感受有點不舒服的是我的頁面那個地方，整個頁面不能拉動感受比較僵硬，是否是能夠嘗試採用好比微信這種能夠上拉下滑的效果，雖然沒有什麼特別做用，但感受這樣會舒服一點。
  
  

---

web端：

• 用過IOS端的後再用一下web端感受舒服了許多，像登陸頁面web端能夠用手機登陸，這是很便利的，若是是用用戶名登陸則會麻煩一點，說實話，用那麼多APP幾乎每一個APP都有一個用戶名，因此很容易搞混用戶名，固然了，還有密碼，滿滿的痛，每次都是忘記密碼，gg。
  

• 進入頁面後感受頁面設計很溫馨，像這個項目，看起來就很舒服，還有這個工做項的頁面設計比起手機IOS端看起來美觀一些。
  
  

• 還有這個用戶我的信息界面，能夠修改頭像，比手機端完善。
  

• 還有我上面說的那個父子工做項的問題，在web端就完善了，看web端就把子工做項包含在父工做項下，頓時舒爽。
  

2.按照描述的bug定義，找出幾個功能性的比較嚴重的bug。至少兩個。

• NO.1
  • bug描述：在scrum類型項目中，當你在其中添加工做項時，會發現只有Bug、Feature、Story三個選項。而在項目中卻有四個，也就是添加工做項時缺乏了Task這個分類。
  • 圖片展現：
    
• NO.2
  • bug描述：IOS端在待辦界面中，選中一個項目左滑進行分享或刪除，當點擊分享時，APP會崩潰了，而在項目裏的工做項中操做不會崩潰。
  • 圖片展現：
    

3.你以爲爲何這個產品組的人沒有發現這些bug?

• 我以爲產品組開發過程當中像那個工做項類型缺失就是開發中的疏忽問題，同時在測試這方面有點大意，由於我感受這些bug是比較容易發現的。估計也是由於軟件還在初期運營狀態，軟件相應功能尚未的到很好的完善。跟web端相比較，web端作的就舒服很多。

4.假設大家團隊須要開發這套系統，須要注意哪些方面(架構、部署運維、微服務等)。

• 首先前期的架構必定要設計好，有一個好的架構纔能有方向去作。要考慮到軟件的兼容性拓展性等等。部署運維首先要考慮服務器問題，服務器沒配置好那麼問題就來了，想必你們平時都有體會，維護方面也要細緻，有相應問題的準備，其餘方面還要考慮到軟件的兼容性拓展性等等，最後的收費問題也要權衡好，儘可能讓大多數用戶能夠接受。

---

採訪：

1.採訪對象的背景和需求：

• 採訪的對象並無使用過這個APP，平時也只用過GitHub進行代碼管理。因此對這款軟件仍是有必定的需求的。

2.採訪對象使用華爲軟件開發雲：

3.描述用戶使用這個產品的過程, 用戶的問題解決了麼？軟件在數據量/界面/功能/準確度上各有什麼優缺點？用戶體驗方面有問題麼？

界面：web端界面設計的不錯，人性化程度也還能夠，相比 web端APP方面還須要進一步增強。
功能：功能方面比較完善，暫時沒發現缺乏什麼重要功能，就是剛上手尚未很是熟悉的去運用。
準確度：準確度方面還行，web端移動端同步性能夠。
用戶體驗方面在加載方面比較不友好，速度有點慢，同時我列舉的bug也影響了用戶體驗。

4.用戶對產品有什麼改進意見：

• 他感受產品的UI方面能夠加以改進，感受有點單調，再而後就是他也很吐槽APP的運行速度問題，而後就是一些bug要加以修復。

5.結論：通過這麼多工做，你必定有充分的理由給這個軟件下一個評價,請選擇一個結論:

• 通常

---

第二部分 分析

• 1.使用此軟件的大部分功能，聯繫第二部分的分析，估計這個項目作到這個程度大約須要多少時間（團隊人數6人左右，計算機大學畢業生，並有專業UI 支持）。 分析這個軟件目前的優劣（和相似軟件相比），並推理出團隊在軟件工程方面能夠提升的一個重要部分（具體建議）。

• 時間估計：6~8個月
• 優點：界面整潔舒服（特別是web端），功能全面，做爲代碼託管平臺，可以構建部署，還有免費額度。
• 劣勢：移動端問題較多，有很多bug存在，同時速度較慢，移動端的界面設計也須要增強。

• 建議：增強移動端的開發設計，特別是bug的解決與加速問題，讓用戶在移動端可以擁有更好的用戶體驗。

  2.根據理解和體驗，畫出整個軟件全部功能邏輯框圖，根據重要度標識出各模塊的重要度、完成度、出發點及效果；

3.針對不一樣的維度評分，對用戶體驗方面、UI界面美觀度、核心功能，分別打分。

IOS端：

類目	分數
用戶體驗	75
UI界面美觀度	80
核心功能	80

web端：

類目	分數
用戶體驗	85
UI界面美觀度	85
核心功能	80

---

第三部分 建議和規劃

1.若是你是項目經理，如何提升從而在競爭中勝出？

• 若是我是項目經理，我以爲能夠在這幾點進行提升優化。首先是軟件的優化完善，閃退崩潰這些問題要一一排查並解決。再者是速度方面，體驗了一段時間感受這個軟件的速度方面有很大的優化空間，速度是用戶體驗很是重要的一個部分。核心功能要細化，注重一些細節，像我上面提出的父子工做項的聯繫問題是否是考慮一下把他們的關聯體現出來。UI方面在一些界面能夠增強，好比我上面說的我的界面，增長一些靈動，添加一下頭像，讓用戶體驗起來更加舒服，還有一些比較空白的界面能夠換種思路，好比這個工做項描述，可不能夠用一種dialog對話框的方式來實現更加美觀，站在用戶的角度去思考去體驗。
  

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

• 目前市場上有GitHub、騰訊雲等等產品

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

• 我在思考是否是能夠考慮添加一下相似知識社區的功能，能夠供用戶交流分享。

4.爲什麼要作這個功能，而不是其餘功能？

• 做爲一個菜鳥，常常要去技術網站查找學習一些新東西，因此我以爲技術這一塊交流與分享是很重要的一部分，在這裏若是能有一個相似知識社區的地方，用戶的一些小問題能夠比較方便解決。

5.爲何用戶會用你的產品/功能？

• 困難時每一個人都會遇到的，用戶用的同一個軟件，可能會有一些共性問題，在這邊也容易解決，省去了再去別的地方查找相應解決方法的麻煩。

6.你的創新在哪裏？能夠用 NABCD 分析。

• N:用戶會在使用軟件時遇到一些問題，還有一些是技術知識問題，這時候他們就須要求助他人或去查找資料。
• A:添加一個知識社區模塊，裏面能夠發一些經驗貼，求助帖，也要有查找功能，查找相相似的問題。
• B:用戶容易方便尋找到本身的答案，由於知識社區上都是在使用這個軟件的用戶，你們會有一些共性問題 ，分享出來多人受益。
• C:咱們這個知識社區立足於軟件用戶，用戶在使用軟件時會因方便而優先選用此軟件的知識社區，此時使用會相對其餘一些專業技術網站更方便些，並且上面也說了，社區上都是這個軟件的用戶，在此軟件遇到的問題在社區上更容易找到答案。
• D:從本身從身旁開始，慢慢推廣出去，再推廣到各個平臺，星星之火能夠燎原。

7.若是你來領導這個團隊，會有什麼不同？

• 分工是最重要的，必需要有明確的分工，你們各司其職，而後要計劃設定必定的時間用來討論與分析，你們把問題和進度都表達出來，互相探討，工做才能井井有理。當整個團隊運行起來時你們激情有了，凝聚力有了，剩下的就是一步一步踏實前進了。凝聚力，真的很重要，若是團隊內部有意見，那就GG了。

8.若是你的團隊有5我的, 4個月的時間，你做爲項目經理，應該如何配置角色（開發，測試，美工等等）？

• 初期階段在進行架構設計的時候你們都要參進來才能對整個項目有必定的瞭解與熟悉。
• 在Alpha階段，開發人員能夠多一點，4我的，美工測試1我的，由於我以爲這段時間功能的實現還有服務器搭建等等更關鍵一些。
• 在Beta階段，開發人員3人，美工測試2人。

9.描述你的團隊在16 週期間每週都要作什麼，才能在第16周如期發佈軟件，大小里程碑績點設定。

• 第1周主要是項目規劃，需求分析，同時對下階段的任務進行安排，配置好每一個人的角色。
• 以後的4周進行主要功能的開發以及初步測試，同時對界面有初步的設計，主要功能是項目管理和代碼管理。
• 第6周總結前一階段的工做，根據前一階段完成狀況安排下一階段的任務和人員配置。
• 以後的6周對上一階段的功能進行深刻的測試，確保每一個功能都可以穩定的實現，不會出現嚴重的問題，同時對一些附加的功能進行開發，同時根據需求的變化適當的修改對應的功能。
• 第13周總結前一階段的工做，根據前一階段完成狀況安排下一階段的任務和人員配置。
• 以後的幾周就是對全部功能進行最後的整合與測試，將最後的界面和功能進行統一。

10.項目發佈後，有沒有考慮過項目該怎麼部署才能知足需求。依據下圖（某校教務處系統的部署）做爲參考，分析16周後你所完成的項目上線須要哪些配套設備(服務器、帶寬、數據庫需求數量與配置) 。

• 項目管理功能對服務器與數據庫資源的佔用並非特別大，可是代碼管理方面，好比代碼託管須要比較大的帶寬，保證大量用戶可以同時上傳代碼而不發生擁塞，代碼檢查則須要服務器具備強大的處理能力，同時存儲代碼等項目資源須要很是大存儲空間。並且這個項目是面向全球用戶的，隨着用戶不斷增長，對服務器的要求也會愈來愈大，因此隨着時間的推移也須要增長服務器和數據庫的配置和數量。