開發人員最討厭產品經理的哪些做法？

01-01

這個問題可以和另外兩個問題一起看:
開發人員最喜歡產品經理的哪些優點： http://www.zhihu.com/question/19636894?isn=1
產品經理最討厭開發人員哪些毛病：http://www.zhihu.com/question/19629183

開始實施之前

【說不清需求價值】，技術問「為什麼要做」的時候，支支吾吾，或者說「老闆要的、運營要的」，成為了傳話筒，是最Low的，相反，能有理有據的頂老闆的產品經理，通常會在大家的眼中逼格滿滿；

【沒想到功能細節】，表現為技術問細節（當然，是涉及業務的細節，不是技術實現細節）的時候，自己還沒想過，現場想，被發現了，或者因為是接二手需求，並不知道、也沒有去追溯這個需求的初衷；

【幫技術評估工作量】，特別是技術出身的產品經理容易犯這個錯，潛台詞就是「希望加活」，我評估過了，這些都能做掉的，不要給我偷懶；

【逼著技術團隊承諾】，產品經理想的是，如果技術承諾了，但卻做不到，這樣自己就沒責任了，但很多事情，在開始的時候是誰也不知道的，應該大家在一條船上同舟共濟，這就是「接力跑」和「踢足球」在交棒/傳球之後的區別；

實施過程中

【做了一半改需求】，scrum里的表現就是sprint內的非受迫需求變更，大家很難忍受的是產品經理自己沒想清楚，而導致的勞動浪費，俗話說「沒有變更就沒有傷害」，碰到性子烈的就直接要干架了，當然，如果是外部市場變了，大家都可以理解；

【開發過程中消失】，你可以出差、可以開會，但是要能及時響應技術的問題，要不然，為了進度大家照著自己的想法做下去，驗收的時候產品經理跑出來說「這不是我要的」，可不要怪沒人理你；

【過度關注實現細節】，幫技術決定技術方案，也是技術出身的產品經理容易犯的錯，越俎代庖了，會降低技術同學的積極性，漸漸的就完全打工心態了；

產品發布之後

【發布後沒有反饋】，技術人員也需要從市場、用戶那裡獲得反饋，從而知道自己做的事情產生了價值，提升成就感，做完發布，石沉大海，大家是不可能有owner感的；

【無節奏感】，讓技術人員忙一陣閑一陣，發布之後再忙著研究接下來做什麼，讓技術人員在乾死幹活的高強度之後突然不知道做什麼，幾天後又開始要趕進度；

全過程都有

【優柔寡斷無決斷】，是產品經理最要不得的品質，就是在已經討論完畢後，大家都等著你拍板的時候「你說吧，往哪兒走我們就跟著辦」，這時候你說「啊，那個，各種方案各有利弊啊，我也不知道怎麼辦啊，你們有什麼好想法……」，你就完蛋了；

【報喜不報憂】，產品經理總想藏著掖著一些信息，比如「老闆在考慮幹掉這個項目」這類信息，出發點可能是好的，但，當大家通過其他途徑知道了以後，互信就完全打破了，大家會覺得「你還是把我們當資源」；

還有啥，歡迎補充。

1、需求不清晰，當開發人員問PM需求的時候，發現PM也弄不清楚；

2、需求總變更，比如說系統分析都做完資料庫設計都完成的階段了，需求居然又變了。其實需求總變更的原因是PM沒有決策能力，往往被運營、合作方、老闆或者上司所左右，權衡來權衡去導致需求總變更；

3、太年輕、缺乏經驗、缺乏常識、缺乏個人魅力等，這樣會導致比如說無法反饋數據、商業價值判斷有偏差、對項目控制稀里糊塗、思維結構化不足等；

4、太過於市場化或者用戶導向，雖然這個不一定是壞事，但畢竟如果一個人的思維過於活躍或者天外飛仙，會導致絲毫不顧及任何技術可實現性，衍生出很多的問題，當然這個也可以歸於第3點。

5、拍腦門、拍胸脯、拍大腿……

我只說ios平台上的。

1，把按鈕往上挪一下，編譯一個我看看。編譯一個200多個文件的需要3分鐘的東西只為了看一個按鈕。請找美工挪挪，量出具體距離。這是工程，不是美工。

2，你試試下看看這種方式行不行。拜託，如果每個功能要試試多種方式的話，要產品經理幹嘛呢。少量的修改是可以的，或者產品升級的時候是可以的，但是產品開發不是試出來的。

3，這個效果我不是我想要的，你換個。交互不寫，也不交流，等coder幫你想好，你真的是領導，只有想法嗎。請時刻注意，你不想好的話，自己都不知道要做成什麼東西，怎麼叫做產品。

4，美工圖不就足夠了。其實它真的不是一個體力活，雖然ui是有少部分的調整，但是交互，工程圖更重要。工程思想真的很重要。

5，這個code應該這麼寫。請問你是coder嗎。你來寫吧。你不是coder，coder也不做pm，分工真的要注重，不要過度干涉你的工程師同伴們。

6，這次審批沒呀有通過呀，違法了蘋果的人機交互設計。我們重新設計一下吧。coder看文檔，pm看交互，如果coder把這些東西都做了。你們要下崗的。

7，這個我們修改一下，明天提交新的版本，一看，列了一大堆增加的功能，並不是僅僅是修改。coder真的不是神，增加的功能是需要測試的。pm給自己留時間同時，可憐可憐攻城濕，留點時間思考吧。

8，運營說這個功能非常重要，要馬上增加。功能上線。一月後，運營過來發飆。你的做得功能擋到用戶的視線了，這個功能我們不要。產品需要成就感，coder也需要，老做一些沒有經過驗證很傻的東西會很傷心的。

我雖然偏激，但是還是有一些觀點應該有助大家參考參考。歡迎大家指正。

要分什麼樣的開發人員

1 心比天高,技比紙薄的開發人員,討厭一切產品經理,除了沒有與他合作的

2 一心想做管理層的,同1

3 技能尚可,智力尚可的,討厭心比天高,腦比紙殘的產品經理

4 技能不錯,智力不錯,討厭頤指氣使,不懂實際業務,邏輯能力有明顯缺陷的產品經理

5 看上去是程序員,實際是產品經理的,討厭不聽他思想的產品經理

明明不懂技術，還要說「這個實現起來應該很簡單吧」

管過產品, 也管過開發. 從這個問題看, 沒法有標準答案, 因為每個人視角不同, 從大局/細節/性格/工作方法方面會有很多不同但都合理的看法. 但這個問題意義在於, 產品經理應該能通過答案知道自己在和開發人員合作時, 應該做到什麼, 避免什麼.

從和開發合作這個層面看. 產品經理應該有3個事情要做好

1. 能明確的確定需求: 要在開發前將所有人的需求在自己這裡匯總和明確. 不能含混不清, 不能只規劃眼前的一步, 不能無規劃的朝令夕改,

2. 能準確的闡述需求: 從脈絡到細節, 盡量完整而準確的說明, 落實到文字而非口頭, 對可能會變更和擴充的要有單獨的說明.

3. 對資源和可行性的充分了解和反饋: 溝通中明確需求是否可行,了解人力/技術難度/外部資源/周期/風險都能有清晰的認識, 並可根據技術反饋調整和補充需求.

這三點沒有哪個產品經理能100%做好, 但任何一個方面忽視或者沒有完全不做, 都會有開發人員討厭的臭毛病出現.

討厭的毛病：

1.拿著某個native app跑過來說我要在h5版上實現一模一樣的功能（很多時候需要根據平台能力來做需求，最求炫酷的東西有時候就是給開發挖坑。。。）

2.hi xxx,這個這個這個功能需要做一下，後天上線！！

3.這個需求很簡單吧，估計半天就能搞定了。。。

4.拍腦袋個出個idea,不管是否合理先做，美名其曰「試錯」。。。

5.需求籠統不夠細化，導致排期出現漏洞

優點其實可以從毛病反推：

1.思路清晰，需求定下之前做過很多分析，知道自己要做什麼，要達到什麼目的，減少開發無謂的勞動。

2.需求仔細，文檔全面，每個點的交互什麼的都很明白，都說透，沒有遺漏

3.提前跟開發交流自己的想法，對某些自己想做的東西的可行性有所了解。

4.知道優雅的降級體驗，不是硬性的要求所有平台都達到一定效果。

5.對開發排期有合理預期。

不斷地修改scope

1，雖然需求是肯定會變的，但產品經理沒有一個合理控制需求變更的機制。

2，每個任務都有不切實際的deadline，沒有迭代版本管理。

3，做出來的東西，沒有編輯資源去運營，相當於產品或功能被廢掉。

4，只對開發強勢，對領導或其它並行部門一味遷就，沒有自己的主心骨。

5，不了解開發人員開發的艱辛程度

ps,我是產品經理，以前懂點開發，和開發走的很近，以上幾點是我的個人感覺

看完了，沒看出哪個是臭毛病，更多的看到的是抱怨。

不懂技術又浮於表面，東改改西改改，今天這樣明天那樣。

總是在說別人怎麼都可以做，無理由的堅持己見。

對於老闆提出的問題沒有抵抗力

1就是1，2就是2，工程師最聽不得的話就是，「其實這樣也可以」，「要不就這樣吧」

1.不懂技術，但濫用技術名詞去描述非技術問題，或驢唇不對馬嘴。做BS設計卻不知曉頁面元素名稱，隨意造名字或使用含糊不清的詞來稱呼。

2.為了證明自己是深思熟慮的，用超級強勢的態度來不容置疑。

3.當有不同聲音的時候，先想著把你駁倒而不是想著去解決問題。

4.為了實現自己的成就感或虛榮心，不顧性能、擴展性、可持續性甚至需求方及技術的強烈反對。

5.不做調研，不遵守行業習慣，自己拍腦袋造輪子，可造出來的東西不倫不類。

6.自己兩個月時間設計出來的東西，卻想著研發2個星期開發出來。

7.在一個項目中，各個產品經理按前後台或功能分工，各自為政，自己內部都不統一，甚至同一個模塊前後台不一致。甚至文檔與交互是不同的人來設計，也不統一。

8.隨意加工需求部門提出的需求，不顧用戶體驗，曲解真實需求，增加複雜化、無用化功能。

9.變態的UI，拿設計傳統CS的理念設計BS。什麼浮動頭部，浮動底部，集眾力服務其一個人的天馬行空式意淫。

10.從不表述原始需求。讓人以為其設計的就是原始需求，而上線後原始需求部門找過來說，根本就不是這麼個玩藝兒。

11.在產品文檔設計結束之前，不與研發溝通，自己又沒有那麼強的邏輯思維，導致設計很SB以至於在研發周期內還不斷修改需求。

12.拿一個個的新需求來拆東牆補西牆式的修補其犯下的錯誤，導致產品越來越走樣兒。

13.只設計殼子，而不關心運作原理（其實是不懂），那怕是違背數據邏輯。只停留在操作層面。

1、需求傳遞者

2、有需求沒文檔

3、文檔做得太差

4、想法都在討論會上臨時發揮

5、對負責產品不熟，一問三不知

6、「先這麼對付著」

7、產品設計漏洞百出，開個會主要時間在為他補缺漏

8、本該私下和某部門溝通的內容在會上提，很多人成了坐陪

9、不考慮用戶體驗的設計

10、對需求的合理性缺乏判斷，本來是好的需求被拒絕，不好的需求又接受

11、沒有產品規劃思想

12、溝通協調能力差，經常和開發人員起糾紛

接觸過產品同事，也面對開發同事——同樣也是一個產品狗，挖過不少坑。

角度換換，說說開發人員討厭的事：

對技術太不了解，也沒有工程思維

1，【邏輯不清晰，漏洞百出】1個簡單功能，流程細節和異常情況，出現遺漏，或者跨產品，未能納入方案中，或評審時兼顧討論；

2，【不理解工程師要什麼】雖然PRD文檔什麼的，創業公司普遍不正規，走的是『偽敏捷開發』，但立項目後，需要給到後台業務邏輯和關係、各種正常和異常流程：如果可以，盡量給到資料庫關係和建表、用例描述，幫助後台人員儘快『知道自己要做的和應該注意的』，並且一起討論某些異常情況的處理和系統的可擴展性——而不是簡單討論原型就可以啦；

3，【不評審，不溝通，獨斷流】某些活動支持或流程修改，不與後台和前端溝通，就發布一個當前不能或來不及實現的功能，來施壓開發人員；或者單方面只溝通前端或後台，未協調前端和後台，就關鍵細節，達成一致，統一實現思路；

4，【不重視方案的撰寫】雖然是敏捷開發，為了追求高效率，不走瀑布流的開發方式——但每周的backlog，都需要有記錄（不管是郵件，還是文檔），最好能記錄包括修改記錄、需求背景、詳細流程、異常流程、測試用例參考，保證具體實現時，大家『做的事同一件事』，需求與結果一致；

對需求方，不能『疏導』和『管理』

1，【臨時需求，今天提，明天要】常見於市場活動支持，市場人員普遍都是『這事很緊急，明天給我吧』，面對這種需求，沒有區分需求緊急程度，該拒絕的拒絕，不該拒絕的，想想其他方案：先滿足需求——而不是有一個需求，發個郵件就馬上就找開發，就要明天上線；

2，【boss假需求扛不住、理不順】這個就不展開了；

——不說了，明天又要開始挖坑了，想想都好激動呀

作為一個初級的PM，而且是小公司的PM，我感覺到很大的壓力。

尼瑪整天要跟老闆座談，面對一些奇葩需求。

完事還要跟想孫子一樣去跟視覺溝通修改方案讓她做出效果圖；

再然後還要跟研發說尼瑪的這些交互是怎麼回事。

你們討厭的臭毛病啥的都有犯過。

只能在工作中不斷優化，快速迭代了。

個人認為PM必須懂技術，必須成熟穩重有人格魅力。這樣才能hold住。

===================================================

上面的是我半年前說的話。現在我覺得，人與人之間的信任是很重要的。一個優秀的PM可以吸引大家圍著你，幫你成事。除了必備的工作技能外，更多的，是做人。

需求又變了

所謂合作必須首先達成共識,太過主觀又沒有可靠依據的需求都會遭人討厭.

1、多談「我們」少談「我」

2、多拿數據說話少拿腦門說話

3、別只有產生需求的時候才去跟開發人員溝通

4、有成績的時候不要挺胸抬頭地去搶功勞而忽略為實現付出的開發人員

5、需要調整的時候必須給調整，如果是因為之前的判斷太草率，那麼就坦誠點去溝通

6、產品或運營人員有點主觀個性不一定是壞事，但一定要評估自己此時是」自大「還是」自信「

7、適當的時候強勢

有點跑題了，我是產品運營人員

丟一張草圖，在草圖上寫個註解。產：行了：「你就照著做。」code: 「文檔呢？」產：我很忙，不懂我給你講解。。。」。+1