分析：如何做一個讓程序猿討厭的產品經理

【計算機論文】分析：如何做一個讓程序猿討厭的產品經理

開始實施之前【不說清需求價值】，技術問“為什么要做”的時候，支支吾吾，或者說“老板要的、運營要的”，假裝是個傳話筒，因為接二手需求，并不知道、也沒有去追溯這個需求的初衷。相反，切忌不要有理有據(jù)的頂老板，那會讓大家喜歡上你；【不去想功能細節(jié)】，技術問細節(jié)(當然，是涉及業(yè)務的細節(jié)，不是技術實現(xiàn)細節(jié))的時候，自己裝作還沒想過，現(xiàn)場想——這樣做吧，那樣做也可以，或者你定吧……要巧妙的被發(fā)現(xiàn)，這時候你已經能聽到技術的心里話啦——傻逼；【幫技術評估工作量】，特別是技術出身的產品經理，最容易做到，潛臺詞就是“希望加活”，我評估過了，這些都能做掉的，不要給我偷懶，哈哈哈哈哈哈；切記，不要把他們當人，而要當“資源”；【逼著技術團隊承諾】，哼哼，公事公辦，如果技術承諾了，但卻做不到，這樣自己就沒責任了，可能對方會說——很多事情，在開始的時候是誰也不知道的，應該大家在一條船上同舟共濟，這就是“接力跑”和“踢足球”在交棒/傳球之后的區(qū)別。你可以回：我不管我不管我不管；實施過程中【做了一半改需求】，scrum里的表現(xiàn)就是sprint內的“非受迫需求變更”，太狠了，技術同學肯定很難忍受，特別是產品經理自己沒想清楚，而導致的勞動浪費，俗話說“沒有變更就沒有傷害”，碰到性子烈的就直接要干架了，汪們，這時候要注意保護自己；【開發(fā)過程中消失】，你可以多安排點出差、多開開會，注意盡量手機關機，不要響應技術的問題，要不然，責任就回來了。讓他們?yōu)榱诉M度照著自己的想法做下去，關鍵是，驗收的時候跳出來說“這不是我要的”，再次，注意人身安全；【過度關注實現(xiàn)細節(jié)】，幫技術決定技術方案，也是技術出身的產品經理應該很容易做到這點，變著法兒的越俎代庖，把他們全部從積極主動小伙子，打擊成一個純打工形態(tài)的“資源”，哎，又用這個厲害的詞了；產品發(fā)布之后【發(fā)布后沒有反饋】，技術人員也需要從市場、用戶那里獲得反饋，從而知道自己做的事情產生了價值，提升成就感，我們要做的就是，做完發(fā)布，馬上石沉大海，不告訴大家任何結果，甚至慶功會都忘了他們，緊接著趕緊繼續(xù)安排他們干活；【無節(jié)奏感】，讓技術人員忙一陣閑一陣，發(fā)布之后再忙著研究接下來做什么，一會兒讓技術人員有著干死干活的高強度，我就是要結果，deadline，死命令，之后突然不知道做什么——你們也一起來討論下業(yè)務吧，或者培訓培訓做做團建什么的；全過程都可以做的【優(yōu)柔寡斷無決斷】，能表現(xiàn)出這個品質就最棒了，就是在已經討論完畢后，大家都等著你拍板的時候“你說吧，往哪兒走我們就跟著辦”，這時候你說“啊，那個，各種方案各有利弊啊，我也不知道怎么辦啊，你們有什么好想法……”；【報喜不報憂】，藏著掖著一些信息，比如“老板在考慮干掉這個項目”這類信息，表面打死不承認，但讓大家通過其他途徑知道，很容易就把互信完全打破，這時候他們可討厭你了；【不要把他們當人】，這點，最狠了，不關注成長，只關注結果，不能再說了，我們只是要做一個程序猿討