在企業班上課時，由於我的自我介紹中寫著，我同時具備了PMP國際專案管理師與ACP、以及CSPO的敏捷認證，而引起幾位同時導入敏捷和CPM的企業主管課後諮詢，剛好也因為自己帶過的團隊，因應現實的條件而採取了兩大體系，取捨後的混合式做法，也確實得到不錯的成效，所以，常與他們有些實務上的分享。

某次下課後，有個問題讓我印象深刻，發問者是使用了敏捷大概3年左右研發單位的經理：「老師，我發現最近使用敏捷的團隊，好像不似幾年前那麼踴躍，好奇怪，敏捷的方法和原則都沒有什麼變化，難道是台灣的組織環境不合適，所以大老闆決定放棄敏捷？開始評估其他的方法？」

我：「其實大部分的大老闆並不那麼在乎團隊用什麼方法做開發或研發，而且，很多也不太懂敏捷是什麼東西。」

他：「對耶！像我們公司XX副總，他根本沒在敏捷團隊裡面，卻一直說這方法有很多問題，到底憑什麼啊？」

組織中真正具有決策權、資源權、預算權的老闆們，可能不見得參加過敏捷的團隊，也沒有受過敏捷的訓練，別人提到敏捷時，他可能也說不出敏捷宣言 ，只能隱約回答，我們的某個團隊也是用敏捷在run案子。

幾乎所有的老闆都在乎「要做多久？」「要花我多少錢？」「我能賺多少錢？」「我們的客人是否滿意？」如果他上面還有更大的老闆，甚至是董事會，那麼他就有更大的必需也要能夠對他們清楚交待。

我自己的觀察，不知是否有些團隊，上網隨便Google了幾篇文章、看的書籍收錄的實務不足，甚至上過幾堂課，轉頭就雄心萬丈的開始導入，造成團隊在號稱導入了敏捷之後，並沒有真正參透敏捷的精神與價值，而只取其對自己有利的原則遵守，甚至拿來當作不想執行某些事的擋箭牌。

例一：
老闆問：「這個產品什麼時候可以上市？」
團隊回答：「不知道，敏捷沒有辦法預估專案總時程，要一邊做一邊估，接近尾聲才會知道。」

哪個老闆可以接受這個任務交辦下去，卻不知什麼時候才能完成啊？老闆心想，我投入了那麼多的金錢、資源、對董事會承諾、要搶得市場第一手商機的計畫，不就都無法預期了嗎？這個方法真的能用嗎？

例二：
最重要的大客戶抱怨品質出了問題，團隊堅持是照著客戶的需求去進行的，客戶要求提供當初的規格文件，團隊回答：「oh！我們用敏捷，根本不會花時間做文件，敏捷說文件不重要。」老闆修養好、沒破口大罵，難免心裡會想：「敏捷？這是什麼妖魔？絕對是個爛東西，要找個機會除掉它。」

這當然是對敏捷莫大的誤解。

我自己發明了一個名詞叫做「高端偏誤」，高端指的就是組織中真正坐在高階，具有決策權、資源權、預算權的人，位高權重，日理萬機，因為組織分層負責的原則，所以他們不大可能，事實上也不應該親自參與中層基層的每一項實際運作。也因此，若沒有適合而正確的訊息管道，他們其實並不會知道發生了什麼問題，但，可怕的是，若有了偏誤的訊息上達天聽，而且只有這訊息，又缺乏其他的平衡報導，可能就容易以偏概全，也會左右接下來的決策。當老闆總是聽到團隊因為對敏捷不正確的認知，而導致專案的風險無敵高、問題爆炸多時，他可能還來不及看到成效好處，就決定要封殺它。

所以，根本是一知半解的團隊，自己先殺了敏捷，然後逼老闆走回頭路。

這點非常可惜，相信組織在導入敏捷前，一定花了許多時間與精力說服老闆、克服文化、組織重建、團隊成熟度的問題，但開始正式run敏捷之後，卻忘了最重要的利害關係人，其心中最要緊的價值。

其實無論CPM，還是敏捷專案管理，都必需要面對這些問題：

1.無法進行時程預估的問題（如第一個例子）

不知為何，軟體產業的時程，多半是依據一個非常莫名的時間點，然後逼著團隊倒推出來的。那個莫名的時間點可能是合約規範的期限、可能是搭配政府的新法規、也可能根本只是某個重量級利害關係人因為各種不同的理由而指定的日期。說實話，這種實務之下，預估很像是為了過個場交個功課而存在，估不準是必然，估得夠不夠精確，似乎也沒人在乎。

雖然大家心照不宣，但老闆通常還是不能接受對時程完全沒有譜的答案，團隊仍然還是會被期待有一套，看起來似乎科學化的邏輯標準估算的基礎或方法，才能讓他們感到安心。

實務上，或許我們可以跟老闆爭取一點點測試的時間，讓團隊先試試run 1-2個iteration，確認效率後，再去修正預估的時程。

或者與團隊討論User Story在價值度與風險度的排序，究竟是依高風險高價值，或是低風險高價值的優先度，把低價值的暫且後置不估，做為時程預估的排除條件，得到大致預估的結果。

不管是哪一種專案類型，時程的預估都必須在專案的進行中，被反覆持續的調整和修正，每一次的變化，PM或SM（Scrum Master）都必須要清楚知道是發生什麼事情？下個迭代是否可以排除？至少得讓投資者讓認為，我們在情境之內、狀況之中，我們都有掌控住，而且我們會盡最大努力，達成你的期待。

我認為，比起各種看起來厲害的專案文件和工具，更重要的，是取得利害關係人（特別是重量級利害關係人）的信任了。因為只有這樣，才不會讓不安感爆發的老闆們，一直想把手伸進你的團隊，要求你交很多報告、開很多會議來確保進度，你也可以替自己和團隊爭取更多的時間，去做更有價值的事情。

另一方面，我認為一個到位的PM或SM，必需要具備能夠識別與排除影響時程的因子的能力，就得持續觀察、分析並抓出影響專案進度的種種障礙，做為預防，並且主動規畫專案內外的訓練、協調合適的資源（不論內找外包，不論是人、機、材）提升團隊的能力和效率，

因為讓影響時程的因子可以愈來愈可以提早預見、越來越可控，預估才會更接近真實，也更有參考價值。

絕不是一句「我們用敏捷的方法所以估不出來」就能閃躲的。

2.客人要求規格文件，卻遭到團隊因為對敏捷錯誤的理解而拒絕（如例二）

敏捷宣言其中一項

「Working software over Comprehensive documentation」

英文這個 over 用的很妙，但絕對不是取代或廢除或完全不做右邊的意思，永遠別忘了你的老闆可能也是你的客戶、是你專案的投資者、更是你重要的利害關係人，關注什麼才是他最重要的價值，比死背那個a over b重要多了。這不正是敏捷不斷重砲傳達「必須重視利害關係人」之價值的重要體現嗎？取得他的支持、肯定、以及信任，才能夠讓敏捷的方法落地生根、遍地開花，然後長長久久。

或許老闆們最終在乎的，根本不是某個專案的時程預估準確率達到100%，而是當他驕傲的發現導入一個叫做敏捷的方法之後，團隊變得更有效率、得到更多的客戶滿意支持、讓他賺進更多的營收，更重要的是，當他的老闆問他產品什麼時候能上市時，他也能夠清清楚楚，四平八穩的好好交待。

敏捷在經過正確的理解，並依據組織的特性做過修調之後，真的是個很棒的方法，千萬不要讓自己成為兇手啊！

Photo by Paweł Czerwiński on Unsplash