技术对产品的驱动力

互联网井喷的十年已经过去，十年间衍生出了众多国民级应用，涵盖了社交、出行、娱乐和贸易等几乎人们生活的各个领域，那么所有人都在想着同一个问题——互联网的下一个十年会如何？很多人说流量红利消失了，流量红利并不是消失了，而是变得更加金贵了，产品的核心竞争力不在于产品满足了用户的哪方面需求而在于如何能更好的满足用户需求。技术对于产品的驱动力越来越明显，而对于产品经理的要求也越来越高，产品经理的能力模型也在不断迭代。

举个简单的例子，淘宝的双十一超级活动，我们使用淘宝秒杀和抢购的过程中，如果出现了服务器繁忙这些词汇，对于用户体验的影响折损是巨大的，用户在使用软件的过程中只关心能不能满足自己的需求，他们是不会考虑后台少则千万动则过亿的并发访问量的，但是作为产品方为用户服务却不得不考虑这个问题，这时候单纯的站在用户视角很难解决这个问题，高性能高负载成为了产品最具价值的核心竞争力（ps：近几年好多产品因为性能频繁上热搜，随后就是广大网友的各种对比），这只是一方面性能问题，数据的存储问题，大数据配合深度学习的场景化投放问题等等，让产品从认识用户到读懂用户，很像一对恋人从恋爱到结婚的过程。
一个复杂系统的架构设计其实就是用产品思维解决技术难题，如何让数据走最快的路到达自己应该被读取/存储的地方？数据：“我能怎么办我也很无奈啊，堵车很难受啊。”如何在高并发的情况下保障前端用户的响应时间不超过200ms，从用户体验层面这个需求非常简单可以一笔带过，但是系统要考虑的是如何在这200ms内完成数据整个链路的传输，同时保障各数据库间的数据一致，考虑事务的提交终止和回滚，还要考虑最底层的计算资源能够支撑该负载量，这一系列问题带来的是诸如数据库主从热备份，分布式锁服务和缓存机制等多个技术体系升级，在整个数据的流转和计算过程中还要解决数据冗余和异常处理的问题，在这个过程中我们不难发现一个时间需求带动的是多个系统的性能需求和整个产品的后台逻辑需求。
为了做更好的抽象我们来举个比较实在的例子，最近春运，拿用户抢票流程中支付前过程进行举例：用户进入车票详情页，车票详情页在高峰期请求量很高，为了让用户不进入这个页面卡顿，这是用户体验需求，肯定不可能让每个用户访问该页面都请求一次服务器，这时候就需要运用缓存技术将该页面单独缓存然后给用户请求这时候有效解决了用户体验的问题，对应后台的需求则是数据库同步，缓存写入和释放等需求。用户点击下单，高峰时段几千号人抢几十张票，这时候售票平台会面临超售的情况，用户会面临前台显示和后台真实储量不一致的情况，避免这种情况发生需要应用分布式锁服务和在数据库中票数预减和真实数据库中票数反馈的问题，在这中间频繁的发生数据交互，最核心的就是数据一致性问题。
如何面对一个复杂架构和系统的设计这是摆在产品经理面前的一道难题，不仅要对业务内容有很深的理解，同时也要对系统的运作有清晰的认知，系统是没有很高的容错空间的，但是影响用户的覆盖面是非常大的，这时候对于一个高度集成的系统来说是非常复杂的。技术体系本身也是产品，只不过所有内容都是抽象出来的而已，如何让这个抽象的过程更清晰和更高效，底层服务平台，平台服务用户，这是这个时代产品经理应该思考的问题。
技术不等于开发，不等于算法，也不等于运维，技术是一个服务框架是一套思维体系，这个框架内包含算法设计，前后台逻辑设计，数据库逻辑设计，学技术不是说今天写hello world，明天写TensorFlow，后天用python做自动化运维这样，我们要懂得技术体系和产品结构的深度融合，主要体现在三方面：

1. 让产品更懂用户，推荐策略稳准狠；这里我们要知道算法的原理是什么，应用方式是什么，数据清洗的目的和方法，能给用户带来什么便利？结合用户群的属性和用户场景做产品，让产品站在用户角度考虑问题，这里包括用户不同场景安全策略有哪些，该场景下用户更注重空间还是时间，如何让系统更精准的衡量用户使用成本和收益？
2. 降低开发、维护和迭代成本，充分考虑产品功能扩展性和技术平台扩展性，多路复用管控统一方便企业进行产品的运作，同时方便整个产品管理流程中产品与开发和数据科学的沟通等等
3. 用户体验升级，更快识别和响应用户需求，平台如何做到高负载高并发让用户无感知，用户使用产品的流畅性如何提升等等。

资历尚浅对用户的理解没有那么深刻，欢迎各位大佬提意见同时互相学习。