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

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

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

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

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

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

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

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

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

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

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

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

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

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