敏捷項目管理的十大誤區

許秀影，PhD、OPM3、CSPO、PMI-ACP、LLP Educator。

本文的觀點均來自筆者親身的經驗或親自輔導的心得，并不是針對某個人的觀點或某家公司的流程做評價，如有雷同，純屬巧合。若您的看法與做法列在文中，意味著根據國際的敏捷趨勢、知識與筆者個人的經驗判斷，它可能會導致失敗，應該引以為戒。

敏捷就是在快速變化的這個“互聯網+”時代，所有知識工作者必備的DNA。對于敏捷的認識最主要的就是要能夠像任正非所講的“你的笑臉要面對客戶，你的屁股要面對老板”。如果你一天到晚巴結你的領導，然后你的領導又巴結他的領導，然后大家一心一意所想的所看的都是領導高不高興，那么這個組織通常不太敏捷。你所想的應該是我們怎么樣能夠對客戶最好，怎么樣能夠為客戶創造最高價值。這樣的話才是敏捷。

敏捷是時代演進的必然結果，傳統的項目管理是從工業時代遵循泰勒的科學化管理方式而來的，演進到PMI以及后面一系列的項目管理標準，敏捷項目管理是從彼得·德魯克的人性化管理演進而來的。敏捷項目管理提供了以人為本和科學管理有機融合的項目管理方式，敏捷團隊以協同合作、自我組織的方式工作，努力的成果是為了要達成項目愿景，幫助客戶創造最高價值。在我的著作《敏捷項目管理：基礎知識與應用實務》（中國電力出版社出版，2016）一書中，我提出敏捷項目管理的架構APMF，這個架構就是用中國的《易經》陰陽平衡的理論，基于一個自然界運行的方法。

全世界優秀成功的信息公司幾乎都采用敏捷，尤其是Scrum，如谷歌、諾基亞、奧多比、蘋果、微軟等。采用敏捷可以實現幾個主要的商業目標。第一，持續創新。因為新的點子是來自自我組織的團隊，不是由上而下的下命令。第二，產品比較有彈性，可以根據客戶現在跟未來的需求進行調整。第三，可以加快上市時間，就是用比較小的迭代，然后趕快上市，趕快回收所花成本，提高投資回報率。第四，人員跟過程有彈性。第五，產出可靠的成果，支持業務的成長及提升獲利的能力。

誤區1 敏捷是將大瀑布變成幾個小瀑布？

我發現大部分導入敏捷失敗，問題都是出在團隊雖然用了敏捷的流程，但是沒有用敏捷的思維，而是用傳統的腦袋和思維在做事情。那也就是會導致“有形無意”。空有敏捷的流程外觀，沒有把握敏捷的精神，做事情的方法都跟以前一樣，這些團隊只是把一些大瀑布分割成為小瀑布，要求團隊用更少的時間來完成，這樣不是敏捷。

導入敏捷項目管理是一種組織的價值觀跟文化的變革。項目團隊不是只有如期如質如預算地完成項目而已，是要達成項目愿景。敏捷解決了長久以來無法讓用戶滿意的主要原因——“缺乏使用者參與”跟“需求不明確”。敏捷把客戶納入到敏捷團隊，然后在過程當中頻繁跟開發團隊進行互動，并且逐步地細化需求，讓團隊能夠做出符合客戶需求，為客戶創造最高價值的成果。

誤區2 敏捷只適合在IT產業？

根據我的實踐經驗，除了已經廣泛應用的IT產業，敏捷適用于各行各業，包括嵌入式的系統、公關、數字媒體等，同時也適用于我們的工作和生活。在《敏捷項目管理：基礎知識與應用實務》一書里，我提到的一些范例可供大家參考。但是，并不是所有的項目都一定要用敏捷。如果需求和技術都非常明確，用傳統的項目管理就可以；如果需求不是很明確，就是大方向確定，小的細節可能修改，那就比較適合用敏捷。

誤區3 敏捷只適用在小型的項目？

其實敏捷適用于各種類型的項目，包括小型的項目，也包括大型的項目，在我的敏捷一書里提到，有非常多上百人的團隊也都是采用敏捷的方式。雖然是在不同的項目，可以有不同的適用敏捷或者傳統項目管理的方式，但是無論是哪一種項目，如果能夠運用敏捷的心態和敏捷的一些實踐，不管是任何形態的項目管理都會有更好的成果。

誤區4 敏捷不需要文檔？

我對企業進行輔導的時候，企業里的領導有時候會要求我在輔導時跟團隊強調，敏捷不是不要文檔。原來自從他們去外面上了敏捷的課程回來之后，所有的軟件開發的人員都不寫文檔了，其實這是錯誤的概念。敏捷的精神應該是追求科學化與人性化管理的平衡。所以，敏捷修煉的秘訣就是維持平衡，而每一家企業根據狀況的不同，維持平衡點也不一定在中間，這是我在書里面特別提出來，認為敏捷不是偏左，也不是偏右，而是要維持平衡。

誤區5 敏捷就是“無法管”？

敏捷強調仆人式領導，鼓勵團隊成員以“自我組織”（Self-Organizing）的方式執行與管理項目，不是用“命令-控制”（Command-Control）方式，并不表示敏捷項目管理等同“無法管”。

用仆人式領導的方式，意味著不要告訴團隊怎么做，而是要告訴他們愿景在哪里，要做什么，然后協助團隊自發性地發揮他們的創造力，完成項目。所以，敏捷強調讓客戶代表、開發團隊更多地協同合作。導入敏捷之后其實是比以前更有規矩，而由誰來維持這個規矩呢？就是敏捷教練。所以，敏捷不是沒辦法管，敏捷團隊是自己管自己，管得比以前別人來管他、盯著他推著他來得好。

誤區6 敏捷是需求跟目標都不明確？

敏捷并不是在需求目標范圍都完全不明確的情況之下執行項目，敏捷適用于目標明確、需求大方向明確、細節不明確的項目，而不是完全不明確的狀態。這在我書里也提到，項目啟動的時候要有明確的愿景、目標，過程當中不是不斷地變更范圍，而是緊盯愿景，計劃細節可以變，但是項目范圍不可以變。只是漸進明細地在適當的時間點根據更細化的需求做適當精度的計劃，項目愿景跟范圍不變，為達成項目愿景，有時候計劃必須要根據內部外部環境而變。如果說是新創公司，或者新產品的開發項目，那需求跟目標都不明確的時候光用敏捷是不夠的，還要配合商業模式圖跟客戶開發，也就是《敏捷項目管理：基礎知識與應用實務》書中介紹的“LLP敏捷創新創業”方法。

誤區7 敏捷在每個迭代都提出新的需求？

每個迭代都提出新的需求，會不會做了一些東西都不在我們項目的范圍里面，而造成范圍的蔓延呢？其實不會。敏捷項目管理是把客戶代表作為產品負責人納入敏捷團隊，而產品負責人的主要任務是讓團隊的努力為客戶創造最高價值。所以，產品負責人也就是這個客戶代表，最主要的工作就是跟團隊討論后，排定產品待辦列表的順序。團隊成員所做的所有工作都是從產品待辦列表最上方拿自己擅長的工作來做。每一次發布，每一次迭代，都是把需求更細化，而且可以在不改變合同的情況之下改變工作的先后順序。

敏捷使用的“用戶故事“，與傳統項目管理用的規格書不同，因為規格書無法充分表達需求。項目執行過程中，用戶將原來的需求表達得更清楚，但跟原來規格書不一樣，從傳統的項目管理視角認為是改變需求。敏捷團隊在合同范圍內，歡迎改變需求，因為每次發布、每次迭代，用戶代表就會把需求表達得更明確，可能會跟原來的描述或條件不同，其實只是按部就班地將需求細化，不是亂改亂提需求。

誤區8 導入敏捷之后就不需要計劃？

因為需求一直在變，計劃一直在變，所以不需要計劃。事實上這也是錯誤的概念，敏捷是緊盯愿景，而不像傳統項目管理緊盯計劃。所以，敏捷需要計劃，通常來講它需要五個層次的計劃，計劃是漸進明晰，而不是沒有計劃，詳細的內容也請參考《敏捷項目管理：基礎知識與應用實務》一書。

誤區9 敏捷是在每一個迭代重新審查需求？

敏捷并不是重新審查需求，而是在適當的時間點才把需求逐步細化。所以，在項目啟動的時候，我們會把需求展開為大的用戶故事。進一步發布計劃的時候再把大的用戶故事切分為小的用戶故事，并且討論跟記錄用戶故事的驗收條件。在迭代計劃的時候討論跟記錄驗收的用例，并把這個用戶故事再分解為工作。

誤區10 敏捷不能拋棄傳統的項目管理方法？

認為要使用敏捷項目管理，一定要先學會傳統項目管理，這也是不對的。敏捷工作者不一定要先學傳統的項目管理，也可以采用單一敏捷，敏捷跟傳統混合，敏捷跟敏捷混合的方式。如果是新創公司，沒有以前的包袱，為什么一定要先用傳統再變敏捷呢？可以直接采用敏捷項目管理的方式來進行項目的管理。