大家好，我是產品經理大會主持人“驪山老郭”，今天是第15篇文章。我們來聊聊項目過程中改需求對產品經理是什麼感受以及如何可以理直氣壯的改需求。
說實話，說起程序員節日，說起1024，我只能想起來2的十次方是1024，完全不太理解這個數字與程序員的關係。
有人說計算機是二進制，所以1024應是程序員節日，那我說PM的節日可以是1023麼？因為需求是從PM手裡給到技術的，所以應該要提前一天才對，這樣的順序也符合我們做項目的流程。
工作中總有程序員吐槽產品經理，感覺這個職位是抄抄抄與傳話筒的職位，開玩笑說若產品經理哪天滅絕了，反而項目的進度能更快。
赤裸裸的鄙視是存在於大量的技術人員中，所以生在技術部門的產品經理，很想談談改需求後產品經理的感受以及我們如何去理直氣壯的向技術提出改需求。
感受1：程序員和產品經理作為相愛相殺的兩者，是沒有任何職位高低的。
在一個項目啟動階段，產品經理會參與到整個前期業務的梳理與討論中，反覆與業務部門溝通，以確保出具的需求文檔和原型是經過業務確認過的，儘量避免技術人員在後期的反覆工作。
所以當技術拿到需求時，其實已經是產品經理多次與業務撕逼篩選的結果，是一個明確的，可以進入技術階段的輸出的東西。
可以說兩者的工作都是深度參與項目的，本身職位是沒有任何高低的。
感受2：改需求、加需求非我所願，一切為了項目
需求確定，給到技術進行開發時，會出現很多的意外情況，比如需求修改，需求增加等。
業務部門對於需求的確認，很多都是基於已有的經驗和競品給到的。但有時候可能是基於系統原因或者業務原因，需求在進行到一半或後期的時候，需要進行修改以滿足業務需求。
當發生需求改動時，業務一般都是找到產品經理進行相關的技術確認和排期確認，以確認他們修改的是否能實現，以及修改後的排期時間表。
產品經理對於這種需求修改也很牴觸，但為了項目能實現最大化的價值，也是出於職業道德，會計算已有資源，技術方案，排期時間等，給到業務一個相關回復。
能做的做，產品不會推辭；不能做的，產品經理會直接拒絕業務，以確保能按時按量的完成項目。
當產品經理將需求修改給到產品經理後，程序員就不樂意了。因為之前已經確認是最終需求，結果開發到一半，改了需求，這是他們接受不了的。很可能那他們之前的工作是白費功夫，因而對產品經理這種隨意答應業務需求改動的事情深惡痛絕。
而這種改需求的事情多了後，程序員對產品經理的評價就會下降很多，有時候開玩笑吐槽產品經理，說這個職位就是個傳話筒，什麼需求都接。
作為產品經理，看到上述兩條應該是歷歷在目和似曾相識的，那我們如何來避免這種程序員的吐槽呢？
1、 需求分析做好
一個項目的方案在開始階段討論和確定時，產品經理一定要參與，確保能獲取第一手信息，避免信息或者需求在傳播過程中的缺失和失真，這是我們能做好需求分析的前提。
做好了需求分析，我們就能瞭解整個項目的節點和流程，在業務再次改需求的時候，就能瞭解業務的目的和想達成的目標。這樣也就有利於評判業務提出的需求是否是合理的，是否是閉環的。
所以說改需求不可怕，可怕的是前期的需求分析沒有做好，導致產品經理不理解需求，只能作為一個傳話筒來傳遞業務的需求，導致我們被diss。
2、 修改需求時需要合理評估
第一個點的需求分析做好後，那麼我們就要合理評估需求了。
首先，基於現有已確認的流程，業務給到的修改需求會不會影響主流程？
如果影響主流程，那麼就需要重新進行項目計劃評估了。因為主流程的更改，很大幾率都是已有技術功能的重構，影響到整個項目的質量和交付時間；這種情況下，只有確保領導層或者說業務leader確認，我們才能進行往下的分析工作。
如果不影響主流程，我們要基於理解業務提出需求更改目的前提，合理評估，如果不確定，請與技術人員共同來評估會更準確。
其次，修改的需求是否在業務層面能完成閉環？
業務層面的需求改動，是個性化的還是共性化的需求？
如果是個性化的需求改動，基於老郭已有的經驗，這種功能能往後排就往後排。如果緊急，那也是在本次項目上線後，再技術這種個性化需求。
如果是共性化需求，分析後可以進行技術，那麼郵件和相關業務確認，提前和技術溝通，重新排期。
然後，修改的需求導致的變化需要告知業務與技術，並將你的意見提出來
業務改需求後，產品經理是第一個瞭解和知道的。對於修改的需求，產品經理經過評估後，要告知業務與技術這種需求導致的變化，同時將你的方案提出供業務參考。
此時的需求改動和方案告知技術人員和業務後，業務再有問題，直接拉著技術人員與業務開會確認，避免產品經理隔空傳達需求，保證技術人員能瞭解本次需求改動的背後原因。
3、 處好私人關係
平時與技術baba的私人感情要處理好，避免直接起衝突，因為產品經理的上游是技術人員，良好的私人感情，不是說巴結對方，而是說作為產品經理，你要能理解對方說什麼，對方想表達什麼。
只有瞭解這些，才能在工作中高效率的與技術人員溝通，才能避免技術人員的嫌棄，處好私人關係。
4、 向上管理
項目開發到半截，業務人員突然告知說之前提的需求因為不合規，在監管層面過不去，要修改相應的流程。
但開發不同意，因為這種做到半途而廢的感覺每個人都很牴觸，項目可能就此卡住。那麼學會向上管理是一個有效解決這種情況的方法。
要及時將項目情況和遇到的困難向領導彙報，讓兩個部門的領導去溝通，這樣的溝通比起作為執行角色的你更有效率。
當然辦法很多，老郭只是拋磚引玉了幾條，各位可結合自己的實際情況靈活處理。畢竟都是為了工作，相應的職業道德大家基本都會遵循。
總而言之吧，一個項目的完整，是整個團隊的結果，並不是某一個角色，某一個部門獨立能解決的。
1024是程序員節日很好，但我覺得1023作為產品經理節也不賴吧。
