SmartM 人才培訓網

數位商品開發守則:不要開發聰明,而是人們想要的東西

喬治‧伯克斯基
2015-05-04
數位商品開發守則:不要開發聰明,而是人們想要的東西

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商務社群網」粉絲團,更多商務訊息等你關注。 
嚴禁抄襲,未經授權不得轉載。歡迎各媒體交換文章。

關注工作、管理、商務情報

親愛的讀者,歡迎加入「SmartM人才培訓網」Facebook粉絲團,每天更多豐富的工作、管理、商務報導等你關注與分享。

加入Line帳號,關注最新的工作、管理、商務情報,學習不間斷,精采文章不漏接。