太多这种例子了,老板们早上出的新想法,恨不得第二天就能上线。。每个互联网公司都试图突破固定领地,不断地尝试新的业务,一旦发现不行,就立刻砍掉,名曰“试错”。
研发部门,为了应对压力,必然采用大军团作战的开发方式。打个比方,一个 6000 的项目
-
10 个人,每人效率 10,要 2 个月完成
-
而 100 个人,每人效率 5,只要 12 天完成
当然,这 100 个人的薪资成本肯定远高于这 10 人,但是公司不缺钱,更看中 2 个月变半个月的时间效率提升。在激烈竞争下,晚一天都会导致产品处于下风。
为了让大军团作战成为可能,公司的软件开发流程和工具,把程序员打造成螺丝钉和流水线工人,让人员充分的可替代。同时,公司对程序员的个人能力要求并不高。即使面试的时候被考核到的知识面很广很深,但是实际工作中,由于只负责很小的一块,导致每天就是拧螺丝。
对于技术管理者,也看中他的团队协作能力、向上汇报能力,而技术实力的比重越来越小。毕竟管理 10 人团队,还是要自己参与研发过程的,而管理 100 人团队,参与研发已经不可能了。
上述现象出现的根本原因,就是整个行业资金充裕,不需要自己盈利。如今,风口已经退去。互联网用户增长已经到顶峰,几乎所有能被互联网渗透的行业都被渗透,更关键的,获取风投、赴美上市的路子走不通了。所有的软件公司又要重新回到靠自己造血养活自己的正常商业模式。
风口过去了,资金没有那么充裕了,竞争也将逐渐缓和。大军团软件开发模式也难以继续下去,必然引发各大公司裁员,逐渐把大军团,缩减成小规模软件开发团队。人少了,但是要做的事情并不会等比例减少,为了应对这种情况,提升研发人员的个人能力成了必然的趋势。
低能力的程序员们应该尽早考虑逃离程序员行业,还在行业内混的程序员们,要不断提升个人的软件研发能力,来应对市场的变化。公司的用人理念也必将被迫转向更看中程序员个人能力。原本那些靠善于写 PPT,搞向上汇报,实际和研发脱节的管理者们,就业面越来越窄。
软件的内在质量,是用户看不到的质量,比如易读性、易测试性、易扩展性等。大军团作战时,由于团队总体水平低下,又特别赶时间,导致只要软件功能正确性能满足要求,就交付给用户了,没有多少时间去打磨软件的内在质量,代码逐渐变成屎山。屎山的后果是维护和再开发的成本越来越高。
由于有风口的加持,人力成本似乎都不是问题。等到屎山终于要倒塌了,出来一批勇士重写系统,再竖起一座新的屎山也就是了。这样的事情,在我过去十几年的从业经历中,不断重现。
哪些有益的实践要被重新重视起来?
比如,朴实实用的软件架构,而不是一味追求分布式微服务等高级架构。过往,有多少采用分布式微服务架构的系统,是因为真的有伸缩需求,真的基础设施能力达到了?我想有一大批只是为了向上汇报显得高大上吧?也有一些,单纯是因为团队太大,想借助分布式达成模块化,以符合康威法则吧?过往的经历中,大部分的微服务都是一场灾难。原本 IDE 内代码分析就可以掌握的代码依赖关系,必须依赖运行时的监控系统,原本 IDE 内一键重构的事情,必须变成线上灰度热替换,原本简单的上线步骤,变成复杂的分批上线。程序员为此加班掉头发,整个社会则为此浪费钱财。
再比如敏捷开发,大军团下,几乎没有全职能团队,部门墙,团队墙耸入云霄。敏捷开发的根本就是以人为本,近几年,在技术领域低代码是比较热门的话题,通过低代码工具,自动代码生成和可视化编程,只需要少量代码,即可快速搭建各种应用。
应用入口:JNPF快速开发平台(http://www.jnpfsoft.com?csdn),找个有空的时间自己试试!除了低代码工具,其他工具我在以往的文章中都有提到,你可以自己看看。
如今,风口过后,该重新关注软件内在质量了,留下来的公司们,该调整用人策略了,留下来的程序员们,该重视提升自身的研发能力了。