顯示具有 專案管理 標籤的文章。 顯示所有文章
    顯示具有 專案管理 標籤的文章。 顯示所有文章

    《敏捷方法的成功密技》系列文章總覽

    敏捷團隊衝刺老失敗,人才也是難留下,問題到底出在哪?

    敏捷團隊在「衝刺規劃會議(Sprint Planning Meeting)」中所做的工作計畫,是對該次衝刺的一種承諾,也是衝刺的目標。因此,「衝刺工作的完成度」也常被當作是敏捷團隊的績效衡量指標之一。

    這個指標本身並沒有什麼問題,問題在於,當敏捷團隊無法達成衝刺目標的時候,公司會讓他們面臨什麼樣的後果?這個後果,對敏捷方法是好的?還是不好的影響?

    專案狀態報告:你不可不知的四大法寶

    不知道身為 PM 的你有沒有過這樣的經驗,當你走進公司大樓電梯,沒想到公司高階主管也走了進來並關上了電梯門(因此你想逃也逃不掉),緊接著,他冷不防地問你,「那個XXX專案現在的狀況怎麼樣了?」

    他不是你的直屬老闆,只是你老闆的上司或更高層的上司,所以平時你並沒有直接向他報告的機會,這個時候你會怎麼做呢?

    專案團隊加班的藝術

    有同學問我,「老師,用敏捷方法做專案,是不是就可以不用再加班了呢?」

    參與過「專案」工作的人,對「加班」這件事肯定都不陌生,而且老實說,真的遇到狀況,應該也很難可以躲得掉,不管你是用傳統式的還是用敏捷式的專案管理方法都一樣。

    只是說,有些人加班加得很開心,有些人卻加班加得很傷心;有些人只需偶爾加個班,有些人卻常被迫要加班。為什麼會有這樣的差異呢?加班又怎麼可能會讓人覺得開心呢?

    此外,加班對傳統式專案管理的專案團隊,或對敏捷式專案管理的敏捷團隊而言,又會有什麼樣的影響呢?

    什麼樣的專案適合使用敏捷式專案管理


    前陣子有位學員來電,「老師,我是以前上過您敏捷式專案管理課程的學員,我在您的網站上有看到,您有在輔導企業導入敏捷式專案管理,我想邀請您到我們公司,輔導我們用 Scrum 敏捷方法來做專案...」

    對方向我介紹完他們公司後我才知道,原來他是這家新創軟體公司的共同創辦人。

    用戶故事時間老是估不準?三大技巧助你敏捷團隊一臂之力!


    「老師,我們公司有在使用敏捷方法做專案,可是團隊在估算用戶故事(User Story)時間的時候,老是估不準,有的時候會多留很多 buffer,有時候又少估很多時間,導致衝刺的工作做不完,這該怎麼辦才好?」 

    我在《Scrum 敏捷方法裡,渾然天成的九大風險管理把關設計》一文中談過,敏捷方法的框架其實隱含了不少巧妙的風險管控設計,其中當然包含了管控「因時間錯估而延誤」的風險。這裡我們先假設,這位學員提及的敏捷團隊,有確實遵守敏捷方法要求的原則來運作,沒有自行偷斤減兩,可是團隊對於時間的估算,卻依然不夠準確。在這樣的前提背景下,我們還有什麼其他的招數,可以來改善這樣的問題。 

    專案管理輔導紀實-國境之南篇

    在我企業內訓接案的對焦經驗裡,有不少客戶,其「原本想要」的服務,其實可能根本就不是該公司「真正需要」的。只是有些客戶會認真聽你講,願意讓你的專業說服,走對路,預算用對地方;有些客戶則是早有定見,只想交差了事(如,老闆交代、消化預算、有培訓紀錄),任憑你說破了嘴也沒有用。

    當然啦,生意就是生意,能成交而且雙方都滿意就好,沒什麼對錯的問題。只是以我立場而言,既然客戶你付了錢,也讓員工花了時間,能讓員工有巨大收穫,能讓組織的問題獲得解決,這樣的合作不是會更有意義一些嗎?

    2020 年倒數最後幾天,我收到一家南部電子大廠人資經理的來信,目的是想要邀約敏捷課程顧問輔導服務。這個案子頗為戲劇化,也有些峰迴路轉,不過,最後的結果是,我把該公司「原本想要」的服務,轉變成該公司「真正需要」的方案,而且事後成效極大,滿意度極高。

    優秀敏捷大師(Scrum Master)應具的能力和特質有哪些?

    下課後一位學員來提問,「老師,我們公司想要開始導入敏捷方法做專案,我現在是工程師,我想轉換跑道做敏捷大師Scrum Master),您覺得這樣好嗎?」

    「好不好,我不知道,不過,如果你想做敏捷大師,除了剛剛課堂上談的之外,你還可以先想想這些問題,例如...」

    敏捷產品負責人發生「決策錯誤後悔厭惡」,你該怎麼辦?



    最近跟一位朋友吃飯,席間聊到他十年十多萬公里的老車,保養貴得不得了,於是他認真地研究了一下各廠新車的性能和配備,準備要換車,結果看來看去,只有日系L牌房車的性價比和妥善率最合他的胃口。

    敏捷團隊遲遲無法高績效,大風到底吹不吹?

    「老師,您覺得我需不需要定期把團隊打散,攪一攪比較好?」一位高階主管學員在課間休息時這樣提問。

    這個問題違反了我多年來帶團隊的經驗和直覺,因此我好奇地回問,「您為什麼想要這樣做呢?」

    你不可不知,「當責」對「專業」的影響有多大

    最近跟一位裝潢設計師友人 Jean(化名)吃飯聊天,席間談到她的一個 case,這 case 不僅讓她多賠了一些錢,還弄得她客戶有點不太開心,讓她覺得有點委屈。

    Jean 其實相當細心,設計功力不錯,且心地善良(因此生活上常被人詐騙^^!),因此,我出社會以後,多次的新房設計裝潢都是交給她負責的。以我吹毛求疵的高標準來說,她能多次從我手上活著完工結案,裝潢設計的品質和質感一定是掛保證、沒問題的。

    那為什麼這樣的人依舊會出包,惹得客戶不開心呢?這點讓我很不解,因此我決定繼續深挖這個故事。

    敏捷團隊裏的大牌與王牌


    有位學員在課後向我 私下提問,「老師,我們公司有在試行敏捷,我是那個專案的敏捷大師 Scrum master ),我有個困擾,就是,有一位工程師,他的技術能力很強,可是卻不太合群,常常很大牌,只做自己想做的工作,不 follow 團隊在衝刺規劃會議 Sprint planning meeting) 中的共識,我該怎麼辦才好啊?」

    「敏捷大師」可以怎麼生出來?

    敏捷大師Scrum Master)之所以稱為「大師」是有它的道理的,「大師」是那個能帶領團隊走對方向,並在敏捷路上愈走愈順的賢者、智者,絕非隨意指派,給個稱號就行的。

    在《大錯特錯!敏捷大師不是團隊的助或秘書》這篇文章中,我曾經概略說明了敏捷大師這個角色的職責、資格和等級,可是如果組織就是欠缺這樣的理想人選,那又該怎麼辦?有沒有什麼方法可以把「相對適任」的敏捷大師給生出來呢?

    「老師,請問您要怎麼向我們保證課程的成效?」

    前陣子一家做遊戲的企業客戶找上門,詢問一些關於敏捷課程與顧問輔導服務的細節,在一些相關中階主管都在場的對焦會議上,對方窗口最後提出了一個問題,「老師,想請教一下,您要怎麼保證,我們上完課之後會有成效?」

    「喔~這沒問題啊!只要貴公司可以保證,完全按照我教的去落實執行,那就可以保證課程和輔導的成效。」

    奇了!過了不久,又有另外一家做儲存設備的企業客戶找上門,同樣也是類似的狀況。這讓我動了寫這篇文章的念頭。

    Scrum 敏捷方法裡,渾然天成的九大風險管理把關設計

    「老師,要管好專案的風險,您覺得是用傳統式的方法比較好,還是用敏捷式的方法比較好?」一位學員在課後向我這樣提問。

    當下我還真楞了一下,倒不是因為我不會回答這個問題,而是自從教授敏捷相關課程這麼多年以來,這還是頭一遭有人問到這樣的議題。

    先說我的結論,總體而言,我認為,敏捷方法比較技高一籌。