1、是不是只要沒有技術上的實現問題，開發者就不應該對產品經理提出質疑？
2、需求文件、功能文件、最新而最全的原型設計文件，這些要求過時了嗎？
3、產品經理高階建議。
軟體工程領域，本著分工合作高效進行的管理方式，每個人只要做好自己的分內事就行。當產品經理召集開發人員進行各種評審會的時候，其實是想讓開發人員好好分析下，會不會出現邏輯問題。至於在產品設計上，開發還是比較人微言輕的。產品負責將這次的版本迭代做出來，讓功能能夠覆蓋相關的需求，讓開發人員確認過沒有邏輯問題的情況下就可以進行到開發階段了。如果開發人員產品設計上有過多的囉嗦，產品就會問你「是否有實現邏輯的問題？如果沒有的話，就按這樣設計的做就行了。」
關於這種情況，在軟體實施管理的知識來說，是正確的。賈伯斯也說過：
大致的意思就是，「你必須從使用者體驗開始，然後用技術實現它們。而不是反過來先去考慮技術。」
但是，如果一位產品經理代表的並不是使用者體驗（只是自己的主張），而拿這句話來搪塞勤勞的開發人員，那真的很讓人煩惱。
類似的情況還有：當開發人員指出產品的設計漏洞時，產品會以一種「戰略性的鄙視」告訴你，「你所說的我們早都考慮過了，但是這一次的版本迭代我們先這樣做～」唉，真是厲害。
上面說了這麼多，我只是想替勤勞的開發人員說句公道話。首先請理解軟體工程行業的元件化思維，元件化思維不僅是開發要做的事情，產品、ui、測試等人員都是需要進修的一門課。然後，在開發人員把常用控制項元件化好以後（按道理來說，應該由產品提出哪些控制項需要元件化，盡早的統一好樣式和功能讓開發封裝好），產品卻還要進行改動。其實，開發人員不是不願意改動，而是，他們只是想確定下你是不是認真的？是否真的有這方面的需求？是否真的需要改進？那之前的樣式是否需要統一起來，還是區別處理？這些問題，開發只是想確定好產品經理是認真思考過的，而不是「看產品經理當時的心情」。
其實，如果開發與產品經理之間的關係到了這種不信任的地步，這樣下去就會出現兩者情況：第一種是，開發和產品經理不和氣，經常會為了產品的設計發生爭執。其實這種情況，至少說明開發還是比較負責的態度，如果真是第二種情況，那就沒希望了。第二種情況就是，以後產品怎麼設計，開發就怎麼做，產品本身的事不再關心。產品想怎麼改都行，反正只要有時間，沒有什麼是開發不出來的（軟體行業，又不是研究行業），最終受到損失的是公司。
上面說了這麼多，包括有時發生的產品經理和開發人員發生暴力事件。都說明了一點，現在大部分的軟體工程行業，或者直接說是網際網路公司吧，產品經理的話語權沒有放置在合適的層次。當然什麼事情都有兩面性，當這位產品經理的能力得到大家的一致認可，並且通過了各方面的考驗，那麼賦予這位產品經理更好的執行權是可以的。否則，還是乖乖的按照正常流程執行會比較好。所謂的正常流程就是說，學習西方的管理方式，制度為上，而不是人治。
敏捷開發提倡口頭交流這種高效方式，但是並不是說就從此以後就不需要文件了。所以，需求文件、功能文件、完整的原型設計文件是不可少的。
～（先寫到這裡，後面有時間再繼續往下寫，估計週六天吧）
開發人員轉行做產品經理 1
很多從事開發的小夥伴，工作幾年後，都會有這樣的疑惑，未來的職業之路應該如何繼續。其實開發人員有自己的優勢，那就是了解熟悉技術，從事it行業，了解一些技術總也是好的。和開人員溝通有一定的優勢。但是開發人員也有自己的劣勢，就是溝通起來不是太好。一下是轉其他人的 文章 開發人員到一定階段以後就要尋求轉型，...
開篇 從開發人員的角度理解產品經理
首先需要宣告的是，我只是乙個普通的開發人員，但是我希望自己的目標是成為乙個擁有暫時軟體工程功底的，能夠駕馭創新產品，引領團隊的產品經理。本文只是個人的一點隨想，以及閱讀他人著作的一些感悟，尚不成熟，僅在這裡做個記錄而已，牛人不要見笑。從我做研發的經歷來探索產品經理的特質 1 解決方案而不是功能模組。...
IT開發人員
其路五 轉行到市場 絞盡腦汁的想想，我所知道的人之中只有兩個開發人員去了市場，這兩個人都不能說是朋友，認識而已。他們都是主動要求去了市場，結果是這兩個人均在市場都是乾到一年左右，然後都自已開公司了。呵呵，很奇怪，極高的轉行成功率！不過仔細想想，我對這兩個人的思路佩服的五體投地。能下決心仍掉每月5 6...