產品需求對於我個人來說並不陌生，在本科期間學習的軟體工程這門課程中在介紹軟體開發流程的時候對需求進行了簡單的介紹，但是並沒有對需求這個概念進行比較詳細的介紹。雖然在本科期間也做了幾個專案，也只是按著需求進行相關流程圖、類圖的設計、以及**的編寫，並沒有進行延伸的思考。
作為乙個技術人員，其實很少直面客戶和市場，所以我們有時候會固執的認為功能豐富的系統就能滿足所有的需求。當然剛才的觀點是沒有錯誤的，確實功能豐富的系統能滿足所有的需求。但是功能豐富的系統也意味著開發周期和難度大，系統的成本高，那麼也就意味著系統產品的定價高。然而市場是多樣化的，也就是說我們的客戶也可能是多樣化的，並不是所有的客戶都需要所有的功能（比如我去買牙刷放在家裡面用，我肯定是買好一點的，但是如果我出差的時候忘記了帶牙刷，考慮到成本以及我只是臨時用等情況，我肯定就會買一支質量一般，這就是需求多樣化）。
技術要深挖，但是要理智！
我對需求文件的理解
prd需求文件說明書建議滿足以下要求 1 專案背景 名詞解釋 2 需求目標 專案計畫 對於prd中要開發的內容，給出關鍵里程碑，比如需求評審通過的時間 開發的完成時間 上線時間等等 3 影響範圍 主要針對迭代版本 4 功能摘要 業務邏輯流程圖。分兩部分，一是業務流程圖，對產品整個業務流程的發生過程做...
我對產品經理的理解
我們每天要接觸到很多的產品，不離身的手機 喝水的杯子 使用的電腦 空調 穿的衣服鞋子，都是產品，作為種種的產品包圍著我們，那麼，在網際網路的世界，我們該如何定義產品？每天開啟電腦，個人電腦中，總會安裝許多形形色色的軟體，有些軟體我們甚至已經離不開，我想，每乙個軟體 應用程式 的開發之前，都會有種種的...
我對產品化的理解
我對產品化的理解 產品化的時機是看業務的需要，不管是對前景的落實，還是專案轉化成產品，這些都不是技術人員能考慮的，業務的發展和策劃，如何進行市場細化等如果都由技術人員考慮，產品化的風險很大。風險最大的是對於產品化的理解。提到 產品化 大部分技術人員，包括很多公司老闆，首先想到的是可銷售性，也就是免實...