Ⅰ 產品經理和程序員,如何避免矛盾
產品汪和程序猿
一、產品經理和程序員最討厭的三句話
產品經理和程序員,就像一對情人,若即若離,有時還會撕逼,和諧的時候一切都好,撕逼的時候兩敗俱傷。
你知道程序員最討厭的三句話是什麼嗎?
1、這個需求很簡單,改一下就好了
2、你先大概弄一個,我看看再說
3、我先下班了,加油啊
我想任何一個程序員聽到這樣的話都會氣炸了,不撕逼才怪,你作為程序員會如何回答這三句話?
1、這個需求很簡單?你行你來啊!
2、大概先弄一個?請問先生(女士),什麼叫大概?
3、你大爺的
你知道產品經理最討厭的三句話是什麼嗎?
1、這個需求做不了
2、這個需求工作量太大了,估計要搞3個月
3、這個變更沒時間做,往後排吧
產品經理在前端,有用戶、有老闆、有銷售,版本發布的壓力很大,聽到這樣的話估計心情也好不了哪去?
1、這個需求做不了?又不是我提的,還不是那個2B用戶提的
2、要做這么長時間?養你們有什麼用,還不如我自己來
3、變更沒時間搞?隨便,等老闆來拍你吧。
二、產品經理和程序員本質上的差異是什麼
奶爸干過程序員,也干過項產品經理,深知這兩類工作的差異,各有各的不易。
總體上來看,做產品更側重於創造和方案能力,不需要精密的邏輯,所以試錯成本相對比較低,大不了改改原型,改改方案,這個成本是可承受的。
程序員的工作是非常精密的邏輯,一個看似很小的變更有可能對代碼產生很大的影響,所以試錯成本非常高,弄不好可能會因為需求的變化導致系統的重構,這時候程序員的挫敗感是可想而知的。
三、產品經理和程序員友好相處的清單
1、產品經理收集需求後,在需求分析階段,需要把一些不合理的需求盡量和用戶溝通去掉,避免不合理需求造成產品發布時間延遲和沒有必要的成本浪費,當然這需要產品經理去說服用戶,不能只做用戶的傳聲筒。
2、需求分析時,產品經理應該根據經驗,敏銳的發現一些在技術層面實現有困難的需求,及時讓研發介入,評估技術可行性,避免後續出現需求定下來,研發說做不了的情況。
當然這需要我們的產品經理對軟體技術架構有一定了解和預判能力,你不能所有的需求都要在需求分析階段讓研發介入,這個成本也是極高的,所以要把握好這個度也是一項能力。
3、原型還是需求溝通的最好方式,這樣是避免產品和研發在需求理解上有差異的最好手段,只靠寫一些文字的需求說明書很難達到好的效果。
但這裡面要注意一點,產品經理繪制出來的原型一般是非高保真原型,是為了更好的溝通需要,所以不能完全按照原型做,需要基於我們自己的前台架構進行定製。
4、需求評審的時候,研發可能會有一些不一樣的意見,他們做了很多年的開發,會有很多好的經驗,好的經驗要虛心接受,不能覺得自己是產品就是老大,就是要按我說的做,這樣很容易造成矛盾,求同存異,目標一致,這個是最好的結果。
5、研發說這個需求做不了的時候,有兩種情況,一個是覺得這個需求實現起來比較麻煩,故意騙你;另外一種情況就是他的知識盲區,他可能確實不知道這個事能做。
產品經理需要有能力和研發進行談判,比如採用類比法(類似的需求在其它項目上咱們就做過),比如去找架構師探討技術可行性。
6、研發有時候評估的工作量會比較大,整個上線計劃拉的比較長,產品經理可以要求研發出詳細的資源配置清單,這樣能清楚的看到一個需求被分解成了多少個研發任務,每個任務的起止時間,由誰負責完成。這樣產品經理大概能看出任務的前後置關系是否合理?工作量是否合理等。
產品經理絕不能說,這么簡單怎麼要搞這么長時間,類似的話一出,絕對會激怒對方,還是要有理有據進行談判。
如果實在無法壓縮工作量,如果增加人力能解決問題的話,可以考慮找領導申請資源。如果還是不行就要砍需求或者改方案了。
7、在版本計劃定好的情況,盡量不加需求,這樣很容易打亂開發的節奏,如果一定要加進來,一定要和研發說清楚,這個是用戶領導或者老闆的強制要求,轉移矛盾。如果可以的話,增加了需求盡量推遲上線計劃。
8、開發過程中如果需求有改動,需要及時更新需求文檔,同時發給我們的研發同學,否則只是靠嘴說一下,很可能研發的同事就不做了,所以一定要落到紙面上。
9、上線的時候要堅持和研發同事一起加班,這樣大家才是一個團隊,贏了一起狂,輸了一起扛。
10、最後一點,就是要多交流,沒有什麼問題是一頓火鍋解決不了的,大家關系好了,很多事情溝通起來自然容易,而且也會更信任對方,這樣就萬事OK了。
Ⅱ 生產技術部如何處理好與生產部、品質部的關系
產品在生產時,這個產品的一系列數據按理生產技術部都已有明確的數據了!生產部只按技術部的數據來生產就行了,而品質部是為了檢驗產品的好壞,也是根據技術部提供的數據來檢驗! 所以技術部自己的工作做到位,其它的部門不配合都不行,產品的技術開發數據正確,出了問題那就不是技術部的問題了! 至於各部門之間人與人之間的交流,我認為平時咱們以一種平等和藹的態度跟人交流,我想沒有人會很難相處的,除非那個人是存心無理取鬧!