軟體産品案例分析（團隊）

标簽（空格分隔）： 軟工實踐

作業的傳送門

一、調研，評測（20分）

評測

• 上手體驗
  • 綠色的UI還是第一次見到
  • 軟體的延遲感覺很影響體驗
  • 不能通過左右滑動來切換界面感覺很不習慣
  • 主界面中間的建立功能感覺比較的新穎。
  • 項目的四個分欄(全部、需求、任務，缺陷)簡潔、易懂
  • 工作項裡面的功能選擇感覺有些複雜繁瑣,最基本的完成任務在第一次上手時候沒有找到。
• BUG
  • 1.項目的篩選功能,篩選後無反應,需要退出目前項目,再進入時才生效,并且無法識别目前是否處于篩選狀态。
  • 2.頻繁反複的點選選擇框(3~6次即可)時,會出現頁面卡死,滞留在如下圖所示的頁面,需要手動點選傳回

    • 

    • 

    • 

  • 3.編輯項目資訊時,部分非法命名時回報資訊出錯,如項目名稱修改為3個空格時,回報資訊為:網絡繁忙,請稍後再試

    • 

（影響使用者體驗的可能不算BUG的BUG:）

- 4.下載下傳附件不會自動儲存,每次點選附件都會重新下載下傳

- 5.進入項目的二維碼有分享與發送和儲存圖檔功能,但是識别二維碼的時候卻沒有檢視本地圖檔的功能。

- 6.隻有點選進消息後,才知道是否有新的消息。

• 你覺得為什麼這個産品組的人沒有發現這些bug?

  有些BUG我覺得還是很好發現的,比如說,篩選的設計,這個隻要随便建立幾個工作項篩選一下就很容易看出來有BUG了....我也不知道為啥這個辣麼嚴重，并且 篩選後體驗極為不友好()

采訪

• 采訪對象的背景
  • 漢森
    • 西二成員,有豐富的個人和團隊的項目經驗。
    • 使用的工具是teambition
• 需求
  • todolist的建立
  • 可建立小組
  • 可分享
  • 自動生成燃盡圖
  • 自動deadline提醒
  • ......

• 描述使用者使用這個産品的過程,使用者的問題解決了麼？軟體在資料量/界面/功能/準确度上各有什麼優缺點？使用者體驗方面有問題麼？
  • 手機APP:賬号登入->建立項目->進入項目->建立工作表->檢視工作表->退回菜單->檢視待辦->改動待辦事項->分享
  • 界面比較簡潔,主界面的建立還是比較有意思的,但是界面太過單調,不夠吸引人。
  • 功能比較基礎,但是上沒有發現什麼特别的亮點
  • 沒解決，體驗不友好，loading時間太久(聯通4G網絡)，某些功能入口太深，或者不明顯，比如添加待辦事項。整個UI設計比較正常，對于我個人來說，一個獨具風格的UI更能吸引我。
• 使用者對産品有什麼改進意見？
  • 優化loading時間，mask遮罩層意義不大。
• 結論：經過這麼多工作，你一定有充分的理由給這個軟體下一個評價,請選擇一個結論:
  • 不推薦。最後,我還是選擇teambition。

二、分析

• 估計這個項目做到這個程度大約需要多少時間

  估計需要3到4個月左右的時間

• 軟體目前的優劣

  市面上類似的軟體也不少，我就拿我用過的teambition和這個軟體進行對比。

  • 優勢：華為軟體開發雲的任務分類更清晰，能夠更清楚的為一個任務分類，并且對任務的查找提供了詳細的篩選功能。
  • 劣勢：使用者體驗不佳，比如項目不能删除，篩選過後的提示不夠顯眼，容易讓别人忘記目前看到的是經過篩選的任務。使用者之間的交流也比較困難。評論不能夠删除，發送評論時沒有發送鍵，隻能夠點回車。相比來說teambition的項目以及任務的建立删除更加的簡潔明了，使用者間的交流也更加簡單。是以使用者體驗會比華為軟體雲好很多。除了使用者體驗就是對不同使用者完成的任務沒有篩選功能，不能夠直覺感受到每個使用者對這個項目的貢獻度大概有多少。
• 建議
  • 一. 改善使用者的體驗，具體内容在上面的劣勢中有提到。
  • 二. 提供對不同使用者完成的任務的篩選，能夠更友善的讓大家看到某個人完成了多少任務。
• 功能邏輯圖

  

• 對使用者體驗方面、UI界面美觀度、核心功能，分别打分（單項滿分10分）
  • 使用者體驗 5分
  • UI界面美觀度 8分
  • 核心功能 7分

第三部分 建議和規劃（20分）

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

  APP響應太慢，使用者互動不流暢，減少loading時間，可以從服務端或者用戶端入手，更新服務端的架構，移動端則可以考慮預請求等。

• 目前市場上有什麼樣的産品了？

  市場上同類型的産品數不勝數，coding、teambition等。。。

• 你要設計什麼樣的功能？

  對于同類型的軟體，我覺得主要的功能不應該在todolist上，而是對于一個項目/業務進度的跟蹤，包括部署，包括上線以後的一些狀态監控，甚至可以推送線上的錯誤，例如sentry。可以線上開組會，線上組織活動等。

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

  我覺得目前沒有什麼提供給大衆這種服務的系統，大部分有這種系統的都是企業内部自己實作，那麼對于非專業開發來說，這樣一個系統可以節省很多時間。可以減輕運維的壓力，讓開發人員更專注于開發。

• 為什麼使用者會用你的産品/功能？

  為什麼不用？比起自己花幾個小時去搭一個環境好還是使用一鍵部署更友善？

• 你的創新在哪裡？可以用 NABCD 分析。

  部署：給出多套方案，适應不同的語言和架構。線上開組會就和知乎live差不多，可以把每個人的發言記錄下來，更友善做總結。錯誤收集，将使用者使用過程中軟體出錯自動送出。大概是一套運維工具，給非專業運維人員使用的一套工具。

• 如果你來上司這個團隊，會有什麼不一樣？

  我覺得，就目前來說，這個APP缺點還是太多，要麼就是企業不重視，或者是小組随便推出一個APP來KPI++，很多很明顯的小細節都沒考慮到。如果是我，可能差别不會特别大。需求都是PM定的，照做就是了。

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

  5個人，美工就算了吧。PM可以當美工用。測試的話，人手少當然就找一個除了自己以外的人測試，最後小組一起測試。APP包括移動端和服務端，2個服務端，3個移動端。我覺得移動端要處理的事情比較多，包括還原原型，互動邏輯。比如：後端寫一個删除的接口，前端删除的時候還需要詢問是否删除。發删除請求，請求成功處理，請求失敗處理。弱網環境？loading。請求成功後的處理，是在list中删除，還是重新擷取資料，再重新整理清單。是以我覺得移動端的人應該多配置設定一點。

• 描述你的團隊在16 周期間每周都要做什麼，才能在第16周如期釋出軟體，大小裡程碑績點設定。

  首先，得先商量架構，在第一周，商量架構，使用的技術棧，可能用到的庫等。然後把大緻的架構搭出來。細分功能塊，配置設定任務。16周，每周上班時間為5天，周1-4開發，周5總結+測試。13周之前結束開發任務。14周做各種各樣的優化。15周集中測試。16周釋出。

• 項目釋出後，有沒有考慮過項目該怎麼部署才能滿足需求。依據下圖（某校教務處系統的部署）作為參考，分析16周後你所完成的項目上線需要哪些配套裝置(伺服器、帶寬、資料庫需求數量與配置) 。

  

  架構使用微服務，k8s叢集部署，每個服務單獨跑一台主機。

  API網關：越高越好 * m

  微服務主機：越高越好 * n

  資料庫： 主從資料庫+備份

  緩存：redis 主備

  網站安全：DDOS