關於K米的案例分析
第一部分 調研，評測
評測
1.第一次上手體驗
首先，很遺憾的表示我沒有接觸過類似的軟件，對於這類軟件是一無所知。
接下來說說對他的第一印象吧，第一眼看到它的圖標覺得不錯，簡潔明了，讓人一眼就知道這個是K米軟件。
然后，打開軟件看看吧，跳到的是主頁面，KTV點歌，讓人頓時明白原來這個是KTV點歌的，只要掃描包廂上面的二維碼就可以進行點歌功能。那么再看看別的頁面吧，把每個頁面都打開看看，發現每個頁面的主要功能都是一眼就抓住人們的眼球，讓人能夠很快的知道這些頁面都是用來做什么的。
2.大家一起找bug
- 什么是bug？
通過《構建之法》的學習，bug言簡意賅的說就是軟件的缺陷，它包含了三個方面：
症狀：從用戶的角度看，軟件出了什么問題
程序錯誤：從代碼的角度看，代碼的什么錯誤導致了軟件的問題
根本原因：錯誤根源，也就是導致代碼錯誤的根本原因
那么我們作為一個普通用戶來測試這個軟件，我們要找的bug當然是從它的症狀方面入手。
- 找到bug
時間：2016年10月18日
地點：榕橋之聲
人物：我說的都隊
圖片：測試的時候都忘記了拍照，what a pity！
- 本地傳歌，搜索不到本地歌曲
測試傳歌功能的時候，發現有的手機可以上傳本地歌曲，有的手機無法搜索本地歌曲，在搜索過程中，只提醒來自酷狗、百度音樂、天天動聽的的歌曲導入體驗更佳，而沒有說明不支持哪些app的歌曲導入。PS：使用網易雲音樂的可以導入。
- 評分系統不專業
測試評分系統的時候，有人的評分開關沒有反應。當開啟評分系統之后，無論是有沒有開原唱，有沒有真人在唱，都沒有影響他的評分，都是一如既往的高分，后來我們發現只要是有聲音，他都能評分。
- 已點歌曲既刷新無反應也沒法取消
使用手機遙控點歌之后，發現已點的歌曲刷新沒有反應。錯點的歌也沒法取消，只能等待播放時切歌。點過的也唱過的歌曲記錄為0，不是很懂是為什么？
- 快速點擊發布，出現多個輸入頁面
當多次點擊發布的時候就會發現，跳出多個輸入框的頁面，導致返回的時候要多次返回才能回到主頁面。
- KTV預定，商家信息不真實
負責小組測評的KTV選擇的時候，預定KTV，打電話過去預定的時候，發現有家KTV的電話不全，只有0591-，還有一家打電話過去，店家說人家開的KTV位置在日本，這都是些什么鬼？
這兩家店鋪都是排在商家列表的前幾位。
- 產品組為什么不改bug？
我認為，可能有以下幾點：
a:在這個app不斷更新的時代，同類型app可能會有上百家公司都在研究這款，那么為了抓住這個機遇，往往不得不先上線，再不斷修復bug。
b:一款產品是由多個人合作共同完成的，那么每個人都有負責相應的部分，你以為對方寫的內容沒有問題的時候，直接拿來使用，導致bug的迭代，看起來小小的bug不是那么容易修改的，以至於修改bug的周期就變的更長。
c:網絡環境的多樣性，客戶端環境的多樣性，導致開發/測試人員沒有辦法一一測試，導致了某些手機上面的bug發生。
采訪
-
采訪對象：數計學院大三某女生，該生喜歡唱歌，平時也會唱歌給我們聽。
-
需求擴展：由於這個軟件的主要是在KTV包廂使用，平時好像並沒有什么能夠用到的地方，她認為應該擴展一下評分功能（如唱吧）可以隨時對自己的歌唱水平進行測試。
-
使用過程：在KTV里面唱歌的時候，可以使用手機遙控，進行點歌等功能。
-
用戶體驗：
KTV的遙控功能不錯，人手一台遙控。
直播可以邀請遠方的朋友一起加入。
- 用戶意見：
陌生人可以隨意進入包廂，不喜歡這個功能，希望可以設置密碼等。
掃描二維碼等待成功，需要的時間太久了，在信號不好的時候，掃描不出來。
直播時候K米不能放在后台，一不小心就會自動退出。
社交圈好像都是陌生人，不會判斷，可能認識的人。
-
結論：K米雖然可以在KTV里面使用，但是很多功能都還不夠完善，界面方面也不夠美觀，加上我對這個軟件的測評體驗，我是不推薦這個軟件，對於不常去KTV的人來說，這個軟件根本沒有什么用處。用戶人群太局限。
-
用戶反饋：
最喜歡什么功能？
手機遙控功能，可以掌控燈光，音效，點歌，切歌的感覺不賴。
會為哪些功能付費？
就目前K米提供的功能來說，會進行付費的功能可能就只有給主播送禮物這一功能。
第二部分：分析
1.工作的估計
團隊6人，計算機畢業生，專業UI支持
這是我自己假定的幾個可能性：
有過多次的項目經驗
其中有人寫過類似的K歌功能
編程水平普遍比一般人要高（大佬級別）
根據以上的假定，可以總結出，要想寫出K米這個程度的項目，要花費的時間應該是比較久的，6個人應該是可以直接上手編碼的，以下是我估計的時間：
| 功能 | 時間/天 |
|---|---|
| 需求分析 | 1 |
| 分工安排 | 0.5 |
| KTV點歌 | 5 |
| 各類排行榜 | 2 |
| 附近動態 | 1.5 |
| 附近人 | 1.5 |
| 交友 | 1.5 |
| KTV預訂 | 1 |
| 系統設置 | 1 |
| 搜索功能 | 1 |
| UI設計 | 2 |
| 合計 | 18 |
看完這個時間估計，自己都覺得可怕，開發一款軟件好像被我想的太簡單了，好吧，這可能是我腦中對大佬的印象吧，高不可及。
2.軟件的優劣
優勢
查找了一下手機里的應用商店，發現關於唱歌的軟件更多的是全民K歌這種的手機版現場KTV直播，而K米是更適合在KTV包廂里面使用手機就可以進行的各種點歌功能。
劣勢
核心功能要在KTV里面實現，線下根本沒有什么用處，也不能錄歌等功能，使用率降低，缺少競爭力。
3.團隊提高
功能的完善：有些功能有顯示在頁面上，但是無法使用
軟件測試：感覺測試不夠，導致不同手機出現各種各樣停止運行的錯誤。
注重細節上面的實現
提高用戶體驗
4.功能邏輯框圖
5.模塊分析
| 模塊 | 重要度 | 完成度 | 出發點 | 效果 |
|---|---|---|---|---|
| K歌 | 非常重要 | 85% | 與KTV合作，與點歌台功能類似 | 連接過慢，網絡配置要求高，用戶體驗一般 |
| 附近 | 重要 | 90% | 增加社交功能，吸引用戶 | 社交功能不錯 |
| 聊天 | 非常重要 | 80 | 增加社交功能，吸引用戶 | 界面混亂，聊天內容有限制，用戶體驗差 |
| 發現 | 重要 | 98% | 增加社交功能，吸引用戶 | 社交功能不錯 |
| 遙控 | 非常重要 | 90% | 滿足KTV懶癌患者，使用手機就可以進行各種操作 | 按鈕不靈敏，視頻不可錄制 |
| 個人主頁 | 較為重要 | 100% | 用戶管理 | 一般 |
6.多維度評價
要對一個產品進行評價的話，首先，要確定從哪個角度出發，這次我是站在用戶的角度出發來評價的。K米的主要用戶是KTV常客
| 維度 | 說明 | 評分/十分制 |
|---|---|---|
| 用戶體驗 | KTV包廂使用的功能 | 9.5 |
| 交互視覺 | 用戶能否很好的使用app功能 | 8 |
| 技術性能 | 用戶想要的功能現有版本是否存在 | 8 |
| UI風格 | 視覺效果 | 8.5 |
| 便捷度 | 使用這個app是否方便了生活 | 9 |
| 與人分享 | 能否在朋友圈里面一同使用這個app | 7.5 |
第三部分：建議和規划
如果我是項目經理，我能夠為項目做的是什么呢？
- 市場調研
手機應用商店里的手機KTV應用有唱吧，天籟K歌，全民K歌，這類產品更注重的是查找歌曲，根據歌曲的完成度評分。
- 提高競爭力
在K米注重的KTV點歌功能上，精益求精，擴展需求。
增加與KTV合作的數量，普及度不高
增加模塊：如唱吧的核心功能
- 功能擴展
1.KTV包廂里面的人員可以和遠程的人員對話（不是通過彈幕的形式）？
理由：發現進入同一個包廂的大部分都是認識的人，他們更想要的是可以實時的對話，而不是發彈幕在上面。
2.設置包廂密碼
理由：當不想讓陌生人員隨意進入包廂，觀看包廂視頻的時候可以使用，保護用戶的隱私。
3.增加合唱功能
理由：合唱在KTV里面是必不可少的額環節，而一個貼心的app怎么能缺少這一功能呢？
- 用戶使用率
本款app面向的是那些喜歡去，經常去KTV的用戶，使用這款app可以讓他們感到更好的服務，可以隨時的控制KTV包廂里面的設施：燈光，音效，點歌等等，而且還不缺少社交功能，富有趣味性。
- 需求分析
* N（Need）
KTV商家管理：為顧客提供服務，吸引客戶
用戶：更舒適的唱k環境
K米管理人員：對接KTV的硬件設施，提供軟件的技術支持，既幫助KTV留住顧客，也留住自己常用用戶
* A (Approach)
和商家合作，推出優惠活動
是否在現場都可進入包廂，觀看包廂現場狀況，如臨其境
自帶麥克風，隨時隨地可以唱歌
* B (Benefit)
KTV的商家：可以有增加途經推廣自己的店鋪，吸引客戶，在市場競爭下，有了獨特的競爭力。
用戶：既享受更舒適的唱K環境，也不缺少和朋友的交流。做到和朋友隨時隨地去KTV唱歌的便利。
K米管理人員：可以進行廣告競標，獲得營利點。
* C (Complete)
優勢：主要功能在KTV里面使用，這是市場上其他商品所沒有的地方，給顧客更舒適的唱K環境。
劣勢：功能單一，社交圈有局限性，用戶體驗不佳。
* D (Deliver)
先跟商家合作，讓商家幫忙推廣給客戶。
在各類使用范圍廣的app上安排廣告宣傳
在電視節目里面植入廣告。
-
工作安排
-
任務分工
人數5人，時間：4個月
-
首先，了解一下5個人各自擅長的方面，選定一個為主力隊員，負責項目的協調。
一個負責美工，兩個負責開發，一個負責文檔，一個負責測試，兩個開發者如果實力不均，可以是厲害的帶領另一個編碼，而不是厲害的一個人把所有的全包了。
-
項目進度安排
周數 任務 說明 1 任務的分配 開發過程中組員的任務細化分配 需求說明書 根據需求，細化說明，編寫需求說明書 思維導圖 完成思維導圖 2 原型設計 根據需求說明書完成原型設計 風格確定 美工的設計 3 編碼規范 分析軟件，編寫編碼規范 編碼環境 確保團隊的編碼環境的統一 4 編碼初期 正式進行編碼，審查項目進展 5 編碼中期 審查項目進展 6 Alapha版本發布 Alapha版本的完成 測試 查找不足點，更改需求等等 7 Alapha版本的完善 根據上周的審查，改進不足之處 細節 改善用戶體驗 8 繼續完善 第一版本修改完畢 9 測試 對Alapha1版本的測試，提出要求 Alapha1版本的改善 進一步優化軟件 10 美工上線 對軟件進行美化 Alapha1繼續改進 連續兩周的持續改進 11 Alapha2版本發布 測試 繼續測試軟件的bug 12 Alapha2版本的改進 13 Beta版本的發布 修改需求說明書 查看和需求說明書的不同之處 14 補缺補漏 根據需求說明書補缺補漏 15 Beta1版本發布 用戶初體驗 測試軟件的bug 16 軟件上線 發布產品 -
我的效益
促進團隊的溝通
督促團隊的進度
給隊員噓寒問暖，端茶倒水