Just My Life & My Work

2020年末回顧年度App成長

2020年~新冠肺炎疫情瀰漫全球一整年,終於來到最後倒數計時,總是要來回顧這一年來的收穫,看我們在哪個地方成長多少。

我在公司負責產品已超過一年,經過我一手「調教」之後的App,在品質與用戶是否有成長呢?透過Google後台統計,可輕易檢索各式各樣的指標。首先就以「事件數」和「用戶數」來看成長幅度。

整個時間軸我調整一年來做比較,期間2019/12/15-2020/12/15對比2018/12/16-2019/12/17。可見圖表有藍色實線與虛線,實線代表最近一年,虛線代表前一年,可清楚看到最近一年成長幅度相當大!

我最愛看用戶數指標,因為流量大也就代表營收多。很高興我們用戶數一年累計約110萬,每日都有1萬上下用戶使用。好奇突起物是什麼?就是活動推播囉~今年的推播次數很多吧!

我這一年來為公司貢獻多少?基本上從數據就能看出來,不過當然也不是我一個人就能辦到,我僅負責App程式端。用戶在App下單後,就會開始作品製作流程,最後出貨送達用戶手中。

在我加入公司後,App開始往「社群化」發展,這是我進公司前跟老闆建議,可以增加用戶對App黏著度。原本僅是個工具來編輯作品,我們要以過去為基礎,加上善用行動裝置的優勢,讓更多人有機會接觸我們的App。

來條列我參與的項目:

增修功能:

  • 多相片版型:原本每個頁面的版型只有:(0-1)個相片框+(0-1)個文字框,經過我巧手編制後,已能使用(0-5)個相片框+(0-1)個文字框
  • 相片拖曳對調:承上,既然已能使用多相片框版型,那麼在UI/UX就得更加方便與流暢。像是若我使用五個相片框,我想要對調相片,較好的方式就是經由拖曳來替換,而非如過去僅能一張一張重新選擇相片來放置。
  • 線上版型:App和Web有個大差異是前者需要「審核」才能上架,現在App功能普遍都需要在連網狀態下才能使用,為了保有彈性來增減版型,我們透過API來取得版型清單,也就如此不需要讓App再次送審上架,即能享用最新的版型。
  • 上線新產品:布幀本、相片沖印6X8、隨手翻6X6、木座桌曆
  • 產品新增功能:木框畫系列支援圖文雷雕、經典桌曆支援主題、明信片支援主題
  • 普遍性功能:作品分享、Apple登入、急件、找靈感(逛作品&部落格)、好書店

崩潰紀錄:

若說App完全沒有Bug和不會Crash,那肯定是人間奇蹟。在一個持續成長的App,有時候為了趕工無法測試完全,也偶爾會因增修某個功能而對其他功能埋下「地雷」,礙於測試人員不足,總是會在上線後收到用戶回報,才曉得原來我們不小心出差錯⋯⋯

現在我們會透過Crashlytics來記錄崩潰,若是邏輯性錯誤(非崩潰)則以Event來統計次數。崩潰會直接知道是哪個Class的哪一行Code有問題,修正就顯得容易許多,而邏輯性錯誤則先以統計發生次數,若太過頻繁發生,再來回溯邏輯哪裡出問題。

這一年來,我們家App維持在99%無崩潰的狀態。

重大失誤:

最讓我感到絕望(一點也不誇張),就是明知道最新上線版本漏洞非常大,卻無法立刻挽救⋯⋯因App不像Web,一旦上架被下載後,許多功能就只能在下一版本被修正,若是由API控制的資料,是可透過後台來修正,不過內建在App的邏輯只能望錯誤興嘆哪~

失誤主要有兩種:

  1. App內邏輯錯誤
  2. API資料錯誤

需要重新上架的是1,錯誤影響範圍非常大,只要用戶沒有更新App,該錯誤就會持續被延續⋯⋯比如3.7.6版,我測試新開發好的功能,但沒有測試完全,使得部分產品受影響,讓用戶無法完成作品⋯⋯

2020-03-25的截圖,3.7.6才上線四天,15天後還有14%使用率呀~

這是典型的增加新功能弄壞舊功能狀況!只是一不留意忘記加入判斷版本、產品、功能,就會埋下不知何時會爆炸的地雷。

1的修正或阻擋失誤有以下幾種:

  • 作品上傳到伺服器時,可判斷是哪個版本、哪個作品、哪個功能,並強制將資料植入以端正。
  • 承上,若無法透過自動方式修正,偵測有問題的作品上傳時,便以Slack通知,以便人工調整。
  • 由於有問題的App版本會一直在市面上流通(很難完全讓有問題App更新),隨著時間有問題的作品會逐漸減少,但依然得留意曾經鑄下的大錯。

遇到2的錯誤能立即解決,找到出問題的API,修正後推上線。

第三方問題:

Facebook SDK有兩度發生問題,使得一開App就會Crash,造成全世界(真糟糕⋯⋯)有用Facebook SDK的App慘況爆表!馬上在App Store上收到差評,也就是不斷地Crash,被誤會是我們的問題,確實我們不該太依賴FB,這就是我們最大的問題XD~

我們撈推播資料回來,卻發現時間顯示有問題,追溯問題到App內邏輯或是API資料,查證後認為這兩個沒有錯,經過幾個月某幾次推播都有同樣的問題,才找到原來是第三方套件的問題,在於解析XML發生錯誤,解決之道就是不要使用「>」字元,因為XML格式中有非常多「>」,是用來判斷哪個標籤。當然我也可以大費周章換掉解析XML的套件,不過誰知道下一個就完全沒問題?要是有充裕的時間,我可以測試所有狀況,不過就當前時間寶貴,還是簡單解決問題!為了避免負責推播人員忘記,我必須寫個判斷式,讓解析不出來的話就顯示現在時間。

2020年Instagram API大調整,使得我們也要更新串接部分。由於前人使用第三方套件來整合Instagram API,我勢必得清楚知道整合的廣度與深度,要嘛整個拔掉,不嘛只是硬插新流程。儘管我成功更新可運作,程式碼卻不好閱讀與維護,使用體感不如過去順暢,甚至在較舊機型(如iPhone 6)會崩潰。

2020年Fabric和Crashlytics已被納入Firebase,還好只要透過Cocoapods更新,再稍微調整寫法,並沒有出現太大問題。

困難與挑戰:

公司iOS App和Android App是從2012年進行開發,邊開發邊維護已經8年,經歷許多優秀開發者「加油添醋(是褒揚~)」與神來一筆,才成就今日功能和產品眾多的App,當然免不了日積月累的技術債,都將在往後維運日子中陸續碰上,並持續修補與更新。

由於公司成立時,智慧手機尚未火紅,最早期的產品就是透過電腦來使用的編輯器,這讓我們公司得以當領頭羊。隨著時間潮流,陸續有競爭對手出現,智慧手機逐漸普及,公司意識到勢必得在行動裝置範疇迎頭趕上。

挑戰之一:Web與App的優缺

該怎麼做才能讓Web和App產品一致?以我們的產品範疇來說,是非常得難!電腦與手機有各自先天的優缺,我當時就建議老闆,App就該發揮其本身的優勢,而非全部功能都從Web搬過來。若是把App做得像「瑞士刀」,雖可以滿足一部份人的需求,但同時也會失去一部份人的耐性,而我們開發時間會拉長,得到的效益卻不大。

對於公司產品的世紀難解問題,就是Web要與App保持一致,如上圖。

挑戰之二:舊版與新版的相容性

我們家App顯示的資訊,一部份儲存在手機,一部分來自伺服器,這在版本更新會需要做「向下相容」,也就是用戶更新版本,同時也要讓舊版本正常運作,新舊版本會持續存在,直到所有用戶都更新到最新版本,才能安心放棄舊版本,但這基本上不可能!看那偉大的Apple不就每年有意無意驅趕用戶更新iOS~

我們App資料存在手機端,也有在伺服器端,新舊版本控制便顯得非常重要。必須做到,用戶在舊版本App製作的作品,升級新版本App後能繼續編輯。

挑戰之三:規格有限的設備

設備上需要改進的是筆電的容量,最近為了更新Xcode,大費周章地把某些檔案刪除,才有足夠容量安裝新版Xcode。詳細情形可見我紀錄的文章:安裝Xcode空間不足。下次若要更新硬體設備,非常建議公司採購至少256GB以上的筆電!不然我會花不少時間在刪除冗贅或暫存檔案。

挑戰之四:難以擴展的技能

我當前職涯目標是同時精進iOS和Backend,如此我能一個人獨自完成前後端程式,這會讓我生產力提高非常多!公司確實有如是環境讓我磨練,只是若要全心投入Backend,勢必得對前人的Code了然於心,才能修改得正確且無產生Bug。

其實鍛鍊技術能力,較快的方式就是重新打造,因為可以毫無顧忌地發揮,當然還是需要看前人的程式碼來學習,只是得到的成就感差異很大。

我嘗試協助製作Web的前端Interface和後端API,但因為不熟悉工具與語法,所以進展緩慢,甚至耐不住性子,會想要「抄捷徑」,直接改掉共用的函式XD~這會造成增加新功能弄壞舊功能,但若瞻前顧後,開發進度肯定慢得像烏龜。

於是,我僅想要增修簡單的部分,不需要大範圍檢查可能影響的地方。畢竟若是後來上線出問題,到時候要找出源頭也得花時間。說個實際發生的例子,同事聊到某次老闆心血來潮,改了某一段程式碼,結果出差錯需要補救,但老闆已不知如何修改起,於是請同事幫忙。幸運的是,Web修改後馬上就能上線,而App則僅能再次送審才能上架。

App和Web開發步調非常不一樣,除了開發環境不同之外,在開發過程也有大差異。開發App基本上是「編譯式」,每次修改再怎麼小如錯字,都得重新編譯來安裝測試,而編譯時間都能讓我去上個廁所;開發Web則是「直譯式」,若僅改一行程式,儲存後重整,馬上就能看到成果,速度非常之快!App上線至少需要一天,包含送審與上架,需要經過Apple與Google的審核,這是經過第三者平台,所以時程上有風險;Web要上線呢?其實只要一分鐘,推上Git版本控制,對外伺服器拉下最新Master,立馬就能讓用戶享用~

挑戰之五:開發新功能與維護舊功能

按圖索驥是較理想的方式來了解整個產品,不過工程師通常不會寫文件,最多就是留下與外部溝通的文件(例如Web Service文件、介面設計文件等等)。於是,基本上我得從程式碼來探索,了解整個專案架構如何,如果要說個數字,一開始大概10%我能掌握。我可透過把玩公司App,來了解與程式碼相對應的部分,從大範圍到小地方,看程式碼命名大致可了解。

公司產品至少經過三位前賢開發,架構大抵上在第一位已決定,後來者多能順從架構繼續開發與維護。正常來說,產品不可能一次到位(產品會持續成長),也不可能什麼都想做(必須取捨且決定先後順序),於是乎當初所做的決定,會影響之後開發流暢度。

當然我們都希望能把架構做得相當彈性,使得後來擴充能比較容易,不過在需求不明的情況下,怎麼可能做到準確預測未來會做什麼功能?況且設想得太多寫起來就變得複雜,以人性的角度來看,當然是以最快速且精準的方式實作。是以當時「最佳解」來進行。

行銷與體驗:

公司發展品牌,勢必得讓產品與服務維持一定水準,於是會在行銷和體驗下大功夫!

原本付費方式僅有三種:

  1. ATM
  2. 信用卡
  3. Paypal
  4. 支付寶

在我的建議與期待下,終於開通Line Pay7-11 超商代碼繳費。近十年(2010-2020)來,行動支付、電子支付與第三方支付如火如荼發展起來(已經比大陸慢太多了!),市面已充滿各式各樣的支付方式,在人手一機的時代下,付款的方式變得多元,我們當然也就必需強化付款管道,用戶越是能輕鬆付款,就越能提高營收,於是不管男女老少,都會是我們的客戶。

將來我會建議再加入街口支付,其跟Line Pay有類似的市場影響力。

我非常重視UI/UX,努力把產品做到連自己也會想用。App中的A畫面到B畫面,我會希望平滑地轉換,而不是突然跳到下個畫面。我會加強動畫特效,讓用戶的眼球跟得上畫面,如此賞心悅目,必然增加黏著度。

客服方面:

由於上架到App Store,會有用戶去評分評論,我會時常會留意用戶的回饋。當然我們都希望用戶評滿分五顆星,但我們也要樂於接受差評,這是我們成長的關鍵之一。我會以客服的角度去回覆每一則評論,包含我未經手時期的評論,未來新舊用戶看到認真不馬乎的回覆內容,就會更加信任我們公司的產品與服務。

例如會看到兩年前用戶許願「希望有較多相片的版型」,今年我就回覆「目前已支援多相片版型 🙂」。用戶願意留言是相當難得的事情,那麼我們就得用心對待與回應,將來一定會有新用戶,會仔細查看App是否值得信任,畢竟要把私人相片上傳平台,需要有一定的信任感!

接著來展示一下我回覆久遠之前差評的留言吧!

有差評當然也有好評,不過通常都是差評砲火猛烈,好評難得會長篇大論~

其實我有建議可以衝評分與評論,進行促銷活動讓用戶願意給好評,或是在用戶心情愉悅下請求留好評。

2019/11我們有450多個評分(平均4.4),就很好奇競爭對手怎麼能夠達到22000多個評分(平均4.9),絕對是有在進行相關作業,這是我們要去強化的部分!

到了2020/12,我們有約650多個評分(平均4.4),就很好奇競爭對手怎麼能夠達到32000多個評分(平均4.9),經過一年的時間,我們才增加200多個評分,而對手居然增加10000個評分!!!

下個年度計畫,我會建議公司多修飾App門面:)

評量與回饋:

每次公司的自我評量,我都會盡可能寫我經手的項目,大多數的工程師會覺得寫這兒好無趣,最好幾句話就帶過,直接看成果就好。

從世界末日2012年開始,我已習慣用Trello在記錄我的工作進度,像卡片般用眼睛掃過去一目了然,知道這一週、一個月甚至一年間我進行了哪些任務,習慣隨手截圖並輸入關鍵字句,當我回首展望,充滿令人欣慰的過程!

我總是期待能「做我所愛,愛我所做」,儘管現在可能很辛苦在工作,但這些過程將會引領我往期待的方向走去!

結語:

期許下一年度,我所經手的部分都能有正向成長,讓公司整體業績往上提升。

我的技能方向是技術與行銷並進!

Comments on: "2020年末回顧年度App成長" (1)

  1. 還有非常偶爾的舊版本(例如3.2.7),在印製時會被檢查出手機截圖與編輯器不一致問題!😝

隨意留個言吧:)~

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

標籤雲

%d 位部落客按了讚: