最新文章

越忙,越要避免零碎溝通:工作上使用通訊軟體的3個省時技巧

最近幾次在大學演講,不約而同被問到一個類似的問題:「在用即時通討論事情時,常常覺得對方很沒有效率,討論很零散,進度很緩慢,對方的回應有一搭沒一搭,感覺彼此都會拖延到時間。」而面對一些重要的事情,或是自己很忙時,這樣的即時通討論,反而讓工作的效率降低。 在遇到上面同學的提問時,我都用了同樣一套方法來回答,核心精神是:「我自己不要發動零碎的討論,別人就無法零散溝通」,而在即時通討論工作上,則落實為三個技巧。

成為主管並不是晉升,而是轉換職涯:《優秀管理者的後天養成之路 》讀後感

FACEBOOK產品設計副總Julie認為,成為主管並不是晉升,而是轉換職涯,有些人是優秀的設計師,並不代表他就能成為優秀的管理者。我們也不該將「晉升管理職」跟「職涯成長」綁在一起。矽谷有許多資深工程師的薪水可以媲美執行階層,俗稱 10x Developer,他們可以一輩子鑽研他們最拿手的技能,在職涯路上繼續前行。她也認為,好的主管每天都該反省,你的理想願景(Why)、團隊(Who)、過程(How)。最簡單的測試方法就是隨機問五個員工:「我們的願景是什麼?」當他們全都給出一樣的答案時,恭喜你!你建立了一個清楚的共同願景。

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

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

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

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

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

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

你的專案裡,卡了許多現金嗎?

我最近隨手拿起書架上一版多年前的商管漫畫看,裡面的主角遇到的問題是,她負責的公司面臨倒閉危機,這間公司一條龍從成衣的設計、製造,到銷售,都一條龍包下來。但是由於銷售狀況不好,現金流不足,快要無法償付銀行的貸款利息。銀行端要求主角在半年內想辦法生出十五億現金還貸款,才不抽銀根,不然公司就要破產了。主角嘗試了很多方法,最後,她在實地探訪工廠時,找到了藏在裡面的「現金」,這個現金就是:半成品庫存。

只是持續做,不是好的習慣養成法!放下恆毅力,打破習慣鎖鍊

所謂的習慣,我們以為就是可以每天、定期做到一樣的事情。但只是「在堅持」的習慣,反而往往不是好習慣。把心智力量放在逼自己,很有可能適得其反。於是往往在其他壞習慣、其他需要運用心智力量去做的事情上,更加容易放棄、拖延。即使能夠一直堅持,但重複去做一件事,這件事的效力反而逐漸降低,樂趣也逐漸降低,最後就算成為習慣,也很有可能只是為了做而做。或許,不要把力氣放在堅持上?

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

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

要看一個主管的管理品質,就看他怎麼開例行性會議的

幾乎每個公司、每個部門都會有例行性會議與報告,但如果,你希望把管理做得更到位,那例行性會議對你來說就非常關鍵,重要性甚至遠高於月會。其實例行性會議就是團隊運作的縮影,這是團隊慣性,騙不了人。你相信嗎?只要改變例行性會議的報告內容、進行方式與跟進工作,團隊的整體能力也會有大幅度的提升。這就是我常講的「管理槓桿」,從小的改變來撬動大的變化。

進階的管理人才,是怎樣解決困境的?

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

到底是誰殺了敏捷?

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

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

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

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

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

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

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

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

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