相信很多在传统软件开发领域的朋友或多或少对互联网公司的软件开发有如下疑问:开发流程是怎么样的?人员组成是怎么样的?系统架构是怎么样的?成长路线是怎么样的?是不是加班厉害?薪资福利是不是传言的那么有诱惑力?
而在互联网行业高压力的同学,也会问:传统软件开发公司工作会不会轻松点?会不会稳定一点?是不是在传统软件开发领域年龄没那么敏感?
这篇文章会一一解答上述疑问
首先,先来介绍一下何谓传统软件行业,何谓互联网软件行业,有如下几个明显差异点。
传统软件开发行业,也可以叫做企业软件开发行业,它的明显特征如下
作为码农,不论在传统行业还是互联网行业,都是做软件开发,软件开发一般都是以项目为单位。首先,就先以项目流程的角度聊一下传统软件行业与互联网软件行业的区别。
结合上图,从如下几点说说传统软件项目的项目流程
需求来源一般为甲方客户,当一家公司慢慢成长起来时,往往需要软件来提升公司的管理与运行效率。比如所有公司无一例外都需要人事管理系统、财务管理系统、OA系统、考勤系统;一些制造行业还需要生产管理的ERP系统,医院需要病例管理系统、学校需要学生管理系统、政府需要公文管理系统等等。这些甲方客户一般都没有专门的软件开发团队,大部分只有一个叫技术中心的部门负责网络与各种系统的管理。所以,要落地这些软件,就需要专业的软件公司来实施。
有了实际的需求,要么客户主动找到软件公司,要么软件公司挖掘客户;首先入场的一般都是销售入场(主管商务事项,比如报价、签约,客户关系维护,需求挖掘,以便签约项目二期、三期…)。有时还会有售前顾问支持(主管技术,比如给客户给出技术方案、初步分析出项目实施范围,方便合理报价);需要说明的是售前顾问通常都是技术出身,项目经验丰富,不仅是技术专家,还是业务专家,对某一行业有深刻理解,能够告诉客户,怎么做才是行业最好的方案,利用行业经验帮助客户提升效率,而不是简单把客户的下线流程搬到线上。
项目签约下来后,紧接着就是项目实施团队入场。项目团队包含这些人:项目经理、需求分析师、技术经理、技术开发、UI、QA项目实施有时为驻场开发,有时是在公司开发好后到甲方公司去部署上线
需求通过QA测试部署后,通常会有试运行阶段,在试运行阶段,客户可提出问题点与优化点。所有功能没问题后,即完成交付,技术团队撤出,投入到下一个项目,销售收尾款。偶尔客户还会购买系统运维服务,即支持系统运行期间的问题处理以及小需求迭代。
结合上图,从如下几点说说互联网软件项目的项目流程
需求来源主要在于这三个方面
产品需求:PM发起的需求,比如要做个视频面试的新产品、要优化下单流程之类的营销需求:此类需求一般为公司运营和营销人员发起的需求,PM把需求梳理为产品文档后,交由技术团队落地内部需求:此类需求可理解为内部系统建设需求;前面两种一般称之为To C,这种叫To B
最后,还有一种活儿的来源,那就是技术自己发起的需求,比如系统重构,技术基础设施的建设,比如系统性能、异常监控系统、持续集成系统等
在互联网公司,所有的需求都会收集到产品经理(PM)处,技术团队原则上只从产品经理处承接需求
PM会把各种需求整理成需求文档,还会附带上需求原型。通常会先期找技术初评,确认哪些功能无法实现然后调整需求文档。
需求没问题后,C端需求最先入场的是UE、UI,即交互设计与视觉设计,完事后前端FE拿到设计稿后进行开发,这期间后端开发可并行,最后接口联调、测试
贴一个以前端视角的大致项目流程:
最明显的感受就是,传统行业的软件开发是给甲方干,在互联网行业的软件开发是给自己干!
上面介绍了项目的整体流程,接着针对于项目团队的组成,即实际参与项目落地的人员以及人员分工聊一聊。
下面贴一张曾经以项目经理角色负责过的项目,因为该项目较大,牵涉到的人较多,可以很清晰的看到一个项目的完整人员分工与构成。
传统软件项目开发一般都会基于公司产品来做二次开发,提升开发效率。互联网软件大部分情况都是对现有线上业务的迭代,为了提升开发效率后端也有中台组、架构组支撑,前端与UI也会抽取业务组件方便开发。
传统软件开发项目,由项目经理负责制,从项目最开始跟到系统上线验收;互联网公司中的项目组织相对零散,需求详设评审进入开发后基本上就没PM的事情了,这个时候一般会在FE、RD、QA中推举一位项目负责人推进项目的落地,把控项目进度。敏捷项目一般由Master来负责。
核心诉求: 在满足功能需求的情况下,怎么好维护,怎么开发成本低怎么来。机器都是甲方出,所以能通过堆机器解决的问题都不是问题 (不过也需要为客户考虑项目整体成本)
常见的架构是这样的:
传统行业的企业内部系统技术架构80%都是只做到读写分离、按应用拆分、分布式缓存、单独的查询服务就不再往下走了,因为再往下走,开发成本会呈指数级上升。少数会做到大表拆分、负载会上LVS或F5。
对于这样的技术架构,只要机器足够,性能够强,足以支撑一家上万人的公司日常正常运转了。
对于那种项目金额上千万的项目,更多的也是采取多地分开部署,数据集中上报汇总的方式,避免架构复杂化带来的开发成本提升。
核心诉求: 支持快速迭代、稳定、高并发。另外,机器都是自己出,多一台都是成本….
为了达成上述诉求,基础配置大部分都是这样的,上不封顶。
可以看到,对于传统行业软件技术架构,相对于互联网软件架构,最明显的区别标志就是微服务。
大部分上了规模的互联网公司都有清晰明确的职级体系;传统行业软件公司大部分职级体系较模糊。
一般分为技术路线与业务路线两种
职级从初级开发、中级开发、高级开发、资深开发、一路到系统架构师;
实际工作中,做到在项目中负责整个项目的技术负责人,或者公司的产品研发负责人,技术路线基本就到头了
项目技术负责人更多的要求综合能力;产品研发负责人给更多要求技术深度与从项目业务中提炼成产品的能力
大多数都会先做一两年技术,然后做项目的需求分析人员,再然后到项目经理,成为业务方面的专家;例如财务领域专家、生产制造领域业务专家、金融领域业务专家等。
这条线是业务经验越丰富越值钱,需要靠一个个实际项目历练出来,无捷径可走。