本文中主要闡述的問題包括：
1、是不是只要沒有技術上的實現問題，開發者就不應該對產品經理提出質疑？
2、需求文檔、功能文檔、最新而最全的原型設計文檔，這些要求過時了嗎？
3、產品經理進階建議。
軟件工程領域，本着分工合作高效進行的管理方式，每個人只要做好自己的分內事就行。當產品經理召集開發人員進行各種評審會的時候，其實是想讓開發人員好好分析下，會不會出現邏輯問題。至於在產品設計上，開發還是比較人微言輕的。產品負責將這次的版本迭代做出來，讓功能能夠覆蓋相關的需求，讓開發人員確認過沒有邏輯問題的情況下就可以進行到開發階段了。如果開發人員產品設計上有過多的啰嗦，產品就會問你“是否有實現邏輯的問題？如果沒有的話，就按這樣設計的做就行了。”
關於這種情況，在軟件實施管理的知識來說，是正確的。喬布斯也說過：
大致的意思就是，“你必須從用戶體驗開始，然后用技術實現它們。而不是反過來先去考慮技術。”
但是，如果一位產品經理代表的並不是用戶體驗（只是自己的主張），而拿這句話來搪塞勤勞的開發人員，那真的很讓人煩惱。
首先，在現在的軟件工程行業，開發人員為了能夠更好的面向對象思考問題，也會面向對象的組件化開發。舉一個簡單的例子，如果一個app項目中有好幾處可以提供給用戶選取時間的功能，因為考慮到現有的3處地方都是一樣的，為了以后的組件化開發，一個負責的開發人員會把這個“選取時間”的控件封裝好，以便下一次直接使用。可是糟糕的是，下一次的版本迭代中也有一個地方需要提供時間選擇功能，但是產品將這個時間選擇界面的樣式改變了，以前其他地方用到的時間選擇樣式依然按以前的來。對於這種情況，開發人員真的是好難過。但是，開發者要擁抱改變。這無可厚非，但是請說出這次為什么就要改變樣式？以前的樣式不符合嗎？。。。“不好意思，這個不是你們開發考慮的問題，你只需要告訴我能不能做出來就好了。設計上的問題，不用你們操心。”產品會這樣告訴你。
類似的情況還有：當開發人員指出產品的設計漏洞時，產品會以一種“戰略性的鄙視”告訴你，“你所說的我們早都考慮過了，但是這一次的版本迭代我們先這樣做～”唉，真是厲害。
上面說了這么多，我只是想替勤勞的開發人員說句公道話。首先請理解軟件工程行業的組件化思維，組件化思維不僅是開發要做的事情，產品、UI、測試等人員都是需要進修的一門課。然后，在開發人員把常用控件組件化好以后（按道理來說，應該由產品提出哪些控件需要組件化，盡早的統一好樣式和功能讓開發封裝好），產品卻還要進行改動。其實，開發人員不是不願意改動，而是，他們只是想確定下你是不是認真的？是否真的有這方面的需求？是否真的需要改進？那之前的樣式是否需要統一起來，還是區別處理？這些問題，開發只是想確定好產品經理是認真思考過的，而不是“看產品經理當時的心情”。
其實，如果開發與產品經理之間的關系到了這種不信任的地步，這樣下去就會出現兩者情況：第一種是，開發和產品經理不和氣，經常會為了產品的設計發生爭執。其實這種情況，至少說明開發還是比較負責的態度，如果真是第二種情況，那就沒希望了。第二種情況就是，以后產品怎么設計，開發就怎么做，產品本身的事不再關心。產品想怎么改都行，反正只要有時間，沒有什么是開發不出來的（軟件行業，又不是研究行業），最終受到損失的是公司。
上面說了這么多，包括有時發生的產品經理和開發人員發生暴力事件。都說明了一點，現在大部分的軟件工程行業，或者直接說是互聯網公司吧，產品經理的話語權沒有放置在合適的層次。當然什么事情都有兩面性，當這位產品經理的能力得到大家的一致認可，並且通過了各方面的考驗，那么賦予這位產品經理更好的執行權是可以的。否則，還是乖乖的按照正常流程執行會比較好。所謂的正常流程就是說，學習西方的管理方式，制度為上，而不是人治。
敏捷開發提倡口頭交流這種高效方式，但是並不是說就從此以后就不需要文檔了。所以，需求文檔、功能文檔、完整的原型設計文檔是不可少的。
～（先寫到這里，后面有時間再繼續往下寫，估計周六天吧）