SmartM 人才培訓網

SmartLinkin：智慧手機當道、各式App等應用程式風行。在這股熱潮中，究竟如何打造爆紅的商品？不管你是想要創業，或是希望在行動應用上找到新商機，App是絕對不能忽略的課題。

 

做出人們喜愛的產品

 

馬克．安德森（Marc Andreessen）是摩塞克（Mosaic）的共同創辦人，這是第一個廣為大眾使用的網頁瀏覽器，他也是網景公司的共同創辦人、矽谷安德森賀維茲創投公司的共同創辦人兼合夥人。此外，還擔任Facebook、eBay和惠普（HP）等公司的董事，非常聰明，對科技業瞭若指掌。 

 

安德森在他的部落格上解釋：「……每個新創公司的生命都可分為兩部分——找到符合市場需求的產品前（before product-market fit，BPMF），找到符合市場需求的產品後（after product-market fit，APMF）。」 

 

他還說：「在尚未找到符合市場需求的產品前，就要盡一切所能，專注於打造符合市場需求的產品，包括改變人事、重寫產品、進入不同的市場，即使心中百般不願意，也要拒絕或迎合客戶……——該做什麼就得做。」

 

找到符合市場需求的產品代表：第一，處於一個適合的市場；第二，打造出一個能滿足該市場客戶想要的產品，否則無法體驗爆炸性成長。 

 

如何讓用戶驚豔

 

保羅．葛拉罕（Paul Graham）是矽谷頂尖新創公司育成中心Y Combinator的創辦人之一，他寫了幾十年的程式後，提出一項真知灼見：「不要開發聰明的東西，而是人們想要的東西。」

 

過去十年，科技公司（特別是軟體公司）發展十分迅速，如開放原始碼軟體、以API呈現的付款、地圖、即時通訊等許多容易取得的服務，都讓開發商能設計出強大的程式。

 

如此一來，現在大家都可以設計出聰明的東西，但卻不易聚焦於開發人們想要的東西。因此，軟體公司已轉變成小巧精實的團隊，集中焦點於提供處理日常生活的解決方案（產品）。創造解決方案而非軟體，會促使實際開發軟體的人更了解客戶及其使用行為。

 

以產品為中心

 

「以產品為中心」（product-centricity）一詞正可說明這種轉變。以產品為中心就是拚命為使用者打造最好的產品，其實使用者並不關心應用程式是不是用C++程式語言寫的，只在乎速度快不快，而且使用前不想閱讀使用說明：希望介面合乎直覺，清楚明瞭。

 

若要打造最好的產品，必須了解使用者是誰，因此「以使用者為中心」（user-centric）一詞的出現，也就不足為奇了。

 

真正成功的應用程式，會把焦點放在這兩個概念的交會點——儘可能打造最好的產品以吸引最多使用者。

 

如果從執行長開始，公司裡每個人都百分之百聚焦於提供使用者最佳體驗，就很可能會開發出極受歡迎的應用程式。然而，如果執行長的焦點不在於產品，而是發展夥伴關係、募資或利潤，那麼產品就非常不容易符合市場需求。

 

經常關注和滿足使用者的需求，這一點至為重要，為什麼？因為人們的品味和流行事物都瞬息萬變，競爭激烈，除非用心了解使用者的改變、成長和發展方向，否則不可能創造出跟上他們腳步的產品。此外，如果沒有把這種DNA植入公司裡（執行長和創辦人對這一點要不斷耳提面命），則很難融入公司每個人每天在做的事裡頭。

 

引領產品願景

 

在此階段，你的公司有兩個關鍵角色，一個負責釐清該開發什麼產品，另一個負責如何開發出來，兩人要能攜手合作。

 

負責開發「什麼」的是產品企劃經理，負責「如何」開發的是技術長（chief technology officer，CTO），由他主導軟體的開發過程。

 

在許多非常成功的高科技公司裡（尤其是以應用程式為中心的那些），通常由執行長擔任產品企劃經理，因為他們胸懷願景，知道該開發什麼產品，且多半會找到能實際開發產品的資深工程師一起創辦公司。一段時間後，執行長的角色變得更複雜吃重，此時需要另尋專業的產品企劃經理，全心全力完成使命。

 

引領產品開發並非易事，我有幸能在多家公司擔任此角色。最優秀的產品人員會聆聽大家的願景、想法和創意，然後提供清楚的資料處理過程，有效開發、測試和改良產品。

 

這個角色的關鍵特質（除了完全專注於測試新產品改良和測量其有效性之外）是有能力說不。「不」這個關鍵字讓新創公司得以聚焦而獲致成功，由於時間、金錢和資源有限，持續聚焦是讓產品符合市場需求的不二法門。

 

查馬斯．巴里阿比迪亞（Chamath Palihapitiya）是個相當坦率的產品人員，也是臉書取得十億用戶背後的一大功臣，他以很簡單的方式解釋產品團隊的角色：測試、評估和嘗試。

 

為了創造殺手級產品，你必須想出好的產品功能，快速開發，與小部分的用戶一起測試，蒐集數據。接著，要是有個新功能提高了一項關鍵指標（例如人們使用的頻率、時間或花費增加），你就將此功能提供給所有用戶。如果產品某功能改良後效果不佳，則必須調整或刪除，很簡單。

 

數據不會說謊，在此過程中沒有太多出錯的空間，除非你不擅長（一）想出可供測試的產品改良方法，（二）釐清如何評估產品改良的成效，（三）判定手中產品功能的相關數據會讓核心指標提高或降低。

 

在「打造百萬美元應用程式」階段，你踏出產品開發的第一步，用紙本原型在星巴克向使用者測試概念，結合所有回饋意見，而開發出應用程式原型。

 

現在要做的就是將此過程植入公司的DNA，建立一個能遵循此過程且不斷改良產品的組織。

 

打造A級（應用程式）團隊

 

若想開發頂尖的應用程式，要靠傑出的團隊，我想在這裡介紹何謂夢幻團隊。在理想的世界裡（或至少是資金充裕的世界），你在早期階段就可以雇用這些人，但在現實中，目前可能辦不到。我們先看看理想的團隊結構，以確認你前進的方向無誤。

 

如果想知道團隊需要哪些成員，最好先深入研究誰能提供下列三個關鍵問題的答案：

 

你正在開發什麼產品？

 

該產品是否解決真正的問題？

 

我們在為誰（目標用戶）解決問題？

 

這些問題的答案與產品團隊脫不了關係。如前所述，通常其中一位共同創辦人會引領產品開發，若非如此（因為創辦人多把重心放在業務、行銷或工程），則須另請高明，專職負責產品部分。在早期，需要有人將創辦人的願景轉為工程師開發給用戶的應用程式。

 

尚未找到符合市場需求的產品前，團隊裡專門負責產品的人不太可能超過一位（理想情況下，還會有一位出色的設計師）。只有等到產品上軌道，才需要擴大產品團隊的規模。根據經驗法則，每六到八位工程師需要一位產品主管（目前尚不需擔心）。

 

情況會視應用程式類型而異。Hailo的產品比較複雜：市場由乘客和司機組成，我聘請一位經驗豐富的行動產品經理分擔工作，我們一個負責乘客應用程式，另一個負責司機應用程式，兩個應用程式必須同時運作，才能到達產品符合市場需求的階段。由於種子期募資順利，所以我們可以這麼做。

 

如果應用程式不複雜，只需要一位產品經理就好，最好把錢花在聘請工程師，全心為公司開發更好的技術。你會遭遇的瓶頸通常不是產品功能的點子不足，而是如何快速讓用戶使用所有的產品功能。

 

在開發應用程式時，還會突然冒出其他問題：

 

應用程式看起來如何？

應用程式使用起來如何？

 

負責回答這些問題的是設計團隊（通常隸屬於產品團隊的一部分）。在「打造百萬美元應用程式」階段，也許只有聘請一位兼職設計師的預算，現在，為了提供殺手級產品，你必須與設計師更密切合作——理想情況下，如果負擔得起應找全職設計師。

 

設計師要與產品經理攜手合作，回答要開發「什麼」的問題：應用程式看起來如何？使用起來如何？有些人清楚劃分產品經理、設計師，甚至「使用者體驗」專家等角色，產品經理只負責列出對於應用程式的要求、設計師只負責應用程式的外觀、使用者體驗專家只負責應用程式的使用方式，老實說，我認為這種分法既無聊又不專業。

 

實際上，產品工程團隊齊心協力，密切合作。每個人的專長的確不同，但到頭來，大家都是應用程式的使用者，而且許多領域會重疊，應該鼓勵所有人注重整個產品經驗，而非單一的部分。

 

設計師（與產品工程團隊合作）負責提供像素完美的應用程式設計外觀，和描述用戶如何與應用程式互動的線框圖。有了這些東西後，就來到極為重要的階段：如何開發應用程式？ 

 

工程師（或開發人員，我會交替使用這兩個詞）負責監督技術，釐清「如何」把漂亮的設計圖變成能運作的軟體，由他們實際動手完成。

 

最後一個重要團隊是要能持續確認應用程式符合預期，提供價值給使用者，且回答以下問題：應用程式的運作是否依照原先的設計？

 

品質保證〔quality assurance，QA，又稱品質工程（quality engineering，QE）〕的任務是確認工程師開發的應用程式，符合原先的設計和規定。該團隊的主要責任，是確認你即將發布給大眾的應用程式沒有錯誤，亦即軟體不會當機、運作能符合預期、使用者介面看起來不會奇怪或不穩定。

 

檢視一下你現階段的應用程式團隊成員：一位共同創辦人引領產品願景和管理；理想上，另一位共同創辦人是工程師，募到種子期資金後，應該至少再延攬另一位工程師（或兩位）加入。你可能無法聘請一位出色的全職設計師，但至少每週要能交流一次，此時大概也無法聘請一位全職的品質保證人員。實際上，確認應用程式運作無礙的重責大任，落在僅有一人的產品部門上。綜上所述，目前的團隊成員共為五、六人。

 

Hailo則是在天平的另一端：我們需要建立一個較大的團隊（可是資金不充裕，意思是薪水較低）。我加入後負責產品開發，有些共同創辦人只領取少許薪資，有些甚至沒拿，我們有一位全職設計師（他發揮極限，同時負責網站、乘客和司機應用程式），還有幾位iOS工程師、幾位後端工程師（back-end engineers）、幾位外包人員以支援開發人員。因為平台過於複雜，最後找來一位品質保證工程師——為了順利推出，我們得做許多產品開發工作！因此，團隊成員約為十到十二人。

 

值得一提的是，世界上一些地方（這些地方真神奇），會有人具備產品管理、設計到軟體開發等所有技能，我稱他們為獨角獸，不要預期你能找到，可是一旦找到了，請好好把握。

 

隨時推出新功能

 

要成為千萬美元應用程式，且找到符合市場需求的產品，就要能快速開發產品功能、測試、評估，採用其中最好的功能，然後重複整個過程。雖然聽起來很簡單，但需要十分了解軟體開發——我們花點時間來看一下。

 

軟體開發的方式不斷演進，我必須提到技術層面（但我有充分的理由），談論敏捷軟體開發（agile software development，業界簡稱為「敏捷開發」），意思是以有效率和效用的方式，設計、交付、測試和配置軟體。

 

若想更了解敏捷開發，比較好的方法是從反面敘述，敏捷開發不是將你想做的東西列出詳細大綱，交由開發人員執行；不是巨細靡遺規劃你的軟體開發，明確指出未來幾週和幾個月的進度；不是給開發團隊一張死板的功能設計清單，然後放任他們自行寫程式。

 

敏捷開發是指在一段固定的短時間內，提供有價值的功能或改良，這段期間叫作「開發衝刺」（development sprint），一般持續一或兩週，目標是從頭開始，提供某個有價值的東西（一個特定功能）讓用戶使用。

 

為什麼它很酷？因為每兩週就可以為用戶提供新功能或改良，代表每兩週用戶能測試新功能，讓你評估是否要留下這個功能。自然地結合了使用者對產品改良後的回饋，和你原先規劃要他們測試的新產品功能。

 

這些實用的功能或改良其實稱為「使用者故事」（user stories），本質上是完全以使用者為中心（例如使用者能用應用程式做的事）來列出一項功能，交由開發人員於一至兩週內設計完成，像是：「身為XX應用程式的新用戶，我希望在地圖點一下，就能把某個地點存到我的最愛地點清單裡，方便未來使用。」

 

系統若要成功，得靠產品團隊為「使用者故事」詳加定義，提供足夠的細節，讓開發人員撰寫出執行此功能的程式碼，包括所有必要的步驟、每個螢幕畫面、按鈕、文字敘述、轉移條件（transitions），以及該有的圖形。

 

敏捷團隊的定義，是指一群人完全獨立自主，採用、執行、測試、配置一個產品功能，最後讓用戶使用。這個概念相當棒，如果團隊規模小，運作成效會很好，但如果你的開發人員多達二、三十位，成效也很好，因為團隊可以同時自主運作，所以在改良產品的過程中，不會碰到瓶頸。

團隊在同一地點工作較佳 

 

這裡很重要的一點是，你的團隊成員應該在同一個地方（因為團隊成員分開或在一起這兩種情況我都經歷過，而且曾跟許多新創公司討論過這個主題），尤其是只有產品／設計／開發／品質保證等少數成員的小團隊。原因如下：

 

我們先從理想情況開始，如上所述，組織（目前小規模）產品開發團隊的真正目標，是讓他們有能力快速推出應用程式的新版本，這件事仰賴有效溝通，過程並不容易。

 

為了能經常「推出新功能」，就要持續改善程式碼，等用戶使用後提供回饋，再看看應用程式是否因此變得更好，你必須在每個可能的層面上追求效率。

 

也就是說，要讓整個產品／設計／開發／品質保證團隊都在同一個地點，隨時待命。如果其中一位或多位成員在遠地工作，只會讓溝通效果不佳，少了大家在同一個房間面對面溝通的機會，也無法隨時私下交流。目前你的團隊規模還太小，尚無法各自為政。

 

等你接近一億美元應用程式階段（開始以瘋狂的速度成長），溝通絕對仍是關鍵。因此你現在所建立的溝通文化，未來將得到豐厚的成果。

 

外包的真相

 

常有人問我是否該將開發工作外包，答案很簡單：不要。如果你想建立一個十億美元的一流科技公司，絕對不要將軟體開發外包，因為這是公司的核心。

 

話雖如此，沒有任何事是非黑即白，我來描述一個合理的灰色地帶。無論如何，你的公司必須有自己主要的核心開發人員——也就是工程部門主管（此時，你要稱他為技術長或工程部門副總裁都沒關係）。如果公司內部沒有一位稱職的高級工程師，你也不會知道該如何外包開發工作，你怎麼知道他們該用哪些技術？他們的架構是否健全？盲目相信外包廠商並非明智之舉。

 

這裡有個折衷方式，但永遠都只能以折衷方式看待。一旦你有了工程部門主管（最理想的是，還有幾位全職工程師加入），才會有一個人能管理外面的開發公司。

 

你的工程部門主管或技術長，應該負責技術和架構方面的決策，管理外面開發夥伴的工作內容，同時還要招募全職工程師加入團隊。否則的話，一定會有問題，不是開發不出有趣的東西，就是你的願景沒有說服力——或是高級工程師能力不足。我看過很多新創公司（已募集到種子資金）如此行事，注定要失敗。

 

各種代理商

 

在產品和應用程式開發過程的各階段，會碰到三種主要的代理商，我快速帶過，讓你評估是否值得花時間（和金錢）與他們合作：

 

綜合代理商。新創公司請注意：這些人存在的目的，是誇下海口承諾提供太陽和月亮，還一併附上一、兩個行星，讓公司的荷包大失血。除了設計品牌識別外，他們還會開發網站和應用程式。像百事可樂（Pepsi）這種手頭寬裕的公司，以外包方式取得任何想要的東西，絕對合情合理——但新創公司這麼做毫無道理。如果請這些人開發應用程式，等於完全無法控制應用程式的架構、程式碼的品質等，簡直失去建立一家技術公司的意義，而且代價昂貴。

 

開發代理商。他們很有趣，實際上專注於提供軟體，通常聚焦於Ruby on Rails、超文字預處理器（PHP）和Android等特定技術平台，會在各層面提供協助：從架構、資料庫設計、API開發，一直到應用程式開發和測試。要是技術經驗不足，這些服務相當有用，但如前所述，你要引導他們的方向。英國有些非常出色的公司，如Thoughtworks，每日的收費十分驚人，但合作時間越長，會越具成本效益。舉例來說，烏克蘭代理商的英文流利，熟知目前所有的專業知識，合作起來非常愉快（Ciklum是其中最受歡迎且經驗豐富的一家）。波蘭和羅馬尼亞代理商也同樣很可靠，有技能、語言和設計才能等優勢，已逐漸取代印度公司。

 

品質保證代理商。我和品質保證代理商合作的成果有好有壞。要找到才思敏捷的品質保證工程師總是一大挑戰，所以會覺得與品質保證代理商合作很吸引人，不必自己再做一次。Hailo的團隊陣容堅強，最後能與我們合作的代理商，必須要樂於指派經驗豐富的品質保證工程師到我們辦公室，在我們來不及聘請工程師時提供協助。

 

坦白說，要建立出色的產品工程團隊沒有捷徑。必須能打造出真正才華洋溢和精實的團隊，才能提供深受喜愛的產品，要是無法延攬到適合的人才，就反映出你目前的願景、團隊或市場機會的品質也許不佳。永遠不要對代理商上癮——他們只是暫時的替補援手。（本文摘錄自《如何打造營收上億的App》第14章）

 

 

書籍介紹

 

書名：如何打造營收上億的App

 

作者：喬治‧伯克斯基

 

出版社：商周出版

 

出版日期：2015年4月

 

喬治‧伯克斯基（George Berkowski）

 

連續創業家，他創的事業包括載人太空飛行、線上約會、運輸與行動應用程式。全球知名計程車叫車應用程式 Hailo 的領導人之一，帶領產品團隊至 2013 年 9 月為止。伯克斯基在麻省理工學院（MIT）研讀火箭科學與經濟學，在巴黎高等商業學校（École Supérieure de Commerce de Paris，後與其他學校合併為ESCP歐洲商學院）學習商業管理。目前是麻省理工學院企業論壇英國分會的會長，並高度參與英國與美國的新創事業活動，往返於倫敦與矽谷兩地。

 

延伸閱讀：臉書玩得好，升遷、轉職都加分

 

嚴禁抄襲，若欲轉載，敬請註明出處「SmartLinkin商務社群網」並附上原文連結。

歡迎各大媒體交換文章連結。

圖片來源：主圖、縮圖-Microsiervos Geek Crew(CC Licensed)

加入「SmartLinkin商務社群網」粉絲團，更多商務訊息等你關注。