今天繼續來聊一下我的第二張證照，PMI-ACP，其實當年上課考照時, 想都沒想過有一天會靠這張證照跨入軟體業，因為當年在新創的工作，常常都在調整進度與規劃，搞得我有時真得覺得PMP只適合拿來寫申請政府研發補助案的知識與工具(也確實很成功，申請到好幾次，最大筆的科學園區研發專案也有好幾佰萬之譜的規模)，對外是安排的光鮮亮麗，對內卻總是有說不上的混亂，因為規劃總是趕不上變化。

也就剛好在那段時期，注意到了敏捷的證照與課程的推出，雖然自從PMP考上之後，都會留意專案管理界的發展，但真正會讓我覺得需要再進修的，還是實務上的真實需求, 尤其是當PM需要跨域整合各領域的RD時, 如何領導團隊? 如何帶領討論? 如何協助找資源解決困境? 似乎缺乏方法與訓練, 而且跟實際的開發時程又該如何連結? 因為需求規格或技術瓶頸常常在變更...此時, 敏捷管理的Sprint planning, Daily standup meeting, demo meeting, retro meeting的周而復始的模式, 也剛好了滿足新創團隊, 人數不多, 卻要很彈性很"敏捷"的作調整的運作模式。

但一開始是在硬體設計為主的新創公司run敏捷的方式, 但確實沒在"真正"的軟體公司裡看Agile到底是怎麼運作的? 跨入了軟體公司的大門之後, 似乎也真是嘆為觀止, 雖然用了Redmine系統在安排每個Sprint的Task, 但只淪為工作紀錄的形式, 沒有敏捷的精神, Iteration Planning淪為每周的例行會議, 沒有人在乎是否真的在每個Sprint中的任務能完成, 只能說就算大家嘴上都在講"敏捷", 但真正執行起來, 卻一點都沒有敏捷的精神...也難怪市面上還是需要很多"敏捷導入和經驗分享"的課程, 因為那是一種"思維"的改變, 而不只是工作流程上的變更。

不過我沒有因為總公司裡的大環境不敏捷而灰心, 還是從中體會到為什麼軟體工作會需要Scrum, 也深刻感受到為什麼敏捷總是強調不要在Sprint中再加入新task, 因為更新上架的時間總是一直在delay, 所以我在自己規劃的專案裡, 盡量安排與融入敏捷的流程與精神, 我們先從分公司的雲端小團隊開始, 規劃-開發-展示-回饋-再修正, 我們後來用了接近敏捷的精神, 在很短的時間內把公司的官方LineBot做出來, 趕上了展場上的使用, 也擴展了從Voice assistant到chatbot的發展 (這個故事之後再談)。

有時候你很難在一開始就去衡量一個證照對你的價值, 上課與考照約略要花掉近五萬台幣, 還有許多熬夜苦讀的夜晚, 但往往也是這些先期的自我投資, 讓我有機會接收新知與看懂更多不同領域的精彩, 而且也讓自己的職涯發展上, 有更多潛在的機會與選擇, 雖然還稱不算上成功, 但我相信我走在通往成功的路上!!