產品案例分析 - 華為軟件開發雲

PART1 - 調研，評測

一、評測

1. 第一次上手體驗

在對“華為軟件開發雲”這個名字抱有極大期望的情況下，第一次使用這個產品的時候，說老實話，給我的感覺其實並不太好。

首先在web端，當我第一次點擊“立即體驗”的時候，突然一片灰：

拖動滑動條往下翻了半天終於找到了這個框居然在這！

（當時使用的是火狐瀏覽器56.0，后來似乎沒有復現成功，但是因為第一次點開這網站所以印象很深，初體驗是很懵逼的。）

並且登錄只能選擇記住登錄名而不能記住密碼。雖說可以理解為出於公司項目的安全考慮，但是對於小團隊或者是只在自己的PC機上使用，不能記住密碼感覺十分的不方便，至少可以是諸如“7天內記住密碼”這樣。

不過web端的UI是真的精美啊~ 城市剪影、塗鴉畫風、細節精致的動畫效果，給人一種很年輕、很有活力的感覺，令人很願意繼續體驗。這也是即使第一次試用不太順利，但仍對這款產品抱有好感的原因。

其次是Android端，我在11月10號左右從官網掃二維碼下載了這個app。由於用的是手機注冊，於是輸入了手機號碼和密碼試圖登錄，結果意外的彈出提示“請輸入有效的用戶名和密碼”，反復折騰了半天才反應過來“輸入賬號”是真的只能輸入用戶名來登錄，而只有web端才可以支持輸入用戶名/手機號/郵箱登錄，況且app登錄頁面的文本框標簽提示“輸入賬號”和輸錯時彈出toast的提示“用戶名”兩者稱呼不一致，很令人費解，並且和web端登錄方式不一致，也感到體驗不太好。

好不容易登錄進去了，結果展示在面前的是一片空白，然后彈窗提示“當前網絡連接異常，請稍后重試”，無論點底部欄的哪一個，都是一樣的彈窗提示（確認了一下我的網絡是正常的）。到這時候作為對這個產品還不是很了解的初體驗用戶，我已經很想卸載了。

后來隔了一周又點進去看了一眼還是一樣的情況，就果真卸 · 載 · 了orz。直到前幾天（11月30左右）我突然想起評測作業快要截止了，才又從官網掃二維碼，重新下載了這個app（小米應用市場沒有DevCloud），這時候發現可以使用。

於是在這一個月，使用十分不順暢的情況下，我仍然把它反復幾次下載到手機上的原因，是因為有個作業等我評測。而如果作為普通的用戶而言，我想基本上恐怕就不會再想碰它了。況且相比起web端的精致完善，這款app還是簡陋太多了。

2. 幾個功能性的比較嚴重的Bug

測試主體：

• 華為軟件開發雲（web）
• DevCloud v3.12.2.8（Android）

測試工具：

• web端：Firefox 57.0.1(64)
• 移動端：MIUI 9.0 | Android 7.1.1

一些零零碎碎的Bug其實還挺不少，可能是還在公測期的原因。下面對web端和移動端各舉出1個我認為相對嚴重的Bug。

Bug1（web端）： 測試模塊中，“移動應用測試”的“測試次數”錯誤

復現步驟：

前提：本賬號已創建了兩個項目，一個項目中已建立了 3 個“移動應用測試”，此時在另一個項目中建立 1 個“移動應用測試”之后：

1. 打開“測試”頁面（顯示“移動應用測試”的“測試次數”為 3 ）；
2. 點擊“移動應用測試”（顯示出的測試項有 1 個）；
3. 點擊菜單“服務” -> “測試”（顯示“移動應用測試”的“測試次數”為 0 ）；
4. 點擊“移動應用測試”（顯示出的測試項有 1 個）。

gif動圖：

出了這個Bug的原因，我的猜測是：1. 當有多項目時，菜單欄“服務”的子菜單到底是跳轉到哪個項目的具體服務沒有判斷清楚。2. 當新建一個測試項時，沒有及時刷新“測試次數”。

為什么這個產品組的人沒有發現這個bug? 可能是測試人員只測試了一個賬號一個項目的情況，而沒有測試一個賬號多項目吧。

Bug2（移動端） ： “新建工作項”的“重要程度”非單選

復現步驟：

1. 點擊底部欄“+”號；
2. 選擇“工作項”；
3. 點擊“重要程度”；
4. 勾選任意項；
5. 點擊“重要程度”；
6. 勾選與前一次不同的任意項（有時會出現兩個√同時存在的情況）。

gif動圖：

出了這個Bug的原因，我猜：給工作項標記“重要程度”的處理方式，是把該工作項的名字加入這一“重要程度列表”里，而不是工作項有一個“重要程度”字段（也更方便在漏斗中篩選）。這樣就可能會在用戶勾選另一個“重要程度”時，還沒來得及把之前那個“重要程度列表”里的該工作項刪了。

為什么這個產品組的人沒有發現這個bug? 復現“修改 '重要程度' 出現多勾選”這個bug的幾率大概是點擊三四次出現一次，可能測試的時候沒有去反復多修改幾次。

3. 假設我們團隊需要開發這套系統，需注意的方面

首先要明確這套系統的用戶是誰，要解決的是什么問題。我想用戶群體其實是比較明確的了，就是那些有項目管理需求的企業/團隊。對於項目經理，希望對項目有個可視化的進度把控；對於開發人員，使用方便和成熟的代碼檢查、測試、部署都是非常亟需的。但同樣能看到，既然是SAAS，用戶對這套系統的要求會是非常之高的，如果不能給團隊帶來切實收益，也就不會去付出高昂費用使用這套系統（若按需計費，21-100的團隊估算費用是240元/人/30天）。

要完成這樣一套模塊多、功能完善且又質量高的產品，那必須要分為多組協同開發了，於是就涉及了微服務架構：業務拆分，服務治理，自動測試，自動運維。

在采訪中我也詢問了那位項目經理這個問題，然而他也只是簡單的提到“注意版本管理和運維部署”。但其實我覺得我們這樣的小團隊怕是沒辦法開發這個項目，因為需要好多資源啊...orz

二、采訪

被采訪人： 黃華強（建發房地產集團有限公司信息部項目經理）

采訪過程：

1. 華為軟件開發雲目前集成了項目管理、配置管理、代碼檢查、編譯、構建、測試、部署、發布等功能，您作為項目經理，是否有這方面的需求？或者對於軟件雲現有的功能還有別的需求嗎？
   答：是有這方面需求的。這些基本已經夠用了。

2. 在使用這個產品的過程, 您的需求/問題解決了嗎？
   答：需求已經解決。

3. 軟件在數據量/界面/功能/准確度上各有什么優缺點？
   答：我體驗了一下項目管理工具，感覺還不錯，尤其在界面的數據展示方面讓我印象深刻，有燃盡圖，趨勢圖，工作項完成率圖等，項目情況一目了然，非常直觀，有利於項目管理者對項目進度，質量，成本做整體的把控。

4. 用戶體驗方面有問題么？
   答：用戶體驗上感覺還不錯，功能比較完善，無需花太多時間研究，感覺挺容易上手的。

5. 您對產品有什么改進意見？
   答：如果項目管理工具能夠實現：項目中具體的某一個工作事項的狀態發生變化的時候，能在第一時間及時的告知項目管理者，這樣便是極高的。

6. 若要給這個軟件下一個評價,請選擇一個結論:
   a 非常不推薦
   b 不推薦
   c 一般
   d 推薦
   e 非常推薦

   答： d

PART2 - 分析

1. 使用此軟件的大部分功能，估計這個項目做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，並有專業UI支持）。

   （什么，要完成這么龐大的項目而我的團隊只有 6名 本科畢業生（人少且極有可能0項目經驗） ！老板我辭職...）

   時間：10個月發布第一版穩定版本。感覺已經是極限了...

2. 分析這個軟件目前的優劣（和類似軟件相比），並推理出團隊在軟件工程方面可以提高的一個重要部分（具體建議）。

   同類競品：軟件開發雲、Redmine、teamlab、DotProject的對比（轉載）

   

   

   具體建議：從上表中可以看出，華為軟件開發雲對於中小型、初創型的企業或團隊的項目開發還是有極大的優勢和吸引力的。但是對於已有一定規模的企業來說，很可能已早有自己的一套開發工具，想要使他們的目光轉移到軟件開發雲上，可能會在性能方面提出更高的期望。

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

   功能圖

   

   重要度標識（按“重要”、“較重要”、“一般重要”排序）：

   

   完成度標識（按“完善”、“較完善”、“不太完善”排序）：

   

   出發點&&效果

   模塊	出發點	效果
   項目總覽	作為軟開雲的使用入口頁，展示加入的項目、工作項、歷程、消息	能夠對大部分的需求情況一目了然
   項目管理	展示項目看板、展示項目列表、新建項目的入口	通過柱狀圖的看板和卡片式列表，很好展示用戶所參與的項目的總體情況
   代碼托管	類似Github的功能，將代碼托管到雲	在Github或其他托管平台使用習慣了的情況下，用戶可能比較難適應
   代碼檢查	實現一些簡單的代碼質量管理，幫助監測源代碼質量	挺好的，精准定位代碼缺陷，提供示例和修復建議，被不少用戶贊過
   編譯構建	與代碼托管無縫對接，提供雲端編譯構建服務	挺好，能夠實時監控構建狀態
   測試管理	提供了一體化的測試功能，覆蓋測試需求、用例管理、測試執行、缺陷管理	挺好，支持自定義用例，能夠輔助高效的管理測試活動
   部署	方便用戶將項目部署到雲服務器上	挺好，比較完善，而且也有引導性的介紹
   發布	包括倉庫初始化、軟件發布、軟件下載、軟件查看	挺好，比較完善，而且也有引導性的介紹
   流水線	自動執行一系列流水任務	似乎是比較邊緣的功能，也沒有引導性介紹，不太明白是做什么用的
   移動應用測試	移動應用的兼容性測試，測試各機型對此移動應用的安裝、啟動、使用、卸載的情況	整體還不錯，報表也很清晰，但是當選擇機型比較多的時候排隊會相當久，而且對於有賬號的移動應用僅測試了成功登錄
   企業賬戶授權	支持子賬號登錄，方便企業項目開發人員的使用	挺好的，郵箱驗證也很快捷方便
   代碼廣場	作為代碼倉庫的開源共享和展示平台	完成度不高，看不太出效果

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

   web端：

   用戶體驗：★★★☆☆
   UI美觀度：★★★★☆
   核心功能：★★★★☆

   移動端：

   用戶體驗：★★☆☆☆
   UI美觀度：★★★☆☆
   核心功能：★★☆☆☆

   根據上文的闡述，對於web端和移動端的各維度評判已經很明確了。對移動端的核心功能只給了2星的原因是，移動端的功能僅囊括了查看和編輯各項目的工作項和“消息”模塊，且仍然十分不完善。

PART3 - 建議和規划

1. 如果你是項目經理，如何提高從而在競爭中勝出？
   答：我覺得作為中國市場上立足雲服務的、一整套功能相對齊全的管理軟件的SAAS項目，本身就已具有相當高的競爭力。可是縱觀之軟開雲的呼聲和期待很高，而企業中真正的使用者卻相對稀薄。所以若我是項目經理，首先要抓住用戶痛點，在第一次開放穩定版時就把服務模塊做到功能齊全、易用精致，特別是國內其他家項目管理工具所不具備的功能，提高用戶黏性；其次就是提高宣傳和推廣力度，為什么這么好用的產品大多數人都仍只停留在“聽說過但沒使用”的階段呢？

2. 目前市場上有什么樣的產品了？
   答：微軟全家桶Visual Studio Team Services ，Redmine，DotProject，禪道

3. 你要設計什么樣的功能？
   答：在“代碼廣場”版塊里，對每個倉庫卡片都有一個“評價”的選項，但我點進去這個倉庫也並沒能找到評價模塊在哪里...orz，猜測這估計是要放在后續實現的一個功能，但我認為還不如做個wiki，而去掉評價，因為這種評價感覺意義不是太大：1. 若是需要評判優劣直接看這個倉庫的收藏數就能一目了然；2. 若是為了實現用戶之間的交互手段，只能在一個個的倉庫下面去評論太受限，不如做wiki更方便開發人員之間的資源共享、開發遇到的常見問題整理等等。

4. 為何要做這個功能，而不是其他功能？
   答：因為覺得其他功能以及相對成熟完善了，在采訪過程中用戶也對目前已有的項目管理服務評價說“能夠滿足需求”，但是“代碼廣場”版塊就顯得薄弱很多，如果能做好可能能成為中國的Github交友社區~（逃

5. 為什么用戶會用你的產品/功能？
   答： wiki為一種開放、自由的交流方式，在用戶除去日常使用這種工具類的項目管理功能之外，能有個地方起到共同維護資料整理、或者是公司/團隊內部或之間的交流，會讓工作也不那么乏味。

6. 你的創新在哪里？可以用 NABCD 分析。
   答：

   • N（Need，需求）: 開發者希望在除去工具類功能之外能有一些方便友好的交流方式。
   • A（Approach，做法）: 在“代碼廣場”版塊中，除去倉庫的卡片式展示，另加入一個獨立的wiki模塊。
   • B（Benefit，好處）: 因為有了用戶間的交互，使整個產品變得更有情懷而非一個單純的工具，從而可以增加用戶黏性。就像Github那樣形成了一個社區，即使之后出了更好的代碼托管平台，但我的following都在Github上又怎么舍得離開不用呢？
   • C（Competitors，競爭）: VSTS有“博客”版塊，但卻不支持評論。Redmine似乎是有wiki版塊的，但相對簡陋，使用度不高。總體看來競爭度不是太高。
   • D（Delivery，推廣）: 可以在“代碼廣場”版塊下的“推薦”、“分類”、“排行”菜單后面緊接着放一個“Wiki”，然后UI用不同於其他的更活躍的方式顯示，比如帶有塗鴉式的顏色等等，來引導用戶使用。

7. 如果你來領導這個團隊，會有什么不一樣？
   答：

   • 在軟件發布之前進行更充分的測試
   • 加大宣傳推廣的力度

8. 如果你的團隊有5個人,4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
   答：
   （？？？不是吧，前面不是還有6人，又跑路了一個...orz）

   • 開發：4人
   • 測試：1人
   • 美工：沒人手，另買界面設計方案...

9. 描述你的團隊在16 周期間每周都要做什么，才能在第16周如期發布軟件，大小里程碑績點設定。
   答：
   默認前提：團隊人手和資源能保證在16周內能做完。

   |周數|具體分配|大小里程碑設定|
   |:--|:--|:--|
   |1周|需求分析，設計原型，撰寫軟件規格需求說明書、產品規格說明書|完成SPEC|
   |2~3周|搭建開發環境，確定編碼規范，架構設計，詳細的開發設計，團隊分工||
   |4~11周|編碼開發階段，完成初版后進行測試|完成內測版本|
   |12周|發布v1.0版本，交付用戶試用，獲取反饋，修復bug、完善已有功能||
   |13~15周|對用戶提出的其他需求進行分析，選擇合適的需求，投入此階段進一步開發||
   |16周|進行嚴格的性能測試、壓力測試、集成測試等|發布正式版本|

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

**答：**（通過采訪已工作的同學獲知可能需要如下服務器部署）

前提: 服務器與數據庫均在同一內網互通集群下, 內網帶寬 1Gbps

**數量**

- 應用/后端服務器各 * 1
- MySQL * 4 (異地冷備 * 1、同地熱備 * 1、讀寫分離 2 台)
- Redis * 1

**配置**

- 靜態資源采用 CDN 就近分發, 減輕應用/資源服務器壓力
- 所有請求采用 WAF 過濾, 防止 CC 攻擊、SQL 注入、XSS 跨站、WebShell 上傳、命令注入、非法 HTTP 協議請求、常見 Web 服務器 0day 攻擊等
- 數據中心網絡選擇接入金盾、ChinaDDOS、傲盾、飛塔等硬件防火牆, 以便於清洗牽引 DDoS 攻擊, 或采用電信雲堤就近牽引清洗
- 請求進入應用層之前, 采用負載均衡平衡集群節點負載 (提前進行線上壓力測試, 確認轉發規模)
- 應用服務器采用 4C8T 8G 配置, 並與后端服務器采用內網通訊
  后端服務器采用 8C16T 16G 配置, 並與數據庫集群采用內網通訊
- 數據庫集群中有 MySQL 與 Redis 兩種類型數據庫, 分別對應存儲與緩存, MySQL 硬盤采用 RAID10, Redis 內存不低於 32GB
- MySQL 采用讀寫分離並同地主備, 異地冷備, 以保證數據可靠與一致性, 盡可能降低一切由崩潰、掉電等帶來的數據丟失、宕機問題
- Redis 自動從 MySQL 熱一部分常用數據到緩存中, 以便於快速讀取