個人作業——福大微信公眾號號使用評測
案例分析:在福州大學公眾號上,我們可以即時使用手機關注福大新聞,檢視自身課表、成績等。公眾號可能存在一些小bug影響同學們的使用者體驗。本次作業中,作為一個使用者——福大的學生,將切身體驗該公眾號的功能,並對公眾號中存在的問題,提出改良的建議。
一、調研與評測
1、評測
(1)上手體驗
福州大學公眾號,給我的第一印象是簡潔,功能分明。相較於其他公眾號較為紛繁的操作,福大公眾號的功能較為明確。譬如當我想即時檢視附近有沒有小白校車時,校園巴士功能
就可以立即查詢附近。公眾號上的大部分功能滿足我們的日常需求,包括查成績,看課表等。那麼問題來了,還有部分功能其實吧我們用上的可能性較低。譬如“移動OA”,無許可權開啟,所以我不太能理解這項功能。對於個人日程,我想大部分同學應該不適應在公眾號內進行日程的安排,多數時候手機自帶的日程記錄已經能夠較好的刻畫實現我們的日程安排表。其實可以在我的課表裡面直接新增日程安排?這樣可以結合課程表來定義我們的日程計劃。福大郵箱,手機頁面沒有註冊入口,切換成電腦版在手機端操作不太方便。
(2)軟體bug
a、課表為空,無法匯入。這個可能是還沒有匯入學校教務處資訊吧。所以看到的課表是空的,包括成績查詢也是,還沒匯入資訊。
b、校園巴士只有一條預設資訊。想要獲取全天的校園巴士資訊,但是裡面只有一條,沒有啥參考價值呀。
c、學生證附卡,認證和補辦時,未輸入任何資訊情況下,提示“獲取失敗!原因:輔導員為空,請新增輔導員”,而點選認證之後,認證資訊卻成功出現。PS:我什麼都還沒輸。並且,那些資訊無法輸入。
d、失物招領上傳圖片失敗,提示上傳圖片為空。當我希望傳送一個尋物啟事或者招領啟事時,成功上傳圖片了,但是提交後卻提示圖片為空。
(3)為什麼產品組的人沒有發現這些bug?
a、可能測試組的人員沒有更多考慮到我們真實的使用場景,所以在一些功能上比如學生證附卡資訊填入時,也許在測試時後沒有出現問題,但在客戶真實體驗時, 出現了資訊無法輸入的問題。
b、可能系統的相容性沒有做好,也許在測試時,尋物啟事的圖片是可以上傳的,但到了使用者手中,不同系統版本下,網路協議可能也不太一樣,導致上傳失敗。
c、可能和教務處的資訊除錯沒有做好。可能匯入資訊許可的時間已經過了。
2、採訪
(1)採訪物件
福大計算機系學生——“吳老闆”。作為一個大三學生,在校兩年間也用過許多類似的軟體方便學習生活,包括福大助手,福大易班,福大教務通等,根本需求是用這些軟體查詢課表,學期成績以及完成一些宿舍保修服務和活動申請。通過近兩年的使用體驗,也算是充分了解了這幾款軟體的優點和不足,以及它們之間可以互相補充的地方。
(2)公眾號體驗以及新的需求
吳老闆覺得,公眾號的大部分功能,目前都在實踐階段,在實用性上肯定比不上已經穩定執行的福大助手和福大教務通。在體驗過公眾號之後,他希望公眾號能夠查詢空的自習室(畢竟吳老闆熱愛學習,喜歡找個安靜的小角落看書),能夠查詢四六級成績,並且能查詢一下考試安排,在微信裡面提前兩週發出考試時間臨近的提醒,以便趁早開始復(預)習!公眾號功能看上去挺豐富的,很直觀。介面簡潔易懂。
(3)實際功能上手情況
12.7週五早晨,吳老闆從睡夢中醒來,一看時間8點半。走進陽臺一看,天降大雨,不宜出門。(畢竟吳老闆沒有我單手打傘順便雨中飆車的神技:危險動作,請勿模仿!)。10點20可是有軟體工程課呀,這門課的同學都特別有意思,老師講話又好聽。那麼翹課是不可能翹課的,這輩子不可能!(風裡雨裡,小白等你!)吳老闆想了想,今天還是坐校車吧,誒昨天那個陳x不是給我推薦了福大公眾號嘛,裡面可以看小白的發車時間,一會我上公眾號查詢下三區到東教的小白髮車時間,估摸著小白10分鐘一班吧,我9點50出門,而且有了這個神器,還怕趕不上小白?不管了再睡會。 嘀嘀嘀,9:50am。吳老闆站在三區門口,開啟公眾號一看。。。。???童話裡都是騙人的,小白路線在哪呢?發車時間不對啊? (這時一輛小白呼嘯而過...)誒司機師傅,別走啊!咋不停車呢? 走錯停車點,錯過了兩班小白的吳老闆萬般無奈。多年以後回想起來,當年那大雨下的奔跑,是吳老闆逝去的青春...(跑題了!)。好不容易跑到教室,一看時間10:19,吳老闆鬆了口氣。坐下聽完兩節課,吳老闆覺得自己有點發懵,還是拿u盤拷下課件回去再看看吧!一摸口袋,what the f..,空空如也。吳老闆慌了,一整串鑰匙連同掛在上面的u盤一併丟失了。咋辦咋辦咋辦,u盤上可是有積攢了兩年的學習資料啊!裡面的知識可是千金難換吶!對了,福大公眾號上不是有尋物啟事功能嗎!幸好之前料到過這一天,提前給u盤拍過全身照。吳老闆開啟尋物啟事,貼上u盤照片,寫下“今晨,3區到東教,丟失鑰匙一串,上掛有如下u盤一個,拾得者請聯絡xxxx,我吳老闆,必有重謝!”,點選提交....10秒過去了,沒啥反應。嗯,可能,網速有點慢。吳老闆重新整理介面,編輯好資訊,重新提交...20秒過去了,彈窗:照片不能為空?“一定是我開啟的方式不對”,吳老闆心想。再次編輯好資訊,提交,依然如故。經過多次嘗試,吳老闆心態已崩。
(4)採訪使用者對於產品的改進意見
“老陳啊,你給我推薦的這個公眾號坑爹啊!”中午,吳老闆帶著3分怒氣來找我。“我冤啊吳老闆,這個公眾號我自己也在用,還闊以的呀!” “你看,這幾個功能靠譜嗎。查詢成績,我是2016入學的吧,這時間只能查詢到2015年,穿越了吧。福大郵箱,為啥我的學號被限制登入了?可我實際上還沒用學號申請這個賬號啊!還有這個學生證附卡呀,我不明白它有什麼實際用途,公眾號上也沒有解釋清楚。那個個人日程,我操作起來差點把自己繞暈,還不如用自己手機自帶的記事本。好吧這些都是次要的,早上的事情你必須給我解釋清楚....”
(5)採訪總結
跟吳老闆解釋一通之後,我來做個總結。目前公眾號上的多數功能可能是還沒有上線,那麼相對於其他成熟產品來說,其實我是不推薦同學來使用的。相較而言,福大助手上功能更全面,並且是能穩定執行的,易班上對應的失物招領也做得較好。因而希望公眾號能早點做好資訊對接,因為很多功能我們目前還體驗不了,所以還不能對這些功能做具體的體驗。能夠體驗的功能包括個人日程,操作起來又有一些複雜,有些功能我們不懂得它能給我們做什麼,希望能做一些說明。
二、分析
1、估計專案用時
(開發場景:團隊人數6人左右,計算機大學畢業生,並有專業UI 支援)
階段 | 週數 |
---|---|
開發前的計劃 | 1 |
需求分析 | 2 |
生成設計文件 | 2 |
設計複審 | 1 |
程式碼規範 | 0.5 |
具體設計 | 3 |
具體編碼 | 12 |
程式碼複審 | 2 |
測試 | 1 |
測試報告 | 0.5 |
計算工作量 | 0.5 |
事後總結、改進 | 1 |
2、分析軟體優劣,推理團隊可提高部分。
(1)優勢
借用微信公眾號平臺,學生只需要用學號進行登入註冊,方便快捷。不需要下載新的軟體,功能貼近日常學習生活,也比較全面。
(2)劣勢
同類產品,比如福大助手,介面美觀可以更換主題顏色。功能上已經基本穩定實現,並且有更多的剛需功能,比如選大物實驗功能,查詢空教室。在同類功能如查詢成績上,已經可以快速更新資訊。並且福大助手可以和易班對接,很多易班上的功能可以直接用福大助手使用,也避免了使用者在多個軟體之間的切換。
(3)建議
軟體工程方面可以提高的一個問題就是軟體質量保證環節。在測試階段應該更全面地考慮一些使用者場景和可能出現的問題,並且在上線之前確保功能能真實可用。另一個環節是使用者介面,可以在部分功能上新增一些引導。
具體建議方面:
a、校車資訊能夠實時更新,資訊要更準確一些。
b、通知檔案功能上面那一部分空白浪費了,其實在使用者點選進去之後可以在空白出先顯示部分的通知,而不用在點選下方三個按鈕之後才出現資訊。
c、福大郵箱手機端登入介面可以優化一下,加入註冊的按鈕。
d、個人日程可以加入到課表裡面的子功能,這樣使用者可以結合課表來定義日程,比如在課程表的加號那裡加一個添加個人日程的子功能。並且課表能夠加一個提醒功能(包括日程和課程)
日程的新增加一點引導。
3、軟體的功能邏輯框圖
(1)個人資訊查詢
- 重要度: 90%
- 完成度: 25%
- 出發點: 滿足學生對於個人資訊的查詢,包括成績和課表以及學生證附卡。
- 效果: 目前大多還不能使用。
(2)新聞,講座等通知資訊
- 重要度: 80%
- 完成度: 95%
- 出發點: 讓使用者能夠及時接受學校的各類通知資訊。
- 效果: 挺好的,資訊更新得挺全面,也很及時,這個功能做得不錯!
(3)特色功能
- 重要度: 85%
- 完成度: 50%
- 出發點: 作為軟體的特色功能,方便使用者生活上的一些功能需求。
- 效果: 福大黃頁資訊很全面也很方便,但是失物招領有bug尚未改進,校園巴士資訊沒有更新。福大郵箱在手機端操作不太友好。
4、針對不同維度評分
維度 | 得分 | 理由 |
---|---|---|
使用者體驗 | 60 | 很多功能還不能夠使用,介面切換有點卡。 |
UI介面美觀度 | 85 | 介面簡潔,功能明確。 |
核心功能 | 60 | 核心功能沒有辦法成功體驗。 |
三、建議與規劃
1、如果你是專案經理,如何提高從而在競爭中勝出?
加強軟體的易用性,在關鍵的功能部分新增引導。因為是福大企業號,那麼可以更多增加與教務處的資訊互聯,使學生能夠在公眾號內更方便地檢視一些不涉及特別私密的個人學業資訊等。加強伺服器的部署,閒時不浪費,忙時不崩潰。
2、目前市面上有什麼樣的產品了?
(1)福大易班
福大易班功能較為複雜豐富,涉及學習和生活的較多方面。並且很多活動和獎學金的申請可以在易班上進行操作。教務處的通知也能夠及時下發到易班。不足的地方就是易班常常在關鍵的時刻(訪問量大)的時候,頁面崩潰,比如申請醫保時頁面時常難以重新整理。這影響了很多學生的使用體驗。
(2)福大教務通
這是一款比較穩定的軟體,功能上也與目前的公眾號有較多的重疊,介面簡潔,功能也比較明確,當然與目前的公眾號相比它也缺乏一些特色的功能,使用者多是檢視課表和成績以及考試安排時使用教務通。
(3)福大助手
這是一款做得比較美觀,功能也很豐富的同類競品,頁面美觀並且貼近目前學生的需求。但目前主要是面向學生使用者,公眾號的部分功能是可以方便教職工使用者的。
3、你要設計什麼樣的功能
可以設計更多,類似於查詢校車的特色功能。在課程上加入課程提醒。還有就是,可以方便教師的功能,例如安排答疑教室,調課通知,考試教室安排等。
4、為何要做這個功能,而不是其他功能?
因為其他功能已經有其他的產品,目前可以較好地滿足使用者的需求,那麼我們如果沒有自己的特色功能,很難再搶佔市場。並且據觀察,這些客戶端多是滿足學生使用者的需求,而微信公眾號可以同時滿足教師使用者的需求,這樣我們的使用者群體就擴大了,不會受到更多的侷限。
5、為什麼使用者會用你的產品/功能
因為目前很多學生使用者確實對於校車的路線和發車時間有點不明確,那麼我們的這個功能可以方便學生使用者,尤其是在下雨天,乘坐校車的人流量較大的時候,需要這樣的功能來進行通知。對於教師使用者,可以在公眾號上釋出調課提醒等通知,那麼公眾號就可以給目前在此班級中的學生髮送微信提醒。因為微信基本上是人人都在用的,所以這些通知資訊就能更好地被相關學生所知。
6、NABCD模型
- Need,需求
對於在校的學生而言,他們希望能有一個產品,它能夠提供方便的教務資訊查詢,以及部分生活服務。學生們所需的是一個方便,快捷,功能簡明易用的產品。
- Approach,做法
目前人人都有微信,開發一個對應微信公眾號,在公眾號中對學生進行身份驗證,相關學生使用者就可使用對應的功能。
- Benfit,好處
微信公眾號可以免去APP登入註冊較為繁瑣的流程,而直接使用相應的功能,佔用的資源小,方便快捷。並且公眾號的功能貼近日常的學習生活。
- Competitors,競爭
目前同類競品有如福大教務通和福大助手等,他們的功能較為完善並且介面也十分友好。那麼我們的特色功能就是我們的兩點之一,可以提高我們的市場競爭力,比如查詢校車和失物招領。因為我們起筆較晚,那麼在功能上可能還不及福大助手全面。但是我們也有優勢,就是輕量化,精準化。定位學生使用者的核心需求,滿足需求的前提下,做到特徵差異化。比如在課程和考試上設定對應的提醒等。
- Delivery,推廣
校園門口海報推廣,宣傳我們的核心功能。掃碼關注公眾號,送小禮品等。
邀請相關軟體課程學生體驗,提出對應改進建議。
年級通知群裡邀請學生體驗。
7、如果你來領導這個團隊,會有什麼不一樣?
可能會更注重實用性,除了主要的幾個資訊查詢功能之外,相應的工作重點可能會集中在校園巴士和失物招領等特色功能的開發。像那種訊息通知,福大新聞講座等的通知功能的開發會被整合在一個模組內,並在模組內做更清楚的分類。因為我覺得通知資訊不需要分在通知檔案,校內新聞和講座報告等三個模組。
8、如果你的團隊有5個人, 4個月的時間,你作為專案經理,應該如何配置角色(開發,測試,美工等等)?
- 1個專案經理(兼寫文件)
- 1個美工
- 3個開發(兼測試,幫助寫文件)
9、描述你的團隊在16 週期間每週都要做什麼,才能在第16周如期釋出軟體,大小里程碑績點設定
週數 | 任務 |
---|---|
1 | 需求分析 |
2 | 需求複審,確定開發模式 |
3 | 搭建開發環境,確定編碼規範,進行系統概要設計 |
4~5 | 進行系統的詳細設計,包括系統的基本處理流程、組織結構、模組劃分、功能分配、介面設計、執行設計等等 |
6~10 | 編碼開發階段,每個開發者根據設計要求分別實現各個模組的功能 |
11 | 測試階段,對各功能模組進行單元測試和整合測試 |
12 | 釋出alpha版本,進行小範圍內測和實地測試 |
13~14 | 修復軟體內測中發現的bug,並追蹤是否有需求變更,繼續美化介面 |
15 | 釋出beta版本,最後進行相關除錯 |
16 | 釋出正式版本 |
- 小里程碑:第2周、第5周、第10周
- 中里程碑:第12周、第15周
- 大里程碑:第16周
10、伺服器頻寬配置
應用伺服器配置:4核 8G*2
後端伺服器配置:8核16G*2
關係資料庫:SQL Server/SQLite
快取資料庫:Redis 數量:2
網站安全性:DDOS
(注意伺服器執行峰值期,期末考前和選課時間要尤其關注伺服器狀態)