進階專案知識

到底是誰殺了敏捷?

某次教完【專案管理一日特訓班】的課,下課後,有個問題讓我印象深刻,問問題的,是使用了敏捷大概3年左右研發單位的經理:「老師,我發現最近在使用敏捷的團隊,好像不似幾年前那麼多,好奇怪,敏捷的方法和原則都沒有什麼變化,難道是台灣的組織環境不合適,所以大老闆決定放棄敏捷?開始評估其他的方法?」

該怎樣估價自己的專案價值?我想用商業思維來談

在手上這麼多的專案裡,我如何決定專案執行的輕重緩急?衡量其價值?以及如何有效的切分階段?其實,這幾個疑問其實都指向同一個規則:你沒有一套專案價值估算方法。如果你能估算一個專案價值,那你應該也能估算專案中一個工作包,或一個user story的價值,若一個專案若包含10個工作包,你也能排出這10個工作包的順序。問題是,該怎樣建立自己的專案價值估算法呢?

敏捷開發就是不用寫文件?該怎樣取捨?優缺如何?

敏捷開發中要不要寫文件是一個問題。該寫多少內容?該寫多深?這類文件製作「質」與「量」的問題,都應該回歸到該文件的原始初衷是什麼來思考。

為什麼團隊總是對目標無感?你可以用「一個前提」和「一個公式」避免自己落入傳聲筒角色

你的團隊有多麼目標導向,取決於你有多強大,可以讓團隊精準理解並聚焦目標能力,這需要練習,更需要準備。做的到位,不僅能夠讓自己逃出自彈自唱的獨角戲舞台,且常能在數字管理型的組織裡閃閃發亮。但是,應該要怎麼做呢?你可以用「一個前提」和「一個公式」避免自己落入傳聲筒角色。

誰能救救敏捷開發團隊裡的菜鳥?

「如果敏捷團隊中有菜鳥,是不是時間就會估不準?進度就會被延誤?」這個是課堂上常被提問的熱門議題。原因多半是提問者對「菜鳥是否有能力參與好這兩種活動」心存疑慮!現在我們就來看看,Scrum 敏捷式團隊合作方法有哪些設計可以解除或舒緩這種疑慮。

怎麼樣才能建立專案經理的專業感?

對很多專案經理而言,尤其是技術職轉上的專案經理,常常都有很深的焦慮感。因為過去擔任技術職時,會有個感知上很扎實的一技在身,面對別人往往也能拿出技術文獻或是量化數據來佐證。但當了專案經理,聽起來雖然是升職了,但心態上卻感覺虛了很多。因為當管理職,必然會開始接觸一些過去不懂的技術,再加上「大部分時間都只是靠一張嘴去協調」,做久了不免自我懷疑:長久以往,到底該以何服人?

為什麼 Scrum 敏捷方法倡導「專職專注在一個專案上」

有位學員在課程的中場休息時間跑來問我 :「老師,我們公司都是一個人要同時負責好幾個案子的,你講的『專職專注在一個專案上』,根本就不可能實現的啊?那是不是我們公司就無法使用敏捷方法了?」 說實話,這兩個問題不只一個人問過,我相信,這必定也是許多對敏捷方法有興趣的人心中的疑惑。既然如此,我們就先來聊聊「一人專職專注在一個專案上」這個主題好了

臨時工作加不停,重要專案都卡關,我能怎麼辦的七個步驟

雖然我知道時間管理就是自我管理,就是專注自己的重要事情。但問題我的工作上就是無法專注,因為每天都有老闆、客戶臨時加入的大量工作,而且每件意外工作都說是緊急又重要,導致就算我想專注重要工作,最後重要專案還是都卡關......這時候,應該怎麼辦呢?

被溝通工具疲勞轟炸? 讓敏捷方法拯救你的團隊效能

有了 email 、 Line 之後,大家用電話分機溝通的頻率就少得多了,同事之間面對面討論事情的機會也變得越來越少!而那些還喜歡用分機或是直接找人開會討論事情的,就算時間都控制得宜,似乎還是會不太受人歡迎。這到底是為什麼?為什麼大家總喜歡在 email 上你一嘴、我一句地,回過來又回過去,結果造成同一主題的 email 討論串愈來愈長,而每個收件人都變成是這一大群 email 轟炸的受害者......

從薩提爾變革模型看敏捷帶來的改變

牛頓運動定律說:「靜者恆靜,動者恆動」。組織停留在近期現狀階段的力量往往非常強大,由組織內部自發性所引發的變革往往十分困難。因為組織與個人會不斷地否定問題,迴避改變的必要性,這也是薩提爾所說的:「熟悉總是比舒適更有力量」。畢竟,待在舒適圈的力量真的太強,只要舒適圈依然存在,又何必做出改變呢。所以,要讓組織脫離舊有現狀,經常需要藉由外部力量來推動。

什麼是「忙而不急」的上乘職場功夫?跟敏捷方法又有什麼關係?

我們之所以把專案團隊關在大會議室裡一起近距合作,目的就是希望專案團隊表現得像是「一個人」那樣,1 + 1 > 2,沒有多餘的內耗,就像上面武俠小說裡閉關練功的掌門人一樣。閉關中的敏捷團隊(掌門人)需要有能專注、不被任意打擾的環境,才能展現出超高的效率(練成蓋世神功)。 然而,組織當中一定會有許多意外事件或是新專案欠缺人力等事情發生(邪教來踢館),這些都會讓組織的中高階主管們想伸手去調動閉關中的團隊成員來因應,要他們同時兼顧兩三個專案(出關救門派)。雖然這是常見的兩難,但請務必深思這樣做的長期利弊與得失,會不會變成「賠了夫人又折兵」的窘境呢(掌門人

新任PMO主管該做的三件事(上)

PMO在這幾年其實變成一個新鮮的議題。我身邊還滿多讀者或是朋友,因為公司突然決定要成立一個PMO,而被長官指派要負責這部門的營運。可是因為公司過往從沒做過類似的事情,專案管理在目前又還不像會計有法規上面的要求,所以任何的開展方式好似都說得通:好像什麼都能做、又好像什麼都不能做。若負責PMO的人政治敏感度不夠,缺乏組織變革所需要的知識與經驗,很可能花了很多心力卻碰到大家的抗拒。抗拒下做不出結果,慢慢老闆對此就失去興趣,最後往往就變成一個被冷凍的部門了。

為何某些PMO會夭折?

我在這裡打算分享的,是想很務實地告訴大家一些你在別處不會看到的「小建議」——哪些事情會讓你迅速搞爛這個部門;如果你剛巧接手或是即將接手這樣一個部門,又不希望自己做錯事情,那你實在該好好看完這一篇! 

五大原因告訴你,為什麼專案延誤時加人反倒更糟!

如果你問我,人生最重要的資源是什麼,我會說:「時間」;如果你問我企業最重要的資源是什麼,我還是會說時間。因為時間是完全不可逆的,多數資源的缺乏我們都可以用金錢來彌補,但對於時間,就算全地球所有的黃金鑽石加起來,也買不回一毫秒!

從評估軟體時程,論人性化管理

軟體開發時間是工程師一天到晚都會被問的問題。但是通常工程師只能對著PM、主管說「該花多久時間就花多久時間」,可惜PM、主管總是因為立場不同而不懂。到底有沒有更敏捷的方法,可以縮短軟體開發時間?有沒有更有效的管理方法,可以幫助管理專案開發時程?