天天看點

軟體産品案例分析(團隊)

任務配置設定流程圖

軟體産品案例分析(團隊)

第一部分 調研,評測

【評測】

下載下傳并使用,描述最簡單直覺的個人第一次上手體驗。

移動端

  1. 軟體登入界面,色彩清新,操作流暢,這種風格看着還是蠻舒服的。不過登入、注冊等按鈕距離間隔太近容易誤操作。
  2. 注冊界面直接以web網頁形式加載,響應速度較慢,體驗并不是很好。
  3. 使用者的主界面非常簡潔清新,“我的”界面除了使用者名、區域看不到使用者的其他資訊。
  4. 附件功能挺全的,包括檔案、照片、語音。項目及工作項的描述資訊提供很多選擇,例如日期、優先級、子產品、标簽等等。
  5. 總體來說界面操作流暢,下拉重新整理,頁面加載等互動的響應速度在能接受的範圍内。

web端

  1. 登入界面簡潔是真的,不大好看也是真的,和首頁的UI設計感覺不在一個水準。
  2. 功能強大且邏輯布局合理,較易上手。
  3. 動态效果很不錯,為使用者操作添加了不少樂趣。
  4. 相對于移動端,web端的使用者提示更清晰。
    軟體産品案例分析(團隊)
  5. 保姆級輔助開發,為使用者省下了不少時間。
    軟體産品案例分析(團隊)
  6. 操作過快會出現白屏現象。

按照描述的bug定義,找出幾個功能性的比較嚴重的bug。至少兩個。用專業的語言描述(每個bug 不少于 40字),如有必要,可以配圖 .

  • 本次尋找bug環節,web端表現良好,是以我們小組以吐槽移動端為主;
  • 此次測試的機型有兩款,以下的bug在兩款手機上基本都有出現。
  • 機型:一加3(Android8.0 )+ iphone5s ( ios9.2.3)

bug1

  • 标題:未能及時清除緩存
  • 重制步驟:登入軟體,進入項目建立工作項,或是進入意見回報,添加語音附件,在操作多次後取消儲存。
  • 内容: 語音附件在取消儲存的情況下仍殘留在本地SD卡,也沒有提供清除緩存的選項,若是頻繁附件操作,這将對使用者的存儲空間有一定影響。
  • 建議:改進取消儲存後自動清除本地相關緩存的功能,并在界面上增加清除緩存的功能按鈕。
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)

bug2

  • 标題:找回密碼的圖形驗證碼即使輸錯也會通過。
  • 重制步驟:登入界面點選忘記密碼進入頁面進行密碼找回。
  • 内容:圖形驗證碼形同虛設?在輸錯驗證碼的前提下還可以繼續下一步的操作。
  • 建議:完成圖形驗證碼的正确稽核。
    軟體産品案例分析(團隊)

bug3

  • 标題:關于意見回報及附件功能
  • 重制步驟:進入“我的”頁面點選意見回報。
  • 内容:在進行附件的錄音時未顯示錄音時間,也未提醒使用者最短時間,但是超過60s自動停止。且在一定數量的附件時(3段語音,20張圖檔)送出意見回報響應異常緩慢,甚至發送不了(6分鐘仍未成功且無法進行退出操作,隻能強行殺程序退出)。
  • 建議:完善使用者提示,提高抗壓能力和反應速度。
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)

bug4

  • 标題:添加評論的問題
  • 重制步驟:進入使用者的項目,點選進入工作項詳情頁面,添加評論。
  • 内容:點選添加評論後彈出的軟鍵盤把底下内容給遮擋了,導緻無法正常輸入評論。另外,已發的評論内容不能複制,不友好度+1。最可怕的是有一次嘗試在評論框裡輸入文字的時候APP閃退了,重新啟動後評論就恢複正常了。
  • 建議:加強軟體的測試力度。
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)

bug5(好像不是bug,應該算是不足吧qwq)

  • 标題:不能進行模糊搜尋
  • 重制步驟:進入使用者的項目頁面,點選搜尋框。
  • 内容:沒有模糊查詢的功能,當搜尋詞采取縮寫後,無法識别相應的項目。且需要按下搜尋按鈕才能找到結果,很不友好。
  • 建議:增加模糊查詢功能。
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)

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

  1. 軟體功能多而雜,可能并沒有考慮到這些細節。
  2. 測試機型不同,系統、螢幕尺寸等都會影響測試結果,不同機型的适配未能做好。本次測試裝置為iphone5s及一加3,在不同螢幕下表現略微有所差别,但問題一樣。
  3. 軟體還處初期階段,可能還未考慮極端的壓力測試,例如超大附件的情況,頁面加載有時很遲緩。

假設你們團隊需要開發這套系統,需要注意哪些方面

  1. 遵循團隊的代碼規範,提高項目的可維護性。
  2. 功能性架構依賴性不能太強,善用開源架構,需要經過充分的測試選擇成熟穩定的架構,例如網絡請求架構。
  3. 注意封裝一些重複性功能,适度耦合,通過統一入口進行調用,友善維護修改,也友善擴充,例如常用的添加附件功能。
  4. 估計項目的規模大小及使用者群體的通路量,選擇可靠的開發和運作環境。
  5. 開發者在程式設計之外還需要注意編寫單元測試,接口部分需要更新到團隊的彙總中。
  6. 需要注意前端和WEB端的之間的調試方式,各層之間通信設計按照微服務架構的設計原則,這些服務需要共享資料庫。
  7. 考慮使用者資料的安全性,以及操作的安全性(例如連續點選按鈕可能出現的情況)。
  8. 始終堅持以使用者為本的原則,在設計時盡量減少使用者的使用負擔。

【調研】

ps:采訪對象的試用在android平台進行。

介紹采訪對象的背景和需求(他們有沒有用過這個APP或類似的APP,除了現有的功能還有别的需求麼)

  1. 背景:周龍榮,創業團隊成員,該團隊計劃開發一款提供資訊交流共享平台的App。
  2. 需求:
  • 該團隊需要一款可以對項目進行任務分工、進度跟進、并能将開發過程中的問題、成員的溝通交流及回報資訊進行記錄管理,協助團隊進行項目開發的一款軟體工具。團隊成員沒有用過類似的App,但是有用過網頁端的類似産品。
  • 除了現有的功能外,受采訪者覺得如果APP能夠整合出一個及時通訊功能子產品,滿足團隊在日常開發過程中的交流讨論,就更好了。
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)

描述使用者使用這個産品的過程,使用者的問題解決了麼?軟體在資料量/界面/功能/準确度上各有什麼優缺點?使用者體驗方面有問題麼?

子產品 優點 缺點
資料量 項目建立不限個數,滿足基本開發。 限容量。
界面 軟體的整體界面整潔,邏輯跳轉較為合理。 部分控件布局不夠友好,間距過小。
功能 移動端能夠建立工作項,并設定工作項的詳細資訊,如詳細資訊,優先級,疊代資訊,和完成進度等,基本滿足了團隊開發的簡單需求。 1. 相對于web端,app端的功能不夠完善,核心的一鍵式部署和代碼範檢查功能并沒有在APP上展現;2. 并且部分功能存在bug,使用者體驗不夠友好。
準确度 大部分功能都能正确響應。 部分操作存在問題,例如前面提到的圖形驗證碼。
  • 使用者體驗:相對于web端,移動端的使用者體驗很不友好,例如前面提到的在界面布局、使用者提醒、反應速度等方面都存在着或多或少的問題。

使用者對産品有什麼改進意見?

  1. 豐富主要功能。
  2. 為項目設定更直覺的進度檢視。
  3. 增加及時交流子產品或完善評論功能。
  4. 完善使用者提示,提高使用者體驗。

結論:經過這麼多工作,你一定有充分的理由給這個軟體下一個評價,請選擇一個結論:

  • Web端——推薦
  • 移動端——不推薦。
  • 附上一張來自深夜的吐槽。
    軟體産品案例分析(團隊)

第二部分 分析

時間預估

  1. web端+移動端(iOS或Android) —— 12個月

    理由:整個産品涉及web端和移動端(iOS或Android端),web端的功能更是多種多樣。靠一個6個人的團隊(還是剛畢業的學生),在整個項目的過程中肯定會遇到各種各樣的問題。

  2. 單做web端 —— 9個月。

    理由:web端的功能強大,且加入了不少動态效果,難度可以說是很大了。

  3. 單做移動端 —— 3個月。

    理由:移動端的功能相對較少,實作難度不高,但對于剛畢業的大學生,還是需要一定時間的。

軟體優劣

産品 優勢 劣勢
華為軟體開發雲web端 功能齊全,各種該有的功能都有,界面美觀,收費不高 點選反應慢,加載很慢,跳轉的時候經常整個浏覽器白屏,有時候點選還沒有反應。使用者體驗存在問題
華為軟體開發雲移動端 具備項目管理的基本功能,界面簡潔,邏輯設計合理 存在較多bug,具有閃退、抗壓差等問題,使用者體驗差

具體建議

  • 建議:提高使用者體驗很重要。
  • 團隊在軟體開發過程中,應注重界面的設計,不能太醜,或者邏輯混亂。不能在使用者還沒使用時就留下不好的印象。
  • 同時也要考慮性能方面,反應速度過慢,或者bug較多都會很大程度地降低使用者體驗。
  • 要有有效且便捷的使用者回報管道,讓使用者參與到軟體的疊代過程中以便于更好的提高使用者體驗。

web端功能邏輯框圖

軟體産品案例分析(團隊)
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)
軟體産品案例分析(團隊)

移動端端功能邏輯框圖

軟體産品案例分析(團隊)

子產品分析

重要度 完成度 出發點 效果
看闆 重要 90 主要用于檢視燃盡圖,完成率以及story統計 能夠較為直覺的反映出工作完成情況
工作 非常重要 95 主要功能子產品之一,用于建立與檢視工作項以及對項目的規劃 是面向軟體開發團隊進行靈活化項目管理的團隊協作服務,功能較為齊全
檢查 85 用于檢查并檢視項目的問題與風險 精準定位代碼缺陷,提供示例和修複建議,支援一鍵跳轉到代碼庫線上修複。
測試 對項目進行必要的批量測試,提供驗收報告且支援對移動端應用進行周遊測試 高效管理測試活動,保障産品高品質,操作較多,執行較慢。
代碼 對代碼的操作與管理 基于Git的線上代碼托管服務,支援代碼一鍵下載下傳到本地,操作簡便
建構 對項目進行環境的建構 與代碼托管無縫對接,為使用者提供配置簡單的混合語言建構平台,實作編譯建構雲端化
部署 對項目進行配置的部署 實作部署環境标準化和部署過程自動化
釋出 将軟體包上傳釋出 通過安全可靠的軟體倉庫,實作軟體包版本管理,提升釋出品質和效率,實作産品的持續釋出
流水線 80 設定與執行流水線 提供可視化、可定制的自動傳遞流水線對小規模代碼效果不明顯
設定 一般 對軟體開發雲進行設定 能根據使用者需求進行基本的設定

針對不同的次元評分

打分 理由
使用者體驗 90分 整體簡潔易用,但操作并不是很流暢,頁面跳轉等待時間過長。
UI界面 整體UI比較簡潔明了,邏輯布局也很分明,動态效果加分。
核心功能 95分 功能相當強大,所有子產品對應的功能幾乎涵蓋了使用者的全部需求,并且簡潔易上手,提示明确,減少了使用者負擔。。
60分 反應速度慢,且存在較多bug,使用者體驗相對不夠友好。
80分 界面簡潔,邏輯合理,但控件布局不夠友好。
相對于web端,移動端的功能略顯單薄,但是也基本滿足一些簡單的需求。

第三部分 建議和規劃

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

我認為需要提高的地方大緻有三點:

  1. 首先是宣傳。宣傳的重要性是不言而喻的,它在我們的生活之中也是随處可見——書籍網絡電視,甚至是高速路上的巨型廣告牌。産品的品質固然是重中之重,但如果根本就不被人所知,沒有人使用,那再優秀也是白搭。而華為軟體開發雲這款軟體,關于它的宣傳就不太夠。單純從app store上的下載下傳次數來看,用鮮為人知來形容都不為過。即使是在網絡上搜尋,它的讨論熱度也不高。這對于一款需要大衆支援的軟體來說是緻命的,是以加強宣傳,提升知名度,擴大傳播範圍,是它與競争對手争奪使用者中極其重要的一環。
  2. 第二個要提高的地方是移動端的品質問題,需要做得更好。在試用的過程中我們可以很明确地感受到華為軟體開發雲的這個app在設計制作上的嚴重不足,若将其同功能齊全,制作也較為完善的web端相比較,那根本就是雲泥之别。從界面設計不合理到功能設定不完善,這款軟體的app需要改進的地方有非常多,不要說同對手競争,吸引使用者了,它連單純的滿足使用者要求,留住使用者都非常困難。手機現在在人們生活中的比重非常大,在工作中的分量也舉重若輕,如果在手機上的觀感不好,極有可能會影響到使用者對整個軟體的印象和定位。會對該軟體有需求的使用者基本上都很繁忙,誰都不會願意浪費時間在一款并不便捷,使用體驗也不盡如人意的app上的。
  3. 還有一個需要注意改進的部分是産品使用的便捷程度。正如第一點中我所提到的,使用者的時間是很寶貴的,沒有人願意花大把的時間浪費在對一個軟體單純的使用上。

    移動端需要提升的部分前面已經提過了,而Web端雖然已經比較完善,但在登入過程上卻令人意外的繁瑣。Web端無法維持長時間的登入狀态,關閉網頁即需重新登入,而網站本身沒有提供記憶密碼的功能,使用者每次重新登入都需要自己再手動輸入一遍密碼——這無疑是非常不友善的,重複的操作也容易讓人厭煩。試想一個使用者有着急用的需求,然而當他打開自己不久前還剛用過的網頁,卻發現自己需要重新輸密碼登入,這是何等的讓人不耐。細節最為磨人,卻也最為考驗人。如果不想在競争中落敗,就該抓住使用者心理,處理好每一個與之相關的功能。

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

1. 目前市場上與華為軟體開發雲相類似的産品主要分為兩類:

  • 第一類為Google,Amazon,IBM等國際知名企業為代表的,以其旗下的雲平台為依托,提供的DevOsp,比如IBMCloud的DevOps.
  • 第二類為一些小型公司開發的以項目管理為核心,不以雲平台為基礎的'僞'軟體開發雲平台,例如Worktile.

2. 兩類中具有代表性的産品比較:

功能特色 目标群體 收費标準
IBMCloud--DevOsp 基于開放式工具鍊,可以使用工具鍊模闆,或者通過應用程式建立工具鍊。支援自定義配置工具內建,以定制現有工具鍊。 中小企業開發者,個人開發者 工具鍊中第三方工具收費
AWS--DevOsp 提供各種工具包,使用者依自己的需求進行選擇。 按使用者需求選擇收費
Worktile 将單個第三方開發工具以服務的形式提供給使用者,使用者可以自主選擇添加。 某些第三方工具收費
HUAWEI--DevCloud 平台提供明确的服務,一站式的解決方案,能可視化地建立流水線。CloudIDE實作在雲中編碼調試,開發、測試、部署、運維等一切研發活動都在雲上。 中小企業開發者,衆包開發團隊,個人開發者 基礎按需計費和基礎套餐按需計費

你要設計什麼樣的功能?

  • 一個與軟體開發安全性相關的功能。該功能可以監控和記錄開發流程,能夠評估目前開發風險,并且提供一系列安全工具和可行的安全解決方案等。

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

  • 基于雲平台的軟體開發,其提供的服務對開發團隊來說是隐蔽的和不可控的。保障軟體的安全性對于此類産品就成為了一個極其重要的功能,而且是使用者選擇這類産品的一個重要考慮因素。引用書上一句話 “想象一下得到蘋果公司關于下一版iPhone的項目計劃會怎樣。”

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

  • 首先,這個功能通過緊密的監控和記錄,可以向管理人員提供大量的資訊,有助于分析和解決安全問題。使用者也可以利用安全評估功能,發現存在的安全漏洞,同時系統也會向使用者提供可行的解決辦法。如果使用者對此不滿意,可以自主選擇安全工具保障軟體開發的安全性。

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

Need

  • 現在,軟體開發與雲平台的結合面臨的一個重要問題就是安全性得不到保障。使用Devcloud時,使用者希望知道開發的安全性怎麼樣,如何提高安全性。并且使用者可能對于,希望能夠自主選擇安全工具。

Approad

  • 設定一個安全功能子產品,提供監控和記錄,安全評估,安全工具和安全解決方案等功能,并且不斷完善。甚至可以提供安全咨詢服務,讓專業人士提供建議。

Benefit

  • 能給使用者建立一個更加安全的開發平台,并且通過監控和記錄傳遞流程,可以確定更高品質的軟體,提高使用者體驗,吸引潛在使用者。
  • 而且使用者通過我們的安全分析後會更願意消費購買相關的安全工具,有助于我們産品的銷售。

Competitors

  • 我們産品的競争對象主要是IBM,Amazon等公司雲下的軟體開發平台。相比之下:
  • 我方優勢:
    • 一站式雲端DevOps平台,操作更簡易,能很好得滿足國内大量的3,5人的小型開發團隊需求。
    • CloudIDE實作在雲中編碼調試,開發、測試、部署、運維等一切研發活動都在雲上。
    • 提供流水線功能,加速開發。
  • 我方劣勢:
    • 一站式服務,使用者不能自主選擇工具,靈活性較差。
    • 雲端的開發和管理工具不如對手豐富。
    • 某些技術水準可能比競争對手低。
    • 産品的國際影響力較弱。

Delivery

  • 這種開發模式有别于傳統。要得到認可,不僅需要使用者在技術層面上适應,更需要思想上接受。
  • 為了使用者接受我們的産品,需要施行以下推廣方案:
    • 适當普及與項目安全性相關的知識。
    • 利用自身影響力鼓勵使用者使用這類産品。
    • 借用一些使用者成功使用本産品的例子進行推廣宣傳。
    • 加大廣告宣傳力度。
    • 開展限時優惠活動,并且對新使用者提供優惠。
    • 向使用者提供技術支援和教育訓練。
    • 完善和豐富産品的使用幫助文檔,建立相關論壇以供幫助。

如果你來上司這個團隊,會有什麼不一樣?

  • 我會在移動端的開發上更加重視一些。
  • 華為軟體開發雲這款軟體本身功能較為齊全,與同類産品相比界面的美觀性也很強,但在這段時間的試用中可以看出,它的移動端還比較簡陋:功能少,部分設計不合理,還有一些bug存在。這些都非常降低手機使用者對這款軟體的觀感印象,也不利于web端和移動端之間的聯系。在現在這種手機已然成為人們生活不可或缺的一部分的情況下,将移動端的内容做得更完善會更有益于這款産品的推廣,也能夠吸引到更多的使用者。

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

  • 開發主力三人(前端一人,後端兩人);
  • 測試一人(開發階段輔助前端);
  • 美工一人(包括UI和原型設計)。

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

周數 任務 裡程碑
1 确定項目内容與項目核心,進行需求分析,初步完成需求說明書。
2 完善需求規格說明書,明确分工,計劃好接下來的時間安排。 需求分析完成
3-4 統一團隊内的環境搭建,制定編碼規範,建構架構,進行原型設計。 原型設計完成
5-7 開始主體功能的編碼,前端與後端并行,美工完成UI設計,持續跟進,視情況調整完善。
8 功能完善,測試并改進,接收回報修改。 Alpha版本釋出
9-11 開始其它功能的編碼,接口設計完成,實作對接,完成剩餘子產品的任務。
12 繼續完善各功能子產品,初步完成正式版本。 Beta版本釋出
13-14 大規模測試,修複bug,根據回報不斷調整完善最終版産品
15 編寫使用者手冊。 使用者手冊完成
16 項目部署,釋出最終版本的産品。

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

  • 負載均衡:2台(主備)
  • 應用伺服器:16核32G 2台
  • 後端伺服器:32核64G 3台
  • 關系型資料庫:Oracle/SQL Server 3個(讀寫分離2個,備份1個)
  • 緩存資料庫:Redis 2個(主備)
  • 網站安全:建議部署WAF,防DDoS攻擊的防火牆等裝置
  • 帶寬:采用千兆以太網連接配接