1. 互聯網產品項目管理現狀

根據Standish Group發布的報告，在2012年所研究的IT項目中，有18%的項目是失敗的，43%的項目是有問題的，只有39%的項目是成功的，能夠同時滿足時間、范圍和成本的要求。也就是說，在2012年有61%的項目是沒有達成項目目標的。影響項目成功的因素很多，如不清晰的需求，頻繁的需求變更，不合理的進度計劃，低效溝通，風險管理的缺失，不穩定的項目團隊等。

對單個問題進行分析時發現每個都能被解決，但當問題交織在一起時，整個項目就像陷進了焦油坑，如Brooks在《人月神話》中所說：“表面上看起來好像沒有任何一個單獨的問題會導致困難，每個都能被解決，但是當它們相互糾纏和累積在一起的時候，團隊的行動就會變得越來越慢。對問題的麻煩程度，每個人似乎都會感到驚訝，并且很難看清問題的本質。”

2012年IT項目執行結果

而在互聯網行業，產品功能需要快速迭代以解決用戶痛點問題，并且需要根據用戶對產品的反饋快速對功能做出調整，因而需求很難在項目初期被準確定義。

為了持續交付對客戶有價值的功能特性，互聯網產品的項目管理多采用敏捷開發，以“小步快跑”的模式來適應不斷變化的需求。但每個項目團隊所處的行業不同、公司文化不同、人員素質不同及對“敏捷”的理解程度不同，互聯網型項目管理還存在很多問題，比如：

·迭代內需求模糊

·項目進度延遲嚴重

·缺乏風險管理意識

·項目團隊不穩定

·進度與問題溝通不暢

·產品質量不高

如何解決這些棘手的問題，成為很多項目經理關注的焦點。

2. PDCA循環簡介

如圖2所示，PDCA是Plan(計劃)-Do(執行)-Check(檢查)-Act(行動)的首字母縮寫，來源于質量管理領域，由著名統計學家休哈特 (Walter A. Shewhart)在20世紀30年代提出構想，后來由戴明( W. Edwards Deming)完善并加以廣泛宣傳，運用于持續改善產品質量，因此PDCA有時也被稱為戴明環或休哈特環。

PDCA 循環是一個持續改進的過程，它是針對在計劃和執行過程中遇到的問題進行分析，并通過制定相應的解決措施，在下次計劃和執行中進行改進，從而達到流程和質量持續提高的目的。如下圖所示，下一階段在改進上一階段問題的基礎上執行，因而可以達到一個更好的水平，這四個過程周而復始，整個水平呈階梯上升的趨勢。

PDCA循環是一個發現問題、解決問題的過程，其適用范圍不僅僅在質量管理領域，它的思想同樣可用于互聯網項目管理。

3. PDCA在項目管理中的運用

互聯網產品的項目周期通常比較短，從需求導入到功能發布一般在2~4周，有的互聯網公司可以做到每周發布新版本。頻繁的項目需求導入以及固定的項目團隊能夠保證PDCA循環可以很容易的應用到項目管理中去，下面將探討在項目管理中應用PDCA時需要注意的地方。

3.1 Plan階段需要注意以下幾個方面

·清晰明確的需求是計劃的前提。

很多項目經理在需求沒有弄清楚之前，因迫于管理層的壓力而匆匆做計劃，結果執行的時候發現很多問題，最后做出來的功能并不是產品經理想要的。如果在做之前沒想清楚產品要做成什么樣，那么如何保證開發出來的產品符合產品經理的要求。

需求清晰明確并不是要求一定要有詳盡的需求規格說明書，因為那需要花費大量的時間和精力去維護這些重量級的需求文檔，但是對于需求，產品經理、項目經理、開發團隊和測試團隊至少要有清晰一致的理解，即大家對需求的認識是一致的。

有了對需求一致的理解，才可以準確地將功能需求轉化為設計、開發和測試任務，進而對每個任務進行準確的時間估算。通過產品需求文檔結合產品原型的方式可以幫助項目團隊更快更準確地理解產品需求，做到需求清晰明確其實并不困難。

·任務分解誰執行誰估算。

在很多公司，項目執行不好的原因之一就是從需求分解、任務拆分、工期估算、任務排期都是項目經理一個人依據自己的經驗搞定，但是項目經理又不負責具體任務的執行，大多數情況下在做計劃時往往很樂觀，任務工期估算的偏少，結果就是項目總是處于延遲的狀態。團隊為了趕進度經常加班，如果再碰到一些技術難題，延遲就更嚴重了。

因此在計劃階段做工期估算時，需要讓具體執行任務的人依據自己的知識和能力去估算，項目經理根據自己的經驗可以針對估算結果做調整，但是調整時需要向任務執行的成員說清楚為什么做調整。敏捷開發中的“撲克法估算”是讓每個項目成員都對同一個任務進行估算，這樣得出的結果比較準確，如果有條件可以嘗試這種估算方法。

·項目管理也是項目任務。

第一次擔任項目經理的時候，我在計劃里給自己安排了很多開發任務，基本上在工作時間都安排了開發任務，天真地認為項目管理就是每天與團隊成員開個會了解一下進度，不會耽誤太多時間，更不會影響項目進度。結果到了項目執行的時候，我需要花很多時間去和每個人溝通進度和問題，比如：每天組織項目晨會、組織設計評審會、整理會議紀要、與產品經理討論需求有爭議的地方、與采購同事溝通設備的采購進度、向領導匯報進度、處理突發問題、組織團隊活動等等。

后來學習PMBOK時了解到項目經理75%~90%的時間都是在溝通，項目經理不在溝通就在溝通的路上，去溝通計劃、溝通進度、溝通問題、溝通風險等等。所以，項目經理的時間就是被各種溝通碎片化，如果在計劃時還要像其他項目成員一樣排任務，那估計只能在加班時候完成了。所以，在項目計劃里面一定要把項目管理工作當成一項重要的任務，它也需要時間。

·風險管理不可缺。

為什么要有風險管理計劃，要回答這個問題，首先要想清楚我們做好的項目計劃(準確說應該是進度計劃)是在什么情況下制定的。我們假設項目組成員都不會生病、家里有事、不會離職，因此可以每天8個小時工作;我們假設項目里的技術難題可以在估算的時間內解決，不會影響進度;我們假設采購的設備可以在和供應商談好的時間內交付，保證測試環境可以按時搭建;我們假設項目組成員小A每天心情都很好，可以在每天6個小時高效工作。

從這幾點我們可以看出，我們的項目計劃很多都是基于假設來做的，我們認為這些假設都是成立的，那么問題來了，當假設不成立的時候我們該怎么辦?這就需要風險管理計劃了，一般來說，在計劃階段，可以采用專家判斷、頭腦風暴和檢查表等工具來識別風險，并通過定性分析和定量分析形成風險登記冊，最后針對每個風險制定相應的應對措施。通過風險應對計劃來解決假設不成立的問題，將實施過程中意外情況對項目造成的影響降到最低。

3.2 在Do階段需要注意的幾個方面

·控制需求變更。

在項目執行過程中，需求變更常常會會引起設計返工或項目進度計劃的變更，頻繁的變更會導致項目計劃不具備可執行性，另外也會對團隊士氣造成影響，團隊會認為反正計劃會變，做了可能也是白做。在互聯網項目中，2~4周的項目計劃一般情況下都不應該進行需求的變更，如果有特殊情況必須變更，建議重新制定項目計劃以保證項目計劃具備可執行性。

·確保溝通高效。

項目經理75%~90%的時間都是在溝通，同時也要給團隊創造一個便于高效溝通的氛圍，尤其要提倡“面對面溝通”。在敏捷項目管理中，每日站立會是很好的方式，每天固定的時間，每個人通過回答“昨天做了什么”、“今天準備做什么” 和“有什么障礙”這三個問題向團隊其他人同步自己的工作進度和問題，簡單的問題在站立會上就會馬上解決。

除了站立會外，很多成員習慣于QQ/RTX上說問題，有的甚至通過郵件來問問題，一個簡單的問題當面溝通三分鐘就解決了，結果在QQ上說了一上午也沒搞定，所以項目經理要鼓勵大家在有問題時盡量當面溝通，能“動嘴”的堅決“不動手”，做到溝通基本靠“吼”。

3.3 在Check階段需要做什么

PDCA 循環中的Check可對應于敏捷項目管理中的項目回顧會議，團隊通過對本次迭代的完成情況進行回顧，找出本輪迭代中團隊中哪些方面做的好，哪些方面需要改進。在回顧會議上需要注意的是要營造一個開放安全的氛圍，大家可以放心說問題而不用擔心說問題會導致領導不高興，從而影響自己的績效，所以有的團隊在做回顧會議之前會做安全測試，即大家對這次會議的安全性進行不記名投票，如果安全性過低，則ScrumMaster會將領導請出會議室，以保證大家可以放心說問題。

會議最后會選出在這次迭代中TOP 3 GOOD THINGS和TOP 3 NEED IMPROVEMENT，會議之后需要將這3件做的好的方面和需要改進的三個方面記錄下來，以鼓勵團隊在下一次迭代中繼續保持好的方面，改進不好的方面。

3.4 在Act階段需要注意的兩個方面

·確保改進措施可行。

在回顧會議上會選出3個需要改進的方面，但是具體的改進措施有時在回顧會議上不會制定出來，會后可組織團隊專門針對問題改進措施進行討論，制定可行的改進措施，可行的意思即為在下一次迭代中團隊可以做到。如果改進措施團隊無法做到，則改進沒有意義。

·督促改進措施落實。

有些敏捷團隊按照敏捷實踐組織了項目回顧會議，選出了需要改進的方面，也制定了相應的措施。但是在下一次迭代中，沒有人監督這些改進措施的落實，團隊仍然按照上一迭代的方式做事，項目回顧會議完全淪為一種形式。PDCA是一個通過發現問題和改進問題達到持續改進目的的過程，如果只有發現問題而沒有改進問題，則談不上改進，更沒有持續的項目管理水平的提高。因此，項目經理需要在每個迭代中監督上次回顧會議上制定的改進措施的執行情況，保證制定的改進措施執行到位。

4. 總結

大多數IT項目在項目收尾時都無法達到同時滿足時間、范圍、成本三方面預期的項目成功標準，在項目管理中通過引入質量管理領域的PDCA循環，可使項目管理水平持續提高，從而保證項目具備越來越高的成功率。

在Plan階段，制定計劃前需要確保所有的需求都清晰明確，還要保證由具體的任務執行人來做任務分解和工期估算，把項目管理作為重要的項目任務，最后要做好風險管理計劃;

在Do階段，需要控制需求的變更，同時要營造高效溝通的氛圍;

在Check階段，總結團隊在本次迭代中做的好的方面和做的不好的方面，針對做的不好的方面制定相應的改進措施;

在Act階段，有時需要適當修正改進措施以確保改進措施可行，最重要的是要監督改進措施真正執行到位。