萬惡的KPI
萬惡的KPI
2016.05.23 | 創業

本文作者曹政,原文刊載於微信公眾號:caoz的夢囈,《數位時代》獲授權轉載。

##1、KPI的緣起

用最簡單的描述就是,KPI來源於工業化的年代,車間工人,業務代表,你很容易設計一套數據指標,來考核他們的工作績效和工作質量。而傳統的管理學又將這裡的指標更加地細化,分出不同的條目、類別,以實現更精確的管理和考核,這一切的基礎是,你的工作目標,是完全確定的,而你的工作成果,是完全可以量化的。

##2、新時代的問題

在網路時代,或者說更早一點,在IT崛起的時代,我們應該意識到一個巨大的變革來臨了,工作的價值往往不在於工作量和勤奮程度,而在於員工的創造力以及一些方法論的東西。而工作目標也會隨著市場的變化快速的調整和迭代,人與人在才能和表現上的差距也會無比放大,在這種情況下,**繼續去苛求量化方法,或者強求去制定一些標準,往往產生南轅北轍,與目標相反的結果。**而這些,其實不斷的扼殺一些企業的創新能力,並持續低估一些傑出員工的價值體現。

前天的文章,談談激勵的原則。有些人表示看不太懂,但也有一些作為企業管理者表示非常需要,昨天文章剛發出去不久,就有極為優秀的遊戲製作人來詢問我關於激勵體系的問題,實話說,我並沒有太好的方案提供,但所遇到的激勵體系的問題,確實是很多企業共有的。

下面,我們說一下典型的KPI問題,先從技術領域說起。

####1、以工作量為考核目標。

圖說明
圖片來源:Streetwill

據說某公司用程式碼行數作為考核目標。

這個策略實際上是激勵大量的垃圾程式碼,優秀的程式碼都是簡潔優雅的。參見雲風老師的 skynet開源程式碼。如果考核員工的程式碼行數,菜鳥工程師絕對開心,你不需要考慮架構,不需要考慮複用,大量的copy & paste很容易堆砌大量程式碼,我在最初編程的時候,也會有這樣的習慣,把以前的程式碼直接貼過來改寫,而這實際上是複用性很差的表現。

####2、以解決問題為考核目標,比如處理實際問題數,修補bug數。

這個聽上去合理一些,但我以前舉過這樣的例子,兩個專案組,第一個組長水平很高,寫出來的專案程式碼非常穩定可靠,上線後啥問題都不出,專案團隊變得無所事事。第二個組長,稍遜一些,寫出來的專案程式碼上線後,經常出一些奇怪的問題,結果疲於奔命,各種加班,各種救火,結果第一個小組團隊全部被調往第二個小組支援,第二個小組組長因卓越的工作積極性,大量的問題處理表現,和持續性的加班奮鬥而被領導賞識,升職,第一個組長只能作為其下屬。

很多企業都會犯這樣的錯誤,這樣的案例其實也有不少。

####3、以專家小組的考核為準。

技術的事情,讓技術專家去評定,有些大公司有非常優秀的技術專家,就組成評委會,技術工程師需要申請升級的時候,去報告自己的工作表現,所使用的技術,所完成的工作量,所達到的目標,技術專家根據其表現決定是否升職加薪。聽上去很合理對不對?

然而並不是,十年前,我遇到過這樣的問題,我需要處理一個線上的問題,這個處理方案不複雜,按照我的方案做很快就能完成,和我搭配的工程師人蠻好的,水平也很高,但是就跟我抱怨了,「對不起啊,我上次評高階工程師沒過呢,說我工作技術價值太低,這個方案我工作考核肯定上不去啊,我有個什麼什麼算法,你看行不行。」咳咳,都是打工族,你好意思難為人家嗎?本來一兩天的事情,做一兩週,說實話,這還是非常照顧產品需求,很容易溝通的工程師,如果有那種非常自我為中心的,出個一兩月的技術方案你也沒轍啊。

今天我說一句可能有些人不服氣的話,很多大公司,存在大量技術過剩的情況,就是因為這種技術考核體系,小題大做,沒必要的技術方案,沒必要的過度架構,很多是為了滿足技術評級和升職的需要,而這一切,除了人力和資源的浪費外,更導致了產品迭代緩慢,市場應對能力緩慢。

其實我們看很多新創小公司,乃至個人,可以很短時間內發布很有意思的產品,包括一些hackathon的活動,36-48小時做出來的產品也都有模有樣,但是大公司做一些同類產品動輒幾百人團隊,半年以上時間,有人會說,大公司性能要求高複雜度高,懂不懂?呵呵,這個我還真的略懂。

而更可怕的是,某些管理職能的人為了能升職,一些本來不需要很多人的崗位,也要硬掰出一堆工作任務來,招一堆人來滿足一些根本沒太大實際意義的事情,手下人多了,自然職位也就上去了。

####4、基於犯錯率考核

這種思路是,考核你工作中出現的問題數,bug數和相關故障數。
嗯,其作用大家都知道,多做多錯,少做少錯,不做不錯。
吶,工程師都已經習慣背黑鍋了。

####5、基於團隊目標

恩,單獨的技術實在難以考核,只好基於團隊目標,和你的專案團隊共進退,雖然存在不公平,比如優秀的技術如果配到了一個不靠譜的產品經理手裡,可能就被拖累了,但是好歹也是一種弊端較少的方案了吧。

然而,我們知道,大公司最怕的是什麼,部門藩籬,有些熱心的技術強者,願意和更多人分享,願意幫助其他人分析問題,解決問題,願意輔導更多年輕人,然而,這一切,都沒有任何激勵。很多大公司在KPI的導向下,部門利益高於公司利益,甚至不同部門明爭暗鬥,搶專案,搶資源,搶話語權。如果有個人才,是以公司利益為重,甚至願意為了公司利益犧牲團隊利益(有些情況下是需要的,比如,公司有個特別重要的專案,比這個部門當前的專案價值大很多,一個優秀的技術,在與本部門管理者溝通確認後,去緊急支援人家的專案,就比按時完成本部門專案,對公司價值更大,我個人是非常鼓勵這種行為的),那在這種考核目標下,簡直就是要被淘汰的典型了。

可怕吧。

技術職位不好評定,那麼其他職位呢,設計師類似技術人員,做的多不如做得好,一個好的設計,勝過1000個平庸的設計,然而好這個評定,如何定量?

在產品和設計領域,KPI的問題在於,只能考核已知的東西,如何評估未知的東西,而網路產業,IT產業,要經常面對未知的場景,提出新的觀點,新的構思,和新的產品特性,那麼,在這些東西提出來之前,我們的KPI原則是什麼,每個月遞交幾份ppt報告嗎?

所以,在西方有個說法,KPI= kill people idea,你照上司吩咐的做就是了,KPI沒有任何關於想法和創造力的評估手段。

我另一篇 狼,兔子,激勵 也提到一個話題,

前端時間有個老闆最喜歡的大毒草雞湯,叫做寫給加西亞的信。別管我的要求多麼過份,別管我的方向多不靠譜,別管我到底想明白了沒有,你們做到了就是狼,做不到就是兔子,就算我是智障,你們也要把公司帶得轟轟烈烈,幫我賺錢,這就是各個老闆熱衷的狼性文化。

圖說明
圖說:Streetwill

今天重講一下這個話題,在完全以目標為導向的體系裡,就會出現一個嚴重的問題,就是為了目標不擇手段,而這種不擇手段,很可能是犧牲企業長期的信用,或者犧牲的是產品的可持續發展能力達到的,而這一點,也是非常多網路巨頭一直在犯的錯誤。

案例說話:
當年,易趣和淘寶打架的時候,易趣買了百度的「易趣」關鍵詞,淘寶沒有買「淘寶」的關鍵詞,這事我就很好奇,我覺得這個詞易趣不買也是他們的啊,自然結果本來就是他們自己的,為什麼要花這個冤枉錢,後來別人給我一解釋才明白,我有多幼稚。廣告購買是市場部門的行為,廣告轉化率是市場部門的KPI,大家都知道品牌詞的用戶銷售轉化率是最好的,購買這個詞,所帶來的客戶轉化都能提高他們市場部門的KPI表現,如果是自然搜索流量,對不起,和市場部門業績毫無關係。那麼淘寶的人說,我們不要這種KPI。

再說遊戲產業,那麼遊戲營運團隊,製作團隊,以遊戲收入為指標分紅,聽上去是一個相當靠譜和準確的指標了,但是這裡就沒問題了嗎?

有,而且很嚴重,實際上,大部分打工者,都比較看重短期的回報和效果,這很正常,誰也不確定自己能否在一個公司待多久,此外,誰都希望短期業績好看一點讓老闆賞識,也許就此升職加薪呢,長期的事情誰知道。所以就會存在一個問題,以犧牲產品的生命週期來刷收入,中國的遊戲產業,這個特徵冠絕全球。從業遊到手遊,中國的遊戲收入高峰能堅持六個月的都寥寥無幾,很多月流量過億的產品三個月後就剩下兩千萬不到了。 coc一款產品的生命週期,我們這邊對應的可能換了七八代主打產品了,問題是人家還在繼續稱霸排行榜呢。

我最近也有這個煩惱,給團隊按業績分紅是公司的原則,但又不能鼓勵那種衝流量的活動。這就不是規則所能控制的了,必須靠人的判斷力。

昨天那個朋友跟我分享的案例是,某個優秀公司的原則是,用業績分紅的方式沒問題,但是所有遊戲內活動安排都必須CEO親自審核,以免有過度的充值活動犧牲產品生命週期,問題是,這個CEO必須很懂業務啊,而且必須熟悉所有產品才行。所以,想要複製,還是很難。

那麼,問題這麼多,公司是否說,就不需要KPI了呢?或者說,有什麼更好的方法嗎?

其實,IT產業優秀的新創公司,初期都是沒有KPI的,我們看一些成功企業的發展史,在最早期的時候,都是靠一些天才的產品和技術,快速發展壯大,在網路產業,沒有哪個成功的企業創業初期是靠管理優勢的。直到人員膨脹,老闆已經無法直接面對所有員工的時候,管理的意義和重要性才凸顯了出來。而此時,引入職業經理人,引入績效考核制度,才被提入日程,這時候,你要說完全杜絕KPI,自由發揮,可能也不現實,畢竟缺乏自制力和目標感的人在職場佔據多數。

KPI的意義在於,約束平庸的員工,以提升他們的執行力,而不能用於去規範優秀的人才,如上的案例,很多時候,KPI的激勵,對於優秀的人才而言,反而是負面的。

往下滑看下一篇文章
AI讓軟體開發更快,誰來接住「上線之後」?諾德資訊以Production as a Service補上最後一哩
AI讓軟體開發更快,誰來接住「上線之後」?諾德資訊以Production as a Service補上最後一哩

2026台灣設計展於9月24日至10月11日在桃園登場,以「桃園流」為主題,結合千塘之鄉的水文地景、國門之都的航空與物流優勢、多元族群文化匯流,以及 AI 科技應用,展現城市運轉的動態美學。

其中,為提供民眾不同於以往的互動體驗,AIoT 智慧感知大數據平台服務商棋苓(Chylyng)推出全展區 AI 穿戴互動體驗「FLOW CHECK」。參觀者配戴主辦單位提供的智慧手環後,可沿著展場動線於不同站點進行互動。即使多人同時參與,每位參觀者仍可依照不同的路徑、選擇與互動節奏完成體驗;系統並依據互動過程與結果,即時生成專屬的 Flowmomo 數位卡牌,讓參觀者儲存並帶走屬於自己的展覽體驗紀錄。

看似簡單的手環互動,背後其實是一套整合穿戴裝置、即時感測、場域互動、資料處理與雲端服務的完整系統。尤其在大型公開展覽環境中,不僅必須因應大量參觀者於短時間內同時使用,也必須確保從手環感測、站點互動、資料傳輸到最終結果產出的每一個環節,都能維持即時且穩定的服務品質。

棋苓以自主開發的 Eleplo AIoT Platform 為技術核心,整合穿戴裝置、感測設備、人員與資產定位,以及即時事件與資料管理,並負責建構 FLOW CHECK 的手環互動邏輯、站點應用、卡牌生成及參觀者操作介面。

專業分工合作:諾德資訊坐鎮後端,撐住大型公開展覽的服務韌性

為了讓系統從開發與測試環境順利進入大型公開場域,並進一步提升正式服務的可用性、資安與系統韌性,諾德資訊與棋苓採取專業分工合作。棋苓聚焦於 AIoT 平台、穿戴應用及使用者體驗;諾德資訊則負責後端基礎架構、正式環境部署、壓力測試、高可用性驗證,以及服務上線後的系統與流量監控。

由於展場現地部署時間僅有兩天,雙方將大量驗證工作提前至開展前完成。諾德資訊於正式開展前約一個月即建置專用測試環境,讓棋苓的應用服務提早與正式營運架構整合,並進行壓力測試、高可用性驗證及異常情境測試,使原本必須於現場進行的系統驗證工作大幅提前完成。

諾德資訊業務開發經理邱柏瑞表示:「FLOW CHECK 的挑戰在於大量參觀者可能集中於同一時段使用手環,因此除了確保服務穩定之外,也必須辨識進入系統的流量究竟來自真人使用者、合法自動化程式、AI Bot 或惡意攻擊,並透過即時監控及早發現異常。」為此,諾德資訊導入 IntelliFend Bot Management,協助辨識真人使用者、合法自動化及異常機器人流量,並於展覽公開服務期間透過遠端監控,持續掌握主機、資料庫、應用服務及外部流量狀態。

此外,為驗證系統在大型展覽情境下的承載能力,正式展出前,諾德資訊亦協助棋苓進行大規模壓力測試,模擬最高約 3 萬人同時使用的流量情境,提前觀察系統資源使用狀況、服務反應與可能的效能臨界點,並據此進行相關調校。

透過棋苓在 AIoT、智慧穿戴與互動應用上的技術能力,以及諾德資訊在正式營運環境、資安、壓力測試與維運監控上的經驗,雙方在展覽正式開放前,即完成從應用層到基礎架構的完整驗證,讓 FLOW CHECK 能夠在大型公開場域中穩定提供即時的 AI 穿戴互動體驗。

諾德資訊
諾德資訊業務開發經理邱柏瑞表示,FLOW CHECK展前模擬約3萬人同時在線情境,並即時辨識流量來自真人、Bot、AI或惡意攻擊,提前掌握系統臨界值。
圖/ 數位時代

AI加速開發腳步,但也增加「上線」考驗

從生成式AI到代理式AI,軟體開發速度快速提升,過去需要長時間才能完成的產品原型(Prototype)與概念性驗證(PoC)專案,現在可以很快完成驗證,讓軟體商有更多時間跟資源投入客戶需求、產品創意與使用體驗。

但是,從PoC走到Production,面對的是完全不同的考驗。
諾德資訊技術長張家榮解釋,進入正式環境(Production)後,軟體服務必須面對真實使用者的流量、不同客戶的IT環境、計算資源擴充、資料庫負載、網路連線、資安攻擊,以及服務異常時的切換與處理,就算在壓力測試時表現正常的系統,也可能在Production的時候出現問題。

更值得特別注意的是,AI不只讓開發者更快,也讓攻擊者發現漏洞的速度加快;過去,服務上線後還有時間慢慢觀察、修正,現在,服務一上線,可能很快就遭到掃描甚至攻擊。

也因如此,軟體商、系統整合商選擇基礎架構夥伴的條件開始改變,從過去關注功能與價格轉向:產品能不能順利上線?出了問題誰來處理?面對流量變化與資安風險,服務能不能持續運作?

張家榮表示:「諾德資訊可以提供從公有雲、私有雲、地端、邊緣運算、主機代管、網路,到維運與監控等服務,讓軟體夥伴可以將資源集中在應用與客戶需求,無須擔憂Production議題。」

諾德資訊
諾德資訊技術長張家榮指出,公司可提供從公有雲、私有雲、地端、邊緣運算、主機代管到維運監控的完整服務,讓軟體夥伴無須擔憂Production議題。
圖/ 數位時代

不僅提供資源,諾德資訊將Production變成一項服務

而這也是諾德資訊會提出「Production as a Service」的原因:不是在提供另一種雲端或主機服務,而是將軟體從開發走向正式營運所需的Production流程,轉化成可以被專業分工、驗證與持續維運的一項服務。

「Production as a Service不是單純把主機或雲端資源租給客戶,而是共同檢視這套軟體能不能順利上線與正常營運。」邱柏瑞表示。

實際做法包括,在上線前協助檢視架構,建立與正式環境相近的測試環境,確認系統正常狀態、最大承載量與資源需求,並驗證高可用性、資安、備援及服務切換機制;上線後則持續監看服務狀態、容量與流量,及早發現異常並處理。

諾德資訊之所以有這樣的服務能力,可以歸結為三點:

第一,長期累積的基礎架構與維運經驗,目前,諾德資訊同時服務的客戶數近30家,應用情境涵蓋IoT、購物平台、遊戲、音樂等不同類型的軟體服務。

第二,諾德資訊將每一個客戶遇到的問題與解決方案收攏至知識庫,讓團隊成員可以快速處理、借鏡,滿足客戶需求。

第三,依循ITIL的維運精神,並具備ISO 27001等資安相關認證,將服務流程、操作紀錄、備份、監控與異常處理等機制內化到服務之中。

這也是諾德資訊與單純提供雲端、IDC或主機代管服務的業者之間的最大差異:交付的不僅是基礎設施,而是讓服務持續運作的能力。面對客戶同時使用公有雲、私有雲、地端與邊緣運算環境,諾德資訊另以 MQloud 提供統一管理,把網路、防火牆、流量、監控與帳務收進同一套平台,降低跨環境營運的複雜度。

「軟體商負責開發,就像晶片設計公司;諾德資訊則負責協助完成測試、製程調整與正式生產,讓產品真正走向市場,希望成為『軟體界的台積電』。」張家榮如是說道。

展望未來,諾德資訊將持續深化 Production as a Service,成為軟體公司從上線到長期營運的夥伴。自構想階段起即與軟體商共同討論架構,於測試階段協助驗證,於準備上市時承接正式環境,上線後則持續守住流量、資安與服務韌性。軟體開發者與 SaaS 業者可將資源集中於產品與客戶,完整基礎架構與 24×7 維運則由諾德資訊端到端承接。

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
一次搞懂工業AI
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓