守則１ 永遠不要顯得比客戶更聰明
第一條：了解需求，而不是去批評客戶；
第二條：客戶比你更熟悉業務的環境；
第三條：客戶總是知道問題在哪兒，你的工作就是要讓他們自己願意說出來；
守則２ 尊重使用者的現實選擇
第一條：客戶永遠是對的；
第二條：提供最合適的解決方案，而非最好或最貴的方案；
第三條：不要把客戶當傻瓜；
守則３ 轉述需求的人也是客戶
第一條：轉述者一般會把自己想象成設計者；
第二條：轉述者可能會遺漏或補充一些額外的需求；
第三條：對轉述者的自由發揮不應抱怨和生氣，而是將其視為客戶；
守則４ 客戶和使用者要區別對待
第一條：產品為終端使用者設計，需求的功能轉換為終端使用者的使用要求而確定；
第二條：為客戶尋找價值上的需求；
第三條：使用者的利益高於一切；
守則５ 用最簡單的文字工具記錄需求
第一條：所有人都能懂的東西，最不容易出錯；
第二條：不需要再學習的東西，最不容易出錯；
第三條：不要希望客戶能花更多的時間來了解需求轉換後的模型；
第四條：保持溝通的通暢，是了解需求的保障；
守則６ 天下沒有免費的午餐
第一條：客戶從來沒有不合理的需求；
第二條：客戶的要求都是可以實現的；
第三條：我們能做這事－這是所需的費用；
專案管理使用者需求分析
使用者反饋分析 不過這種方式更適合於前台的產品，後台的產品主要使用使用者就是公司內部員工，或者是比較少的開放出去的管理員，這部分的使用者反饋相對來說容易收集的多，可以制定特別的渠道來獲取反饋。產品資料分析 還可參考一些公共調研機構出具的一些資料分析報告，比如艾瑞資訊等對網際網路行業裡面所做的一些資料...
專案過程管理（六）需求評審和工作量評估
流程 預審 產品提前2小時發出通知和初稿 不需要完善細節，可以只是原型 召集主管或負責人預審。未必需要開會，只要每個人能確認需求沒大問題就好。跟運營有關的需求，應該在全體評審前由運營先審核完畢。產品經理根據問題修改完畢後，逐個找負責人確認。都通過後，發出通知 專案經理收集工作量評估進行排期，並在各方...
專案管理論 需求分析
什麼是專案，專案為什麼要管理，什麼是專案管理，怎麼樣才是合格的專案管理 專案從軟體的角度看就是乙個需求，一系列需求，乙個解決方案，乙個班底要完成的目標 專案從生活的角度看就是某段時間內你要完成的目標，如 乙個高三學生的最大專案就是能考上乙個理想的大學，進一步細化就是能夠考上清華或者北大或者武大或者浙...