短期與長期目標如何有效平衡?

短期與長期目標如何有效平衡?

在企業管理上,若要針對最棘手的問題排名,我相信如何決定優先順序,如何平衡長期與短期策略一定排在前三位。

針對這個議題,很多的商業或管理書籍都有探討,但始終缺乏一個很有效的決策框架來協助企業判斷該怎麼做才正確,因為這件事涉及到的因素非常多,企業的財務狀況、風險承受能力、所具備的資源、企業的發展階段、產品組合、短期市場的波動、長期市場的預測、管理制度的健全、企業領導階層的素質等,若只影響單一個項目或許容易判讀,一但這些項目都攪和進來,處理的難度就很高了。

我本身有個框架可以協助企業做有效判斷,但本篇我先針對長/短期策略之所以難以平衡的原因,以及有哪些基本的原則可以協助我們簡化任務的優先順序問題,進而做好長短期的平衡。

企業遭遇的現況

2015 年時我到一家 7*24 小時運轉的互聯網公司上班,到職時,我就發現團隊花在「救火」的比重過高,真正處理重要專案的時間嚴重不足。當時團隊成員們對既有系統,規劃了許多需要優化的地方,但往往不敵緊急案件的壓力。

重要的專案一再 pending,所有人都忙於不處理就沒業績,不處理客戶就退錢的案件。

到後來根本不分輕重緩急、優先順序,只要業務或客服轉來案件,就馬上派人處理。這段時間以來,部門既沒有進步,到年底也無法拿出績效。

我與團隊討論這個問題時,大家給我的說法是「沒辦法,業務那些問題不處理會出大事」、「這家公司是業務導向,業務說話最大聲」。大家反應的都是事實,也是現況我們遭遇的困境。

我說:「這些我都理解,但即使我們拚了命的應付這些緊急需求,拼命的用 workaround 的方式處理問題,我們何時才能去做有價值的事?我們又何時才能脫離現狀,搞出一些好東西?」

我說我們需要立即做出調整,但當時團隊總覺得我的說法太理想了。

但我接著調整了團隊的工作方法,首先與業務部總經理洽談,敲定專案的優先順序,承諾我們會準時交付排序最前面、最重要的幾個專案,並兼顧短期的緊急案件。

當時我們團隊有 6 個工程師,我將 4 個配置在專案開發,2 個配置在處理緊急案件,初期因為人力限縮,但緊急案件沒有減量,2 位處理緊急案件同仁被迫只能處理部分案件,有些案件要跟業務部門協調緩緩,但這樣的舉措也引發大家開始思考,重新聚焦於真正重要的事情上

而事實證明,即便只有 2 位同仁處理緊急案件,日常營運也並沒有因此受到太大的影響。

與本來相比,我們大幅減少了處理緊急需求的人力,將資源放在處理技術債與重要的專案開發工作上。

不過團隊資源還是難以應付公司成長的需求,所以我們需要在短時間內近快擴編團隊,當時我要求團隊一個禮拜得安排 20 個以上的面試,也就是說我們得在這麼忙碌的狀況下再花 20-30 個小時面試,當時部門內有兩位資深同仁提出建議,他們希望招募的工作可以緩一緩,先讓他們專心把專案趕上

我告訴他們:「需求只會變多不太可能減少,現在一定得招人,兩個月後我們才有機會變得更好,這段時間可能得辛苦各位。」

不論是將資源配置在長期的專案上,而限制短期需求的可用資源,或者是強調長期的人力資源,而選擇短期咬緊牙關撐過去,這都是一種優先順序選擇。

長/短期策略平衡的困難點

長短期之所以難以平衡,我認為最主要的原因有幾個。

第一個原因,長期與短期的目標是有衝突,假設企業有一個成熟產品,與一個正在開發中的新產品,新產品的目的是為現有產品的衰退做準備,簡單的說就是第二曲線的概念,但短期內企業的營收還是由成熟產品所肩負,而成熟產品的目標是營收成長,這對企業來說算是短期目標,而醞釀中的產品目標則是準時上市,這是稍微長期一些的目標。

當成熟產品的業績達成狀況不佳,或者有個大客戶因為產品出狀況想要退貨,身為老闆的你會不會立即將負責新產品的人力資源拉過來處理成熟產品的問題呢?我想機率應該很高。

但這麼做,就讓新產品的準時上市產生了變數,這是一個很明顯的遷就短期而犧牲長期的案例,而這樣的決策之所以有問題就是因為短期與長期的目標是不一致的,如果今天兩個產品的目標都是為了營收,先投入資源在哪邊的問題就不大了

第二個原因,短期的目標的達成對長期目標並沒有直接幫助,如果今天短期目標是圍繞長期目標而展開的,也就是說做好短期目標,長期目標也會直接受益,做決策的難度就沒那麼高,很可惜的是絕大多數人並無法很好的作長短期的銜接,短期的努力對長期沒有帶來正面助益,因此兩者之間互相爭奪資源也成了一種必然。

第三個原因,沒有人同時為長期與短期目標負責,如果要問企業內誰同時為長短期目標負責,那大概就是老闆或 CEO,除此之外,沒了。不用懷疑,你的業務主管只為短期業績負責,但他可不負責新產品能否在一年後上市;你的專案經理也只為了近期的專案能否上線,客戶反應的問題是有按時處理好負責,基本上也不是那麼在意產品是否持續有競爭力;研發部門主管則只在意目前研發的項目能否順利產品化,對目前公司的業績狀況其實不太在意。

關注長期的人,不對短期負責,負責短期的人,其實不在意長期,除非,長期的時間點近了,變成短期時,這個狀況才會改變。

第四個原因,缺乏有效評估長短期目標價值的方法,很多人或許覺得難以排出優先順序的關鍵是沒有方法,但我認為這最多就排在第四位而已,方法我就有,但給你之後你解不了前面三個問題,最終還是會落入無法決策的困境中。

三個動作,有效平衡長/短期

前面談了這麼多長短期平衡的困難,那究竟有沒有什麼解法能解決上述問題呢?當然是有的,總共有四個方法,往下我分別一一講述。

投資在不變的事物上

Amazon 的 Jeff Bezos 在一次演講中講到:「人們經常問我:未來 10 年什麼會被改變?我覺得這個問題很有意思,也很普通。從來沒有人問我:未來 10 年,什麼不會變?在零售業,我們知道客戶想要低價,這一點未來 10 年不會變。他們想要更快捷的配送,他們想要更多的選擇。」

還記得 Amazon 的成長飛輪嗎?Jeff Bezos 提到,如果要投入資源,應該盡可能把資源投資在那些 10 年後也不會改變的事物上,就零售業來說就是低價、快速配送、無限選擇。

當你將資源盡可能投入在不變的事物上,你會發現一件神奇的事,那就是你現在投入的資源,對 5 年、10 年後都是有幫助的,此時不就讓長期與短期有效銜接在一塊了嗎

而尋求 10 年不改變的事物,並將資源投資在這些事物上,這是 Amazon 做決策的依據之一,而有清楚的決策依據,在公司內不也相對容易獲得共識,有共識,對於策略的選擇與排序就相對容易許多。

找出資源槓桿點,將資源投入在槓桿點上

如果公司現在有三個團隊,每個團隊都有一個目標在,而這三個目標彼此之間是互不相關的,那你會如何決定資源的配置呢?

第二種狀況,一樣有三個團隊,而這三個團隊的目標之上是有一個共同目標的,例如營收,A、B、C 三個團隊做的是基本上都是為了營收,此時我們比較容易以 A、B、C 團隊的目標對營收的貢獻來決定資源配置,而這也是多數企業在面對營收議題時的資源配置方式。

第三種狀況,一樣是三個團隊,三個團隊也有共同目標,此外,A 團隊在做的事情可以同時對 B、C 兩團隊目標產生幫助,而B團隊做的事情則會幫助到 C 團隊的目標,此時你會發現把資源投入在A團隊的任務上或許是相對有效益的,因為做一件事可以同時對三個目標產生效益,而這就是我所說的槓桿點

我先前曾用企業的數據脈絡當範例告訴大家怎麼找出管理的槓桿點,以下圖為例,我們發現 60% 完食率這個指標會直接影響到服務滿意度、回購率與推薦率,此時 60% 完食率就是所謂的槓桿點,我只要能改善這件事,我就能同時達成多個目標。

當我們能將這個數據脈絡畫出來,就有機會找出經營上的槓桿點,當大家對槓桿點取得共識,排優先順序跟調動資源就變得簡單許多。

到這邊,你會發現上述兩個做法都是為了有效解決長短期不一致或者衝突的問題,而這也是我過去使用過相對有效的方法。

這邊也推薦閱讀另一篇文章:

數據力:績效指標管理的核心觀念
上上禮拜被問了一個關於學習過程的指標設計的問題,我才發現很多人其實並不知道如何正確的設計指標,其實指標的意義並不僅僅是一個數字,好的指標設計是可以協助我們理解現況、找出問題並校正方向,本篇的閱讀與理解可能會花上 30 分鐘,但如果你有以下幾個問題,我相信你會有收穫的。 1. 看了很多 OKR 跟 KPI 的文章還是不知道如何有效的設計指標 2. 訂好了指標,但管理還是卡卡卡,總是找不到關鍵問題 3. 跨部門時,大家都只顧自己的 KPI,時常要開一大堆會 4. 組織愈大,管理愈來愈複雜,到底是團隊問題還是我的問題? 花點時間看這篇文章,我相信上述問題在這篇文章中都有解。 指標管理的基本觀念 本篇的開頭,我想先跟大家聊一個重要的觀念,那就是領先指標( leading indicator )與落後指標( lagging indicator )。 領先指標與落後指標 落後指標基本上都是結果,例如業績表現、服務滿意度、品牌知名度等等,而多數公司的 KPI 其實都是落後指標;那領先指標是什麼呢?基本上就是在一件事情發生前的早期徵狀,

逐步交付,讓長期目標創造短期價值

長期目標之所以讓人難以下定決定投入,而是將資源配置在容易判斷的短期目標上,很大一部分的原因就是長期目標要投入的資源與時間太長,而且短期看不見效益,長期也不見得能獲得理想的成效,如果我們可以針對這個問題來解決長期目標的困難,或許就能有效的解決此問題。

解決的方法其實就是敏捷的核心,逐步交付,盡快創造價值,如果我們能將一年的目標拆成四個部份,那每三個月我們就能有成果交付,如果再進一步拆成 12 個部分,試著在每個月都交付一部分價值。

此時長期目標就變成 12 個短期目標,當彼此所需的時間接近,投入的資源也相去不遠時,這 12 個由長期目標拆出來的短期目標就可以直接跟其他短期目標競爭資源,因為它們也能在短期內創造價值

讓長期目標做為指導方針,而日常作業則以短期目標為主,但讓長短期目標有效的銜接在一塊,能做到這樣,基本上企業在做長短期選擇時一般會容易許多。


別過度放大短期的影響

當我在溝通長期的重要性時,很多人經常會放大短期的風險,例如「活下去比較重要」、「能賺多少是多少」、「把人拉走營收會掉」、「客戶會客訴」。

這其中有多少是真的,身為經營者你得做出判斷,但就我過去的經驗來說,多數的調整並不致命。

如前方的案例,我將投入在短期任務的工程師從 5.5 個縮減到 2 個,這對業務團隊帶來的衝擊微乎其微。以前是所有的任務都很急,5.5 個工程師都能努力在當天處理完,但是經過排序,只保留當天非得處理完的任務,那 2 個工程師其實綽綽有餘了。

再舉個例子,到底是要將資源投入在研發新產品,還是現有產品的開發上?過去大家總習慣投入過多的人力在現行產品上,一來因為需求較具體,二來則是多數部門的 KPI 都壓在現行產品上。新產品現階段跟多數人是無關的,所以當我們提出要將資源挪去開發新產品時,多數人都是反對的。

但我的溝通邏輯也很簡單,請大家盤點現行產品需求的價值,並對應回產品的年度目標,如果目標是營收,那請按對營收影響大小來排序,如果目標是客戶滿意度,那一樣按對滿意度影響大小來排序。而我們應當只著重其中的 3-5 項做開發,並為此保留必要資源。

關於價值的衡量,可以參考這篇文章:

量化需求價值的 7 個步驟
在軟體開發的世界裡,有一個經常被提起的難題,那就是如何有效的量化一個需求或一個專案的價值。在數據脈絡中,我提到,如果今天我們能找到價值衡量的基準,我們就能有效地進行手邊任務的排序。 但這個基準怎麼設計,又該怎麼獲得大家的共識呢?是否有一套結構化的方法呢?有的,本單元我就來跟大家好好介紹一下過去我是怎麼做的。 企業的優先順序是如何被決定的? 過去經驗裡企業決定專案順序的方法通常有三種:權力決、數據決與共識決 第一種,權力決,通俗一點來說,就是由權力大的人來決定,排第一的通常是老闆或業務部門最高主管。權力決有另一種變形,那就是讓承擔該業務的主要負責人做決定,例如產品經理決定產品優先順序,業務主管決定業務需求優先順序。 權力決得好處在於,讓應該承擔責任的人來做決定,做對做錯他一力承擔,很容易究責,但缺點也是顯而易見的,決策過度集中,且決策的優劣仰賴一人之智,萬一他不是那個適合的人怎麼辦? 第二種,共識決,由大家共同決定專案的優先順序,嚴謹一點的甚至會成立一個委員會來定期處理此事,讓決策從一個人身上移轉到一群人身上。好處是決策因參酌了較多人的意見,會變的比較客觀,但缺點是,當大家

這種做法對現有產品的 KPI 衝擊大多在 10% 以下,如果這 10% 是可承受範圍,那就勇敢地做決定,把其他資源保留給長期吧。

「維持現狀,一年後會是什麼樣子?」

對於那些明知應該投入長期,但卻又不願承受短期風險的朋友,我經常會問一個問題:「你繼續維持現狀,那一年後狀況會有所改變嗎?」

多數只看短期而不看長期的團隊,他們早就困在當前的焦油坑好一段時間了,可即便他們知道正在犯同樣的錯誤,他們仍然一如既往地堅持重複過去。

與其如此,不如趁早覺醒,認清這種作法只是在自欺欺人,短期咬牙,預見一個更好的未來吧。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

[徵才]方圓國際誠徵兩個新職務

[徵才]方圓國際誠徵兩個新職務

今年四月份,我加入了方圓國際擔任策略長,方圓是一家茶飲連鎖公司,旗下有兩個主要品牌「吃茶三千」與「喫茶小舖」。吃茶三千在海外 30 多的城市有約 130 家門市,喫茶小舖在台灣則約有 60 家門市。 我從去年底開始擔任方圓的顧問,主要協助梳理公司的管理制度、流程與阻礙成長的問題。四月份我轉任策略長,過去這一個多月,我除了 AI 的引入與建置外,我也花了大量的時間重新構思公司的整體策略。 我們進行了「未來十年不變的事」的策略探討,最終設定了十年戰略方向,三年目標,以及 2026 年的關鍵任務。 透過這樣深度的策略思考,我們也藉這個機會盤點了公司目前的人才缺口。 以下有兩個很關鍵的角色是我迫切在找尋的。如果你覺得自己或身邊的人很適合加入方圓,請自薦或推薦給我,謝謝。 歡迎將履歷投遞到:gipi@teashop168.com.tw 門市體驗經理(Store Experience Manager) 門市是接觸終端消費者的最後一哩路,也是品牌傳遞價值的關鍵接觸點。我們在全球因應不同的市場有不同的店型設計,

By gipi
克服 AI 焦慮的方法,唯有實作

克服 AI 焦慮的方法,唯有實作

2018-2019 年左右,線上學習在台灣整個大爆發,線上課程一大堆,每個禮拜都有很多線下學習活動。每天都可以看到大量的學習心得與活動心得,每個人講的內容都很有道理。全台灣好像瞬間變成一個知識島,所有人都學識淵博,而自己似乎懂得有點少。 知識焦慮年代 在那個時候,很多人染上了「知識焦慮」的病症。 害怕別人知道自己不知道的,擔心自己沒跟上世界的節拍,所以哪邊有新知往哪兒去,哪邊學習氛圍濃厚就往哪兒鑽。看起來是因為熱愛學習,但內心的煩惱其實是「害怕失去」。 害怕失去話語權,害怕失去社交談資,害怕失去機會,害怕失去競爭力,害怕自己不再是別人眼中領先的族群。 而克服焦慮最有效的方法,不是知道更多,而是實踐,從時間中獲得成果,獲得進步。 那些仍在學而沒有做的人,焦慮是無法停止的,因為他並沒有真的改變現況。 這也是當年為何我們想舉辦 case study、學習營、打卡、案例練習,並且鼓勵大家多多輸出的原因了。因為輸出,其實就是最輕量的實踐,而動手做,則是讓自己學有所用的基本配備。 在那個知識焦慮的年代裡,因為我本來就熱愛學習,也經常輸出,

By gipi
我如何與 AI 協作開發,我的開發步驟分享

我如何與 AI 協作開發,我的開發步驟分享

昨天到工程師場子分享,想說跟大家對照一下,現在是否多數人都跟我一樣,寫程式完全不手打任何一行 code,全部都是 AI 做的。 結果發現,現場只要有在用 AI 開發的人,多數時候真的都是讓 AI 來完成程式撰寫工作。 目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare,其他還有根據程式功能需要而使用的第三方元件。 做一個新系統的習慣是: 1. 跟 Claude 討論我想解決的問題,以及我的核心需求,中間我可能會用 Claude Cowork 做本地資料的分析,然後請他廣泛收集一下資訊,做幾輪 prototype 的模擬。確認方向是否是我所期待的。 2. 對完需求後,請他產出系統定位、限制、邊界與 PRD。 3. 把 PRD 跟幾個

By gipi
加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi