關於「留才」的三個思考與五個關鍵做法

前陣子在一堂課程中被問了一個問題：「如果今天有個員工想離職，但你想留他怎麼辦？」我說：「這個問題可能問錯人了，因為我幾乎不太會去留人。」說到這，可能會有人誤以為我不重視人才，實際上我對人才的培養與發展非常在意，只是我處理的方式並不在員工提出離職的那個當下，而是在日常的工作中。

接手新團隊，該先做什麼？空降經理人該注意的幾種難題及解法

新創企業成長到一定程度，董事會或老闆發現團隊的能力缺陷，需要由外部專業人才補足，以確保公司承諾投資人的目標，舉凡成長曲線、團隊穩定、HR 制度優化等等。偏偏這時候公司又被迫著要繼續高速成長，這時候老闆開始找方法，要嘛請更多能執行的人來完成更多不明所以的專案、要嘛就請個經理人一起解決問題。我自己的親身經歷是，一方面上頭給你的期待目標絕對不會太容易；另一方面空降到一個新的環境、突然就成了最高主管，底下的成員一時間也不知道該不該相信你。當下眼前面對這個「期待」跟「信任」的落差，真的會讓你輾轉難眠久久不能自己。

讓老闆很期待，員工卻怕受傷害的一張表單：工時單

工時單是個不錯的構想，對公司與員工都有好處：公司可以掌握真實的人力成本，對提案報價有好處；員工也不會過勞，因為主管能從工時單看到真正的工時分布，進而合理地分配工作。然而這都是理想狀況，所謂理想很性感，現實卻很骨感，在多年的顧問生涯中，我也目睹了不少怪現象

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

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

到底是誰殺了敏捷？

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

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

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

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

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