Posts Tagged ‘adobe’

創業 CEO / 掰掰年度考核,Adobe 改用 Check-in 系統得到低流動的開心同仁

June 30th, 2015

Adobe Check-in

在「創業 CEO」系列,我們討論創業者如何教會自己,成為偉大的 CEO,因為歷史上最偉大的科技公司,往往都是由這樣的人在領導

2010 年 4 月,時任蘋果 CEO 的 Steve Jobs 罕見地在 Apple 網站上貼出一篇 Thoughts on Flash 署名公開信,正式宣告 iOS 將不會支援當時在 Facebook 平台如日中天的 Flash 播放器,敲響了該生態系第一個喪鐘。隨後,YouTube、Android 等盟軍陸續叛走,曾經制霸網路的 Flash 王朝終究日暮西山。

在這段 iOS 與 Android 聯手掀起的世紀平台大顛覆中,Adobe 失去的還不只 Flash 這個珍貴的資產,經年仰賴的 Photoshop、Illustrator 等長銷軟體,也在 App Store 與 Google Play 帶動的免費 Apps 革命中,眼巴巴的看著巨大市場被蠶食鯨吞。

也因此,在 2011,面對前後夾攻,營收獲利成長趨緩、股價創下歷史低點的 Adobe,終於決心轉型,要從傳統的賣軟體盒子的公司,轉型為賣網路服務的 SaaS (Software-as-a-Service) 模式。

家齊才能平天下

這是一個巨大的轉型,需要的是組織的上下同心。也因此,在人事管理方面,他們也決定大膽變革,藉以激發同仁的向心力,一起協助這艘 11,000 成員的大船轉彎。

經過討論,Adobe 高管們很快把他們的目標聚焦在年度考核之上。這個考核制度首先週期太長,完全不適用於 Adobe 計劃轉型成為 SaaS 模式需要的敏捷。另一方面,他們一年投資 80,000 小時在年度考核,但換來的不是更清楚自己努力方向的同仁,而是考核後大量升高的抱怨、流失。

事實上,根據人資顧問公司 Achievers 在 2012 年的一次調查顯示,有高達 98% 的人資主管,認為他們的年度考核系統缺乏效用。WorldatWork 在 2010 年的另一次 The State of Performance Management 報告也指出,60% 的高階人資主管,只給自己公司的年度考績系統 C 的評價。

所以要讓同仁們更有向心力,要有一個新時代的回饋系統,更能協助他們進步,更能留下優秀的人才。

Check-in 登場

最後 Adobe 發明了這個名為「Check-in」的管理方法,從 2011 年開始實施。目前為止,雖然無法取得深層的 HR 數據,但至少在四年內,Adobe 順利推出 Cloud 系列產品,營業額得以維持,而股價居然從 2011 年最低點的 22 元,已經升至今日的 81 元,顯示投資人對於這個轉型的認可。

而雖然沒有分享深層的 HR 數字,但 Adobe 的資深人資副總 Donna Morris 目前為止的確數度表達了他們對 Check-in 系統的滿意,也分享了不少關於實施 Check-in 的心得

所以到底 Check-in 是怎麼樣的一個系統?基本上它可以說是一個運用「網路思維」的考績系統。

往前看,不往後看

Check-in 的第一個特色,是著重期初的個人計畫設定,而不是期末的考評。所有的經理人要在年初挪出足夠時間,陪他的團隊成員定義他們的年度計畫,用以作為接下來提供回饋需要的依據。

更短、更彈性的迴圈

接著,每位團隊成員至少每 8 週要與他們的老闆「Check-in」一次,也就是一對一面談,但經常是更頻繁。這些更彈性、更大量的 Check-in,可以協助老闆更了解每位同仁的狀況,給予即時的回饋,並且協助適時他們修正未來的目標與方向。

期末獎勵

最後,在年末,每位員工會根據一年度裡面所有 Check-in 的狀況,被給予適當的獎勵。

提供經理人對的訓練與工具

明眼的人應該看得出來,這個系統的重新設計,真正的關鍵是經理人,尤其是他們協助同仁們定義合理目標,並且給予即時回饋的能力。所以在這中間,Adobe 投資了很多時間與精力,辦理了大量的經理人訓練,並且提供各種線上、線下的資源,去協助他們升級成新時代需要的經理人。

結論

在相當程度上,Adobe 的 Check-in 與 Google 的 OKR,其實有異曲同工之妙。這些新的人資系統的發明,在講的都是同一個故事,那就是在這個變化越來越快,人才越來越重要的知識經濟世界,傳統把人當生產機具的邏輯,必須大幅的被改變,才能夠創造出在新世界裡,擁有一流競爭力的 A 級企業。

希望今天的 Adobe Check-in 案例,有給你一些啟發。

___

歡迎訂閱我的 MR JAMIE 電子報

iPhone App Store 大受歡迎的幕後秘辛 與網路的未來又有什麼關係?

May 5th, 2010

我不知道你有沒有注意到,在現行的各種“運算裝置 (computing devices)”上 — 這包括了桌上型、筆記型、智慧手機和 iPad 等等,其實都至少有兩個執行應用程式的環境。一個是大家都有,(一般來說) 可以共通的“Web 平台”,也就是透過瀏覽器來執行的各種網路應用,例如:Gmail。另一個則是每種機器上都有點不一樣的專屬平台 (proprietary platform),也就是透過作業系統來執行的各種原生程式 (native apps),例如:Outlook。

一般來說,大家都認為 Web 應用是未來,因為他有許多好處,像是免安裝、免升級、資料有共通性、不會被某台電腦綁死等等。但是,在網路應用“突飛猛進”了十多年之後,我們卻始終無法離開原生平台 — 最好的例子就是 iPhone App Store 瘋狂受歡迎的程度。發表不到兩年,這個蘋果的手機的原生應用市集,就已經累積了 20 萬種的應用,和超過 40 億次的下載

你或許會說,App Store 能得到這麼多的開發商青睞,這麼多的使用者採用,都是因為 iPhone 本身的熱賣的關係。然而,就像我一開始說的一樣,iPhone 上面也有 Safari 瀏覽器,最近還加上了 Opera,都可以執行 Web 應用,甚至還不用經過 Apple 的層層審核,額外的剝削,根本就是一道寬敞的後門。然而,為什麼有這麼多的應用開發商,卻捨棄 Web 不用,全都跑去寫原生程式呢?問題顯然不是那麼簡單。

你還可能說,App Store 方便的付費管道,讓開發商更願意使用。然而 Web 上也有許多好用的付費機制,像是 PayPal、Amazon Payments 和 Google Checkout 等等,且手續費比 App Store 更加低廉,所以這也絕對不是原因。

而真正的原因,其實跟開發的環境比較有關,就是當你寫一個基於 Cocoa 環境的原生 iPhone 程式,你可以做到的事情比一個基於 HTML/CSS/Javascript 的 Web 應用,來得多太多了。用 Cocoa (iPhone OS 和 Mac OS X 上的開發環境),你可以呼叫 iPhone 上的各種特殊功能,像是 3D 引擎、語音輸入、多點觸碰等等等等。但是如果用 Web,你就只能使用 Safari 有支援的少數陽春功能組合。

在了解了這點之後,你就知道為什麼北美網路工程師界的大神 — 喬依‧休維特 (Joe Hewitt),最近這麼忿忿不平了。至於還不知道喬依是誰的人,請容我簡短的介紹:喬依是 Netscape、AOL、Firefox、Firebug 等著名軟體的主要開發者,他最近最有名的作品,則是狂受歡迎,被下載超過 5 千萬次的 Facebook iPhone App。所以,如果說要把這世界上的工程師,用他們寫的軟體改變了多少人的生活來排名,那喬依不是第一名,也絕對是前幾名。而就像 TechCrunch 在上面連結的文章裡說得一樣,當喬依抱怨的時候,就是大家該認真注意的時候。

在今天讀完喬依的抱怨後,我才恍然大悟,他說得真對,原來網路產業問題的核心,根本就不是 Flash,也不是 iPhone OS,更不是蘋果。原來,制定 HTML/CSS/Javascript 等網路應用標準的機構 W3C,才是這其中的罪魁禍首。如果 W3C 創新的速度夠快,趕得上時代的潮流,那我們從一開始就不會需要 Flash 播放器,也不會需要 Cocoa 環境,更不會有什麼封閉平台的問題。如果 W3C 有把他們的工作做好,那我們早就該進入 Web OS 的時代,可以任意的轉換電腦,根本不用擔心被任何機器、任何公司綁死。

問題就是 W3C 是個非營利組織,是一個被大公司挾持,需要取得各方妥協的官僚機構。所以,短期內,我們根本沒辦法期待他變成一個有效率、有組織、可以快速反應市場需求的機構。而最好的例子,就是 W3C 最新推出的 HTML 5 標準。理論上,這樣的一個新標準應該是時代的標竿,但可悲的是, HTML 5 能不能取代十年前就已經出現的 Flash 技術,都還可以成為各方爭辯的話題。這種時候你就知道, W3C 創新的速度有多麼的緩慢了。

所以,如果從這樣的層面去觀察,我們想我們可以得到以下的結論:

  1. Web 應用將很難成為網路的全部未來 — 他絕對會是網路的部分未來,但很難成為全部。
  2. App Store、Android Market 將繼續發燒 — 提供裝置上原生應用的環境,由於創新的速度會比 Web 快,所以將會持續的推進,讓 Web 應用無法追趕。
  3. Chrome OS 將會失敗 — 基於這個 Google 開發的全瀏覽器作業系統,所開發出來的行動、平板裝置,由於沒辦法有原生應用,將會在應用的品質上,大大落後 iPad 和使用 Android OS 的其他裝置,所以終將失敗。

我想這些趨勢,對於網路創業團隊發展的決策,絕對非常重要,我希望大家多方去了解,多多思考。如果你有不同的想法,也歡迎留言讓我知道。加油!

(Pic via joe.hewitt.usesthis.com)

你的網站該開放平台嗎?你又該如何選擇開放的程度?

May 4th, 2010

開放還是封閉,是科技圈近來常常爭辯的話題。最常聽到的討論就是 Android 的“開放”,和 iPhone OS 的“封閉”,例如去年中 TechCrunch 主筆麥可‧阿靈頓大喊受夠了封閉的 iPhone,毅然轉用 Android 事件。而不滿常常成為箭靶的蘋果 CEO 賈伯斯 (Steve Jobs),也在上周的文章中反稱 Adobe Flash 才是不折不扣的私有發開平台來反駁。

不過每每讀到這些文章,就覺得少了一個客觀的、有系統的分析方式。斷章取義,隨便抓一塊出來講,當然每個平台都少不了封閉的部分。

而這個缺少的模型,上周末終於讓我在克里斯‧迪克森 (Chris Dixon,Hunch.com 的創辦人) 的網誌上找到了。 克里斯的這篇“開放與封閉的優劣”,首先引述了哈佛大學 (Harvard) 教授湯姆‧艾森門 (Tom Eisenmann) 的一篇長達 29 頁,關於開放式平台的研究報告 (名為:Opening Platforms: How, When and Why?) 中,最關鍵的一個圖表:

根據艾教授 (愛叫獸?好,我知道很難笑…) 的模型,他把一個平台的開放或封閉,分成四個層級來分析,例如:Linux 就是完全的開放,從消費者、開發者、平台硬體和平台軟體,都是非常自由的。而 iPhone 則是在另一個極端,除了消費者端,其他都是封閉的。(不過他也承認在北美市場,iPhone 連消費者端都是半封閉的,因為你只能選擇 AT&T 一個電信商。)

我覺得這是一個相當不錯的模型,因為他把一個“平台生態系”的四個主要角色,所受限制的程度,分開來分析,然後再來斷定這個平台的開放程度。如果用這樣的模型來分析,那 Flash 平台應該是有兩個開放 (消費端、硬體端),和兩個封閉 (開發端、軟體端)。也就是說 Adobe 罵 iPhone OS 是個封閉系統,的確是像賈伯說的那樣,有點五十步笑百步的感覺。

至於開放與封閉的好處和壞處,克里斯則提議應該從公司、產業和社會等三個面相去分析。不過和創業團隊最相關的,是來自下面的這段論述:

…a company should close their core assets and open/commoditize complementary assets. Google’s search engine is their core asset and therefore Google should want to keep it closed, whereas the operating system is a complement that they should commoditize… Facebook’s social graph is their core asset so it’s optimal to close it and not interoperate with other graphs, whereas marking up web pages to be more social-network friendly (open graph protocol) is complementary hence optimal for FB to open…

大略可以翻譯成:

一個公司應該要保護他們的核心價值,然後開放周邊的產品。以 Google 為例,搜尋引擎是他們的核心,所以應該要封閉。相對的,作業系統和瀏覽器可以幫助人們使用搜尋引擎,所以應該要開放,甚至免費的提供。再以 Facebook 為例,人們的人際關係和喜好是他的核心,所以當然要保護起來,至於可以增加和 Facebook 互動的 Open Graph,則要鼓勵其他網站多多使用…

我覺得這是一個非常直覺,卻非常有道理的判斷角度。而從這樣的邏輯去思考,就不難發現為什麼 Google 要讓 Android 如此開放,而 Twitter 又為什麼要推出官方版的手機應用

所以,當你的團隊下次面臨要選擇開放網站上哪些功能和內容,才能夠吸引人家來幫你開發應用,刺激更多的成長,而卻又不想讓平台因此失去競爭力時,我認為上面的分析模型和邏輯,相當值得你參考。加油!

(Pic via sharman@flickr under CC license)

©2020 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成