关于思考:反思软件开发生存策略
本文要谈的不是软件产品的生存策略，而是作为软件开发人员在团队中的生存问题——按理来说，这也像前两篇所讲的一样属于「人为因素」问题。 团队类型无论是不是与互联网相干，在一家靠提供软件及服务吃饭的公司里，只有具备肯定规模了，就会分化出业务型团队和撑持型团队—— 分工细化的前提是流程环节比较复杂，并且因操作规范化水平不够或其余什么起因导致不能自动化，无奈用机器取代人工，因此要拆分出子环节并找到对应的人去解决。 欧雷《反思软件开发：软件生产》 业务型团队专一于「开源」，即「创收」，给公司的产品添砖加瓦以带来更多支出或流量；撑持型团队负责「节流」，也就是「提效」，让业务型团队的事件可能更快、更好、更有品质地落地。 工作价值当被问起「你某段时间做了什么有价值的事件」时，会如何作答？ 置信有很多人会「自信满满」地说本人为业务带来了多少支出和流量；也有不少人「满心冲动」地列举本人为让业务更好落地做了多少奉献。 正当你在向他人对本人做的一些自认为很有价值的事件大谈特谈时，对方问了一句：「你做这些的价值是什么？」你听了之后的第一感触很可能是不爽，并且纳闷：「这么有价值的事件都没看进去哪里有价值？」 问的人不肯定是歹意，有可能是你的表述没让他 get 到你所认为的价值点，也有可能是他尽管 get 到了你所认为的价值点但他认为没价值。 前者是表达力和理解力的问题，这个别不是大问题，换个形式论述；而后者则是价值观问题，这会影响站队，也就是与另外一个人或群体的匹配度、融合度。 从下面的团队类型划分看，直觉上会认为做的事件只有合乎团队的职责定位，可能让团队变得更好，就是有价值的。从「团队」这个整体来看兴许是这样，但深刻到团队外部去看呢？ 「有无价值」是「评估」，「评估」受「人的意志」影响，只有被「人的意志」影响就是「主观」的，无论这个「人的意志」是一两个人的还是很多集体的。 所以，集体或团队做的事件是否有价值，最终还是靠直系下级的价值观去定性——做的事件的成果是空谷传声还是须要质变到量变，直系下级自己和其余共事或被撑持的团队认不认可。 如果做的事件在比拟长的工夫后才体现出（微小的）威力，那时你可能曾经因为当初直系下级认定你做的事没价值而被裁了或本人走了。 生存窘境上文中的内容看起来可能感觉「很失常啊」、「这都没什么」，那上面开始说一些我感觉会让人丧气的事实。 总看我文章和理解我的人都晓得，我的从业经验是既在业务型团队干过也在撑持型团队待过，不论是在哪种类型的团队中，都积极主动地做了很多基建方面的工作。 并且我也治理过小小团队，能够用不同的视角去尽可能全方位地论述—— 业务型前端职业倒退与成长的问题围绕着每个人，对于研发人员来说，对于在业务型团队中的前端工程师来说尤甚。 在业务型团队中，前端工程师的主要职责就是实现产品需要，保障产品质量和上线工夫。想封装 UI 组件库、脚手架、开发框架？不是有现成的开源我的项目和撑持型团队的我的项目吗？有反复造轮子的必要？需要做完了吗？能让团队赚钱吗？ 在业务型团队中，业务跟前端有什么关系吗？前端只是施行环节之一，前端工程师仅仅是个搬砖的，根本只能在施行的可行性、合理性上插插嘴，想砍需要或左右产品倒退方向？呵呵呵…… 业务型团队的前端工程师，把代码写得没什么 bug 是「应该的」，这是「本职工作」。如果 bug 多，不仅会被单干的人投诉，还会被他们和下级认为能力不行。 想做些基建工作去提高效率和缩小品质问题？能够啊，但不能影响失常需要的开发。并且，做那些货色只能算是你的集体晋升，因为没让团队赚更多钱啊，不算你「不务正业」就不错了，顶多在考评时认为你还算有上进心吧！ 这样看来，业务型团队中前端工程师的天花板切实是太低了，很容易就会遇到倒退瓶颈。 就算能够给团队中的所有我的项目代码做重构，等全副重构之后呢？做的这些重构会让你的下级和其余共事褒扬你，赞叹你，更看重你，进步你的重要位置，让考评后果有利于升职加薪吗？若是不能，这是不是在自嗨，自我打动？ 如果还留在这样的体系中，摆在面前的根本就三条路：转到撑持型团队；做前端负责人；转做产品方向。 撑持型前端「撑持型团队」听起来有些高大上，给人以技术屌炸天的样子，使业务型团队的人心驰神往——在技术上相对来说是有些优越性，毕竟靠提供技术性服务吃饭，但也没那么夸大。 在这里，「撑持型团队」是指那些提供通用开发工具等的公共技术部门，或提供像低代码平台、数据智能服务等门槛较高且相干资源集中的中台部门。 进入撑持型团队之后，心想终于能够不必思考那变幻莫测的业务而分心做本人喜爱的技术相干的事件了！ 真的是这样吗？真的是这样吗？？真的是这样吗？？？ 且不说前端工程师在有的撑持型团队中的处境理论跟在业务型团队一样，想想撑持型团队的业务方是谁？是业务型团队！ 如果做的技术工作不能满足或者满足不好业务型团队的需要，那么做的这些工作的价值和意义在哪里？在与业务型团队对接过程中呈现问题，或者对接后他们业务上呈现问题，没准还会被投诉。 所以，纵然不在业务型团队，也会受到变幻莫测的业务的影响，即便会绝对小些。 就算相较于业务型团队可能将更多的心理放在技术上，天花板更高一点，瓶颈也会晚一点遇到，但又能做啥呢？ 工具库？UI 组件库？脚手架？开发框架？跨端计划？配置平台？监控平台？低代码平台？还有呢？ 这些货色，第一次做会感觉很陈腐很有播种，但上进的你如果在业务型团队中时就做过一遍了，或者换到了另外一家公司的撑持型团队做同类事件时，就很可能会发现没什么陈腐玩意，思路和做法都差不太多。 那么，对于你来说，再做这些事件还有价值吗？有什么价值？ 当依照团队负责人的布局、批示循序渐进地做那些货色时，你就像在业务型团队中一样仅仅是个搬砖的，没任何亮点，依然是可替代性很强的螺丝钉，没什么区别。 对于研发人员来说，对于在撑持型团队中的前端工程师来说，与在业务型团队中最大的不同就是本人的间接业务是技术，比在业务型团队中更懂本人的业务，更有可能去左右倒退方向。 要想左右方向，体现本人的价值，就得弄清楚团队的价值是什么，开掘问题的根本原因，提出更好的、能解决真正问题的思路和可行计划，去压服团队的负责人和其他人以及业务方。 撑持型团队的职责是大家所津津有味的「提效」，也是大多数软件工程师的「本能」。 然而，兴许很多人没想到的是，引以为豪的「提效」在某些情景下却成了剥夺别人饭碗的「屠刀」，本人变成了「鹰犬」。更为滑稽的是，本人可能就是被剥夺饭碗的那些人中的一个，变相「他杀」了…… 这背地的逻辑是——「提效」进步了产能，如果组织整体营收没有相应的增长，即那些业务型团队不够给力，就会劳动力过剩，进而加大组织经营老本；为了生存，组织会想方法缩小开销，从而通过各种模式增员。 前端负责人有的人会天真地认为做了前端负责人就能够居安思危了……我不否定会存在这种状况，但更可能的是—— 不仅持续做着一线开发工作，即履行好一般业务型团队中前端工程师的职责，还要做团队治理、项目管理相干工作。 本人部门里的事件还好说，当遇到跨部门合作时，责任划分和资源协调会相当麻烦。 因为组织架构调整和人员变动造成的踢皮球景象时有发生，想找到集体征询问题得兜兜转转绕上一大圈儿，很多工夫过来了才可能问到，当然也有得不到答案的可能。 本人或上司遇到对方不配合时，得本人跟对方 leader 或找本人下级跟对方 leader 的下级去沟通。这类事件就算是同部门也会遇到。 作为业务型团队的前端负责人，依照人们的惯性思维，得要比其余的前端工程师更懂业务吧？但问题是，怎么去懂业务？ 要真的懂业务，首先得对那个畛域感兴趣吧？不感兴趣的话如何做到真的懂业务？不喜爱数学的人把数学考高分让我膜拜下？ 那些说本人懂业务的人真的懂业务吗？？？能发现以后产品架构和商业模式中存在的问题并提出改良计划吗？？？ 作为业务型团队的前端负责人，依照人们的惯性思维，得要比其余的前端工程师更懂治理吧？但问题是，如何做好治理？ 「治理」是什么？是挥动着手里的势力大刀逼迫就范？还是用各种技巧、伎俩画个大饼引诱并套路他们？ 抱有这类想法甚至如此口头的人不懂「治理」，更别说懂兽性了。真正的「治理」是发明难受的环境，去激发别人工作的主动性，成就他们本人进而成就团队—— 最现实的治理，应该可能激发出上级的激情，唤起风雨同舟的使命感、成就感，让他们感觉工作不只是维持生存、生存的伎俩，同时也是自我实现的形式，最终达到自驱动、自组织、自治理的成果；最现实的组织状态，是基于独特愿景的去中心化或弱中心化组织。 ...