軟件產品案例分析（團隊）

前言

• 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周後你所完成的項目上線須要哪些配套設備(服務器、帶寬、數據庫需求數量與配置)