这是芃篙君的第319篇原创
本文适合软件行业的朋友。大概1900字，阅读需要8分钟。
从软件开发者的视角来看，软件升级似乎没什么不能理解的。因为软件之所以”软“，跟硬件相对比最大的区别就是可以OTA。如果不升级，搞软件就丧失了超过80%的意义。
但是，客户并不一定这么认为。
01 toB 软件的困境
toC的业务，APP软件的升级一般由应用商城负责。大部分用户一般设置个连接WiFi时自动升级、自动清理安装包就搞定了。对用户来说，没啥负担；对开发者来说，也没有那么大的压力。
toB的软件则不然。大部分客户对软件的要求，基本上就是保持稳定就好。并且客户是一个组织，真正负责做事的一般就是个别对接人。如果客户整体是懂软件的，那可能还好；但是如果客户企业是偏传统的，问题就比较麻烦。客户的对接人的个人绩效可能就是偏向于保守不捅娄子的，那么他个人并没有意愿去了解什么的软件的意义，而更看重投入的成本、风险和产出的结果。做出偏保守的决策，就太常见了。
但是，软件总是不能一直放那不升级的。有可能是发现了个别兼容性的问题，在新版本已经改了，老版本还存在；有可能是客户看中了新版本的某个局部的新功能；还有就是诸如Android和iOS的每年年度新系统版本适配的硬性要求。
对于保守的客户而言，这些情况都可能演化出更让人头疼的问题。
什么，你说老分支有BUG，那你得给我在老分支改掉呀。
什么，你说这个新功能在老分支上没办法简单的合并上线，那你得想办法解决呀。软件的意义是啥，你反思一下。
什么，谷歌和苹果要求适配的？那没问题。在老分支适配一下行不行？
假如你的业务是一条永远往前跑的公版基线分支，然后客户基于某个分支节点来拓展自己的品牌APP的形态的话。这就是最让人头疼的基线升级问题。
02 大厂的做法
因为从维护成本的角度讲，如果客户版本总是跟着公版基线走，那么在公版基线的非功能性与功能性的维护和演进，总是能够直接复用给客户的版本上。
并且对于一些特殊情况，比如技术栈维度的切换、升级，只有跟得上升级的客户才能以低成本的方式获得对应的能力更新。离最新基线越远，对应的维护成本就越高。试想一下，假如客户的APP是两年前的基线版本，然后提了一个BUG过来，这种情况下，得花多少时间才可以解决。如果这样的客户APP有个十个八个的，那么整个团队的所有开发计划被打断是必然的，计划延期也大概率是必然的。因为总会有一些莫名其妙的问题，需要投入人力去解决。
那么有什么可以参考的案例吗？大厂的办法就在眼前，也是前面提到的必要升级的一部分原因。
Android和iOS每年都会发布新的系统版本，从系统版本的层面来说，其实存在类似的问题。系统厂商也不希望自己发布的历史所有系统版本，都需要投入人力来维护。他们更希望用户买最新的手机，最差的也得是跟着系统更新的频次，来升级系统软件版本。同时，对于他们平台之上的APP开发者而言，就必须要按时适配他们系统的新特性。必要的时候，还需要解决他们新系统带来的新问题。以便于共同为用户提供更好的手机使用体验。
toC部分暂且不提，toB的，相当于面向APP开发者的角度来讲，作为主流两款手机系统而言，它们的规则非常强势。如果开发者在规定时间内不完成适配要求，那么在对应的系统版本的应用商店中，就无法搜索到该款APP。
这就是强势系统掌握APP安装与升级入口的重要性了。有了入口，就可以起到强力约束的作用。
03 可参考的思路
但是，那毕竟是大厂做派。这个世界上能做到手机系统垄断地位的厂商，也就那么两三家而已。
那么对于咱们这种乙方软件供应商，没有巨大的平台力量。那就需要一定的策略了，大概就是一个软硬兼施的思路。
首先，要想办法来降低升级成本。可能需要在架构设计上考虑UI更迭的低成本兼容的可能性；可能需要提供必要的配套升级工具；可能需要提供一些对应的商务策略。
然后，就是要诱之以利。要去找新版本的更好的功能是什么、更好的非功能性能力是什么。在老版本中做到这些的成本要远高于在新版本中做升级。再者就是，手机系统要求我们做新系统适配，这个咱们无法反抗，都得做的，对不对？
最后，就是要明确升级与维护规则，提前通知、给出足够的升级时间。然后到期执行，有理有据。从客户服务的角度讲，这是应该是最先放出的规则，但是可能是最后执行的手段。因为从乙方的角度讲，很难有强硬的底气一概而论。还是需要一客一案，或者一类客户一案。积累经验之后，再去解决具体的问题。
相关链接
关注芃篙君⬇️，每日获取思考与践行的认知更新...
可获取软考备考资料；
亦可加微信探讨开发者、职场与管理、IoT行业等话题；
共同成长，穿越周期！
