專案之所以成立，是因為有需求；然後從需求中，粹選出專案範疇。可以說，專案需求是專案的根本。專案需求沒有確定，專案規劃所計畫出的成本、時程、風險、品質…等等，全都不切實際，也沒有意義。
沙拉氣沖沖的回到辦公室，一屁股坐下，口中不停喃喃自語：又要變，又要變，到底還要變多少次你才會滿意？自己要做什麼都不清楚，我們怎麼幫你做好？拜託你！可不可以先想清楚再要求我們做，可以嗎？可，以，嗎？
做過專案的朋友們，對這場景應該都不會陌生。是的，專案需求改變了。這是一件很平常的事，有句名言是這樣說的：這世界上唯一不變的真理是，永遠在變化中。因此，當專案資助人(sponsor)，不論是客戶、老闆或是業務單位，對專案需求提出變更要求時，實在不需要要像沙拉一樣被觸怒；要知道這不是特別不順利的一天，這只是另一個 more...
projectclub提到：
這世界上唯一不變的真理是，永遠在變化中
這句話在IT界真的是名言啊！
老實說，我16年職涯接觸的專案，無一不遇到或多或少的需求變更，有些甚至會更動到系統架構，偏偏提出需求的有可能是引響力很高的利害關係人，所以如何有智慧地處理就是門學問了！
且在台灣，有公司設立CCB的可說是微乎其微，因此通常我們很難拒絕變更。但是日復一日地與利害關係人針對變更的溝通，加上許多利害關係人真的並沒有受過IT知識或邏輯訓練，很難在專案規劃階段就把"完整"的需求告訴你，那麼PM和團隊真的只能默默接受變更，沒有其他方式可以改善彼此的關係嗎？
這個問題困擾我很久，直到今年偶然機會遇到台灣PMI分會的理事長JACK老師，他給我個答案：你該去了解ACP(敏捷式專案管理)！
敏捷式專案管理很適合用在IT產業，因為IT產業的特性就是：【變化快速、需求不確定性高】，因此專案分成多個階段(iteration)，每個iteration都會產出視覺化可操作的功能，讓利害關係人可提早接觸專案成果，提出意見回饋給團隊，讓團隊能夠在下一個iteration依據回饋再調整、排序需求，這樣的循環讓變更提早發生，利害關係人的參與度也增加，專案成果的商業價值與可用性也大幅提高，真的是個多贏的解決方案。
我不是補習班的寫手，只是身為IT，在實務上遇到很多狀況後，努力去尋找解答！我很開心我認識了敏捷，也通過了認證，在將來的職涯，我想敏捷可以幫助我和我服務的公司、客戶增進彼此的關係，而不需要在處於對立。
projectclub
iThome鐵人賽
看影片追技術