“分手快樂－－單飛後的開發者生活” 與新的 6 篇文章 - Inside 網路趨勢行銷與開發 |
|
- 分手快樂－－單飛後的開發者生活
- Google 搜尋「自動完成」的開發故事
- 該如何與軟體開發團隊溝通，請他們加班以讓專案如期上線呢？
- Twitter、紐約時報與赫芬頓郵報網站遭到敘利亞駭客組織攻擊
- Hands Up 從台中出發，為創業者打造逐夢空間
- Paul Graham：我一點也不想再嚐創業滋味
- 負責產品內容的人該怎麼與開發者合作？
|
Posted: 28 Aug 2013 05:41 AM PDT
香蕉相機開發者 Boris Yang（貼圖是本人自己選的 XD） 從智慧型手機仍罕見新潮的時期開始自學 iOS 程式，到如今人手一支的行動時代寫出 App Store 第一名的拍照軟體；香蕉相機開發者 Boris 四年創業路程相當蜿蜒曲折。 2009 年， 本名楊劍雄的 Boris，帶著 500 萬積蓄從華碩離職（註一），與大學好友共創公司「雲端線上」，在美國科技新聞媒體 TechCrunch 於台北舉辦的聚會中，以閱讀器 app 初試啼聲。2010 年與信義房屋合作推出房屋查找 app 賺了一筆，同年加入台灣育成中心 appWorks，陸續產出 App 產生器，最終決定以「ekado」電子會員卡登上期末舞台，從 appWorks 畢業後四人團隊整軍，照相軟體「自拍王」問世，同時與雲端生活 + 展開合作。 2013 年初，Boris 脫隊重新出發，自主開發「香蕉相機」，五月甫推出便一舉登上 iOS 免費排行榜冠軍，最近付費版同樣奪得第一。 四年來，與團隊共同催生五項產品，而後選擇單飛做自己，Inside 採訪到 Boris，請他與我們分享沿途風景。 分手之後，繼續當朋友團隊拆夥並不是新鮮事，但就如戀人分手，既有好聚好散，卻也可能反目成仇。很幸運的，Boris 屬於前者，儘管與夥伴在創業道路上走向分歧，現在他仍與先前共同奮戰的好友每週固定聚會，雖然不太談論彼此事業，不過維持純粹情誼也已實屬難得。 Boris 與夥伴能夠畫下完美的休止符，金錢處理得漂亮是主因，再加上 Boris 後期重心擺在營運與雲端生活 + 的合作軟體，甚少參與主力產品「自拍王」的開發，因此他的離開可說乾淨俐落，不留遺憾。 不過，脫隊仍是事出必有因，回想當初，Boris 不諱言，自己的個性比較乾脆，希望速戰速決，即使失敗也能快速重新來過，不過由於團隊共有四名共同創辦人，舉手表決制往往得在選擇、說服、妥協之間耗費大量時間，在結束與雲端生活 + 的合作後，Boris 決定脫離團隊，成立「Sambar Deer 三博鹿」，展開一個人的大冒險。 關於這個名字，Boris 自述：
想必這是 Boris 給自己的期許，在崎嶇艱險的旅途中，以靈活的心態，面對各種挑戰。 找到藍海中的紅海起初 Boris 對未來並沒有清楚的藍圖，靈感靠著社群網站而來，看到大家流行張貼名言錦句，便寫出 PixQuote 這個照片 + 名言的 app，但是反應普通。 今年五月 Boris 發表可以編輯日期、時間、濾鏡，還能加上個人小語的香蕉相機，還可選擇中文字型變化，當然，也沒放過東亞人最愛的貼圖，一個個傳神的香蕉人充分表達喜怒哀樂，滿足使用者創作慾的 app 迅速獲得好評，締造連續一周 iOS 排行榜冠軍紀錄。 而付費版推出三個月後也「解開付費榜 Top 1 成就」，只是，有點出乎我們意料，Boris 透露，台幣 30 元的 Pro 版，一天下載量僅為一、兩百個，就足以在這個時刻擊敗群雄，推測可能是蘋果太久沒出新機，導致 App Store 販賣機生意清淡。他自嘲，這樣的成績算是「成功的失敗」，也在 Facebook 上訴心聲： Post by Boris Yang.
無論如何，香蕉相機已然在台灣市場逐漸熟成，使用者自免費版本跳到付費版本的 4% 轉換率亦在水準之內，同時，又收到一堆「甜蜜」負評－－Android 使用者急切盼望香蕉相機快快播種到 Google Play 的土壤裡。各種條件都在催促 Boris 快馬加鞭，最近他已找到 Android 工程師與設計師，預計十月就能誕生香蕉相機 Android 版，並且計畫在下個月進軍中國。 相機 app 儼然一片汪洋，Boris 卻仍選擇這個題材，他說，紅海不一定比較不好，找到還沒被滿足的需求，就可以在紅海中創造藍海。Boris 自己分析市場上多數相機 app「都幫使用者設定得好好的」，香蕉相機的標語與貼圖都能自由移動，後者甚至可以放大縮小，藉此做出與它者的差異化，仍能擄獲使用者的目光。 一路走來，有你真好回首這半年，Boris 不斷強調自己非常感激貴人相助，特別是 Cubie Messenger 創辦人 Tempo 與 Cjin，有段時日因為 Cubie Messenger 將香蕉相機置入 app 內協助宣傳，成效斐然。訪談結束後 Boris 還特地傳送訊息：
確實，身為獨立開發者，少了團隊成員一起腦力激盪、鞭策彼此，幾乎是孤立無援的狀態，遇到疑問多半只能自答，但要取得成就，還需創業前輩拉一把。Cubie 無庸置疑是台灣團隊站上世界舞台的典範，先前 Inside Salon 邀請到 Tempo 分享募資經驗，獲得許多年輕創業家的好評。幫助雖非義務，但若有更多如他們一般，願意提攜後進的成功創業家，或許也會有更多如 Boris 般的年輕人或團隊綻放光芒。 此外，使用者的回饋，也是 Boris 遭逢迷途時的指南針：參考使用者需求修改產品，但切忌照單全收。其實這與我們先前一再複述的「使用者便是最佳解答」是一樣的意義。 縱使有貴人與使用者兩盞明燈，Boris 基本上仍是孤身一人，寫程式、想行銷、談版權，除了曾找好友幫忙繪圖，幾乎所有工作事必躬親，開發上豐富的國外資源不成問題，儘管他很滿意一切自己作主、節奏快速的生活，但也有令他使不上力的時候，比如推廣。特別是前往海外市場時，雖然寫了英文、日文電子郵件向好幾個日本 app 評測網站介紹香蕉相機，但都石沉大海，他殷切期盼，能有個共享推廣技巧的論壇或網站讓獨立開發者交流。 未來，如前所述，Boris 已經找到 Android 工程師與設計師，雖然目前都是兼職性質，但他們都有共識，將朝組成團隊的方向前進。Boris 有信心當初脫隊的原因不會重現，他想營造「充分討論的獨裁」，在成員自由發表意見的前提下，賦予決策者特殊權力，從而建立一支快速反應、不拖泥帶水的團隊。 後記訪談過程中，感覺得出來 Boris 是一位不說大話、相當務實的創業者。歷經育成中心、團隊合作的洗禮，Boris 找到屬於自己的步調，產品大放異彩後，又將重整團隊。即使路程並非一路坦途，只要方向正確，仍能結出甜美果實。 |
|
Posted: 28 Aug 2013 03:22 AM PDT 您是否曾在使用 Google 搜尋時，發現字都還沒打完 Google 就列出您想搜尋的項目呢？或者從 Google 的搜尋建議中發現有趣的事物，還是對 Google 的搜尋建議感到困惑不解呢？本文編譯自日前 AllThingsD 發表的文章，談 Google 自動完成的開發故事。
當我們試圖在 Google 搜尋某件事物時，從輸入第一個字開始，Google 便會開始列出與輸入字詞相關聯的搜尋建議。有時候 Google 能正中使用者要搜尋的項目，如果要搜尋的目標正好是當下熱門的話題時，可能只要輸入第一個字 Google 就能馬上建議你要搜尋的項目。有時候 Google 的建議令人感到有趣，有時則會顯示出某些奇特的選項......（讀者不妨試試 Google 一下：「google is」、 「 這個功能的正式名稱為「自動完成 Autocomplete」，所提供的搜尋建議是由系統基於各種演算法條件（包含搜尋字詞的熱門程度、使用者的搜尋記錄等）演算而來。基本上，Google 認為使用者會傾向於搜尋與多數人（尤其是具同樣搜尋偏好或在同一地理位置的人）相同的字詞。 誕生於 Google 巴士的「自動完成」「自動完成」出自當時剛到 Google 任職不到三個月的軟體工程師 Kevin Gibbs，當時 Gibbs 主要是負責維護系統設備以支援數據中心的運作，在穿梭於舊金山市區與山景城總部的 Google Bus 上，Gibbs 想著要結合當時開發者們熱烈討論的話題：「大數據、JavaScript、高速網路」開發一個產品，於是在接駁巴士上 Gibbs 想出了他的第一個作品「網址預測器 URL predictor」，在網址預測器中開始輸入一串網址時，它會開始分析 Google 背後龐大的網頁內容資料集，接著自動填空列出相關的網址。 一位同事在看過網址預測器後覺得網址預測器太酷了，並建議 Gibbs 何不把它運用到搜尋上。於是 Gibbs 重新設計整個系統，當時 Google 搜尋的領導人 Jeff Dean 和 Rob Pike 得知消息後也全力支持 Gibbs 的計劃。Gibbs 最初為這項功能提出 Google Complete 的名稱，之後被當時人還在 Google 的 Marissa Mayer 定名為「Google Suggest」。 在 Google Suggest 問世前，Gibbs 設計了一份黑名單，裡面包含某些特定字詞將不會出現在 Google Suggest 上，這表示某些涉及暴力、色情或怪異的字詞會在 Google 的阻擋下消失在使用者眼前，就算這些字詞是最合理或熱門的搜尋選項。隨著黑名單字詞越來越多，要阻擋的字詞永遠擋不完一樣，Gibbs 擔心他的黑名單會進而影響使用者行為，畢竟當使用者搜尋不到特定字詞時不代表它們不存在。 最後經過一連串的內部測試與修正，Google Suggest 進入 Google 實驗室，Gibbs 當時在 Google 官方部落格寫道：
至於 Gibbs 當初最擔心的黑名單問題，現在 Google 官方有這麼一段解釋：
從 Gibbs 在巴士上有了初步構想之後，他運用 Google 給員工的 20% 時間完成 Google Suggest 項目。Gibbs 提到 20% 時間讓 Google 成為更好的企業，從公司整體運作、資源到最重要的工作夥伴，全都齊心讓一些很棒的點子能真正被實現成為很酷的產品！ 在實驗室測試四年後，Google Suggest 在 2008 年終於問世，此後 Google Suggest 不單只是一項功能，已成為會發生在每一次搜尋時自然而然的情況，像是 Facebook 也在 2010 年跟進這項服務 。2010 年在 Google Suggest 打下的基礎上 Google 推出更加快速能邊打字邊搜尋的 Google Instant。 再偏遠的小鎮村也不會被 Google 遺忘把時間拉回現在，Gibbs 提到 Google Suggest 最讓他感到驕傲的是其民主平等的本質，儘管 Google 傾向於建議搜尋某些相關的熱門字詞，但當 Gibbs 搜尋兒時居住的偏遠小鎮 Porterville 時，Google 還是會列出與當地相關的建議搜尋選項。Google 讓使用者無論身處什麼樣的環境，不論我們在乎的是什麼，這個世界還是如此偌大與豐富，而 Google Suggest 正能讓我們的眼界更加開闊。 Kevin Gibbs 現在已經離開 Google 與離開 Facebook 的技術長 Bret Taylor 共同創業。最後談到對於自己開發出 Google Suggest 的看法，Gibbs 說：
|
|
Posted: 28 Aug 2013 12:50 AM PDT
說明 最近在 Quora 上看到了一個有趣的問題，What is the best way to communicate to a software development team that they need to work more hours to meet a launch date? (該如何與軟體開發團隊溝通，請他們加班以讓專案如期上線呢？) 問題原文如下︰
就問題來看，發問者在團隊中應該擔任的是類似 PM 的角色，而發問的內容在實務上也很常見，所以引起了不少人的回覆。其中在眾多答案中，評分最高的，也是最引起我共嗚的答案，是由前 Quora 工程師 Edmond Lau 所提供的 (答案連結)。 Edmond Lau 在回覆中，說明為什麼他認為超時工作不可行，並且分享了他個人在過去專案執行中，所遇到的慘痛經驗。整個答案內文比原始的問題內文要長得多，但又非常實務且有趣。我在讀了之後覺得非常喜歡，所以想說就乾脆把它翻譯出來好了，希望也帶給遭遇類似問題的朋友一些思考。 要說明的是，我不是專業的譯者，所以對於內文的翻譯，或許有錯誤或是不到位的地方 (這很有可能發生)，都非常歡迎大家指正。如果有相關的經驗可以一起分享的話，那就更好了，這也是一開始我翻譯這篇答案內文，希望帶給大家的幫助。 譯文 在要求你的開發團隊加班之前，請先確定你們目前的上線計劃是真正可行的。 如果如期上線目前看來只是痴心妄想 (wishful thinking)，那麼你最佳的策略，要嘛是根據目前的專案狀態，重新訂定到上線日時，你們可以交付的成品內容；又或者是，根據專案目前的進度狀態，重新設定更可行的上線日。 處理滑落的開發時程，在軟體開發上是很困難，但卻不幸地是非常常見的事情。我參與過兩個大型、開發時程橫跨多個月份的專案，在這兩個專案中，雄心勃勃的專案經理總是要求團隊加班，以向專案交期衝刺。 在這兩個專案中，因為我們被告知，專案一旦無法如期完成，將會造成嚴重的商業損失。因此我們團隊中許多有天份且願意付出的成員，拼盡全力試著達成這樣 "樂觀" 的交期。我們的每週工時從一開始的 60 小時，到後來成長到每週接近 70 小時。 而在長達數個月的加班後，專案仍然結束不了。最後的結果証明，在這樣的專案馬拉松中，我們只跑到了一半，而不是接近終點。無謂的加班衝刺毫無意義。(It turned out that rather than sprinting at the homestretch of a marathon, we had started sprinting somewhere near the middle.) 在這些專案中，燒掉了團隊成員們的熱情，他們當中的一些人相繼離開。而這使得團隊中的其他人，要再花時間來接手離職成員的工作。短期來看，做出加班的決策來追求更多進度似乎是合理的，但長期下來都會傷害開發團隊。 這兩個專案的經驗，教會了我們一個沈痛的教訓︰當你希望一個專案在可以指定日期內完成，並不表示這個專案真的可以在這個日期內被完成。不要混淆「一廂情願」和「對事物樂觀」這兩件事！ (just because you really want a project to be completed by a certain date doesn't make it any more realistic that it will. Don't confuse wishful thinking with realistic optimism.) 為什麼超時工作不可行？你的思路可能是這樣子的︰目前進度已經落後表定的進度 25%，所以為了趕上原訂的專案交期，你需要使團隊多花費 25% 的工時以趕上進度。這表示在在未來兩個月中，團隊每個成員需要每週工作 50 小時。(譯註︰原發問者說明他們目前是每週工作 40 小時) 在這裡我提供一些理由，來說明為什麼這樣的思考邏輯在實務上並不可行，與為什麼加班並不一定可以趕上上線日期的原因︰ 1. 每小時的生產力，會隨著工時的增加而下降如果你的團隊已經習慣一週工作 40 小時的工作節奏，額外的工時帶來的邊際生產力，很有可能比一般工時來得低，甚至很有可能是負的。疲勞與睡眠的減少，最終會傷害認知功能與降低工作的品質。 近 150 年下來，關於長時間工作如何降低生產力的研究，可以總結在 Sara Robinson 的 Bring back the 40-hour work week 與 Evan Robinson 的 "Why crunch mode doesn't work" 兩篇研究文章中。1890 年代的員工，在每天的工時為 8 小時情形下，每位勞工的生產力較高 [1]。Sidney Chapman 在 1909 展示，超時工作下，生產力會快速下降，勞工開始犯他們在充足的休息下，不會犯的錯誤。而後續的成本在，他們的產出在後續幾天也會接著下滑 [2]。Henry Ford 在 1922 年開始採用每週 40 小時工時制，因為持續多年的實驗告訴他這樣的制度設計，可以提升勞工的總產出。[3][4] Tom Walker 在 "The Prosperity Covenant" 研究中寫下以下描述︰
邊際生產力下降代表即使加班可以提升團隊的每週總產出，但總產出提升的幅度不會是你所預期的 25% (譯註︰代表即使總產出有所提升，落後的專案進度仍然趕不上)。但 1980 年代的一篇研究 "Scheduled Overtime Effect on Construction Projects"，甚至質疑加班會提升每週總產出的這個論點︰
這個研究也許不是以軟體開發工業為研究主題，但這並不能成為，我們不學習這 100 多年來研究成果的理由。 2. 有很大的可能，團隊目前落後的進度比你們認知到的還要多精確的專案估計是工程中最困難的一項工作 [6]，目前專案進度上的滑落，代表你們之前幾個月的產出是低於預期的，而與其樂觀地認為只有先前的產出預估低於預期，更有可能的是對於整個專案產出上的預估都是錯誤的。這也包括你們對於未來的兩個月產出的預期。 使時程估計不準的效應更加重的情形是，我們傾向在專案開始時就可以將專案時程估計得準確，而此時我們預估時程的依據，都是聚焦在我們已經知道怎麼進行的開發工作上，而不是整體的專案工作項目。團隊常會低估整合測試所需花費的時間，而這些被低估的工作項目，通常會拖累整體的工時數週甚至更多。 Frederick Brooks 將這個效應寫在 "The Mythical Man-Month" (人月神話) 一書中︰
3. 額外的加班工時可能會燒掉你的團隊成員團隊成員的加班工時，來自於犧牲他們額外的時間 -- 也許是他們與朋友或配偶相處的時間、運動的時間、休息的時間、睡覺的時間或做其他工作以外的事的時間。當我們希望他們犧牲這些時間，而改用高壓的工時來代替時，所燃燒掉的團隊熱情將難以量化。 在 "Peopleware" (Peopleware： 腦力密集產業的人才管理之道) 一書中，Tom DeMarco 與 Timothy Lister 將其中一個這樣的現象，稱之為「偷工時間」(undertime)，而勞工在超時工作時「總是會幫自己挪出相同長度的偷工時間，以使自己的生活節奏得到補償」[8]
4. 加班可能會傷害到團隊的熱情並不是所有團隊成員都有餘力可以應付額外的工時，可能有成員家中有小孩要照顧、可能成員花費在通勤的時間非常長，壓縮了可以額外用來工作的時間、或是有成員已經規劃好了未來兩週的假期。 而一開始團隊中處在正面的狀態，所有人都聚集在同一個地方，每週工作 40 個小時。但現在所有人被要求投入更多他們不能或是不願意投入的的工時，其結果可能會導致原本快樂的團隊成員之間的痛苦或怨恨。 5. 倉促趕工會導致額外的管理成本超時的工作，會需要額外的站立會議，來確保每個成員正在做正確的事情，而不幸地的是，這些額外的會議與溝通成本並沒有被納入當初的工時預估中。 6. 趕工可能會造成額外的技術債有項難以避免的問題是，當你要求團隊成員超時工作以達成交期時，他們通常會在開發上，採取抄近路的方式以達成目標。 或許他們會負責任地寫下筆記，告訴自已在專案結束後，要回頭來處理這個問題，但他們在 A 專案結束後，通常又會接著投入 B 專案，而無法如他們的預期回頭處理問題。因此在趕工的專案結束後，團隊通常會留下一大堆等著未來要償還的技術債。 上述這些成本不是理論，而是實際發生在我參與的專案中。而且很不幸的，這些情形在軟體專案中是非常常見的。 但這些事不會發生在我身上撇開上述這些長期的成本不看，我也理解改變航道與向上線日期說「不」的困難度。也許組織中的其他人都在期待這個專案的上線好一陣子了；也許這個專案相當重要，以致於如果專案延期會造成商業上的損失；也許你害怕如果專案延期的話，你的團隊不知道會發生什麼事 (譯註︰XDD)；或者，也許你認為你和你的團隊的情況將會有所不同。 不論背後是怎樣的理由，如果你仍然執意想要求團隊加班，我建議你與你的團隊多著重溝通以下的項目︰ 1. 與團隊討論並釐清造成目前專案時程滑落的主要因素專案時程的滑落是因為成員的鬆懈，還是因為開發工作比預期來得更複雜與更花時間？如果你不了解專案落後的根本因素，那你就不能說服大家這些因素，在未來兩個月不會再發生。 2. 向團隊說明真正可行的新時程規劃，並向他們解釋為什麼這次加班，可以真的讓專案順利上線只是告訴團隊成員因為進度落後需要加班是不夠的，如果你們討論不出一個更仔細且可行的上線計劃，那麼這將是一個警訊。因為很有可能接下來所需的工作，會比你們現在所認為的還要來得多，而加班並不是一種好的解決方式。 3. 確保專案成員都對新的時程「買單」(buy-in)如果專案的關鍵成員(key person) 並不認同新的時程是可行的，那你可能要思考，你是不是將「某件事要在某天完成」和「某件事『真的』可以在某天完成」這兩件事搞混了？(then you need to consider that you might be conflating what you want to get done by a certain date with what is realistic to get done by that date.) 如果你不讓所有人買單，那將只有部份專案成員會真正加班來追趕進度，就算不論這種情況會傷害團隊的公平性，你也別想讓專案在你所預期的日期上線。 4. 與團隊說明整體大方向，說明為什麼如期上線對於組織來說是重要的如果你不能將所有團隊成員凝聚在一起，那這將是另一個警訊。因為所有團隊成員，將不是和你站在相同的出發點，進行加班趕工。 結論最後，如果在這兩個月的加班期間，你們發現你們的進度又一次在新的專案時程中落後了，那你們應該準備放棄這次的加班衝刺。接受你們目前仍然處在在馬拉松慢跑的中段，而終點比你們所預期的還要遠(Accept that you might have sprinted in the middle of a marathon and that the finish line is farther away than you thought.)。在這種情形下，要求團隊更加努力解決不了這個問題。你應該要做的是擺脫你的損失，並且花心思擬出下一個可進行的應急計劃。 無法如期上線可能很糟，但更糟的是燃燒光了團隊的熱情，而仍然無法如期上線，而對於新的上線日期仍然無法有效掌握。處理滑落的上線日期並不是件容易的事情。 附注 [1]: Tom Walker, The Prosperity Covenant: how reducing work time really works to create jobs. [2]: Sydney Chapman (economist), Wikipedia. [3]: Samuel Crowther, Henry Ford: Why I Favor Five Days' Work With Six Days' Pay, World's WOrk, October 1926. [4]: Ford factory workers get 40-hour week — History.com This Day in History — 5/1/1926, History. [5]: Scheduled Overtime Effect on Construction Projects, Business Roundtable, 1980. [6]: What are some ways to improve your project estimation skills? [7]: Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering, p20. [8]: Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, p15. [9]: Peopleware, p179. |
|
Twitter、紐約時報與赫芬頓郵報網站遭到敘利亞駭客組織攻擊 Posted: 27 Aug 2013 07:31 PM PDT
如果您早上習慣打開紐約時報網站，可能又會發現它們的網站又掛了。
敘利亞電子戰部隊（The Syrian Electronic Army，後文簡稱 SEA）在 Twitter 上表示他們對 Twitter、紐約時報與赫芬頓郵報英國版網站的域名伺服器進行攻擊1。最近敘利亞政府疑似向自己的人民動用化學武器一事正引起國際間的嚴重關注2，但該項指控遭到敘利亞政府否認3，而聯合國的調查小組則是剛完成相關調查（尚未公布結果）4。
SEA 亦聲稱他們控制了多個 Twitter 國際域名。
紐約時報與赫芬頓郵報英國版也是這次攻擊的受害者。SEA 竄改了聯絡訊息與 DNS 記錄，而 Twitter 用於處理 CSS、JavaScript、cookie 和影像的 twimg.com 其 DNS 記錄同樣遭到竄改，這表示許多使用者可能無法正確載入 Twitter 網頁，甚至被指向其他地方。
Twitter 也已發表聲明，指出他們的 DNS 服務供應商出現問題，經過大約一百分鐘後 twimg.com 的紀錄已復原，沒有使用者的資訊受到影響。但他們並未多提 twitter.com 與其他國際域名的狀況。 紐約時報在聲明中表示，由於負責管理公司域名的 Melbourne IT 遭到攻擊，目前網站暫時無法使用。
這是紐約時報網站一個月內第二次出問題，上一次是 8 月 14 日網站短暫掛點，當時他們改用 Facebook 報導重要新聞；目前紐約時報將新聞發表在 news.nytco.com，有需要的讀者可藉由該網頁讀取新聞。 最近幾個月 SEA 已經發動過多次攻擊，包括四月份攻擊美聯社 Twitter 帳號，發表錯誤訊息導致 S&P 500 指數瞬間大跌。 |
|
Posted: 27 Aug 2013 07:20 PM PDT Inside 介紹過不少夢幻辦公室：Line 的辦公室充滿熊大兔兔，可愛氣息從裡蔓延到外；Dropbox 把一棵棵棕櫚樹搬進室內，讓人上班宛若置身度假村；Facebook 的辦公室因為狐狸進駐而搖身一變成為生態保育園區；韓國 KakaoTalk 的精巧細緻如其產品一般；Google 更不用說了，遍佈全球的辦公室與其稱之辦公室，不如說是遊樂園。 可惜…這些公司都存在國外，不過，誰說台灣沒有良好舒適的工作環境？最近 Hands Up 育成中心正式揭幕，創辦人洪大倫委託空間設計公司打造出的辦公室，跳脫一般規矩制式的陳設，處處為激發靈感、促進協作的設計創意，令我們耳目一新。 做為全台最大民營創業育成中心， Hands Up 座落於台中市區，佔地 200 坪，共分成演講廳、共同工作區（co-working space）、獨立培育室、會議區四個區域，開放式的空間讓彼此交流變得很容易。 開放自由的辦公空間，來自 Hands Up 的創辦理念，創辦人兼執行長洪大倫於部落格中表示，之所以將公司取名為 Hands Up 有兩個含意：其一為舉「手」發問，Hands Up 設有專屬的會計師與律師團隊，每週都會安排特定時段免費讓會員諮詢；其二為白「手」起家之意，Hands Up 聚集天使、創投以及來自各領域的顧問與專家，整合力量，從旁協助資源相對稀缺但逐夢踏實的創業者。 來觀賞一下活潑的 Hands Up 辦公室環境吧！
洪大倫為會計與金融背景出身，目前專職於協助創業團隊尋求資金，並提供相關育成服務，也是一名天使投資人。Inside 先前曾轉載過他對投資的洞見，有興趣的讀者可以參考： 若以區域論，台北或許還是台灣創業風氣最盛行的地方，大大小小的創業講座、活動以及新創公司、育成投資機構多數集中此處，「Hands Up」選擇在台中出發，無疑是中部創業者的一大福音，我們樂見未來 Hands Up 帶動、激勵更多優秀團隊，為全台有志者再添旺盛薪火。 |
|
Posted: 27 Aug 2013 06:37 PM PDT
矽谷創業育成中心 Y Combinator 創辦人 Paul Graham
Paul Graham 的科技創業育成中心 Y Combinator 已經塑造了許多包括 Dropbox、Reddit 和 Airbnb 在內的重量級創業公司。這位創業圈的巨人就創業公司成敗的原因、選擇專案的標準和方法、創業公司的成長、乃至創業的前景等問題分享了一些真知灼見，全文如下。 為什麼有些創業公司能夠成功，而有些卻失敗呢？創業公司夭折是因為他們耗盡了資金。那麼他們是如何耗盡資金的呢？有時候，是因為銷售疲弱；但大部分情況下，原因在於他們沒有做出受眾想要的東西。這跟開餐廳是一個道理：酒香不怕巷子深，即便地處偏僻、價格偏高、服務又差，只要有美味這個「殺手鐧」，它還是會廣受歡迎。所以，「做出人們想要的東西才是關鍵。」這才是根本所在。如果你把公司做死了，也許因為你沒有提供人們想要的東西。 從 Groupon 和 Zynga 近期發展受阻來看，您怎麼判斷哪些是人們的長遠需求，哪些又是人們的短期需求呢？這兩個是很極端的例子，銷售上過於激進會過早消耗公司的發展後勁。公司成長很快是件幸運的事，但同時也面臨著疏遠使用者的風險。你所談到的是貪吃的風險，雖然大多數創業公司都是因為吃不飽而做死的。 您最近選擇了 Groupon 的創辦人 Andrew Mason 作為兼職合夥人。為什麼呢？他很棒。人很聰明，而且開朗有趣。在我眼裡，創業公司都是火車殘骸。你透過媒體了解到一些火車失事的新聞，然而還有更多的類似事件是在人們視野之外的。而 Andrew Mason 就是那個被報導的幸運兒。 創業育成中心往往因輕看創業面臨的挑戰而受指謫，YC 的創辦人們對創業的困難程度有充分理解嗎？關於創業圈是什麼，我寫過的文章並不少。也許其它創業育成中心會低估創業的難處，但我們不是。換言之，創業的現實困難程度是每個人無法預料的，因為人們之前未經歷同樣的難處。由於沒有太多時間和資金風險，這讓我們樂意創辦一個 YC 這樣的公司。所以，我們很樂意為有潛力、有誠意的團隊提供資金，即使他們覺得事情做起來很難，那也沒關係。只有嘗試了，人們才知道自己善於做什麼。也許只有 0.5% 的人有頭腦和充分的意志去做這類事情。創業公司難做但不是不可以做，正如 5 分鐘跑一英里很難但並非不可實現。 在 YC 投資的公司中，他們的創辦人有哪些普遍的缺點？他們往往不知道如何去獨立。孩提時代，他們聽父母的；上了學，他們按學校規定做該做的事情；工作了就聽從老闆吩咐做好本職工作。他們總是像嗷嗷待哺的雛鳥一樣離不開餵養。因此我們不得不告訴他們，「我們不是你的老闆，你儘管全權負責。」一些人聽到這個就怕了，他們注定要給人打工。而另外一些人則善於發現自己其實有一雙翅膀並嘗試著飛翔。只有在被扔下峭壁的一瞬，你才能有機會發現自己其實是能飛的。 矽谷的創業者是否在解決「實際問題」的討論一直都在繼續，這個問題您怎麼看？我認為這是人們看不透驚天動地的創新往往出自一開始不起眼的想法。微軟第一款產品是為 Altair 機器實踐基礎程式語言，當時它只有幾千個使用者，起初想法不驚人並沒什麼，人們往往缺乏觀察種子的眼光，不曉得將來它們也許會長成參天大樹。 大創意都是由小想法發展而來的，醫療健康即是如此。如果你想做一番事業，大可不必想法驚人，但一定要把事情做好。剛起步，這是個魚和熊掌不可兼得的事。也就是說，不是走一條「小而美」的路線，然後慢慢變得強大；就是就大處起步，但一開始可能做得差一點，然後再循序漸進改善。為什麼呢？憑經驗講，一開始就想從大處著手很難成事。這比較符合政府的行事做風，他們的表現往往很糟糕。 您如何能看出小想法中蘊藏的大潛力呢？大部分情況下，我們看人。如果他們看起來決心堅定、充滿熱情、靈活機敏，而且想法還不太糟，我們就會投資他們。我們曾認為 Airbnb 很糟，我們投錢給他是因為真地很喜歡他們的創辦人。他們看起來無比堅定且富有想像力。對他們的持續關注讓我們免於愚蠢之舉。 那些精彩的想法起初看起來可能不起眼，Google 就是如此。當時的搜尋引擎市場已是不乏玩家，其中一些還由上市公司運營。人們為什麼需要一個新的搜尋引擎呢？當我第一次聽說Facebook 時，它的使用者群體主要是沒什麼購買力的大學生，他們每天都把時間浪費在看彼此的個人資料上。如此看來，Facebook 是史上是最蠢的公司了。 自 YC 成立以來，您評判創業項目的方法經歷了怎樣的變化？長久以來，我們積累了許多判斷方法。所有的面試我們都有錄影存證，每輪面試前我們都會把前幾輪倒序看一遍。這非常有利於我們掌握這些創業公司的發展狀態。有時，看著看著影片忍不住就想說「我們差點又上了這些傢伙的當。」但有時，我們得說：「哈哈！簡直是刺激的X 計劃！」 怎麼說？比如新創公司的 CEO 不應該有濃重的外國口音。原因大概在於，創業公司有大量細緻而微的溝通工作要做，濃重的口音是個很大的障礙。也許有些人會認為講地道英文的人成功的機率會更高。所以如果 CEO 口音太重無疑會傷害信息的有效傳達。 另一個評判標準是創業公司對拒絕的態度。過去我們投資一家公司是因為他們看起來很友善。而對於那種被認可就開心被拒絕就如天塌了一樣的公司，我們選擇最終會給一個「No」。 現在您怎樣看那些估值 10 億美元的公司呢？這些公司值這個價嗎，這是不是預示著泡沫即將來臨呢？Instagram 可能是樁好生意，因為 Mark Zuckerberg 並不蠢。既然他 10 億美元買下了 Instagram，這意味著他需要這麼佈局。關於他這麼做的原因我的揣測是：Instagram 足以對 Facebook 構成威脅。估值的意義不就在於此？如果對 Mark Zuckerberg 而言你的公司得10 億美金，那它就真的值10 億美金。 但 Instagram 是一個不可複製的特例。某些公司估值高可能是因為他們拖了太久沒有上市。估值高沒錯，但估值高跟泡沫並沒有必然的聯繫。估值高意味著它可能有下挫的空間，以後會伴隨一定的起伏波動。 但泡沫就是更一回事了。如果某個明知價高還照買單不誤的人巴望著把資產轉移到另一個更蠢的人手中，這時候產生的才是泡沫。但現在的情況並非如此。現在沒有誰要想著投資哪個即將上市的公司轉而期待著愚蠢的散戶以更高的價格買進這些股票。我了解這些人。這可不是他們的動機。 當下，您似乎是矽谷最樂觀的人之一。原因何在呢？我之所以如此樂觀，是因為我得以與矽谷最優秀的 2% 的人一起工作。但就 YC 育成的當前 53 家創業公司而言，他們表現都相當不錯。人們常常批評現在的年輕人作風懶惰，我們這兒的年輕人完全不是這麼回事兒。他們都在埋頭苦幹。也許這就是我樂觀的源泉所在。另外，這可能還跟我生來是個樂天派有關。如果你是個天生的悲觀主義者，就很難做到這點。 YC的創業公司是否帶給您一些收穫，同時這些收穫又是您之前在運營 Viaweb 時需要知道但沒有想到的？就我所知，當時我們是唯一的新創公司，所以比之於其它新創公司，我並不清楚自身的相對優勢和劣勢。而現在我很明確我們屬於哪了。Viaweb 是由一群善於程式設計，但拙於銷售和做生意的書呆子所創立的。回過頭來想，我們其實應該把大把的時間花在銷售上。當時佔上風的想法卻是透過寫程式解決所有問題。現在看來，我們軟體的複雜程度大大超過了實際需求。 您是否懷念親自創業時的興奮感受？天哪！我再也不要重來一遍了。做投資人比開公司要容易多了。我意思是，YC 現在已經發展成這個規模，至少我們不需要為付費使用者提供數據服務，也無需半夜處理某些突發的棘手事件了。即使是投資一個不大符合我創業偏好的公司，也要好過親自經營一家創業公司。 您怎麼看 YC 的未來？創業已經成為一股勢不可擋的潮流。以往來看，大學生畢業後有兩個去向：一是讀研究所，二是找工作。而現在又多了一個選擇，就是創業。從產業革命的高度來看，我臆測這會是經濟轉型的表現之一。 當我還是一個孩子時，我認為你所工作的公司的聲望直接影響到個人的榮譽。而創業似乎總跟默默無聞連在一起。現在越來越多的人加入了創業的大軍，我能夠想像將來會有 10 倍、甚至 100 倍於今天的創業公司湧現出來。今天，有不計其數的 Brian Cheskys（Airbnb 的 CEO）和Drew Houstons（Dropbox 的 CEO）想要為微軟和 Google 工作。如果有意願，其實他們可以自己創業。我們同樣要考慮如何獲得成長的問題。也許 YC 以後會成長到現在 10 倍那麼大也未可知。這個世界什麼都有可能發生。
Paul Graham 偶爾會親自撰寫文章在部落格上，Inside 曾經張貼幾篇他對創業的洞見，有興趣的讀者可進一步參考：
|
|
Posted: 27 Aug 2013 05:41 AM PDT 您的工作是負責網站或 app 的內容嗎？是否需要經常與設計師、產品經理或工程師合作呢？過去兩週，Facebook 產品設計總監 Julie Zhuo 寫了兩篇文章 〈 寫給產品經理與工程師：如何與設計師一起工作 〉、〈 寫給設計師：如何與產品經理一起工作 〉，告訴大家「產品開發」的三大支柱（設計師、產品經理與工程師）之間要怎麼合作。 而另一位曾任職 Apple、Facebook 的 Nicole Fenton 這篇 〈 Working on Content with Developers 〉 則是談負責內容的人該如何與開發者一起工作。Nicole Fenton 在 Facebook 的工作既不是產品經理也非工程師，而是負責「content strategy（內容策略）」，小至用字遣詞，大至網站內容的產生、管理與消費。（有興趣的讀者可以參考這個訪談，聽 Nicole Fenton 談自己在 Apple 跟 Facebook 負責的工作與相關經驗。） 以下就是 Nicole Fenton 給負責內容的人要怎麼與開發者合作的建議： 如果您要負責產品的內容，那麼就必須與開發者密切合作。這表示您的工作不僅只是傳遞文件而已。您必須了解開發者、與他們溝通、一起工作，您負責為他們的工作（寫程式）做好準備。畢竟，產品開發的過程一定會影響產品的表現。 我先勾勒出幾個具體的作法，讓您先跟團隊試試看；這些建議並非一體適用。一切取決於您自己，就像時尚教父 Tim Gunn 說的：「to make it work.」 準備在您開始製造內容之前，先跟團隊做好整合。跟他們一起坐、一起吃午餐（或是喝酒，這點取決於你們團隊的文化）。看看他們彼此是怎麼相處的，然後加入他們。 取得工具開發者一般來說都用 IRC 溝通——不管是加入程式碼、追蹤 bug，或是在測試環境中檢視工作成果。詢問、取得你們團隊所用的工具，讓開發者不必遷就於您，工作起來可以更順手。 IRC大部分的開發團隊使用 IRC（Internet Relay Chat）來溝通。IRC 是一個持續的聊天群組，不管有沒有登入，您都可以加入某個聊天室（編按：但是聊天前要先設定匿稱）。 要設定 IRC，先詢問團隊的伺服器位置，請他們協助您。可以下載 IRC 軟體，例如 Mac 上的 Colloquy、Adium，或是 PC 用的 Trillian。 聊天室的東西肯定很多，您不需要去讀全部的內容，重要的是跟團隊成員保持聯繫。
Issue tracking systemIssue tracking system 可以協助您的團隊管理、排定任務（task）的優先順序。請熟悉團隊使用的系統，以便搜尋、發表、指派和結束任務。要是您負責的內容被當做一個「bug」，請不要覺得被冒犯了。 測試環境測試環境顧名思義就是為了讓我們在開發過程中測試產品，讓您看到開發中的產品是什麼樣子。每個團隊用的名字都不一樣，例如 staging、build 或 QA 等等。 請確保自己手上有最新版的產品（網站、app 等），這樣才能掌握產品的開發，您或許會需要開發者協助您安裝最新版的 app 到您的手機，或是在瀏覽器上變更 proxy 設定。 學習開發者的「語言」花時間弄懂團隊的開發哲學和語匯。如果您的團隊採用的是敏捷方法（agile methodology），那麼您就必須了解他們的行話。大部分的 geek 說話其實跟一般人一樣，但是如果您懂他們的術語，就可以節省大家的時間。 同樣的，學著寫一點程式不會怎麼樣。對程式有些基本了解，對您理解產品、產出更實際的內容很有幫助，這對您個人和團隊都有幫助。以下是一些關於團隊參與的建議：
試著去理解他們怎麼看世界、他們是如何熱愛自己的工作。 同步清楚的溝通是關鍵。請為忙碌的 product owner 做好榜樣，讓團隊保持聯席。（編按：product owner 是 scrum 開發流程的角色，負責與使用者群體接觸，並決定產品釋出時應具備哪些功能。） 出席會議對寫作者來說是毒藥，開發者也不喜歡。但如果團隊有每日例行會議或是中午有團隊聚餐，那麼請把這些事列為優先事項。如能參與其中，將會知道產品的開發是如何幫您在開始準備內容之前就避免掉不良的決策。 如果您不用 CMS（內容管理系統）作業，那麼您的內容對開發者會是種麻煩。如果可以的話，直接坐到開發者旁邊跟他們溝通，省去為內容版本做確認的時間。沒錯，開發者很注重細節，但是確認大小寫、標點符號與格式是您的工作。 共享目標與點子您的表現反映出團隊的「健康」，如果您肯花時間一起討論您的目標和點子，產品也會跟著進步。 弄清楚團隊想做的是什麼，去了解團隊面臨的問題，同時確定他們明白您的計畫，以下這些問題可以協助你們一起研擬工作計畫：
不像一般生產線式的團隊，開發者的工作是以客戶或 product owner 的優先事項為主，他們專注的焦點可能每天都在變化。在產品開發之前，先完成產品中內容最困難的部份，並且避免在開發過程中不斷更改。團隊會因此感謝您的超前思維。 軟體開發是充滿創造力的過程；開發者是從無到有把東西打造出來。請尊重他們的時間和專注力，對於彼此都滿意的工作時間與方式達成共識。 填補裂縫身為一個專業的溝通者，填補成員與大型團隊之間的裂縫取決於您。您的聲音代表著客戶；您是連結組織；您的工作是用字彙為這個世界帶來 發聲必要時，挺身捍衛客戶和自己的工作。 清楚、簡潔無論您要回報一個 bug 給團隊處理，或是改善更好的使用者體驗，想清楚您要如何表達，並且給出清晰、簡短而具體的指示。 制定一個有彈性、可重複的流程詢問團隊該如何協助他們的工作，可以的話提出一套標準流程。 製作模板請那些要求為產品增添內容的人給予所需的資訊：
這個結構能夠讓您在東西容交給開發者之前，先充實好內容。 將要求具體化在您要交付一項與內容相關的任務給開發者前，先看看是否包含以下項目：
花時間組織好細節會省去之後確認內容更改的麻煩。 使用友善的格式確認您的內容是不是可以很容易轉換成程式碼。如果是網頁或 E-mail，我通常會用文字編輯器直接編寫嚴謹的 HTML；如果是原生 app，我會為 app 的每一頁製作包含下列項目的文件：
一份清楚的文件可以加速專案負責人的審核速度，並且釐清一些開發團隊的小問題。當您的內容通過審核，準備放到產品中，記得張貼到整個團隊的資源庫或團隊用的維基頁面，避免用 E-mail 來傳遞任何重要的訊息，以免在混亂中被漏掉了。 勇敢地對不佳的內容說不無論是來自何人，別害怕對不佳的內容說不。如果內容令人混淆，請與團隊做好溝通，並儘快解決問題。這對於製作（網站或 app）導覽系統、格式、錯誤訊息和 CTA（calls to action）來說特別重要。 更上一層樓當您的基本供熟練了之後，試著更加積極地參與開發者社群。認識開發者們可以提供您關於商業運作更多面向的觀點，避免您對產品開發做出假設。 做自己的專案您可以學習 CSS，或是做一個無需整合伺服器端的 Rails app。挑一本書、動動腦，以下是幾本值得推薦的書：
參與社交活動下次參加網路人的會議時，跳過一些您最喜愛的講者，看看開發人員間的對話。您也可以去找一些同領域人的聚會。 做好充分準備要有彈性。內容就像程式碼，是流動的。改變您的流程以適應您的團隊和客戶。運動一下自己屬於策略的肌群，像是：
確保細節不會在「消防演習」中遺漏。 跟您的開發團隊成為好哥兒們。您對這些關係投注的心血最終會有所回報。平衡溝通、耐心與尊重，你們便能共成大事。 |
| You are subscribed to email updates from Inside 硬塞的網路趨勢觀察
To stop receiving these emails, you may unsubscribe now. |
Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
留言列表
