技术人眼中的实业与纯互联网业务差异
Updated:
工作那么久以来，前面一大半辈子都是做 J2EE 项目，参与的都是实业企业的业务系统。最近这一两年，接触了互联网产品的开发，我对这两领域的业务差异，以及它们对技术开发人员的影响有更切实的体会。（这里提及的纯互联网，是指不需要和实体行业接轨的领域，比如消息通信，游戏，社交，工具等）
无论哪个领域，都应了解业务
我记得很早就有争论，技术人员是否有必要关心和理解业务。技术人员是否只需要深入技术细节，提高开发技能的深度和广度就可以了？
我的观点是，假如你实现的系统，是和人打交道的，而不是单纯的硬件和机器，那么，你就需要接触业务。因为你做的系统，是人的操作工具，解决他可感知的问题。理解业务，和其它增值的软技能，如写作、演讲和沟通是一样的。而且，从技术的角度来说，只有你理解了业务，才能很好评估技术难度，并做出合理的系统设计和架构。
「业务与缓存」这篇文章大致介绍了如何结合业务来设计和使用缓存。
「听听系统的多地部署改造」这篇文章也举例说明了业务对性能的影响，接口权重取舍，以及任务异步化等。
业务性质的差异
实业企业的业务需求，是为了把实业往系统迁移，以简化流程，保证数据准确性，提升协作能力等目标为主。因为受产业现状约束，调整空间变化不大，功能实现路径相对单一。
纯互联网的业务需求，即便功能或者要解决的问题类似，实现路径相对多样，发挥的空间较大。
需求灵活度和空间
企业系统的需求来源，小的层面是一线业务执行者，对功能和效率的需求；大的层面是老板对整体业务的规划。一般情况下，企业系统的需求到达开发阶段了，应该已经在业务部门达成共识。根据业务流程的指引，功能相对明确。但是，缺陷也明显，因为在没有业务流程配合的情况下，系统是没法优化的。当初我在航运物流公司的时候，曾经参与一些探索性项目。有些想法虽然美好，但是落地很难，因为业务配合很难。
纯互联网行业就不一样了。功能的探索空间大，需要更多的从人性，心理方面考虑，更容易突破常规做新尝试。
比如说，在线直播课程的售票功能，仅仅买卖票吗？要分开提问票和普通票吗？到底是分开，还是不分开好，说不准。知乎 Live 一开始是先买先得，限量。为什么一开始我们听听要设置不同价格的提问票呢？
- 增加稀缺感
- 让主讲人多赚一些钱
- 保证问题的质量
- 技术权衡。因为我们一开始的直播间，是在微信公众号里面。主讲人只能通过一条网址链接查看留言列表。如果用户发言的数量太多，质量不好，对主讲人是一个挺大的负担。
可是为什么后面又取消了呢？
一些主讲人反馈不希望做出区分。因为对于这些提问是否回答，他们是有压力的。即便卖票时已经声明不承诺回答，但是主讲人感觉还是不好。尤其是当一些人故意提问怼主讲人，或者提一些不方便回答的问题时，他们就会更尴尬。
提问的质量，真的不是给了钱的人，就会好好思考，再提出高质量问题的。
后来改版后，主讲人同样能在直播间操作，并且实现了协作讲师选取精选留言，和消息限流的功能，发言权限也就放开了。
有效性评估
当初在实业企业的时候，我也经常抱怨用户和 BA 怎么经常改需求，还提得那么晚。但是，老实说，实业企业的需求，怎么变都没有互联网那么快。因为，实业的业务流程，涉及既定利益体的协作，是没那么容易变动的。它们制约了需求的可变范围，当然这也是被互联网行业降维打击的原因。
纯互联网行业约束少，需求更新快，可能让开发更抓狂。机会和风口以来，可能就要马上跟进试探。这个时候，用临时方案，还是设计完整的功能路径，就必须小心考虑了。因为，如果临时的方案多了，就会把系统搞得千疮百孔。但是，假如每个试探的方案都像常规功能那样来设计，不仅可能拖慢进度，还可能最后发现方向不对，废弃成本高。
我们也吃了这方面的苦头。当初系统实现的工会模式，以及为了让大V节省时间而做的转让直播的功能，后来其实用途不大。但是这两个功能对系统逻辑，开发和测试时间影响还蛮大。
如何评估一个需求的有效性，精简地设计易扩展的模型，让临时方案的代码侵入性小，以及平衡开发效率，是非常大的问题。
责任人确定
责任人是什么意思？要为什么负责？
责任人是业务功能的用户吗？可以说是，但也不全是。
比如说，我们系统最开始有一个心愿单的功能，目的是为了收集用户心仪讲师的讲座或者课程。这功能乍一听很有用，也很快就加上了。但是，后期这些数据是谁看呢？产品？还是运营？怎么看和怎么拿出来分析？这都就是责任人要负责的事情，不是说功能加了就算了。由于责任人前期并没有明确，收集的数据并没有很好地发挥作用，功能最后也砍了。同理，像数据报表，用户反馈等类似的功能，也是需要非常明确地指定责任人的。
当责任人不清晰的时候，可以说任何开发出来的功能，最后都会被慢慢遗弃。所以，一个功能要不要做，怎么做才好用，首先应该确认责任人是谁。
这个问题在实业企业也会发生，但在纯互联网行业更常见，尤其在初创期。