這裡是修真院pm小課堂，每篇分享文從

【背景介紹】【知識剖析】【常見問題】【解決方案】【編碼實戰】【擴充套件思考】【更多討論】【參考文獻】

八個方面深度解析pm知識/技能，本篇分享的是：

【專案管理與需求變動的探討 】

1.專案管理之於產品經理。

（1）專案管理的定義

專案管理的定義是：指在專案活動中運用專門的知識、技能、工具和方法，使專案能夠在有限資源限定條件下，實現或超過設定的需求和期望的過程。或者說運用各種相關技能、方法與工具，為滿足或超越專案有關各方對專案的要求與期望，所開展的各種計劃、組織、領導、控制等方面的活動。對於互聯公司來說專案管理的職責劃分有兩種情況：

一部分公司的專案管理工作主要由專案經理來做。這種情況產品經理主要是負責市場調研、使用者研究並根據使用者的需求，定義和設計產品，然後考慮產品的商業模式、運營推廣方式等。但是即使是這樣作為產品經理你也得在一定程度上去做一些專案管理的事，主觀上作為自己精心設計的產品你肯定會擔心產品在實現的過程中會出現什麼問題，有沒有什麼需要完善的，在開發那裡是不是由於一些需求而耽擱下來。客觀上來說影響開發的進度最大的還是需求的實現和變更上，所以專案的進度和成本質量都與產品經理息息相關。不過這時候由於專案經理的存在其實作為一個pm你對於專案管理來說只是一個輔助的作用，大部分工作都由專案經理來給你承擔。

然而網際網路公司更多的是產品經理來兼任專案管理的工作。我們今天主要要談的就是這一種，產品經理的專案管理。

（2）產品經理怎麼去做好專案管理

由於一個專案往往牽扯到多個部門的協作，因此整個專案進行下來，極其依賴於各個部門之間的配合。就拿現在大部分網際網路公司的專案流程來說吧。一個需求或專案從立項到完成，往往需要產品、設計、開發（前、後端）、測試配合。從上圖我們可以看出在專案的不同階段，產品經理都有著不同的工作目標。而每個階段的時間節點，也是由產品經理去把控。這就要求了產品經理對時間管理有著極其嚴格的要求，否則很容易出現專案delay的情況。對於我們公司來說主要流程是：客戶確定需求——和開發確認技術可行性並估時——估時完成交由客戶報價籤合同——競品調研，寫story，畫原型——和客戶確認原型——Ue組內評——需求評審——需求講解——Ui設計和開發——demo——測試——上線。

其中最容易出現問題的就是開發階段，錯誤評估開發難度、開發結果與實際出入很大。這些問題均會產生一系列連鎖反應，可能導致測試階段無法正常進行，或導致專案Delay。但這並不是說一定都是開發的責任，產品經理也要承擔一定責任。可能由於產品的需求不明確，或者中間又加了一些需求再或漏掉了效果圖上的互動細節。

因此，基於以上的問題所在，產品經理需要定期去了解專案開發進度，把控開發時間。

比如說，開發說可能要延期，那產品經理需要知道延期的原因。到底是開發評估時間過少還是中間有新的需求插入。如評估時間過少，要了解是什麼原因導致的，是開發前期疏忽漏掉了一些功能的工作量還是其他什麼原因。如是新需求插入，則需由產品評估需求的優先順序，評估好優先順序後要去協調是否可以把一些需求放在下一期做以保證專案進度的及時完成。在此過程中，要有合理的掌握度，既不能對專案進度完全不知，又不能頻繁的去問開發，以免因打斷開發思考而被打。最好是在專案開發的中間階段，抽時間和開發開個專案進度會，瞭解一下當前進度，並對開發階段遇到的問題進行引導、解決。另外據我瞭解咱們公司每天開發都會開一個晨會併發一個晨報這也是及時瞭解開發進度的途徑。

另外做好時間節點的重要性。

2.需求變動之於產品經理

需求變動要分階段來考慮，要是再交付開發人員之前需求變動還算能接受，我們視具體變動情況來考慮，但是如果是在開發過程中或者幾近開發完成時那簡直是噩夢。這裡討論的是外包公司的場景，對於做自己公司產品來說大同小異。

（1）需求變動的場景

當我們把原型畫好提交給開發，程式設計師們辛辛苦苦的熬了很多通宵、加班後，產品完成了一半甚至已經完成了客戶提出的功能需求，客戶、企業使用者突然改變了需求，不想這麼做了，提出了新的需求，新的變動，這樣對於我們整個團隊來說，正如晴天霹雷，很恐怖的事情啊，因為有時候，使用者只是簡單的一句話，但是對於系統的調整來說工作量是非常大的。

需求變更，本應是客戶的權力，但確實也為我們的開發工作帶來了很多問題。如果確需變更，當然要滿足客戶需要。問題是不能讓變更權力濫用，把一些無關痛癢的變更寵慣養成堂而皇之的變更。對於客戶提出的變更，無論大小都給予解決，客戶對此是非常滿意，然而，專案進度卻拖的很長，專案一再延期，這樣導致開發小組中的部分成員有些不耐煩了，來一點需求，修改一點，這樣確實很煩人的，作為pm你也很有可能徹底得罪了一波開發人員。

但是如何我們對客戶的要求一概不理，自顧自地按照最初的需求和計劃實施，最終很可能由於沒有使用者的參與，使得系統與使用者的需求相差甚遠，導致驗收通不過，甚至可能導致專案的收款困難。

（2）為什麼會出現需求變動

現實中的軟體開發就是這樣，新開發的軟體不可能一次性全部都提出來，可能客戶自己都不知道自己想要開發軟體是什麼樣子，只是簡單的實現他自己的功能，咱們做出來的1.0版使他們逐步的有意識的幫助他們理清這個軟體的樣子。需求變更的表現形式是多方面的，如客戶臨時改變想法、客戶的習慣、專案預算增加或減少、國家政策的改變、客戶對功能需求改變等。我們理解了這些就會明白使用者變更需求的合理性。所以我們要正確的認識客戶的這種需求變更，應以平和對等的心態來面對。

（3）怎麼正確去面對需求變動

作為PM有一個好的應對方案會使變更需求這一問題在開始階段就會把影響降到最低。

（1）合同制（雖說沒有法律效益，但是在一定程度上可以約束客戶），咱們以後要讓客戶知道需求變更的代價；在和客戶接觸時應該挑明態度，特別是要讓他們清楚需求隨意變更所帶來的代價和風險。如果客戶認為代價太大，那麼開發人 員就沒有必要及時修改，按原來的進度走，但仍要記錄變更，待下一版本在修改。

（2）確認客戶是否接受變更的代價

把變更需求帶來的一些成本和開發週期的延長都明確的告訴客戶，一定要有郵件以便需要時當成證據哦。

(3)每月變更記錄上報雙方領導

最後，實施顧問要將有關變更措施和記錄隨時抄報雙方最高層留檔備案，可採取簡報、檔案、抄報、抄送、會議等多種形式。掌握主動權，逐步讓不合理的隨意頻繁變更，成為客戶不好意思開口的尷尬事件，儘快形成正常的專案執行氛圍和良好的工作習慣，也為可能受到變更所帶來的責任問題留下伏筆。

（4）深入瞭解客戶需求

最後一點也是我覺著最重要的一點，開始和客戶確認需求時一定要認真仔細深入理解客戶的想法。不可為了籤合同而隨意答應客戶，具體實施要具體情況來定。 儘量在一開始就減少後續需求變動的可能性。

3.溝通的重要性

作為pm來說出了我們都知道的確認需求，做調研，寫story畫原型。更多的還有一項重要的能力就是溝通。我們今天談的專案管理和需求變動都是對於一個產品經理來說溝通能力的考驗。具體怎麼樣的溝通技巧就是因人而異，每個人都有自己的處事方式，但有一點我想說就是溝通之前想好溝通的內容和目的，有針對性的去溝通。具體方式那就看個人發揮了，語氣和緩，有理有據，有爭執趕緊撤，找機會再聊。

作者：想做產品的審計狗
連結：https://www.jianshu.com/p/fe08b8de66f0
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。

更多內容，可以加入IT交流群565734203與大家一起討論交流

這裡是技能樹·IT修真院：https://www.jnshu.com，初學者轉行到網際網路的聚集地