Nelson 寫些 iOS 開發的東東

開發產品學到的一些事(下)

| Comments

一個 APP 開發工程師在 start-up 打滾幾年之後,得到的一些心得跟體會,上集在這裡

善用追蹤工具

做任何決定之前都要有所本,不要突然「通靈」了就做出莫名其妙的決策。那要根據什麼做決定呢?很簡單,讓數據說話。善用至少一款追蹤工具(GAMixpanelFlurryKissmetricsKeen IOCustomer.ioSegment 等等)並在上線第一天就開始追蹤使用者的行為,這樣才能知道有多少使用者在用你的產品,以及如何用你的產品。總之,就是要透過數據收集與分析,來了解你的使用者。

日後當你要做 growth hacking 的時候,追蹤工具更是不可少,你會需要這些追蹤工具來幫你統計,看哪些修改會有助於你的業務成長,哪些修改反而會讓業務衰退,以及成長或衰退了多少。

如果有開發 APP 的話,你也會需要想辦法取得 crash log,這樣才知道程式掛在哪,我推薦使用 Crashlytics 幫你收集分析這些 crash log,它非常的好用。

愛用第三方元件

近年來 open source 越來越受到歡迎,網路上有各式各樣的第三方元件讓你取用,所以真的沒必要每一樣功能都自幹,如果有現成的可以符合你的需求,就大膽的用吧。再加上第三方元件的管理程式(像是蘋果開發者常用的 CocoaPodsCarthage)也越做越好,早期會遇到的第三方元件版本控管問題已經很少見了,所以我建議各位可以盡量用第三方元件,或是將第三方元件修改成符合自己需求,沒事不要自己造輪子。

方便的更新機制

隨著時間過去,你的產品需求一定會有所變化,該怎麼向後相容以及如何要求使用者升級就變成一件不得不面對的問題,這裡我有幾點建議讓你參考。

  • 設計 API 的時候要考慮版本化

    同一支 API 背後的商業邏輯很有可能會變化,如果一開始設計的時候沒有考慮版本化,你就會為了 API 名稱而大傷腦筋:可能原本的叫做 checkout,後來叫做 checkout_new,再後來叫做 the_new_checkout

    但如果一開始有考慮版本化的話,你就可以一開始叫做 checkout/v1,後來叫做 checkout/v2。或是直接改 API end point,例如一開始的 end point 是 api.myserver.com/v1/,後來的是 api.myserver.com/v2

  • 呼叫 API 的時候附上環境參數

    雖然現在送 request 的時候,大部分都會在 header 附上 client 的一些資訊,但每個 client 送出的 request header 格式有可能並不統一,所以要 server 去 parse header 來取得所需資訊,其實成本蠻高的。

    比較方便的方法是,client 每次在呼叫 API 的時候就主動附帶一些參數讓 server 好判斷。例如可以送 platform 參數指明是 ios / android / webdevice 指明是 phone / tablet / desktopversion 表示程式的版本等等。Server 就可以根據這些參數有不同的邏輯與回應資料,例如根據 device 回傳不同尺寸的圖片網址,或是根據 version 來得知對方是否使用最新版本。

  • In-App Announcement

    如果一開始就有設計 in-app announcement 機制的話,就可以更輕易讓使用者得知最新消息。例如有新版本可以下載了,讓使用者知道有什麼新功能並引導使用者去下載。或是有在舉辦什麼活動的時候,也可以透過這個機制讓使用者知道(例如 Uber 時常會舉辦不同活動,車子圖示也會跟著變)。或是有什麼新貼圖、新佈景主題、新內容,也可以讓使用者知道(例如 Line 或各款遊戲)。

  • 儲存資料的時候要考慮版本化

    有很多時候我們必須儲存一些資料在本機,可能是透過寫入設定檔或是寫入資料庫,如果儲存資料的時候有考慮到版本化,之後要處理資料相容或是要將舊資料轉換成新資料的時候,都會相對簡單許多。

寫文件

所有人都知道寫文件的重要,但是大概沒人會喜歡寫文件,但其實文件沒那麼難寫。文件存在的理由是什麼?不就是為了日後的查詢參考嗎。

所以 User Story 就是文件的一部分,你一邊設計產品的同時,就一邊在寫文件了。這樣有沒有覺得寫 User Story 很划算,會不會更有動力寫好它!

程式碼註解也是文件的一種,現在有很多工具能夠將註解轉換成說明檔,日後只要註解有所變動,說明檔就會自動更新,這可以幫忙省下超多時間。像我們的後端都會在程式碼裡頭註解說明這支 API 的用途是什麼、傳入的參數是代表什麼意思、是什麼型態、是否可以不傳、回傳值是什麼、有可能產生哪些 error,對應的 error code 是什麼等等。我個人覺得,維護程式碼的註解比額外維護一份說明文件(可能是 wiki 或是 doc 等等)簡單多了。

文件也不是寫完丟在一旁就算了,它是讓人日後可以查詢參考的,所以最好可以把所有文件統一放在一個地方,然後有個方便的作法讓人查詢(可能是規劃良好的目錄結構,或是提供搜尋功能等等)。

簡單來說,文件有三大重點:要完整、要保持最新版本、要讓人找得到。

畫 Wireframe

通常設計師會畫好 wireframe 讓工程師知道整個使用流程,明白該從哪個畫面跳到哪個畫面。如果很不幸的,你們公司沒有這種東西(可能是不見了或根本就沒有),那 APP 開發工程師就認份一點自己畫一個吧。對工程師來說,畫這個並不難,只要把 APP 每個畫面都擷取下來,然後用箭頭把彼此之間的前後關係串起來就可以了。

擁有一份完整的 wireframe 的好處在於,當你們想要增刪或修改某些功能的時候,可以把 wireframe 拿出來,看看增刪或修改這個功能之後,整個使用流程是否順暢合理。千萬不要功能都做完,才發現流程變得卡卡的,這樣浪費的成本太高了。


以上就是我的一些心得,對上集有興趣的人可以看這裡

老實說,就算每一點都做到了,也不保證你的產品會成功,但絕對會讓你開發一款新產品時比較不會走歪,就算歪了也可以早一點救回來,降低你犯錯的成本。

Start-Up Product

Comments

comments powered by Disqus