目錄
- 第一部分 調研,評測
- →評測
- →采訪
- 我根據該SDK想要開發的産品
- 潛在使用者采訪
- 結論
- 第二部分 分析
- 估計這個SDK做到這個程度大約需要多少時間
- 分析這個軟體目前的優劣
- 團隊在軟體工程方面可以提高的一個重要部分
- 第三部分 建議和規劃
- 如果我是項目經理,如何提高進而在競争中勝出?
- 目前市場上有什麼樣的産品了?
- 我要設計什麼樣的功能?
- 為何要做這個功能,而不是其他功能?
- 為什麼使用者會用我的産品/功能?
- 我的創新在哪裡?可以用 NABCD 分析。
- 如果我來上司這個團隊,會有什麼不一樣?
- 團隊角色配置(5個人, 4個月)
- 描述團隊開發安排(要求第16周如期釋出軟體)
- 項目釋出後,項目如何部署滿足需求。
這個作業屬于哪個課程 | →2019秋福大軟體工程實踐Z班 |
---|---|
作業要求 | →個人作業——軟體評測 |
這個作業的目标 | 完成對騰訊實時音視訊的評測 |
作業正文 | 點選這裡 |
其他參考文獻 | 建構之法 |
demo使用過程中的截圖
- ios端demo體驗
- 微信小程式demo體驗
- web端demo體驗
功能性嚴重的bug
1.房間号邊界值不明确,輸入門檻值不等于可進入房間号的門檻值
-
問題描述: web端明确寫出可微信小程式掃碼加入通話,但是兩端房間号邊界卻不比對。當web端建立一個房間号如999999999999999999(18位)時可以建立,但微信小程式進入房間會警告退出。
web端視訊通話房間号可輸入0至18位房間号,且房間号可為0;微信小程式視訊通話房間号最多可輸入20位,且房間号為0進入房間會警告退出。
-
bug截圖
web房間号為18位的999999999999999999
微信加入上述web房間
房間号為0
- 為什麼産品組的人沒有發現這些bug??
各個demo參與制作人在定制房間号邊界時沒有溝通到位,或者制作者沒有考慮到使用者會用到這麼長的房間号。
2.功能提示不夠完善,缺少指引
- 問題描述: 微信端demo中手機直播和視訊通話下方的功能選項并沒有文字提示,而直播播放在内的其他4個子產品界面下方卻都有功能對應的文字介紹。ios手機端demo則是兩個子產品都沒有下方功能提示。
微信視訊直播功能下方無文字提示,微信直播播放有文字提示
産品組就demo而言目的可能是展示實作的基本功能,使用者友好提示的設定或許不在産品組對demo展示的預期中。
3. 缺少視窗關閉選項或提示,視窗自适應問題
- 問題描述: ios手機端demo當 點開設定、使用者清單、音樂功能選項時,界面彈出一個超過顯示内容範圍的功能框,要再次點選該功能按鍵才可以關閉功能框。而功能框大小本身又遮擋了功能按鍵的一半,關閉操作十分困難。但是有時又會出現功能窗大小合适的現象(特别是在ipone6s上大小合适,在ipone6sPluse上多次使用隻出現一次大小合适的情況)
- 功能欄遮擋(左),功能欄未遮擋(右)
這應該是一個産品組沒有解決的自适應bug
4.視訊直播人數上界
- 問題描述: web視訊直播人數達7人會随機強制退出部分使用者的直播間或者關閉攝像頭,ios手機端卻可以看到web被關閉了攝像頭的直播間,兩端未同步
- 可以看到相同時間内兩者未同步
- 産品組沒有考慮到7人及以上一起視訊直播的可能?或者裝置不支援
5.加入直播間使用者名重複強制退出問題
- 問題描述: 後加入直播間的人使用者名與之前在直播間使用者的使用者名相同,更早加入直播間的那個使用者會被強制退出
- 沒有考慮到使用者名重複的可能性?
學習直播app
- 産品主要功能
- 直播學習或工作過程
-
記錄學習時長及PK
設定類似forest的離開即停止計時的功能,可與他人pk學習時長,可以類似與朋友互相激勵監督或者與學習榜大神pk
-
觀看權限
播主可指定是隻能在標明清單内的人觀看直播或者把直播開發給任何人
-
學習分區
可以在直播過程切換目前學習分區,記錄一天中花在不同學科上的時間,可針對分區pk
-
效率評定
直播結束後評定自己的學習效率,或者由pk對手評定
-
成績單
可根據直播分區和時間生成本次直播或者這一個月直播的“成績單”,記錄花在各部分時間和效率,生成類似日常計劃表的“成績單”
- 名師直播講課
- 直播記錄回看
-
産品面向的使用者
想要通過直播督促自己或者記錄學習點滴又不想在娛樂平台直播的群體
- NABCD分析
-
N——Need
在b站首頁經常會看到一些學習直播間,又或者是學霸學習直播間。對于一個想通過直播督促自己,或者學習他人的使用者,娛樂性質的直播平台會帶來幹擾,而一個針對性app可以免除這種困擾
-
A——Approach
觀看權限功能:讓使用者在達到直播督促的需求同時又保障了使用者可接受範圍内的隐私;成績單功能:在記錄計劃的同時又確定了計劃的落實,相較傳統的計劃記錄及打卡更有落實性
-
B——Benefit
事實上我并沒有搜尋到專注學習直播的平台,即使存在應該也沒有推廣開來,要不然也不會總看到b站學習直播了。如果使用者是處在一個緊張的學習環境,如考研。他會盡量避免使用這些可直播的娛樂app,一款可以直播又避免接觸娛樂項目的app更能吸引這部分使用者
-
C——Competitors
我認為我要做的直播産品,是類似無聲直播的,使用者可以選擇關掉聲音安靜學習或者開小音量聽着pk對手的翻書學習聲督促自己。這是一款比較“安靜”的直播app,界面設計首先要簡潔輕盈,剝去備援的娛樂功能,這在我搜尋到的已有的并不是專注學習直播但是有涉及的app中是沒有展現的。
-
D——Delivery/Data
可以讓知名學習up或名師加盟。就資料方面我認為這款app不存在這方面的困擾,隻有一個想自己學習的使用者或者隻有一對想彼此督促的學習夥伴都可以使用起這個app,它無需超大人流量和點選量來支撐app的使用。
-
-
對象的背景和需求
背景:大學大學生
需求:視訊通話/螢幕分享
- 使用者使用騰訊實時音視訊照片
-
使用者使用這個DEMO的過程
使用者的問題是否解決?→是
軟體優缺點
優點 | 缺點 | |
---|---|---|
資料量 | 較為豐富 | - |
界面 | 簡潔明了,布局清晰,一目了然 | 不夠美觀、對使用者的吸引力低;界面的跳轉可以更流暢 |
功能 | 可以滿足使用者的核心需求 | 幾個功能的差別并不是很清晰,第一印象會覺得備援 |
準确度 | 功能實作、跳轉、布局基本準确 | 個别跳轉輕微卡頓;個别布局錯位 |
使用者體驗方面是否有問題
體驗基本順利,但有些功能似乎無法展現(比如視訊水印、橫屏模式)
使用者對騰訊實時音視訊的功能改進意見
界面美觀度需要提升;
對使用者進入房間的處理不夠友好,希望能增加稽核機制或給房間内的使用者發出相關提示資訊;
希望分享螢幕的同時也可以分享媒體聲音而不是隻有麥克風聲音;
需要修複bug;
使用者對你想開發的産品有哪些意見?
學習app的各種功能都要以不影響學習效率為前提,建議增加直播時對消息的設定,避免自控力差的主播因與觀衆交流而分心;
注意安排管理者對直播内容進行稽核、過濾;
可以考慮開發時支援分屏或背景功能,保證主播在開啟直播的時間内還能用手機查找資料等(隻能攝像頭轉換避免死亡視角);
對于直播學習之外啥都不想要的使用者提供一個極簡版本開關
經過這麼多工作,你一定有充分的理由給騰訊實時音視訊下一個評價,請選擇一個結論:
非常不推薦
不推薦✔
一般
推薦
非常推薦
如果是做出所有現有功能的話大概2-3個月?
這裡選擇聲網做對比對象。
- demo容易運作,隻需掃碼或者點選網站就可以直接使用demo;相比之下聲網還有一個代碼寫入過程,步驟更為繁瑣
-
劣勢
1.官網指引不足。聲網的使用者指引簡潔生動,直接展示建構直播各步驟的方法代碼,讓使用者在學習的同時感到趣味而騰訊音視訊則要自己去探索各種功能
2.界面設計不足:就短短的體驗時間中,我能感受到聲網的美工更加符合我的審美,在使用者友好方面我認為聲網做的比騰訊音視訊好得多。
我認為騰訊音視訊團隊可以增加軟體的使用者指引功能,降低使用者的花在軟體品質成本中“預防”和“學習新技術”的時間,像聲網一樣讓使用者有實感的體會到建構的過程。比如在官網快速入門這個部分添加一些指引視訊或者指引動畫,讓使用者更好上手,而不是字面上的“一分鐘XX”
假如我需要用這個騰訊實時音視訊SDK開發屬于我的自己産品:
讓一些學習相關大up推廣推薦或者在有影響力的學習平台打廣告;使用獎勵政策,如設定部分收費功能但是隻要使用者在微網誌發表使用感想就可以開放功能。
事實上在任何直播平台都可以實作學習直播,但是專注學習直播産品我沒有找到
- 設定觀看權限
大多數功能都是因為在b站上看到學習直播有感而發。這裡隻特别講幾點。
-
隐私保護
事實上我在使用騰訊音視訊demo的時候最讓我不适的一點就是隐私沒有得到保護,視訊通話的時候會有人突然加入直播間,或者你一不小心闖入别人的直播間。我有一次就遇到一對父子聊天。在個人隐私如此敏感的時代,即使你開的是直播會被關注,為什麼不能有選擇關注目光對象的權利。我希望即使是内斂的人也可以随意的享受自己的直播間。是以我設定了觀看權限功能。
- 我本身是一個不愛做計劃的人,如果有可以在我完成了這項工作的同時又列明了我做了什麼的清單這簡直是懶人福利。
- 時間花費不代表進度拓展,自己要清楚自己花費的時間是否值得,或許你的pk對手能為你帶來更好的建議
在實作直播監督學習需求的同時避開娛樂直播app的使用
可見第二部分中的NABCD分析
我會更加注重美工的設計和使用者友好設計
兩個前端美工,一個測試人員,兩個app後端開發(包括安卓端和ios端)
第1-2周做出需求規格說明書及原型設計,與客戶交流并修改原型;第3周-第5周前端界面設計并前端測試,同時後端完成項目設計與資料庫設計說明書;第6-9周後端學習并完成大部分基礎功能并功能測試,前端在此期間完成部分前端bug修複;第10周将demo傳遞給客戶使用,收集回報和改進意見;第11-14周根據意見改進并完善完成所有功能;第15-16周測試工作+推廣準備
項目主要需要的是直播視訊的備份和使用者“成績單”的統計備份
應用伺服器配置:4核8G
後端伺服器配置:8核16G*2
關系型資料庫:SQL Server數量:2
緩存資料庫:Redis數量:2