拖鞋旅遊隊專案測評

前言

• 隊名：拖鞋旅遊隊
• 組長部落格：https://www.cnblogs.com/Sulumer/p/10087665.html
• 本次作業：https://edu.cnblogs.com/campus/fzu/Grade2016SE/homework/2436

第一部分 調研，評測

評測

Android端評測

• 上手體驗：功能全面，易於上手，佔用記憶體小，頁面設計人性化。
• 思維導圖：
  
• Bug1：
  
• Bug2：
  
• 為什麼這個產品組的人沒有發現這些bug：測試小組測試不仔細，不全面；這些功能前後端開發可能不同步。

IOS端評測

• 上手體驗：執行流暢，圖示簡潔，配色清爽，部分圖片失真，功能種類多但是不完善，夜間模式，匯入日曆功能方便，實用性高
• 思維導圖：
  點我檢視原圖
  
• Bug1：
  
• Bug2：
  
• 為什麼這個產品組的人沒有發現這些bug：第一個bug可能是因為開發者對於考試安排的理解錯誤。第二個bug是前後端對分享功能的開發不同步。

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

• 我們會加強宣傳。
• 根據反饋修復bug。
• 跟進更新如歷年卷、易班等功能。

採訪

• 採訪物件背景：附件某高校大三學生，沒有使用過類似app。
• 採訪物件需求：需要一款可以檢視課表、考場、成績及一些在校日常查詢的功能。
• 採訪照片：
  
• 採訪物件的使用體驗：
  • 採訪物件對日常一些所需要的查詢資訊的問題都可以完美地解決。
  • 資料量很齊全且豐富，所需要查詢的資訊都可以查到。
  • 介面較為簡潔明瞭且醒目，但不同介面間的字型風格不夠統一。
  • 功能比較齊全和豐富，但部分易班上的功能使用度過低。
  • 準確度上做的較好，使用到目前未發現不準確現象。
• 採訪物件的改進意見：這位使用者強烈建議增加一個課表分享和成績分享的功能，他想分享到微信上給別人看他的課表，以及家長對於成績的查詢，能夠簡單明瞭直觀的看到所需的資料。
• 結論：非常推薦！

第二部分 分析

• 估計這個專案做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，並有專業UI 支援）。
  我們估計這個專案做到這個程度只需要一個月，因為既然是本校大學畢業生，應該會有比較好的基礎，而且做這個專案應該會受到學校極大的支援，對介面的獲取難度應該較低，而且有專業的UI支援，我們認為一個月時間足夠了。

• 分析這個軟體目前的優劣（和類似軟體相比），並推理出開發團隊在軟體工程 方面可以提高的一個重要部分（具體建議）。
  這款軟體優勢在於擁有較為廣闊的群眾而且功能也算齊全，劣勢就在於有些功能可以有時候無法使用（空教室功能），在軟體工程方面可以提高的一個重要部分就是對歷年卷這一模組的管理，許多科目都上傳了不相關的資訊從而干擾大家獲取正確的資訊，希望能夠加強這一塊的管理。

• 根據理解和體驗，畫出整個軟體所有功能邏輯框圖，根據重要度標識出各模組的重要度、完成度、出發點及效果。
  點我檢視原圖
  

• 針對不同的維度評分，對使用者體驗方面、UI介面美觀度、核心功能，分別打分。
  使用者體驗方面打7分：因為有些功能經常無法使用而且歷年卷功能沒有維護。
  UI介面美觀打9分：介面簡潔明瞭，向量圖也很精美。
  核心功能8分：查詢課程表、查詢成績、查詢考場、歷年卷應該都是核心功能，大多數都好用。

第三部分 建議和規劃

• 如果你是專案經理，如何提高從而在競爭中勝出？
  • 加強宣傳。這款產品宣傳力度在同類中非常低，大部分同學沒有使用過甚至沒有用過。
  • 解決bug，增強使用者體驗。
  • 增強功能，如檢視課表，查詢成績，查詢歷年卷。
• 目前市場上有什麼樣的產品了：超級課程表、福大教務通、課程格子。
• 你要設計什麼樣的功能？
  • 歷年卷代列印及送貨上門服務。
  • 學分查詢。
  • 教師基本資訊查詢。
• 為何要做這個功能，而不是其他功能？
  據我們作為學生的角度以及綜合前期的調研等，這幾個功能現有方式較為不方便，而這些功能又都是剛需。
• 為什麼使用者會用你的產品/功能？
  • 到期末的時候大家都會有列印歷年卷的需求，這樣比較方便同學。
  • 目前福大助手易班中的學分查詢已經不能用了。學分查詢對於同學來了解自己還差多少學分還是很有必要的。
  • 教師基本資訊查詢可以幫助同學們在學期選課的時候看到教師的基本資訊幫助同學們選擇任課老師。
• 你的創新在哪裡？可以用 NABCD 分析。
  我們的創意解決了使用者列印歷年卷，查詢學分，已經在選課時可以比較老師的掛科率和高分率。相對於其他競爭者而言，不太可能做到這麼本土化的功能，他們的課表app固然很優秀，但也伴隨著廣告多，社交性太強等諸多問題。而我們的app更能滿足使用者的需求。
• 如果你來領導這個團隊，會有什麼不一樣？
  如果我來領導這個團隊，說實話，我覺得不一定會比現在的團隊做得好。但是站在另一個角度，使用者反饋、運營方面並沒有得在這個產品的現有團隊得到很好的體現。如果是我來領導，在產品上線後，我會加強運營這個產品，至少做到讓全校學生都知道又這款app。使用者反饋也是極其重要的，它可以幫助我們不斷的修復和完善產品，我會重視使用者反饋，有時間甚至會與使用者深入溝通，以此來不斷提升產品。
• 如果你的團隊有5個人, 4個月的時間，你作為專案經理，應該如何配置角色（開發，測試，美工等等）？
  這是一款工具類的產品，同時具有非常強的競爭力，因此我認為這款產品的美工任務還是比較小的，同時開發週期也是比較緊張的，不足以分配一人。我會配置兩名人員作為前端開發（其中一名為前端組長），兩名後端開發（其中一名後端組長），一人專案經理兼產品經理兼美工兼運營，全員開發（兩名組長與專案經理主要測試，其他人員輔助測試）。
• 描述你的團隊在16 週期間每週都要做什麼，才能在第16周如期釋出軟體，大小里程碑績點設定。
  
  
• 專案釋出後，有沒有考慮過專案該怎麼部署才能滿足需求。依據附錄圖（某校教務處系統的部署）作為參考，分析16周後你所完成的專案上線需要哪些配套裝置(伺服器、頻寬、資料庫需求數量與配置) 。
  

第四部分 增量開發設計

• 優化/新增功能點的原型介面
  • 新增歷年捲上傳入口。
  • app訊息推送功能。
• 基本實現思路

  • 歷年捲上傳入口

    • 後端新增一個檔案上傳介面，為了安全要加入token以及AES加密，同時不能直接釋出，需要有一個標識標記稽核情況。
    • 前端在歷年卷頁面加一個上傳按鈕，上傳引數：學院、科目、檔案、學號、時間....同時上傳只是上傳，管理員在後端頁面通過稽核之後，才允許出現在歷年卷裡。
    • 獎勵還是無獎勵機制，後續再看積極性。

  • app訊息推送功能

    • 出成績或者考試日期公佈臨近，就會推送。
    • 校招，每天的招聘資訊推送。 由於考慮到出成績、考試、校招這些都會提前出來，而且也不是緊急時間，所以可以採用輪詢的方式，頻率每12小時或每6小時跟伺服器請求一次，如果有新通知則在安卓端彈出。

• 優化/新增功能點與原有產品如何接入
  歷年捲入口簡要原型：
  

第五部分 答辯總結

• 團隊貢獻比例
  | 學號 | 成員 | 分工 | 貢獻分 |
  | --------- | ------ | ------------------ | ------ |
  | 031602428 | 蘇路明 | 撰寫部落格，回答問題 | 9|
  | 031602401 | 陳瀚霖 | 評測，評審表，提出問題| 11|
  | 031602406 | 程曉巨集 | PPT製作與演示| 12|
  | 031602438 | 葉一帆 | 增量開發 | 9.5|
  | 031602407 | 何家健 | 評測，評審表，提出問題| 10|
  | 031602410 | 黃海潮 | 採訪| 9|
  | 031602429 | 王錦揚 | 建議與規劃 | 9.5|
  | 031602442 | 鄭孔宇 | 分析|9.5|
  | 031602439 | 俞凱欣 | 建議與規劃| 9.5|
  | 031602421 | 林世傑 | 專案評測報告| 11|

• 評分：去除最高分（81）最低分（71）後的平均分：75.84

  組號	團隊名	評分
  1	爸爸餓了	71
  2	拖鞋旅遊隊	81
  3	彳艮彳亍	79
  4	火箭少男100	72
  5	起床一起肝活隊	75
  6	404 Note Found	76
  7	第三視角	74
  8	小白吃	79

• 問題&回答

第一小組的問題：

• Q1:增量開發中的列印送上門服務可行性強嗎，畢竟列印成本很低，但是人力送貨上門的成本很高？
• A1:我們覺得可行性還是挺強的，至少列印利潤高，使用者在這方面需求也比較強。可通過使用者自行選擇上門或者自取，上門收取額外費用（1-2元），其實在校內送貨上門地點還是比較集中的，可以考慮一天送一次等，數量上去了，成本就降低了，同時校內列印服務市場劃分還是比較明確的，這一服務能有效提升合作列印店的市場擴張。
• Q2:是否考慮過對增量功能採用其他的送貨方式，比如使用者到店自提或者使用類似豐巢快遞櫃的設變來支援這個功能？（只是假設）
• A2:有考慮過多種方式結合，如果只是純粹到店自提，資料的管理也是一件很棘手的事情，我覺得在這一場景不適用類似豐巢快遞櫃的設變，成本過高，沒有必要。
• Q3:測評除了採訪物件外是否有釋出問卷調查？
• A3:這一方面我們相對其他組確實比較欠缺，我們沒有釋出具體的問卷調查，只有通過一些資料收集，以及採訪交流。

第三組的問題

• Q1:請問你們的致命級bug2是什麼系統的bug？
• A1:我們在測試報告以及PPT都有以系統來分割bug，我們展示了不止一個致命級bug，好像沒有分清這裡說的是哪個bug。
• Q2:請問再找其他學校同學測試的過程中兩者學校易班或是大物實驗等一些福大助手核心功能模組在現實中的作用是否相似？
• A2:易班類有相似，大物實驗沒有具體瞭解。
• Q3:請問那位被採訪同學說希望增加課表分享,課表分享不是已經有了麼？
• A3:但是目前福大助手這方面做得好像並不夠完善，也不能成功分享吧。IOS系統沒發現課表分享功能。

第四組的問題

• Q1:ppt中部分圖片建議考慮使用透明的底，而不是白底。
• A1:作為白底主要是考慮到圖片的界限問題，以後會注意。
• Q2:bug展示的不夠多，是沒有發現更多的呢還是選了兩個有代表性的呢
• A2:選取了兩個有代表性的，其他的相對感覺不是很重要或者頻率不是很高。
• Q3:採訪使用者數量是否有些不足呢
• A3:這一方面我們相對其他組確實比較欠缺。

第五組的問題

• Q1:採訪物件是否太少，結果會不會出現特殊性
• A1:這一方面我們相對其他組確實比較欠缺。但是我們也有收集其他的資料，從反映情況還是沒有出現特殊性的。
• Q2:ios端的bug沒有體現系統環境，查詢不到是否足以夠作為理由
• A2:福大助手軟體內沒有註明版本，在app store中查詢應是3.9.12.版本。
• Q3:測評報告第八頁，BUG2中的b小點，“幾點”是否為錯別字，這能否體現後期對報告成品的稽核不夠充分
• A3:確實是錯別字，這是我們的失誤，我們考慮將撰寫報告的人員“祭天”。

第六組的問題

• Q1:ppt24頁的改進意見中，課表分享福大助手已經實現了
• A1:但是目前福大助手這方面做得好像並不夠完善，也不能成功分享吧。IOS系統沒發現課表分享功能。
• Q2:邏輯框圖和思維導圖顯示不清楚
• A2:本次截圖確實都顯示比較模糊，我們也有盡力在處理。
• Q3:能否關閉APP訊息推送功能
• A3:確實應加入app訊息推送的選擇。

第七組的問題

• Q1:ppt功能設計中第一點是：歷年卷代列印及送貨上門服務。此功能實現起來有點難度，想知道怎麼來具體實現這個功能？
• A1:使用者選擇列印，後臺資料傳送給列印店併產生單號，提取方式選擇送貨上門（考慮收取1-2元服務費）或者自取，現在跑腿這麼發達，送貨上門應該不會問題。
• Q2:在增量功能中，對於那個歷年卷的功能，假設會去實現，那請問你們怎麼判斷歷年卷的真實性，以及可靠性？
• A2:歷年捲上傳肯定是需要後臺人工稽核的，也可以考慮在前臺註明不明真實性，使用者發現歷年卷的不真實可K它，被K多了的歷年卷將考慮暫時下架重新稽核。
• Q3:ppt功能邏輯圖中你們認為“大物實驗”的完成度是0，你們是怎麼判斷出是0的？
• A3:目前好像登入不上？

第八組的問題

• Q1:測試報告中的中功能點的重要程度與完成程度的數值是否具有準確性和科學性？
• A1:只能說是預估吧。
• Q2:ppt中表示福大教務通作為一款福大助手工具是不合格的，但是為什麼福大教務通的使用率依舊如此之高？
• A2:首先其在產品推出前期做了良好的推廣效應，同時其實官方產品，有官方光環保護。最重要其實感覺其是針對教務通方面，不具備其他的助手功能，其使用率高我覺得是因為使用者習慣（本人也是教務通忠實粉絲，對此方面思考認為是如此）。
• Q3:歷年卷列印功能在期末考啦上面已經失敗過了，你們是否有更好的實施方法？
• A3:其的使用者需求度不言而喻，失敗不代表不可行，失敗也有很多種原因。良好的服務和使用者的便利是這方面最重要的條件，至於實施方案不清楚之前的期末考啦是怎麼操作的，覺得這方面在列印源與配送上有非常大的優化空間。

第六部分 個人部分

• 個人學習進度條