阅读 1945

独立开发该做什么,该不做什么

真正的高手,做事绝不会平均用力,而是把大部分精力投入在价值更大的事情上,从而提高自身效能。

这篇文章来讲,做独立开发,在新功能的开发上、个人工作量的排布上,该做什么,该不做什么。


事倍功半

做独立开发的,大部分都有在公司全职任职开发的经历,做过很多产品经理要求的、细枝末节的功能。很多东西可能 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

关注下面的标签,发现更多相似文章
评论