進階專案知識

成長思維團隊管理:請把這些想在 OKR 之前

最近接觸幾間新創公司,即便開始用了 OKR,卻仍然在目標管理、團隊成長上沒有顯著的改善,甚至有公司花了許多時間在溝通、釐清、評估,反而成長速度被拖累。說直白一點,很多團隊根本還沒釐清自己面對的是怎樣的管理問題,就急著導入外面聽到的時候覺得很棒的制度,是沒辦法解決問題的。與其一直從外面找答案,不如先靜下心思考一下,在真正開始導入某一種管理制度之前,先花時間了解一下你管理團隊的觀念上有沒有基本面的問題、組織迭代應該從哪邊開始,而我們又常常落入哪些管理的誤區。

到底是誰殺了敏捷?

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

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

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

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

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

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

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

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

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

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

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