職場案例分析

項目領域：能源行業

個人崗位：產品經理(兼部分項目經理職能)

案例背景：研發部門一直以部門人員不足為理由，可以壓縮產品部門反饋的需求。每次進行需求溝通的時候都會說“這個需求沒必要，這個需求可以裁剪，下個周期再做”，但在實際涉及業務時，又說這是產品部門的事情，只要產品能背鍋就行，產品怎么說我們怎么做，而且評估工期的時間都很長，自研項目老板有交付要求，外部定制項目客戶也有合同要求，產品部門夾在矛盾中間，在工作中承受了很大的壓力，團隊成員也都出現抵觸情緒。

待解決問題：如何改變這種職場現狀，解決產品和研發的矛盾，減少部門摩擦，讓大家順利完成工作目標呢?

PM創造營-頭腦風暴

01職場共鳴

我們公司目前研發技術也是這種狀態，需求不斷，排期排不過來，個人有如下處理建議：

1.回到最終的產品開發目的上來，做好需求評估，緊急度排期。需求有很多，大致可以分為以下幾類：

①解決業務功能需求，從0到1，根據給公司帶來的收益來評估，收益可以是用戶量，資金、數據等。

②解決運營需求，由繁到簡。功能目前能用，但是用的不舒服，這可以根據使用頻次、使用量使用效率來。

③解決bug需求，具體看對產品影響情況。

2.需求排期優先制定好規則，需求溝通會需要做好需求記錄、優先級排序，每次需求會形成紀要，同步相關干系人，方便后面做溝通。有加急的按流程來，讓需求方他們自己去扯皮，切忌不要做傳話筒。

阿宛-武漢-移動聚合支付

雖然踢皮球很讓人生氣，但要注意管理好情緒，友善溝通，都是打工人，不行就踢到上級去，讓上級拍板決定。

02做好記錄

面對需求方提出的需求，產品轉化需求并評估通過后，產品應該就其評估結果及時轉達至需求提起方，經其同意后，項目可按照項目評估結果進行處理;一旦項目發起人未提出意見，或長時間不回復，可視為同意評估方案;注期間發生的一切結果，均需文件記錄，防止項目相關方做責任推卸。

sixiumi-鄭州-軟件

核心內容就是做好記錄留痕，當研發甩鍋的時候，直接拿出來文件記錄!

03對比簽字

產品是做需求轉換的，如果研發不按產品的需求來，對需求進行了更新，產品可以比對產品需求和研發修改后的需求差異并讓雙方簽字確認，待交付出來產品后，客戶不滿意，再做分析看是哪個需求出了問題，有理有據地打幾次臉后，研發應該不會再改需求了吧。

欣鑫-成都-運營

既然研發覺得比產品更懂客戶的需求，那就一起來出方案簽字確認，最后用結果打臉!

04專家評審團

全程看下來該產品經理兼了一部分項目經理的活，主要問題集中在兩點上：

1.裁剪部分功能：不管是自研產品還是交付項目，我覺得公司都有必要在內部組建一個“專家評審團”，評審團決定哪些功能模塊可以砍掉或者延期后面迭代版本再做。

2.工期評估不準，故意拖延單個功能模塊工期，這一點就像項目管理學習時候說的，把需求最終拆解為日常活動，單個活動最小工作時長單位應在8/80h內，這個也是制作成項目管理計劃，由專家團評審通過后按照計劃執行。

小熊貓不叫熊貓-北京-IT

雖然研發部門是在甩鍋，但想要從根本上解決此類問題，建立專家評審團才是關鍵。

05共識解決辦法

缺人是哪個部門都缺的，只要不想干活就都缺人。有問題可以提，但是不能拒絕工作。產品部門需要在產品需求上定義詳細的需求，即使研發部門不支持也不能刪除，可以在需求項目后面加上研發部門給的需求解決辦法，是外包還是推遲迭代，還是直接取消。但客戶的需求不能刪除，早晚要想辦法實現。

Bright-北京-項目采購

研發部門要明確考核機制，如果對需求有問題，要提出產品明確的解決方案。

06聯合其他干系部門

確定好項目的優先級，如果是老板有交付要求的，就優先做這個項目，如果這個項目研發敢耍心眼，下次開會把老板喊來一起聽證，看研發還齜牙不?如果是外部項目需求，就聯合其它部門(市場)給研發部門施壓，不能所有事情壓在產品這里，要把壓力分出去。

Turkey-長沙-教育化信息

如果確實是研發部門的問題，那就聯合其它部門一起施壓，項目是大家的，壓力也要一起扛著。

07變更抄送領導

需求遭遇否決/裁剪時，問明否決原因/具體排期，并形成郵件數據抄送相關方，即使無法給出準確排期，也要一個大概時間。針對時效性問題，建議這位小伙伴減少主觀描述，從項目交付角度完成時間倒排，拉上領導共識出各流程節點的最晚時間，準備好合理性和必要性的闡述。

李星河-北京-商務

不要懼怕暴露問題，有理(道理)有據(數據)地解決問題。