本文要谈的不是软件产品的生存策略，而是作为软件开发人员在团队中的生存问题——按理来说，这也像前两篇所讲的一样属于「人为因素」问题。
团队类型
无论是不是与互联网相关，在一家靠提供软件及服务吃饭的公司里，只要具备一定规模了，就会分化出业务型团队和支撑型团队——
分工细化的前提是流程环节比较复杂，并且因操作规范化程度不够或其他什么原因导致不能自动化，无法用机器取代人工，因而要拆分出子环节并找到对应的人去处理。
欧雷《反思软件开发：软件生产》
业务型团队专注于「开源」，即「创收」，给公司的产品添砖加瓦以带来更多收入或流量；支撑型团队负责「节流」，也就是「提效」，让业务型团队的事情能够更快、更好、更有质量地落地。
工作价值
当被问起「你某段时间做了什么有价值的事情」时，会如何作答？
相信有很多人会「自信满满」地说自己为业务带来了多少收入和流量；也有不少人「满心激动」地罗列自己为让业务更好落地做了多少贡献。
正当你在向别人对自己做的一些自认为很有价值的事情大谈特谈时，对方问了一句：「你做这些的价值是什么？」你听了之后的第一感受很可能是不爽，并且疑惑：「这么有价值的事情都没看出来哪里有价值？」
问的人不一定是恶意，有可能是你的表述没让他 get 到你所认为的价值点，也有可能是他虽然 get 到了你所认为的价值点但他认为没价值。
前者是表达力和理解力的问题，这一般不是大问题，换个方式阐述；而后者则是价值观问题，这会影响站队，也就是与另外一个人或群体的匹配度、融合度。
从上面的团队类型划分看，直觉上会认为做的事情只要符合团队的职责定位，能够让团队变得更好，就是有价值的。从「团队」这个整体来看也许是这样，但深入到团队内部去看呢？
「有无价值」是「评价」，「评价」受「人的意志」影响，只要被「人的意志」影响就是「主观」的，无论这个「人的意志」是一两个人的还是很多个人的。
所以，个人或团队做的事情是否有价值，最终还是靠直系上级的价值观去定性——做的事情的效果是立竿见影还是需要量变到质变，直系上级本人和其他同事或被支撑的团队认不认可。
如果做的事情在比较长的时间后才体现出（巨大的）威力，那时你可能已经因为当初直系上级认定你做的事没价值而被裁了或自己走了。
生存困境
上文中的内容看起来可能觉得「很正常啊」、「这都没什么」，那下面开始说一些我觉得会让人沮丧的事实。
总看我文章和了解我的人都知道，我的从业经历是既在业务型团队干过也在支撑型团队待过，不管是在哪种类型的团队中，都积极主动地做了很多基建方面的工作。
并且我也管理过小小团队，可以用不同的视角去尽可能全方位地阐述——
业务型前端
职业发展与成长的问题围绕着每个人，对于研发人员来说，对于在业务型团队中的前端工程师来说尤甚。
在业务型团队中，前端工程师的主要职责就是完成产品需求，保障产品质量和上线时间。想封装 UI 组件库、脚手架、开发框架？不是有现成的开源项目和支撑型团队的项目吗？有重复造轮子的必要？需求做完了吗？能让团队赚钱吗？
在业务型团队中，业务跟前端有什么关系吗？前端只是实施环节之一，前端工程师仅仅是个搬砖的，基本只能在实施的可行性、合理性上插插嘴，想砍需求或左右产品发展方向？呵呵呵……
业务型团队的前端工程师，把代码写得没什么 bug 是「应该的」，这是「本职工作」。如果 bug 多，不仅会被合作的人投诉，还会被他们和上级认为能力不行。
想做些基建工作去提高效率和减少质量问题？可以啊，但不能影响正常需求的开发。并且，做那些东西只能算是你的个人提升，因为没让团队赚更多钱啊，不算你「不务正业」就不错了，顶多在考评时认为你还算有上进心吧！
这样看来，业务型团队中前端工程师的天花板实在是太低了，很容易就会遇到发展瓶颈。
就算可以给团队中的所有项目代码做重构，等全部重构之后呢？做的这些重构会让你的上级和其他同事表扬你，赞赏你，更看重你，提高你的重要地位，让考评结果有利于升职加薪吗？若是不能，这是不是在自嗨，自我感动？
如果还留在这样的体系中，摆在面前的基本就三条路：转到支撑型团队；做前端负责人；转做产品方向。
支撑型前端
「支撑型团队」听起来有些高大上，给人以技术屌炸天的样子，使业务型团队的人心驰神往——在技术上相对来说是有些优越性，毕竟靠提供技术性服务吃饭，但也没那么夸张。
在这里，「支撑型团队」是指那些提供通用开发工具等的公共技术部门，或提供像低代码平台、数据智能服务等门槛较高且相关资源集中的中台部门。
进入支撑型团队之后，心想终于可以不用考虑那变幻莫测的业务而专心做自己喜欢的技术相关的事情了！
真的是这样吗？真的是这样吗？？真的是这样吗？？？
且不说前端工程师在有的支撑型团队中的处境实际跟在业务型团队一样，想想支撑型团队的业务方是谁？是业务型团队！
如果做的技术工作不能满足或者满足不好业务型团队的需求，那么做的这些工作的价值和意义在哪里？在与业务型团队对接过程中出现问题，或者对接后他们业务上出现问题，没准还会被投诉。
所以，纵然不在业务型团队，也会受到变幻莫测的业务的影响，即使会相对小些。
就算相较于业务型团队能够将更多的心思放在技术上，天花板更高一点，瓶颈也会晚一点遇到，但又能做啥呢？
工具库？UI 组件库？脚手架？开发框架？跨端方案？配置平台？监控平台？低代码平台？还有呢？
这些东西，第一次做会觉得很新鲜很有收获，但上进的你如果在业务型团队中时就做过一遍了，或者换到了另外一家公司的支撑型团队做同类事情时，就很可能会发现没什么新鲜玩意，思路和做法都差不太多。
那么，对于你来说，再做这些事情还有价值吗？有什么价值？
当按照团队负责人的规划、指示按部就班地做那些东西时，你就像在业务型团队中一样仅仅是个搬砖的，没任何亮点，仍然是可替代性很强的螺丝钉，没什么区别。
对于研发人员来说，对于在支撑型团队中的前端工程师来说，与在业务型团队中最大的不同就是自己的直接业务是技术，比在业务型团队中更懂自己的业务，更有可能去左右发展方向。
要想左右方向，体现自己的价值，就得弄清楚团队的价值是什么，挖掘问题的根本原因，提出更好的、能解决真正问题的思路和可行方案，去说服团队的负责人和其他人以及业务方。
支撑型团队的职责是大家所津津乐道的「提效」，也是大多数软件工程师的「本能」。
然而，也许很多人没想到的是，引以为豪的「提效」在某些情形下却成了剥夺他人饭碗的「屠刀」，自己变成了「帮凶」。更为滑稽的是，自己可能就是被剥夺饭碗的那些人中的一个，变相「自杀」了……
这背后的逻辑是——「提效」提高了产能，如果组织整体营收没有相应的增长，即那些业务型团队不够给力，就会劳动力过剩，进而加大组织运营成本；为了生存，组织会想办法减少开支，从而通过各种形式减员。
前端负责人
有的人会天真地以为做了前端负责人就可以高枕无忧了……我不否认会存在这种情况，但更可能的是——
不仅继续做着一线开发工作，即履行好普通业务型团队中前端工程师的职责，还要做团队管理、项目管理相关工作。
自己部门里的事情还好说，当遇到跨部门协作时，责任划分和资源协调会相当麻烦。
由于组织架构调整和人员变动造成的踢皮球现象时有发生，想找到个人咨询问题得兜兜转转绕上一大圈儿，很多时间过去了才可能问到，当然也有得不到答案的可能。
自己或下属遇到对方不配合时，得自己跟对方 leader 或找自己上级跟对方 leader 的上级去沟通。这类事情就算是同部门也会遇到。
作为业务型团队的前端负责人，按照人们的惯性思维，得要比其他的前端工程师更懂业务吧？但问题是，怎么去懂业务？
要真的懂业务，首先得对那个领域感兴趣吧？不感兴趣的话如何做到真的懂业务？不喜欢数学的人把数学考高分让我膜拜下？
那些说自己懂业务的人真的懂业务吗？？？能发现当前产品架构和商业模式中存在的问题并提出改进方案吗？？？
作为业务型团队的前端负责人，按照人们的惯性思维，得要比其他的前端工程师更懂管理吧？但问题是，如何做好管理？
「管理」是什么？是挥舞着手里的权力大刀逼迫就范？还是用各种技巧、手段画个大饼诱惑并套路他们？
抱有这类想法甚至如此行动的人不懂「管理」，更别说懂人性了。真正的「管理」是创造舒服的环境，去激发他人工作的主动性，成就他们自己进而成就团队——
最理想的管理，应该能够激发出下级的热情，唤起风雨同舟的使命感、成就感，让他们觉得工作不只是维持生存、生活的手段，同时也是自我实现的方式，最终达到自驱动、自组织、自管理的效果；最理想的组织形态，是基于共同愿景的去中心化或弱中心化组织。
欧雷《反思软件开发：人为因素（下）》
先搞清楚「管理」到底是什么，再去想用什么样的方式去很好地表达那个词的深刻内涵——这实际是个社会学问题。
不过说实话，这种中间角色，职级和拿的钱很可能跟其他人差不多不说，还容易做得上下不讨好——既背锅被上级训斥，又被下属说自己摆架子、不是人，委屈只能自己含泪吞下去。
做产品方向
当要转做产品方向时，那就是对团队的业务领域很感兴趣，虽然不一定很了解。不了解可以去学习，但不感兴趣肯定就没辙了。
做产品方向不一定就是当产品经理，业务线负责人、架构师等也都需要很懂业务，这几个都比较适合前端工程师去转型。
其实，这条路的阻力还是挺大的。要补充大量缺失的知识并提升认知能力和思维方式自不用说，「愿景」或者说「共识」可能会成为最大的阻碍。
当自己在产品的定位、功能和形态有比较强的观点时，虽然业务领域和团队的是一样的，但定位、目标等有可能相左。
这时该咋办？说服团队负责人？不大可能。屈服顺从？一是自己会觉得不甘心、憋屈，二是又回到了一开始的问题——自己做的事情的价值在哪？
总结
很多文章从正面、积极的方向去谈论前端工程师的职业发展与成长，就像人类社会总是倾向于去宣扬好的、正能量的事情，让人们吸上名为「安逸」、「快乐」的奶嘴儿，从而忘记自己身边危机四伏。
本文试着从反面、消极的方向去探讨前端工程师在职业发展与成长中可能面临的问题、困境与矛盾，试图唤醒大家的危机意识。
我并未像文章标题一样给出「生存策略」，而是指出「生存问题」希望大家去针对性地寻找适合自己的「生存策略」。