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

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

PART1 - 調研，評測

1、評測

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

2、採訪

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

採訪過程：

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 (異地冷備 * 一、同地熱備 * 一、讀寫分離 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 熱一部分經常使用數據到緩存中, 以便於快速讀取