真正的高手,做事絕不會平均用力,而是把大部分精力投入在價值更大的事情上,從而提高自身效能。
這篇文章來講,做獨立開發,在新功能的開發上、個人工作量的排布上,該做什麼,該不做什麼。
事倍功半
做獨立開發的,大部分都有在公司全職任職開發的經歷,做過很多產品經理要求的、細枝末節的功能。很多東西可能 1000 個使用者裡面只有 1 個人用,但由於產品經理認為這個東西有價值,那作為工程師,也不得不去把它完成。
而這樣的東西,在我們獨立開發的過程中,往往事倍功半。所以我並沒有說“不該做”,我的措辭是“該不做”。獨立開發往往一個人要幹十個人的活,如果事事都按公司裡面那套流程來,必然效率低下。
既然獨立開發要乾的活是全面的、時間是寶貴的,那麼做東西必然**要考慮投資回報率。**如果一個需求,既不能在功能上對你的產品有明顯改變、也不能在體驗上有明顯優化,那麼投資回報率就是很低的,就不值得去做。
反之,有些事情在公司裡找人專人負責的,我們或許只需要幾行程式碼就能做到 80% 的效果,這種東西就必須去做。
該做 - 刷評分
無論是蘋果的 App Store 還是各類安卓應用商店, 應用都有辦法跳轉到商店來讓使用者給應用評分。iOS 10.3 之後還有這樣一個方法,來讓使用者留在 App 內就可以方便地給 App 進行評分。
class func requestReview()
然而很多人對於評分這件事,都是最多在設定頁裡面加一個按鈕之類的入口,讓使用者主動去給應用評分。
這是不行的,這是低效的,讓使用者來主動做一件對他沒什麼好處的事情,我們要積極主動,而不能冷淡處理。更不能嫌麻煩,覺得這和產品本身無關,就不去做。
而實際上,拿 iOS App 舉例,只需要上面那一行程式碼,就可以引導使用者評分。你只需要選擇一個恰當的實際就可以了,比如使用者剛剛成功地儲存了一張圖片到相簿。有人說這種評分機制被蘋果限制了,一個使用者對一個 App 一年只能用三次,於是不敢亂用。然而你看看自己的使用者留存率就知道,絕大部分使用者下載了 App 之後可能就把它刪掉了,或者是再也沒有開啟。這三次機會,多數情況下,你一次都用不掉。所以一定要積極讓使用者去評分。很多應用在這方面沒做好,應用下載量很大,但是應用商店 5 分的滿分評分,使用者評分只有 4 分不到,評分數量也非常少。這一點可能只需要花掉你不到 10 分鐘的時間就可以改變,然而它對使用者看見你的應用的印象分提升卻可能是比較大的。
大公司僱專人來做的刷評分這件事,你沒理由不做。有關去淘寶花錢給自己刷評論、提升關鍵字搜尋權重的 …… 涉及灰產,有興趣可以自行搜尋。
該做 - 常更新
個人開發沒必要和公司裡面的 App 排期更新一樣,比如固定一個月更新一次。
當看到使用者有反饋(問題或新功能需求),自己確定可以馬上實現的話,沒必要等到很多東西攢到一起再打包更新。
一直迅速迭代、小步快跑。不僅可以讓新使用者覺得你的產品一直在更新,可以獲取使用者信任。當使用者發現自己的反饋,及時地出現在新產品中時,使用者也會有一種參與感,從而幫助你的產品形成口碑效應。(小米的 MIUI 論壇就是這樣做的)
當然,如果對倉促加入的內容的穩定性不放心,也要使用灰度來發布新版本,並且時常關注後臺統計的 App 崩潰等問題。
該不做 - 永遠自己寫後臺
我的建議是,有適當的需求和能力的話,獨立開發者是可以自己寫後臺的。重點在於,不要認為獨立開發者永遠應該自己寫後臺。
很多時候,如果你不是對自己的後臺維護特別放心,使用第三方服務是可以提高後臺的穩定性的。並且,獨立開發很難 24 小時做運維,使用第三方服務,是把運維工作外包出去的一個好方法。
該不做 - 過度相容機型與系統
對於各種多年以前的老版本系統,以及很多年前釋出的舊機型,一般大公司都是選擇儘量相容的。因為哪怕是多照顧 1% 的使用者,都可能是上百萬的收入,遠大於做決策的人的工資。
而對獨立開發者來說,放棄 1% 的使用者一般不僅不會對收入帶來太大負面影響,並且這 1% 的舊機型使用者,很多年齡偏大,或者是有人把手機當做備用機來用的,這部分的使用者的付費意願是很低的,這 1% 的使用者量,體現在收入上,可能連 0.1% 都不到。
這樣一來,為了相容舊版本系統和過舊機型所付出的工作量、以及解決出現率很低的 bug 所耗費的時間,就都可以節省下來了。用這些時間、精力,去做開發新功能、收集使用者反饋等工作,可能是投資回報率更高的事情。該做- 儘可能多地存檔資原始檔
對於平時會用到的設計稿、圖片資源、應用商店需要用到的各個語言版本的 App 描述、不同尺寸的應用截圖等一系列與程式碼無關的內容,都可能在你日後做重構、改版的時候用到。
平時多花點時間,把這些內容都索引起來,直接放到 Git 來託管,是非常值得做的一件事情。一點小習慣,可以為日後找不到檔案節省大量的時間。
以及,對於 Git 裡面的哪一次提交,對應於 App Store 的哪個版本,也要有記錄。這樣在使用者反饋的時候,可以一眼看到使用者使用的版本,是不是沒有進行過某次更新的舊程式碼。
該不做 - 過於詳細地產出設計文件與程式碼文件
與公司裡面,文件產出儘量要讓別人看懂不同。獨立開發過程中,由於從設計原型到程式碼落地,這一過程很多時候是自己在完成。如果整理了很多中間步驟的設計文件、開發文件,其實是對時間的浪費。
唯一的標準,其實應該是自己可以把控的 —— 未來自己能看懂即可。
我個人的習慣是,無論是設計的 Sketch 檔案、還是工程的 Xcode 檔案,都儘量有完整的註釋、明確的檔案命名,儘量不出現 image1、image2、rect1、rect2 這種沒有實際意義的命名,但是儘量少地單獨產出文件。關於作者
KyXu,多年獨立開發經驗,長期致力於幫助廣大移動端開發者 變現、擁有自己的產品、成為獨立開發者,微信公眾號:KyXuIndie
關注專欄解鎖更多幹貨:xiaozhuanlan.com/kyxuDev
加我微信入專欄讀者群:balabala-ba