首先需要宣告的是，我只是乙個普通的開發人員，但是我希望自己的目標是成為乙個擁有暫時軟體工程功底的，能夠駕馭創新產品，引領團隊的產品經理。本文只是個人的一點隨想，以及閱讀他人著作的一些感悟，尚不成熟，僅在這裡做個記錄而已，牛人不要見笑。
從我做研發的經歷來探索產品經理的特質：
1、解決方案而不是功能模組。通常程式設計師大概只能接觸乙個功能模組兒的**，在既有的架構基礎上做完善，久而久之失去了對編碼的興趣，工作漸漸的跟coding畫上了等號，思維容易停止不前。事實上很多時候我也是如此。但是限於工作內容可能比較繁重，有時候跳不出這個圈子。但是，如果希望成為乙個產品經理，我覺得必須要有大局觀，對產品的整個體系都要有深入的把握。除非你只是乙個programer，並且樂於程式設計，在你的眼裡，program的吸引力要大於person的吸引力。產品經理對產品的定義，規劃設計的全面性是編碼人員甚至架構師都難以匹及的。產品經理關注整個產品的所有細節：同領導的交流，同客戶（及銷售）的溝通，同開發工作者的辯論，同自己的博弈。
2、與人溝通而不是埋頭編碼。即使我們認識到溝通的重要性，我想這也是必須單獨提及的。人都有一種習性，久了就會習慣，習慣導致思維不前，結果就是封閉。如果不是對技術太過瘋狂的人，還是應該多學習一點與人溝通的能力。這將是自己做出來的東西更加的有價值。獨樂樂不如眾樂樂（呵呵，我居然也說了這句話）
3、通過不同的渠道驗證自己的想法。最直接的方法當然是聆聽客戶的體驗。產品的檢驗當然是產品的使用者更具有發言權。當然，如果這項產品的結果如果是失敗的話，那產品經理的境地將非常難堪。所以我覺得，做人做事要認真仔細，要有進取心和責任感，不然還是不要走這條路的好
待續。。
ps:僅個人隨想，非專業**，並無參考意義，特此宣告
從開發人員角度看待效能基準測試
對乙個開發人員來說，除了保質保量按時完成功能需求外，非功能也不可忽視。決定乙個軟體的成敗往往是非功能性需求比如效能，若是使用者體驗不好那麼必定是個失敗的作品。那麼乙個開發人員如何去做關於自己模組又或者整體的基準效能測試呢？以下將從測試的切入點和具體測試的指標來說明。切入點 通常，基準效能測試有兩個切...
產品經理與開發人員的矛盾
1 是不是只要沒有技術上的實現問題，開發者就不應該對產品經理提出質疑？2 需求文件 功能文件 最新而最全的原型設計文件，這些要求過時了嗎？3 產品經理高階建議。軟體工程領域，本著分工合作高效進行的管理方式，每個人只要做好自己的分內事就行。當產品經理召集開發人員進行各種評審會的時候，其實是想讓開發人員...
開發人員和產品人員對接需求總結
最近一段時間，碰到乙個業務邏輯比較複雜的專案，和產品經理對接了一周的需求，突然發現對接需求也不比開發工作輕鬆多少，所以想把對接需求時遇到的問題和一些好的經驗記錄下來。1 不要接受產品人員一上來就提的 我需要乙個什麼什麼介面 我需要乙個什麼什麼功能 的所謂的需求，這不是需求，這是要求。這樣做其實是產品...