產品：
這次我選擇用來做案例分析的是--知乎。
知乎可以說是中文互聯網最大的知識社交平台，擁有認真、專業和友善的獨特氣氛，分享用戶間彼此的專業知識、經驗和見解。因而在日常生活中，我用知乎搜索答案的概率要遠遠大於用百度、或者上貼吧。在使用過程中，久而久之，也發現了一些bug。
第一部分：調研 測評
-
關於個人第一次上手體驗
在知乎上，可以獲得比百度更為專業的解析。其產品的功能流程邏輯清晰，結構層次簡單清楚，界面簡單自然。總而言之，知乎通過有效的用戶管理和激勵機制、用戶自篩選和主頁推送機制打造了高質量和專業化的知識社區氛圍。
-
知乎bug
第1個bug：在之前的版本中，知乎規定最多邀請6人，但點的快可以邀請十幾個人。（該bug已經修復）
原因分析：人數增加不是在AJAX的success-callback里面，而是在click/mouseup/touchend的時候，所以在你點擊之后前端dom上面的數據會根據你點擊次數++，而真正的數據庫級別的增加應該是在后台的點贊成功回調里面，所以當請求次數大於6時，被后台駁回，所以刷新頁面后上邀請的人數增加顯示最大為6.（參考知乎該類問題答案）
第2個bug：如下圖所示，我隨機提問了一個“hh”的問題，但是提示該問題已經存在，但是存在問題列表中並沒有只以“hh”為題的題目
第3個bug：知乎上偶爾刷到，回復時間是1970年的答案
原因分析：1970年1月1日是unix系統默認的起始時間，也就是說在某些設置下，發帖沒有正確寫入數據庫，發帖子的時間就會被默認為1970年
-
選擇一位用戶進行采訪
問：你在使用“知乎”時，有什么體驗？
答：在我使用的過程中，針對特定問題，能獲得高質量解答。
問：覺得該應用有什么不足之處？
答：有時候會搜索不到對應答案，回答質量過低，得不到對方及時的反饋和回復。
問：有什么建議？
答：希望能對回答質量加大篩選，讓問題覆蓋面更全面。
-
通過對知乎的使用，我給該軟件的評價是：推薦。
第二部分 ：分析
- 該軟件功能
產品的功能包括：問答（包括付費語音問答“值乎”）、專欄、知乎書店（知乎周刊、一小時、知乎鹽）、在線討論（圓桌）、話題分享（知乎Live）......
- 分析優劣
| 知識社交平台 | 技術性 | 全面性 | 社交性 | 客觀性 |
| 知乎 | 較好 | 好 | 好 | 較好 |
| 簡書 | 一般 | 一般 | 一般 | 好 |
| 微博 | 一般 | 一般 | 好 | 一般 |
| 掘金 | 好 | 一般 | 一般 | 好 |
- 功能邏輯圖
- 評分
| 評分點 | 分數（十分制） |
| 用戶體驗 | 8 |
| UI界面 | 8 |
| 核心功能 | 9 |
第三部分：建議和規划
-
假如你是項目經理，如何提高從而在競爭中勝出？
借前車之鑒，仿他人之舉，剔除糟粕，不斷分析規划，更加注重用戶體驗，加大市場調查，加強宣傳力度，不斷提高開發團隊水平，服務團隊質量。
-
目前市場上有什么樣的產品了？
簡書、掘金、百度知道
-
你要做什么樣的功能？
改變邀請回答制，為懸賞制
-
為何做這個功能？
從親身體驗的角度看，用懸賞制度更能激勵用戶回答問題。曾在知乎提問過一個問題，邀請6人回答，晾了一周，還是無人回復，但在采用懸賞制度的“百度知道”，回復反饋的時間僅僅為一天。
-
為什么用戶會用你的產品？
我的產品要做到用戶體驗好，功能完善，是其他產品所不能代替的，用戶沒有拒絕而選擇其他產品的理由。
-
你的創新在哪里？用NABCD來分析？（）
N(Need 需求)
有些問題，需要經過激烈的討論，不是一問一答這種形式可以說得清楚的
A(Approach 做法)
添加一個可以面對面遠程視頻討論的功能
B(Benefit 好處)
可以讓該產品在社交性上更上一層，並且有利於用戶對於專業問題的研討
C(Competitors 競爭)
該功能可以和微信之類的視頻聊天軟件沖突
D(Delivery 交付)
通過提高產品服務技術，獲得好口碑，來推廣產品
-
你來領導這個團隊，會有什么不一樣？
邀請一些外國用戶加入該產品
-
若你團隊有5人，4月為限，你為項目經理，如何配置角色？
一、人員上考慮，我會去在項目開始前，先了解下團隊成員的技術水平以及優缺點，將其分為產品研發1階段人員、研發2階段人員、測試人員以及助理。
二、（1）第一個月前半月，先進行市場調研，看有無開發前景；
（2）第一個月后半月，進行項目規划，進行風險評估；
（3）第二三個月，研發階段，按照螺旋模型，實施軟件研發與驗證；
（4）第四個月，進行客戶評估，評價開發工作，提出修正意見。