从读《微信背后的产品观》到思考前端工程师的“35岁”

我是一名前端开发者，同时兼任pm职责，近半年在公司负责升级一直在开发与运营的一个B端的Saas商城系统；

在对需求剖析、需求抽象、每个字段含义的推敲的时候，我越发对微信这样简洁、自然的产品产生兴趣与共鸣。

也会情不自禁的赞叹微信清晰明了、谨慎内敛的结构化产品思路。

虽然微信这么多年上线了如此多功能与特性，但是产品简洁而克制的灵魂从来没有改变，哪怕对于60岁的人来说，也几乎不存在用不好微信的情况。

而我做为微信的使用者，广义技术上的开发者，无论是产品还是技术维度，都让我越加佩服与引起共鸣(恶心的小程序开发除外)。

昨天终于行动了起来，把这本知名的 《微信背后的产品观》 找出来并读了起来，与其叫一本书，不如说是一个演讲的记录，很短，大约2小时就读完了，主要内容是2012年微信4.0发布时候，张小龙长达8个多小时的公开演讲的内容；

不同于其他产品经理的书籍，他们会告诉你各种方法论、科学分析方法，张小龙截然相反的采用了一种极其浪漫的方式去看待产品，去理解所谓的用户需求，我认为这种产品思路的领先是微信这么多年在社交领域立于不败之地的根本。

虽然在最后，张小龙看似补刀似的说：我所说的，都是错的；但是这恰恰就是他的产品理念，所谓产品没有任何科学方法，完全来自于对人，对人类群体的理解，对自己的拷问与质疑。

我也斗胆推荐大家看看这本书，很快就能看完，人类之所以存在信息差，就是因为不知道，或许看完这本书，你会打开新的思路，某些问题也能豁然开朗。

借此机会，我也想与大家分享一下，这几年我作为一名前端开发者的迷茫与努力。

业务前端开发者的困境

我只是一名普通学历，普通的业务前端开发者，所以以下仅是我的个人感觉，不代表所有前端开发者。

目前在一个小型互联网公司的saas电商部门下，主要职责是前端开发组长，我们公司的主营业务不是saas电商，所以这几年算不上受到到很强的市场冲击，平时会管理几人的小团队，我18年毕业至今，一直在这家公司。

而我大学毕业之后一直从事前端开发方向，在我工作1-3年的阶段，我都保持着对技术的热情，主要是因为尝到了学习技术的甜头，那时候我坚定的认为下一个阶段是全栈，在工作之余我花费了大量的精力学习技术；但是后面我就发现了一个很现实的问题，公司需要大家更好分工协作，所以高级别的项目后端是绝对轮不到一个前端去开发开发；并不是说能力不行，而是人的精力有限，前后端都干，还要管团队，是忙不过来的。

在这样的环境下，关于全栈技术的学习，我也越发疑虑，逐渐走到了大多数业务前端开发者的临界点。

• 
  
• 业务前端的35岁危机在普通人身上是存在的，我们的年纪、精力、外部压力都不允许你永远征战一线，并始终保持高竞争力。
  
• 业务前端的上限很低，大多数努力的前端开发者可以在3 - 5年内触摸到业务前端的上限，职位也就是前端组长。
  
• 技术纵深是很好的选择，但是受限于综合实力（英语、计算机基础、天分），普通人可以达到的纵深远比想象的要浅。
  
• 技术学会了，但是用不上，也会慢慢被遗忘；demo级别的应用无法让开发者对某一项技术有深刻理解。
  
• 在业务开发场景下的前端，永远是没有灵魂的大头兵，上限低就意味着待遇相对较低、可替代性相对较强。
  
• 代码写的越多，与人交流的机会越少，对于几十年的人生而言，这是一件很没安全的事情。
  

总结一下，就是因为兴趣而走的前端技术路径开始越来越窄，前路开始越来越看不清，时间推着我向前，这不禁让我低头沉思，下一步究竟要怎么走？

说回产品

到目前为止我也依旧不确定前路怎么走，接下来的一些结论，只是我的一些探索。

在大学后期，我隐约感觉技术路线并非我所擅长的时候，我有目的的学习了微观经济学、企业管理、竞争战略相关的知识，从而间接接触到了互联网产品，也就是pm。

我很快就感受到了pm的魅力：创造，我恰好是一个喜欢新鲜事物的人，在技术上总喜欢优化、迭代、升级，亲手构建出优美并且有价值的产品极具满足感，而前端开发者与用户的距离比任何一个岗位都要近，甚至可以说：前端开发者决定了用户体验。

如果一个人同时具备前端开发 + 产品的能力是不是还不错？

• 
  
• 消除技术与产品的认知壁垒，后续我们做到了，在我们公司，产品和技术从来不吵架
  
• 如果有能力决定产品走向，开发者就可以是一名有灵魂的大头兵，甚至晋升军衔。
  

也就是说，我逐渐不再下探技术，而是走向用户。

走向用户，并不意味着开发者要放弃对技术的学习，技术很重要，技术能力依旧是核心竞争力，而是随着我对技术的理解逐渐深入，开始越发清晰的了解到，究竟什么样的能力是前端开发者最需要的，什么样的能力边际收益是最高的。

在我从事前端开发第2年至今，我一直都有在产品这方面作出努力与尝试。

关于这几年产品的结果，大概可以用这句话来形容：

100个想法中，80个想法死在在调研与分析阶段，15个想法死在在demo阶段，最后落地5个想法，其中4个反响平平，只有1个还算成功。

虽然绝大部分都是失败，但是站在此刻回头来看，这几年的产品的学习将我的思维高度提升了很多，综合能力也提升了很多，因为很多想法初期是没有团队介入的，凡事都需要亲力亲为，需要思考需求、写最小demo、UI设计、沟通，而上线后，有需要又要为产品负责，就需要进行数据分析，线上数据的观察，等等....，这其实比写代码累多了。

这些进步不像程序的学习有一个可量化的指标，这样的软实力很多的是一种感觉，虽然依旧是时而迷茫，但是也偶尔会有一些收获。

虽然我做的产品决策越来越多，公司与同事给予的信任也越来越多，所以在产品上的舞台也是越来越大，而看了《微信背后的产品观》，里面的想法非常符合我对产品的理解，当然我的理解是相对浅显与张小龙没法比的，不过张小龙对产品的理念，以及他对需求的理解，这样一套浪漫的方法论，真的非常有魅力，这也是为什么，我看完最后决定写这篇文章。

跨越“技术”思维

这几年，我的老板经常会找我聊天，因为我和他提过对产品很有兴趣，在前两年，他反复和我提一句话技术为业务服务，我当时觉得我理解这句话了。

我想，这不是废话，写代码最终都是为了公司的项目，为了更好更快的完成公司需求，我要狠狠的学习技术。

之后来随着我写的代码越来越多，我对这句话逐渐有了新的理解。

之前过于执着于技术，总是站在写代码的角度去理解，而这句话的侧重点是业务，或者我们换个词交付。

并不是技术推动交付，而是在推动交付的因素中，技术是其中之一，我们可以衍生出很多类似的话；设计为业务服务、产品为业务服务....

所以技术的目的并非技术，而是交付价值。

人们总是不自知的放大自己在团队中的价值，这样只会蒙蔽大家的视野，走到更高处，对很多事物将会有不一样的理解。

低纬度的技术思维，走向高纬度的业务（交付）思维。

最后

其实我本来只是觉得读了还不错的一本书，不复盘、不留下点什么反思会达不到学习的目的，写着写着就想到了自己的职业，想到了这几年的经历；

总结性的话不说太多，希望可以帮助到屏