Author Archive

人與才

June 10th, 2011

昨天的「最棒的程式碼」一文,下面出現了更棒的討論。其中 Arvin Huang 的留言,讓我想了一整天,他說:

能夠 document 清楚自已程式含義的人,代表著他胸有成竹,程式的可用性就很高。本人的經驗是在試用一個程式員的時候,有時候您不用去看程式,因為看別人的程式是很累人的事,看他的 document 則是很好的方式,能夠很好的注解自已程式的人,基本上都是 A 咖級的,也是可以裁培的人。

這段話讓我一直在想「人才」這個字的涵義,既然它是「人」和「才」兩個字的組合,那麼一個真正的「人才」,是不是也應該要是「人」和「才」兼具呢?如果「才」指得是能力,那這裡的「人」,我認為應該是個性、價值觀、潛力、工作/溝通的態度等等。

當我們在找夥伴、團隊成員時,往往放很多精力在「才」上面。懂不懂 LAMP、寫過幾年 RoR、什麼學歷、什麼經歷,但是常常花太少的時間在「人」上面。所以我看過不少團隊紙面上看起來非常不錯,但很奇怪就是一直搞不出什麼屁來,仔細研究之下,才發現原因出在成員的價值觀和溝通不良上面,白白浪費了每個人身上的好功夫。

所以在找夥伴時,除了能力,我覺得大家必須要同樣重視「人」這個原素。傳統的面試方式,其實很難讓你看清楚一個人,所以你必須要用一些新的方法。Mixer Labs 的 Elad Gil 前幾天寫了一篇關於他們公司如何徵才的文章,我在裡面發掘了一個是很重要的「看人」方法:

啤酒測試

每一個 Mixer Labs 有興趣邀請加入的人,他們都會帶他去吃個晚飯、喝點小酒,確認這個人和 Mixer Labs 團隊的文化是契合的。有一次,一個非常非常強的工程師,大概是他們面試過最強的,在幾杯黃湯下肚後,居然講出了一些種族歧視的話,這讓 Mixer 最後決定不要雇用他。

這個方法其實 appWorks 也用過,當我們在找 Associate 時,就請了幾個我們覺得不錯的應徵者去參加 Startup Mixer,看看他們跟創業者們的互動,是不是能夠融入我們所屬的社群。這個過程也幫助我們最後找到了 Joan,將近一年後,事實證明是非常正確的選擇。

所以,我想無論是 Arvin 的看 documents 方法或是 Mixer 的啤酒測試,我看到的是他們對「人」的重視,事實上,大多的時候,「人」是比「才」還重要的。這個問題,我覺得值得大家好好的去想想。而如果你有什麼其他的好方法,也歡迎你留言跟我們分享。

(Image via brandoncwarren, CC license)

最棒的程式碼,不是程式碼

June 9th, 2011

上次聊過工程師的生產力不應該用程式碼來衡量,因為他們的極致生產力,是在少寫幾行程式,而不是在多寫幾行程式。今天剛好又看到兩篇文章,可以用不同的面向延伸、解釋這件事情。

首先,是一位跑去日本教英文老師的前任軟體工程師,發現了寫程式和學語言間的共通性,他說:

這些工程師往往可以輕鬆的通過面試,但當他們真正開始工作,卻讓人大失所望。我讀了很多關於這個問題的研究,但當我越看它,就越發現這些「殘障工程師」,就好像我的英語學生一樣。他們有 5,000 字的詞彙,書裡面的每一個文法都背得滾瓜爛熟,但是就是說不出一句話。

我的理論是,程式其實就跟寫作沒什麼兩樣。多數的程式概念上一點都不難 (跟你想的不一樣),我們搞不好的原因往往只是寫作能力太差。大部分的工程師根本就不是「流暢」的語言使用者,也沒有努力想要讓自己變得流暢。他們不去多讀讀他人的程式,看不懂也不會使用「成語」,更不會「用程式語言來思考」。這些人寫出來的程式很糟,因為他們根本就是電腦語言的三歲小孩,卻試著要寫一本小說。

所以如果你是工程師,多讀讀別人的程式碼,是很重要的,就跟學習寫作一樣。

相反的,如果你的程式想要讓人家讀懂,那 documentation 是非常重要的。GitHub 工程師 Zach Holman 發表了一篇非常棒的文章,詳細解釋了為什麼你要寫文件,怎麼寫。

  1. Documentation 是個人的 — 相信我,你以後一定會回來改這些程式,如果要讓未來的自己更快進入狀況,把事情搞定,今天請你務必把東西寫清楚。
  2. Documentation 是清楚的 — 如果你不把你推出去的程式碼講清楚,那根本是在幫自己找麻煩,以後一定會出現一堆 bugs、困惑的同事,最後搞得自己更累而已。
  3. Documentation 是可以測試的 — 因為你必須要把程式的邏輯解釋清楚,這讓你重新思考自己的寫出來的東西是不是符合原始精神,有沒有更好的方式。為了不在寫文件時陷入無法解釋的難關,這也迫使你簡化每一個功能,把一個複雜的東西切成好幾個功能。
  4. Documentation 是可以比較版本的 — 好的文件可以讓版本間的比較更容易,也讓團隊合作更有效率。
  5. Documentation 是行銷 — 透過好的文件,可以讓下載你軟體的人更容易開始使用,這也大大提升了轉換率。
  6. Documentation 讓你在床上表現更棒 — 這點 Zach 還在驗證,不過他認為建立好的文件讓你很酷,這應該對自信會有幫助。

以上,希望這些觀念可以幫助你們更了解工程師、效率和生產力之間的關係,加油!

(Image via zooboing, CC license)

228 位 Groupon 消費者調查結果,大公開

June 8th, 2011

昨天文章聊到 Groupon 申請掛牌,卻落得人人喊打的情況。但我認為大家應該把焦點集中在更深一層的問題,那就是 Groupon 這個模式到底可不可以長久。這個問題最大的關鍵是「消費者經驗」,但我自己只用過一次 Groupon-like 服務,無法代表大家說話。於是,為了更瞭解真正的使用者的看法,解開大家長期以來的疑惑,我隨手弄了一個非常精簡的小小調查

本來想說有 30-50 個回覆就不錯了,想不到,我們居然得到了 228 個人的迴響 (有沒有跟你說市場是無法預測的)。今天早上起床看到之後非常驚喜,趕緊開始分析資料。

首先,讓我們先來先公布答案的分布情況。

消費者使用 Groupon-like 服務的次數

這裡我們看到 8 成的消費者使用次數是 6 次以下,要跟大家道歉的是我問卷沒有設計好,少放了一個 13+ 的選項,因此 10-12 次裡面可能有一些其實是 13+。

用過 Groupon-like 的消費者「回訪」的餐廳數

從這個統計可以看出有「回訪」經驗的消費者大約占 27%,其實不低,下面我們有一些交叉分析。

幫 Groupon-like 經驗打分數 (1-5)

這裡可以看到「負面經驗」的消費者有 36%,閱讀他們填寫的抱怨,最多的是買了之後「訂不到位」、「餐點/服務品質」(很多來自預期落差 — 照片拍得太漂亮) 和「灌水折扣」這三個問題,也有不少人抱怨 Groupon-like 服務寄太多電子報。

交叉分析

如果我們作一些簡單的交叉分析,可以發現:

  1. 有「回訪」經驗的消費者,平均使用 Groupon-like 的次數是 6 次
  2. 整體「總回訪率」 (總回訪餐廳數/總 Groupon-like 使用次數) 是 12%
  3. 使用 6 次以下的消費者 (占 82%),有回訪經驗的比率是 20%,回訪率則是 12%
  4. 使用 7 次以上的消費者 (占 18%),有回訪經驗的比率是 55%,回訪率則是 13%

結論

以上的數據,幫我們稍稍解開了 Groupon-like 體驗的謎團。原來,所有 Groupon 消費者裡面,大約有 6 成是只用過 1-3 次的「嘗鮮客」,而有 2 成是經常使用 (7 次以上) 的「折扣達人」。更重要的是,平均來說,消費者每吃過 8 家餐廳,只會回去其中一家,這和使用過 Groupon 的次數並沒有關係。

但如果你是餐廳,我不認為這個數據代表你應該要預期每 8 個 Groupon-like 消費者,就有一個會回來。相反的,我認為它代表的是每 8 家使用 Groupon-like 服務的餐廳,平均只有 1 家會讓消費者想要回去。也就是說,使用 Groupon-like 做行銷,雖然可以帶來很多客人,但就像上面提的消費者抱怨一樣,有 8 成的結果是讓他們失望的體驗。

所以耍再多花招,最後的重點還是你如何用餐飲和服務把消費者留下來。而這,不就是做生意最核心的精神嗎?

(Image via groupon.com)

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