外包網首頁 > 接案知識庫 > 專長入門與行情   

列印文章

打造A級 App 開發團隊

文章來源:商周出版  發表日期:2016/04/21  瀏覽數:4330

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

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

  • 你正在開發什麼產品?
  • 該產品是否解決真正的問題?
  • 我們在為誰(目標用戶)解決問題?

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

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

  情況會視應用程式類型而異。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》一書,由商周出版發行。