進階的管理人才，是怎樣解決困境的？

初階的管理人才，會希望一切都準備好了才開始做事。他們會希望流程要建好，系統要弄好，其他部門要好好配合，他和團隊不要有太多雜事干擾，若是平台還缺少了什麼功能、系統有不穩的狀況、其他部門無法配合，他們就變得負面，認為時不我予，公司制度不佳，甚至開始「等待」一切變得完善的一天。追求流程、系統的穩定無可厚非，但是，進階管理者會這樣想。

到底是誰殺了敏捷？

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

該用OKR還是KPI？實務上三個迷思與四個建議

最近刮起一陣OKR旋風——這個問世許久的老東西，居然一夕翻身，炙手可熱。也因此，我接到許多苦主的求救，個個倉皇不安： 「老闆最近也想導入OKR，叫我們先研究看看，我該怎麼開始？」 「公司裡有用KPI，但老闆也想用OKR，這要怎麼辦？」 「OKR是不是要讓主管先學會？還是大家都要懂？」

拯救沒時間的第一個推薦練習：時間數據化

回想我的小孩剛剛誕生的上半年，那時候發現自己的時間被切割得更破碎，工作、家人、孩子、寫作，和許多我想做的事情，全部混在一起，我發現自己「感覺沒時間」去做每一件事情。有一小段時期，真的覺得自己什麼都完成不了，只能被時間拉著跑，雖然覺得很忙，卻一點成就感都沒有，只有許多事情沒時間去做到的壓力。你或許也有似曾相識的感覺？

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

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

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

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

吉高由里子教我的專案管理：免費的加班，造成更多隱形成本！

有些老闆總喜歡喜歡團隊加班，甚至喜歡凹團隊免費加班。但加班其實從來就不是免費的，加班費還不是最貴的，背後其實還有另一個隱形的經營成本在其中！

【課後心得】模擬商戰初階：不只在遊戲中搞懂經營，更是理解自己，克服人性弱點！

Bryan在課堂中提到了一個很有趣的比喻，在愛麗絲夢遊仙境這個故事中，愛麗絲問柴郡貓：「我迷路了，請告訴我，我應該走哪條路呢？」柴郡貓說：「這要看你想去什麼地方。」愛麗絲說：「我不知道我要去哪。」柴郡貓說：「那麼，你走哪一條路都可以。」，決策者必須很清楚地設立設定「目標」並誠實的制定出相對應的對策，就算無法一蹴可及，也應該在過程中訂定出短、中、長期的應對策略，確保能朝向目標前進。 目標並非不能更改，必須在途中配合實際的狀況不停的修正，才能夠到達目的地，最好的修正參考，就是一張張我們辛苦累積起來的財務報表。學習創業，第一好的方式，則是實戰，但成本很高。模

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

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

【課後心得】流程設計與跨部門溝通 : 同事有默契，就不需流程？那麼還沒默契的新人該怎麼辦？

課的過程中，還有一點也讓我覺得幫助很大。由於使用「火車鐵軌遊戲」作為實際演練的素材，這個遊戲是實際有火車在跑的，也就是會牽涉到真實空間（火車可能會勾到東西、有載貨限制、需要移動）、時間的問題（火車速度有限、難免會要等待）。 這個對應到如倉管這樣的問題時，很能令人感同真實世界的時空限制。當然，現實工作中可能還會遭遇到必須自己從零組裝鐵軌、安排鐵軌、甚至前線ＡＢ倉庫有容量限制等問題，這使得現實比遊戲更困難，但也更好玩。

爭議協商時，你也犯過「威脅開局」的錯誤嗎？

在我之前工作的公司，有一次在下午的會議上，我看到一個工程師的同事整場不發一語看似氣嘟嘟的。會議結束後，我就跑去問他是發生了什麼事情？他很生氣的跟我說。他呢，在早上跟附近的熟識早餐店買了一個三明治。到了公司，因為先回答了幾個客戶的電話沒能立刻吃，待等到後來一吃，發現味道有點酸酸怪怪的。他覺得自己也不過只是晚了約半個鐘頭才吃，問題應該不是自己這邊，於是中午吃飯時，就跑去找店家理論。我想，這也不是甚麼大事嘛。幾十塊的交易，應該很容易解決，沒想到結果完全不是這樣。

【專案管理書摘】關於利害關係人管理-集體開會，只會讓你的產品走向平庸

專案執行中，利害關係人的管理，始終是個麻煩的問題：他們界定專案成功與否、他們管理資源，但他們也常常因為意見紛歧、或是需求變動，而導致產品走向平庸，甚至難產。因此，有經驗的都知道，控制好利害關係人的需求，會是專案成敗的關鍵。但要如何在專案的初期，有效接觸利害關係人？又該如何了解這一堆人的不同想法？一個一個聊天，也太浪費時間了吧？

【課後心得】專案的談判與協商：看懂對手在意的點，想漲價想趕交期？一點也不難！

在還沒上課之前，其實我對於這類的協商，內心抱持的態度，通常是「我說了算」、「我是你的客戶我有量不然你不要做」、「我就做不出來啊，不然你想怎樣？」、「我不做我不賣你我最大」，當然語氣上沒有實際內心態度這麼偏激，或多或少也會跟對方周旋一下。就像這堂課的講師Joe說的，有時出發點不對，就會把協商導向了「分配型談判」，要嘛你聽我的，要嘛我聽你的「零和賽局」談判，往往會導致兩敗俱傷，就算我是贏的那一方，終究不過是贏了面子，輸了裡子。

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

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

【專案管理書摘】為何產品專案會失敗？團隊一開始就該避免的十個經典地雷

踩到地雷超痛的啊！如果想避免踩雷，最好一開始就先注意幾件事。像是產品路徑圖（product roadmap）一頭熱的那時，我看過無數的路徑圖，絕大多數的路徑圖，基本上是按優先順序來排列功能和專案。行銷部門需要那份圖推出宣傳活動，業務部門需要那份圖招攬客戶⋯⋯但問題就出在這裡，我稱為「產品的2 個麻煩真相」。