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

前言

• Title
• DevCloud

• |組長| 成員 | 負責闆塊 | 貢獻分數 |

  |-------|-------------|-----------------------|-------------------|

  | ★ | 530 雨勤 | 采訪 | 10 |

  | | 311 旭 | 評分 | 10 |

  | | 403 俊 | 邏輯圖 | 10 |

  | | 223 元 | 測評 | 10 |

  | | 437 海輝 | 建議與規劃 | 20 |

測評

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

  • 安卓版的應用看上去十分的簡介以至于簡陋，一些基本的小功能也沒有實作，個人資訊頁面有一個頭像，剛開始以為可以修改，但是并不能，讓人有點小失望。
  • Web端的體驗還是很不錯的，顔色搭配和界面設計都很棒，操作方式也簡潔明了。可以修改頭像但是不能同步到移動端，失望+1。

• 按照描述的bug定義，找出幾個bug，用專業的語言描述，如有必要可配圖。

  • 下面是引用《建構之法》第13章軟體測試中對于BUG描述的片斷。

    - Bug可以分解為：症狀（Symptom）、程式錯誤（Fault）、根本原因（Root Cause）。 
        - 症狀：即從使用者的角度看，軟體出了什麼問題。例如，輸入（3211）時，程式出錯退出。 
        - 程式錯誤：即從代碼的角度看，代碼的什麼錯誤導緻了軟體的問題。例如，代碼在輸入為某種情況下通路 了非法的記憶體位址——0X0000000C。 
        - 根本原因：錯誤根源，即導緻代碼錯誤的根本原因。例如，代碼對于id1==id2的情況沒有做正确判斷，從 而引用了未賦初值的變量，出現了以上的情況。
               

    軟體：DevCloud

    版本：3.12.2.8

    測試環境：Android7.1.2 ResurrectionRemixOS-v5.8.5

  • 掃一掃功能無法啟動相機或掃描時沒有反應

    • Bug圖檔君：bug
    • 具體描述：啟動掃一掃功能，在明确給了相機權限後，掃面界面沒有顯示攝像頭内容，或者顯示瞬間的攝像頭内容後便失去反應，無論怎麼移動手機，畫面都不會動。
    • 可能發生的原因：手機内部運作不穩定或手機記憶體不足。
    • 沒有發現此類Bug的原因：沒有充分考慮各種不同的硬體條件下軟體的運作情況。

  • 昵稱消失或頭像加載失敗

    • Bug視訊君：bug
    • 具體描述：在“我的”和“關于”切換時會出現昵稱消失的情況，有時候是瞬間消失然後複原，有時候在不動界面的情況下一直不出現，頭像也會出現一定機率的加載失敗。
    • 可能發生的原因：軟體優化不好或者網絡加載不暢。
    • 沒有發現此類Bug的原因：沒有充分考慮各種不同網絡情況下軟體的運作情況。

• 假設你們團隊需要開發這套系統，需要注意哪些方面（架構、部署運維、微服務等）。

  • 軟體架構就是軟體的基本結構。微服務架構是服務導向架構的更新。每一個服務就是一個獨立的部署單元。這些單元都是分布式的，互相解耦，通過遠端通信協定聯系。微服務架構可分為三種實作模式。在這個開發雲的系統中，我們可以采用RESTful API模式，服務通過API提供。這樣的優點是擴充性好，各個服務的耦合很低，并且容易部署，軟體從單一可部署單元被拆分為多個服務。這樣做的缺點是服務可能會拆的很細，會導緻系統依賴大量的微服務，變得很淩亂。

采訪

• 相信每個同學的朋友中一定有人需要用這樣的軟體，記載你對這位使用者的采訪。例如使用下面的采訪提要：

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

    • 背景：FZU數計學院2015級軟體工程K班PMS團隊項目管理
    • 需求：項目組員之間時間比較獨立，大家能夠聚在一起讨論交流和敲代碼的時間有限，任務管理與程序推進不能清楚把控，每個人做到哪兒，做的如何全憑自己描述，有時做着做着就有可能偏離目标，需要一個對于項目的主要需求、任務和代碼、缺陷管理都提供較好支援的軟體。
    • 類似的用過：github + leangoo的組合大概能達到類似于華為軟體雲的部分功能效果

• 讓采訪對象使用華為軟體開發雲（請上傳照片證明使用者的确正在使用，遠端采訪的同學請讓别人幫忙照相）

  • 

  • 

  • 

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

  • 移動端

    • 優點

      • 成員互動：以對任務進行評論的方式，具有簡單的互動能力。
      • 操作簡單：邏輯簡單，短時間摸索就能了解用法

    • 缺點

      • 下載下傳不便：組内成員1人使用iphone，4人使用安卓機，iphone下載下傳順利，而各大主流安卓應用商店中則難見其蹤，需要其他管道搜尋。
      • 功能不全：相對于Web端像被閹割過一樣，很多牛逼的功能都不在了，隻相當于一個leangoo。僅移動端，私以為不如leangoo全面直覺。
      • 任務管理：項目成員對任務的操作權限不可修改；任務篩選項中居然缺少按成員的篩選項。
      • 資料管理：個人資料無法管理，也不能檢視組員資料。
      • 其他：很多槽吐不完，整體上感覺移動端就像速成的一個半成品，簡單到簡陋。

  • Web端

    • • 功能全面：各功能清晰可見，比移動端直覺不少，涵蓋了軟體開發完整生命周期的各項内容：開發、測試、部署、運維、監控、分析回報等一切研發活動。
      • 可持續傳遞：開發、測試、運維的跨地域協同和同步疊代，有利于實作項目任務的快速傳遞、快速上線、快速回報。

    • • 任務管理：對非企業團隊，給項目各成員的權限管理有開發人員、測試人員與浏覽者，各自角色權限由系統規定，使用者隻能以角色為機關為組員授權。這樣可以禁止一些非法操作，但是也相對降低了靈活性。
      • 認證繁瑣：認證過程可以說是很麻煩了。

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

  • 好好完善app吧，移動端直接拉低了逼格，被Web端驚豔後看到移動端尤其失望。
  • 權限管理是不是可以既擁有預設的權限方案，又支援自建的角色類型。
  • 認證步驟是否可以進行簡化，推薦使用的銀行卡認證并不覺得值得推薦，身份證認證好像也不太想貼圖爆照（玩笑）。

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

  • web端
    • 非常推薦
    • 無論對于項目管理，還是軟體開發過程管理都很強勢。最吸引人的還是其完整性。
  • • 不推薦
    • 講道理不推薦，太糙了，僅考量移動端，我選擇leangoo。

分析

• 根據了解和體驗，畫出整個軟體所有功能邏輯框圖，根據重要度辨別出各子產品的重要度、完成度、出發點及效果

  • 

  • 

• 針對不同的次元評分，對使用者體驗方面、UI界面美觀度、核心功能，分别打分

  • 打分說明： 0-3為不太好，4-6為一般，7-9為好，10分完美

  • 評分内容 | 本項滿分分數 | 團隊打分 |打分理由|

    --- | --- | --- | --- |

    使用者體驗（移動端） | 10| 5 | 不得不吐槽移動端的功能，首先不能在移動端上修改個人資訊（包括頭像），體驗極差。并且移動端上的功能對比Web端少了非常多，隻能做到項目的管理，相較市面上已有的軟體或公衆号（例如Leangoo）沒有太大的亮點，甚至功能還沒有他們的多，但勝在界面簡潔，操作簡單，是以打5分 |

    使用者體驗（Web端） | 10| 9 | web端使用者體驗還是很好的，可以很好的滿足使用者的大部分需求，為使用者項目進展上提供很大的幫助，但是使用者實名認證上太過于繁瑣，會讓使用者失去認證的信心、興趣，是以打9分。 |

    UI界面美觀度（Web端） | 10 | 8 | 首先從團隊成員的審美來看，這個界面的美觀是符合我們的審美标準的，上部的工作列包含了絕大部分的功能，但界面中不是很能展現華為的企業文化，或者說是比較好看但沒有特殊含義的界面，是以給到了8分 |

    UI界面美觀度（移動端） | 10 | 4 |作為華為這種大公司，團隊成員認為移動端界面過于簡單，像是速成的UI，不符合一家大型企業的開發水準，且IOS和Android端的界面不是一樣，是以隻給出了4分。 |

    核心功能 | 10 | 10 |此套軟體，給出了包括文檔、代碼編輯、團隊管理等涉及幾乎一個項目從頭到尾的一站式服務，甚至能連結到某搜尋網站搜尋相關内容，為項目的進展提供了很大的便利，給10分不怕驕傲。 |

建議和規劃

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

  • 移動端在添加好友功能可以做的更具備人性化一點，是該産品更具有社交性。目前Devcloud對于交流方面的功能僅處于某個項目下的某個看闆，團隊成員可以根據看闆的任務數以及任務完成情況進行有限的溝通和交流。如果我是項目經理，我将緻力于提高技術人員除了技術層面的交流外，加強團隊内部之間的交流，從社交性的角度進行提高。

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

  • 領歌（團隊協作）

    • Leangoo（中文名：領歌）是一款基于看闆的項目協作工具。我們可以使用Leangoo可視化地進行項目需求、任務、問題和文檔的管理和協作，随時随地跟蹤團隊工作進展。Leangoo工具的設計融入了先進的靈活管理思想，由多位業界知名靈活管理顧問提供支援，并由專業的靈活開發團隊精心打造而成，完美支援Scrum靈活開發和看闆方法。Leangoo的核心是看闆，通過看闆共享和實時同步團隊工作以實作高效協同, 團隊工作展現為卡片，内容可以是需求、任務、問題等。Leangoo看闆上的主要元素包括清單和泳道，清單管理工作的不同階段或狀态，泳道實作任務的分組對應，從兩個緯度讓團隊的工作高度可視化、一目了然。Leangoo提供永久免費的線上版本，企業、個人或其他組織線上注冊之後即可免費使用。Leangoo的資料傳輸采用了最新的https/ssl資料加密技術，使用者資料存儲在和支付寶同級别的阿裡雲伺服器上，并且經過了加密存儲，以保證使用者資料安全。Leangoo也提供商業化的專屬版，專屬版本可以部署在企業私有雲或者企業内網。

  • worktile

    • 一站式協作平台，集高效協作、即時溝通和移動辦公于一體，提供企業IM、任務管理、日程安排、企業網盤，工作簡報等應用，真正提高員工的工作效率。

      整合企業内外部各種應用，不同應用之間的資料彙總到企業資訊總線中，真正解決企業資料孤島的問題，目前已經支援超過100個企業級服務。定制屬于企業自己的企業協作平台，通過自定義Logo和登入頁、提示消息打造企業文化；通過配置，自定義企業自己的安全政策。

  • Redmine

    • Redmine是用Ruby開發的基于web的項目管理軟體，是用ROR架構開發的一套跨平台項目管理系統，據說是源于Basecamp的ror版而來，支援多種資料庫，有不少自己獨特的功能，例如提供wiki、新聞台等，還可以內建其他版本管理系統和BUG跟蹤系統，例如Perforce、SVN、CVS、TD等等。

  • Github

    • 作為開源代碼庫以及版本控制系統，Github擁有超過900萬開發者使用者。随着越來越多的應用程式轉移到了雲上，Github已經成為了管理軟體開發以及發現已有代碼的首選方法。如前所述，作為一個分布式的版本控制系統，在Git中并不存在主庫這樣的概念，每一份複制出的庫都可以獨立使用，任何兩個庫之間的不一緻之處都可以進行合并。GitHub可以托管各種git庫，并提供一個web界面，但與其它像 SourceForge或Google Code這樣的服務不同，GitHub的獨特賣點在于從另外一個項目進行分支的簡易性。為一個項目貢獻代碼非常簡單：首先點選項目站點的“fork”的按鈕，然後将代碼檢出并将修改加入到剛才分出的代碼庫中，最後通過内建的“pull request”機制向項目負責人申請代碼合并。已經有人将GitHub稱為代碼玩家的MySpace。

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

  • 交流的層級，可以在項目層級與團隊成員就更大闆塊的内容進行溝通與讨論。
  • 資訊提醒功能，當團隊成員發送讨論話題或者提出問題時，頁面有提醒功能，并可以通過提醒的視窗直接進入讨論界面
  • 添加好友功能，目前該平台添加功能，需要通過掃描二維碼更換所在區或者精确輸入成員名字并通過公司授權，從安全性和需求的角度确實能夠部分滿足部分使用者的需求，但是随着軟體對社交性要求越來越高，将通訊錄直接添加好友方式必将成為主流。

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

  • 社交性這個屬性在網際網路産品中的地位越來越重要，通過公共的社交軟體如同QQ、微信等第三方社交軟體去交流其他産品的問題，于我與周圍的同學來說，感覺到越來越困難，問題的描述，bug的尋找，看闆任務的提醒，截止日期等方面的交流沖突将越來越突出，平台本身的社交功能也使得更加重要。依據我們團隊的構想，從添加好友、消息提醒、交流的層級三方面着手，可以有效的提高該平台的社交性，提高使用者體驗。

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

  • 這項功能對于一個技術大牛來說或許使用有限，但是對于一個小白來說，确實一個救命稻草，很多遭遇的問題和bug在不知公司大佬大牛的微信等私人聯系方式情況下，通過平台自帶的社交功能解決是上上策。社交之外，這個功能更多在于咨詢與請教。

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

  • Need 需求

    • 如上一點所示，我們的需求主要針對兩方面，一個是程式員小白初入公司，無處尋覓大佬支援，需要通過雲平台聯系公司的大牛請教程式上的問題。另一個是團隊協作内部對互相提出的問題以及任務的完成情況進行即時的交流和回報。

  • Approach 方法

    • 為了滿足這些需要，我們可以做出以下處理方式
      • 可以通過調查問卷，采訪周圍使用華為軟體雲平台的使用者或者使用相關類似平台使用者，并給出真實的使用者體驗。
      • 利用網絡，釋出測試版産品，可以讓不同年齡段的使用者使用體驗并且可以給出一些建設性的意見。
      • 充分考慮社交軟體的功能，将可移植部分與團隊協作方面進行綜合考慮，使得兩者無縫對接，另外充分考慮團隊協作社交對于技術上的問題，進行針對性處理。

  • Benefit 好處

    • 雲平台除了能夠提供代碼管理、團隊協作、編譯建構等功能之外，還能整合社交軟體的功能使得開發人員直接通過該平台進行溝通交流，友善靈活。
    • 擁有可以個性化添加好友的選項，很多人的對隐私比較重視，工作和生活應當分開，技術層面大多是工作上的交流，啟用私人的第三方軟體會影響到自己的生活。

  • Competitors 競争

    • 諸如市面上的其他産品，對于平台內建其他功能上做了不少功夫，但是在社交層面有比較領軍優勢的産品暫時沒有，如領歌通過郵箱進行提醒等，許多軟體也在探索符合自己産品特色的社交方式，我們的産品直接針對技術層面的交流進行探索，在原來內建諸多功能的情況下豐富社交功能，使得使用者獲得良好的使用體驗。

  • Delivery 推廣

    • 如果我們的方案能夠通過華為官方的認可，我想，推廣這個東西，應該很簡單吧哈哈哈。

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

  • 如果我來上司這個團隊，我想我會更加注重軟體的廣泛性、社會性、社交性，在實用性方面可能比較弱，整個團隊也會更加充滿生命力，注重建造氛圍，戰鬥力可能從另一個層面提高，相信應對更多的任務，也無所畏懼。

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

  • 2個人負責核心子產品的代碼開發，一個人負責後期測試，一個人負責全程的美工與界面，還有一個人負責整個項目的統籌，以及随時根據社會上的具體情況，調整産品發展的方向，我們不能閉門造車，要随時關注社會變化，在産品完成之時，處于一個良好的推廣時機。

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

  • 第一周，小組内部讨論，對功能進行具體化、方案化。
  • 第二周，小組外出調研，盡可能收集競争對手目前緻力于解決的問題，如發生沖突，應及時調整政策，或在自身功能上做更深入探索。
  • 第三周，敲定方案，立即開始開發與頁面設計。
  • 第四周到第八周，開發過程，争取在第八周alpha版本釋出，并進行小組讨論，補缺補漏。
  • 第九周到第十四周，第二波沖刺，每個版塊功能完善，并争取準釋出版本。
  • 第十五周，公司内部測試，問卷回報，處理問題。
  • 第十六周，界面完善，最終釋出。

• 項目釋出後，有沒有考慮過項目該怎麼部署才能滿足需求。分析16周後你所完成的項目上線需要哪些配套裝置(伺服器、帶寬、資料庫需求數量與配置)