軟件產品案例分析

第一部分 調研,評測

評測:

經過基本的使用,發現了一些優勢以及不足的地方。android

Android 端

  1. 第一次下載使用 Android 端的時候出現了網絡沒法鏈接的問題,從新安裝無效,別人的手機發過來可用的 apk 安裝時候成功使用。這也暴漏了一個重要的問題,Android 端在各大應用商店都找不到,只能從官網的入口下載。第一次很難找到。
  2. Android 端界面很簡潔,而且界面清楚,符合大多數人的使用習慣。
  3. 存在加載慢的問題,每一次點擊都會加載好久,體驗較差。

Web 端

點擊訪問web

  1. 界面較爲美觀和簡潔,網頁的交互動畫效果較多,頁面區域較爲清晰
  2. 功能齊全,各類開發須要用到的經常使用功能都有而且直觀,易於查看和分析。
  3. 第一次打開以後頁面有引導幫助熟悉和使用頁面的功能。
  4. 當切換頁面時要加載好久,大概有 1-2 秒,和 Android 端同樣。網絡和設備性能都沒有問題,因此必定是網頁的性能問題。只切換一個頁面就要加載那麼長時間,會影響用戶體驗,使用中出現一些中斷,雖然時間很短,可是思路會中斷,影響效率。數據庫

    存在的 bug

  5. Android 端輸入語音時會將語音保存在本地,好比在乎見反饋界面,取消以後語音的文件依然在本地保存,並無刪除掉。這樣的話長久以來就會佔用愈來愈多的存儲空間,形成無心義的消耗。

  6. Android 端在發送語音以及圖片的界面,長按應該是進入選擇刪除的界面。可是當長按圖片時,不只會顯示氣泡右上角的刪除按鈕,還會打開預覽圖片的界面,如圖:


    這樣應該是判斷響應方式的問題。雖然是很小的錯誤可是應該是開發的時候沒有考慮到,最好糾正一下。編程

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

我認爲出現這些 bug 的緣由仍是測試的不夠。開發的時候有不少內容,一會兒可能考慮不到,在性能以及一些操控的邏輯方面可能有欠缺。我認爲應當在開發的時候多讓開發人員之外的人來測試,來避開開發人員的思惟定式,發現一些問題。另外性能方面是 Android 端和 Web 端共同存在的問題,我以爲問題應該在服務器,多是服務器帶寬的問題,也多是性能的問題。服務器

採訪:

採訪對象背景和需求:網絡

  • 福州大學大三學生,正在完成軟工實踐的團隊做業,對團隊協做工具備必定的需求,在使用 GitHub。
    讓採訪對象使用華爲軟件開發雲:

    採訪具體過程:架構

    Q:描述用戶使用這個產品的過程, 用戶的問題解決了麼?軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗方面有問題麼?你在使用的時候有什麼體驗呢?
    A:上手以爲這個軟件還勉強算美觀,要花點時間才能搞明白怎麼使用。
    Q:那這個軟件解決了你開發中的問題麼?
    A:使用起來並不方便,仍是會使用 Github。
    Q:你以爲這個軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗如何?
    A:功能較爲全面,能夠說是保姆級輔助開發,可是雜七雜八的功能過多,反而會以爲累贅。用戶體驗的話還好,乍一看找不出什麼大毛病。
    Q:你有什麼改進的意見嗎?
    A:我認爲能夠把一些核心功能作的完善一些,少修飾那些不怎麼用到的功能。運維

通過這麼多工做,你必定有充分的理由給這個軟件下一個評價,請選擇一個結論:
通常。勉強能用,可是絕對不會有很大的幫助,甚至有時候會成爲負擔。微服務

第二部分 分析

估計這個項目作到這個程度大約須要多少時間: 若是隻有6人,而且是大學畢業生的話,全力作這個項目的話可能須要5-6 個月。
分析這個軟件目前的優劣以及提升的部分:工具

  • 優點:
    1. 這個軟件功能全面
    2. 服務器在國內,訪問速度快(同 GitHub 比較)
  • 劣勢:
    1. 沒有抓住用戶需求的痛點。
    2. 沒有方便的插件支持,使用不方便。
      因此我認爲在使用者經常使用的功能裏面多下點功夫會好一點。

第三部分 建議和規劃

  • 若是你是項目經理,如何提升從而在競爭中勝出?
    這個軟件有不少能夠提升的部分。首先在交互的體驗上能夠進行不少優化,包括加載速度,界面的美觀性,還有部分控件的一些小問題,均可以進行更正來讓開發者得到最佳的體驗。另外最重要的仍是核心的功能,要多向實際的開發者徵集意見,多從實際使用中得到一些反饋,抓住使用者的痛點。目前的項目略有雞肋的感受,並非很須要,很難讓團隊長久而且穩定的使用。其次要改進部分交互邏輯,有一些功能略顯繁雜點進去有些不知因此,並不能起到團隊協做的做用。

  • 目前市場上有什麼樣的產品了?
    • Github: 目前市場上使用最廣範口碑最好的就是 Github 了。Github 使用 Git,有兩大功能:開源社交平臺和企業項目管理平臺。Github 抓住了最核心的功能,這也是 Github 最核心的競爭力,也是 Github 脫穎而出的緣由。
  • 你要設計什麼樣的功能?爲什麼要作這個功能,而不是其餘功能?
    在團隊項目中溝通和交流很重要,我但願在在項目中加入更多可視化的交流,好比提供功能樹的可視化功能。另外在使用 Github 的時候同步代碼很麻煩,我但願作出 Android Studio 和 Visual Studio 上的插件,隨時更新同步代碼,而且加入方便直觀的版本控制功能,讓開發者能夠在 IDE 中實現大部分操做,不須要分心去其餘頁面來實現一些操做。我認爲這是我最須要的功能,能極大地提升開發效率。

  • 爲何用戶會用你的產品/功能?
    • 首先,功能樹能夠直觀的顯示功能的細節、完成程度以及各版本狀況,團隊成員之間能夠更好的根據開發狀況進行調整,提升效率。
    • IDE 的插件集成在 IDE 中,使用更方便,不會存在團隊成員由於麻煩不使用的狀況。
  • 若是你來領導這個團隊,會有什麼不同?
    我領導團隊的話可能不會容忍那些小問題吧,另外美觀的問題要解決一下。
    另外有些功能不必能夠砍掉,有些過於累贅了。

  • 若是你的團隊有5我的, 4個月的時間,你做爲項目經理,應該如何配置角色(開發,測試,美工等等)?
    只有 5 我的的話我認爲能夠分兩組,3 人和 2 人,視每組負責部分的工做量來分配。測試的話能夠組間互相測試,美工的話每組 1 我的負責就行了,同時兼任開發的角色。人數較少的小組分工太細反而效率會低。
  • 描述你的團隊在16 週期間每週都要作什麼,才能在第16周如期發佈軟件,大小里程碑績點設定。

週數 任務 里程碑
1-2 用戶調研及需求分析等肯定功能及分工
3-11 進行 α 階段編程,完成最第一版本 α 階段
12-15 在 α 階段的基礎上進行修正和補完,進行 β 階段編程 β 階段
16 確認項目沒有問題,進行最後的修正,測試 完成最終版
相關文章
相關標籤/搜索