項目管理與需求變更的探討

這裏是修真院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畫原型。更多的還有一項重要的能力就是溝通。咱們今天談的項目管理和需求變更都是對於一個產品經理來講溝通能力的考驗。具體怎麼樣的溝通技巧就是因人而異，每一個人都有本身的處事方式，但有一點我想說就是溝通以前想好溝通的內容和目的，有針對性的去溝通。具體方式那就看我的發揮了，語氣和緩，有理有據，有爭執趕忙撤，找機會再聊。