如何管控工程变更和现场签证

全过程工程咨询单位在项目的施工阶段,对建设工程的投资管理活动中,主要工作涉及到招标工程量清单的编制以及施工过程中工程款的支付、工程变更现场签证及索赔管理等几个方面的工作。工程变更及现场签证管理。这都是基于我们通过目标的分解在第58小节文章中所确定下来的投资管控组织架构。 工程变更及现场签证是施工单位最喜欢的工作,那是因为它能使施工单位口袋变得更加丰满,而对于建设单位和全过程工程咨询单位来说,则总是为此担惊受怕,那是因为一方面他们要面对审计,另一方面变更和签证就像是魔鬼,会慢慢吞噬他们的投资。 故而,在全过程工程咨询项目中一度被沦为在施工阶段投资管理最大的风险不可控因素,但在绝大多数情况下,在具体的工程实践当中,又往往不可避免,须重点管控。怎么管控呢?我们今天详细聊一聊。和上一篇文章一样,来点实战点的,如下文。 (一)工程变更管理 1、依据 工程变更是施工阶段费用增加的主要途径,全过程工程咨询单位必须重视工程变更的管理。工程变更的主要依据: (1)国家、行业、地主有关技术标准及质量验收规范及规定等; (2)《建设工程工程量清单计价规范》(GB50500-2013) (3)施工合同 (4)施工图纸 (5)人工、材料 、机械台班信息价及市场价 (6)施工单位投标工程量清单 (7)变更通知书及变更指示 (8)计量签证 2、工作内容 在工程施工过程中,由于各种原因,会出现工程变更和合同争执等情况。这些问题的产生,一方面是由于设计疏漏或错误,导致在施工过程中发现了设计没有考虑或考虑不周的施工项目,从而不得不补充设计或变更原设计。另一方面是由于发生了不可预见的事故,如自然或社会原因引起的停工或工期拖延等。由于工程变更所引起的工程量变化、施工索赔等,都有可能使得投资超出全过程工程咨询单位对投资管控的目标要求,故而在工程实施过程当中,需要特别重视工程变更及其价款的管理。 工程变更管理主要工作是审查工程变更资料,审查的重点包括但不限于变更理由是否充分、变更程序是否合法合规、变更估价是否准确。 此外,对于全过程工程咨询单位所提出的工程变更,需要以函件的形式下发至施工单位;对于施工单位所提出的工程变更,若不影响使用功能的情况下,需得到全过程工程咨询单位的同意和许可,所有的工程变更经全过程工程咨询各专业设计咨询师的技术审核、总咨询师同意后,向施工单位发出。 全过程工程咨询单位在进行工程变更管理过程中,须建立严格的审批制度和审批程序,其目的在于防止任意提高设计标准、改变工程规模,增加工程投资,切实把投资控制在目标范围内。 3、工作方法 全过程工程咨询单位进行工程变更管理的主要工作有以下几点: (1)审查变更理由是否充分 对施工单位所提出的变更申请,应严格审查变更的理由是否充分,预防施工单位利用变更增加工程量、工程造价,减少自己应承担的风险和责任。区分施工单位所提出的变更是技术变更还是经济变更,对其提出的合理降低工程造价的变更则应该积极支持。 全过程工程咨询单位自身所提出的设计变更,则应进行内部审核、评定,若因不能满足使用功能需求或在确保投资目标达到的前提下提高设计标准,可以变更。 (2)审查变更程序的合规合法性 全过程工程咨询单位应审查施工单位所提出变更程序的合规合法性,主要依据是在双方签订合同时对变更程序的约定下进行审核。如果在合同中没有约定,则应根据《建设工程价款结算暂行办法》(财建【2004】369号)文中的规定进行审查,在审查过程中主要应注意以下4个关键环节。 1)施工中发生工程变更、施工单位按照经全过程工程咨询单位出具的变更设计文件进行变更施工,其中,若是政府投资项目的重大变更,需按基本建设程序报批后方可施工。 2)在工程设计变更确定后14天内,设计变更涉及合同价款调整的,由施工单位向全过程工程咨询单位提出,经发包人审核同意后调整合同价款; 3)工程设计变更确认后14天内,如施工单位未提出变更工程价款报告,则全过程工程咨询单位可根据所掌握的资料决定是否调整合同价款和调整的具体金额。重大工程变更涉及工程价款变更报告和确认的时限由双方或三方(建设单位、全过程工程咨询单位和施工单位)共同协商确定。 4)收到变更工程价款报告的一方,应在收到之日起14天内予以确认或提出协商意见,自变更工程价款报告送达之日起14天内,对方未确认也未提出协商意见时,视为变更工程价款报告已确认。 (3)审查变更估价的准确性 在工程变更管理过程当中,全过程工程咨询单位对工程变更估价的处理应遵循以下原则: 1)合同中已有适用于变更工程的价格,按合同中已有价格变更合同价款; 2)合同中只有类似于变更工程的价格,可参照类似价格变更合同价款; 3)合同中没有适用或类似于变更工程的价格,由施工单位提出适当的价格,经全过程工程咨询单位确认后执行。 4)合同中另有约定的,按约定执行。 按照一般规定在合同中没有适用或类似于变更的价格由承包单位提出适当的变更价格,经全过程工程咨询单位造价咨询师审核,给出意见,并由总咨询师及建设单位确认后执行。 全过程工程咨询单位为了有效控制项目投资,应在施工合同专用条款中对上述条款进行补充和修改为:在合同没有适用或类似于变更的工程价格由施工单位提出适当的变更价格,经全过程工程咨询单位审核。若总包单位对全过程工程咨询单位最后确认的价格有异议,而又无法套用或无法参考相关定额时,由全过程工程咨询单位、施工单位双方共同进行市场调研,力争达成共识。对涉及金额较大的项目,由全过程工程咨询单位、施工单位等相关方共同编制补充定额,报建设单位审批后确定变更工程价款。 4、注意事宜 (1)若不能满足工程验收规范要求、不能满足使用功能需求或施工技术要求,则必须进行工程变更; (2)在满足工程验收规范要求、满足于使用功能需求和施工技术要求的前提下,尽管变更理由非常充分,如果总投资不可控,则全过程工程咨询单位也不能同意变更; (3)如果相关单位、全过程工程咨询单位审核同意变更的,则应按变更管理程序变更工程的综合单价。 5、成果性文件 (1)工程变更审批流程表 表1:工程变更审批表 (2)工程变更汇总表 表2:工程变更汇总表 (二)现场工程签证管理 1、依据 全过程工程咨询单位在进行现场签证管理时,主要的依据是: (1)国家、行业和地方政府有关规定; (2)施工合同 (3)其他专业现场资料 (4)现场变化的相关依据;…

全过程工程咨询设计阶段的成本控制

众所周知,在我国,几乎所有的房建项目都需要经过:方案设计、初步设计和施工图设计三个阶段。而我们通常习惯于把这三个阶段统称为建设项目的“设计阶段”

每个阶段成本控制的工作程序和方法虽不尽相同,但主要环节和步骤在时间上和管理职能上的逻辑关系却是不变的,即从粗放到精细的过程。有人说:这是成本控制工作的共性,对此我深以为然。

设计阶段的成本控制是一种事先控制的方法,同时也是一种动态控制的过程。之所以这样说,是因为在设计阶段发生在施工阶段之前就要完成,但成本控制工作却做着与施工阶段相同的事,即:需要在目标值确定的前提下,定期地把实际值与计划值相比较,由此判断其行为是否偏离目标,以及偏离目标的程度,进而分析原因,采取相应的举措把实际值控制在计划值范围之内。从这个意义来说,成本控制的过程应贯穿于项目整个建设期

全过程工程咨询单位在总咨询师的组织下,定期进行技术经济分析、造价成本分析是非常有必要的。其目的在于实际成本不要超出建设方给出的投资限额

另外,我们也不能简单地认为在设计阶段,成本控制行为是被动的。在每个设计阶段,无论是事前、还是事中都应积极邀请建设单位参加到你的设计任务中来。否则的话,你幸苦得来的设计成果很可能会被建设方全盘否定。而这起决于你与建设单位的沟通是否通畅、是否明确了建设方真正的需要,是否及时把中间成果向建设方作为汇报……

不要自以为是,也不要闭门造车,更不要不好意思骚扰建设方,因为建设方配合设计工作本来就是他的责任之一,尽管设计工作本来就是全过程工程咨询单位的份内工作。

那么,在设计阶段,哪些成本控制工作是全过程工程咨询单位份内的呢?

如果不明确这点,很多人、很多事将陷入到迷茫。故而,有必要在设计工作的每一阶段,在正式开展之前就要赋予它一个清晰且准确的使命。工作任务的不清晰将会是后续一切混乱的开始,低效或无效。

项目的每个设计阶段,成本控制的主要任务其实是不同的。比如:

方案设计阶段,成本控制的任务主要是:编制项目的总造价估算,达到建设方的投资要求并得到建设方的初步认可;

初步设计阶段,成本控制的任务主要是:明确概算指标、编制项目的总概算,得到建设方的最终认可,确定建设方的投资目标。对设计的深化严格控制在估算计划值内。

施工图设计阶段,成本控制的任务主要是:完成施工图预算的编制,在充分考虑满足项目使用功能的前提下,尽量挖掘节约投资的可能性、确定项目在施工阶段的建管模式、编制招标文件,在项目的施工阶段定期进行投资计划值与实际值的比较。

有效的结果输出必然是由全过程工程咨询单位在总咨询师的组织下以及无数次建设方对中间设计成果的认可下完成的。这里涉及到建设单位和全过程工程咨询单位二方责任主体。

需要注意的是:在某项设计任务上建设方管理人员与设计人员的职能分工,特别是对于某些需要建设方参与的设计任务,责任一定要分清。

比如,建设方要求项目的整体造价控制在1个亿,在实施过程中,建设方总认为使用功能无法达到预期,于是通知你增加设备、增加室内房间数量,结果实施下来,却发现项目实际总造价为1.2个亿,于是你被建设方一顿狂喷。

再比如,建设方临时要求增加几部电梯或者某项建筑使用功能,这时你几乎已经完成了建筑专业和结构专业的大部分设计工作,为了响应建设方的要求,在有限的时间内,只能在原有的图纸上进行局部修改。但在施工过程中,却发现很多问题,最终的整体效果显得是那么地格格不入。结果你被建设方说得一无是处。

……等等,诸如上述问题还会有很多,这里只呈现了冰山一角。而这一系列的问题,请问是谁的责任?你能分得清吗?

有人会说,那肯定是建设方的责任呀,临时增加那么多东西,造价不偏离目标才怪!那么,建设方也会说:是全过程工程咨询的设计团队不行,就因为没有考虑到我才要求增加的,要是我全都能考虑到,要你设计干嘛?要你全过程工程咨询干嘛?

公说公有理,婆说婆有理!幸运的是很少会有因为设计与建设单位的责任不清晰,导致的诉讼官司发生。但对于管理而言,则应是极力避免发生的,因为这会带来很多后续问题的纠缠,这无论是对于建设方还是全过程工程咨询方,其实都是一种潜在的风险。

规避或减轻此类风险最好的办法莫过于,请求建设方在每个设计阶段工作开展之前书面给予一个正式的《设计任务书》,并在全过程工程咨询合同中明确把它分阶段地作为双方履行全过程工程咨询设计任务的依据。这在我本系列文章的第21节到23节也多次谈到过这个问题。对此有兴趣的朋友不妨到我的个人主页去回看一下。

除此之外,全过程工程咨询单位在设计阶段还需要时刻关注于自己的设计成果是否超出了投资限额。这个很容易理解,但在具体工作实施过程中却很容易因赶进度而被忽视,或者是直接把投资目标和投资限额的概念搞混淆了。

投资目标并不等同于投资限额。可以把投资目标理解成项目的估算,而投资限额则可看成是项目的概算,估算是方案设计及可研的成果,而概算是初步设计的成果。估算要大于概算(一般为投资目标的80%左右)。

之所以要在初步设计进行限额设计,来源于《政府投资条例》(国务院令第712号),其中就规定:“初步设计提出的投资概算超过经批准的可行性研究报告提出的投资估算10%的,项目单位应当向投资主管部门或其他有关部门报告,投资主管部门或者其他部门可以要求项目单位重新报送可行性研究报告。”

当然了,大量的实践和经验也在告诉我们在初步设计阶段进行限额设计才是最好时间点!

由此可见,限额设计这个概念是从初步设计开始的是在建设方确定投资限额以后的深化设计。此时的总咨询师在初步设计阶段就要时刻提醒各位设计师们要有控制成本的意识,超出投资限额的设计,无论你设计得有多好,都要被认为是不合理的存在,也是建设方不可接受的。设计人员也应当自觉遵守,在成本控制人员的配合下主动复核设计成果,直到满足投资限额为止。

常见的研发管理体系

纵观各类科技企业,由于自身所处环境不同,因此其软件研发管理模式也不尽相同,这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系,也有基于IPD集成产品研发框架指导下构建的研发管理体系,当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。

01 基于CMMI的研发体系CMMI能力成熟度模型相信大家都不陌生,从一级到五级,覆盖了22个过程域,一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。

当然,这里主要是指企业能够确实按照CMMI模型去实践,这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。

虽然老谭所在的公司通过了CMMI5的级别,但是实际执行的过程中,我们并不会完全按照CMMI5进行,需要根据实际情况进行裁剪,相比于它对实际研发过程的指导作用,我感觉CMMI认证更多的为公司增加一种重要资质,以期在招投标中获得更好的加分。

对于互联网企业,特别是To C的互联网企业,CMMI认证的意义并不是特别大,因为在C端你无需依赖这些资质证明能力,而是以产品制胜。

02 基于IPD的研发体系

IPD的核心内容是以市场为导向的产品开发,关注客户需求,将产品开发看成一项投资(商业价值),通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品(各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付)。

去年开始负责研发时,我在公司更倾向采用IPD的模式构建研发体系,把技术团队和产品开发团队做了分离,也融合了近几年比较火的中台思想,其目的是将过去分散式的研发体系做适度的统一和整合,加强技术能力建设。

但经过这段时间的运行来看,其实也出现了水土不服的现象,其根本原因是IPD是是一个相对重量级的体系,要落地执行往往需要从整个公司层面去整体考虑和推动,而不仅仅是研发团队内部的变革,需要高密度的跨部门协作,所以对于中小企业来说,IPD也并不一定适用,因为:

IPD需要对产品拆分为技术开发、平台开发和产品开发,一般中小公司没有这么复杂和巨大的产品;

IPD的流程繁琐复杂,虽然可以裁剪,但也很多,针对众多研发项目,需要方方面面考虑周到,对中小公司来说管理成本太高;

IPD的关键要素,无论是跨部门团队、管道管理,还是优化投资组合等都是针对市场,一般中小公司的市场驱动较弱。

03 基于敏捷模式的研发体系

在这个快鱼吃慢鱼的互联网时代,对用户和环境越来越要求要快速响应。

敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系,主要理念就是敏捷迭代、小步快跑,快速改进、拥抱变化,用户参与等等。

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发,而不是一次性完成项目的交付;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发或者可以理解为小步快跑的开发模式,一次只交付客户一部分的特性或功能,如下图:

传统的外部客户的项目如果更适合CMMI管理的话,那么对于产品研发,不论是互联网产品研发还是To B的软件产品研发,敏捷模式都是更加适合的。

敏捷的交付是持续的一个过程,软件更像一个活着的植物,软件开发是自底向上逐步有序的生长过程,类似于植物自然生长;敏捷开发遵循软件客观规律,不断的进行迭代增量开发,最终交付符合客户价值的产品。

老谭在负责一块互联网业务时,更多的是采用敏捷的开发模式,基本两周一个迭代的快速改进。

敏捷模式下,迭代的节奏是非常重要的,基于统一的节奏,产品、开发、测试、发布等不同岗位的人员就像建立了生物钟一样有规律的执行,团队间的协同能力得到极高的体现。

在这个研发体系里,敏捷团队负责人的主要工作除了执行例行的会议、任务分派以外,我认为最核心的就是对于sprint backlog的控制,既要照顾到需求方的关切,又不能轻易破坏节奏。

04 总结

这三种开发模式中,IPD的层级最高,既包括了“做正确的事”,又包括了“把事情做正确”,是公司级的运营级流程,CMMI和敏捷是同一个层级流程,是工程方面的实践级流程。CMMI和敏捷不具备高层决策能力,而一种“把事情做正确”的开发模式。

华为公司早在2009年正式发文在全公司现在流程IPD、CMMI的基础上,所有产品线的软件开发团队全面推行敏捷开发,可见这三个体系并不是孤立存在的,而是可以相融互补的。

由上图所示IPD关注整个产品的开发管理,包括市场、开发(软件、硬件)、结构、生产、采购、财务等各个方面,CMMI/Agile流程关注其中的软件研发过程的管理,CMMI是在研发过程中走瀑布模型,而敏捷是走版本迭代的模式。

所以如何建设自己的研发体系,并没有标准的答案,而要关注自己团队的发展阶段、规模大小、业务形态,根据上面三个体系的指导,建立一个适合自己发展研发体系。而且研发体系也不是一成不变的,也要根据业务的变化不断的迭代调整,以符合业务发展的需要。

软件产品研发管理体系

  1. 对软件研发管理体系的一些概念认知 1.1. 研发管理是什么 关于研发管理,百度百科中这样定义:研发管理就是在研发体系结构设计和各种管理理论基础之上,借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。 也就是说,研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构,之后按照这种研发体系结构组件一支高水平的研发团队,设计高效合理的研发流程,借助合适的研发信息平台支持研发团队高效工作,以绩效管理调动研发团队的积极性,以风险管理控制研发风险,以成本管理使研发在成本预算范围内完成研发工作,以项目管理确保研发项目的顺利进行,而知识管理使得研发团队的智慧联网和知识沉淀。 纵观各类软件企业,由于自身所处环境不同,因此其软件研发管理模式也不尽相同,这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系,也有基于IPD集成产品研发框架指导下构建的研发管理体系,当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分,最终追求的目标都是能否适合企业的发展,给企业带来市场和财务上的成功。 1.2. 基于CMMI的研发管理 CMMI能力成熟度模型相信大家都不陌生,从一级到五级,覆盖了22个过程域,一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然,这里主要是指企业能够确实按照CMMI模型去实践,这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则,实际上,大部分企业尤其是国内企业并不会严格按照这个模型去做,因为如果每一个过程域都不打折扣地执行地话,需要非常标准化的流程和强大的资源支撑,在这个讲究快速响应变化的时代其实是很难做到的,通常这个时候都会进行相应的裁剪,甚至会结合敏捷迭代等方面的模式,从而逐步形成自己公司的研发管理体系。 1.3. 基于敏捷模式的研发管理 在这个快鱼吃慢鱼的互联网时代,对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系,主要理念就是敏捷迭代、小步快跑,快速改进、拥抱变化,用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外,还有相应的成熟工具做支撑。例如,腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分,实现对需求的有效管控和分解,从而确保持续迭代上线。 敏捷研发管理在当前我们以业务为导向、项目为主的情况下,要全面实施尚有较大困难,当然并非是完全不能做,主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。 1.4. 基于IPD的研发管理 之前有简单了解过IPD产品研发管理体系,我认为其中的核心就是“四四四”模型,四四四代表了四大团队、四个流程、四个支撑体系。 四大团队建设包括建立集成产品管理团队(IPMT)、建立产品市场团队(PMT)、建立产品开发团队(PDT)、建立技术开发团队(TDT)。 四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。 四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。 个人感觉,基于IPD的产品研发管理从整体上来看是一个相对重量级的体系,要落地执行往往需要从整个公司层面去整体考虑和推动。 IPD的理念和敏捷开发理念在本质上是基本一致的,比如以市场需求(用户价值)为核心,将产品开发看成一项投资(商业价值),通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品(各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付)。 从理论上来讲,IPD研发管理体系是一个较全面的体系,在当前我们的现状下也可能容易出现水土不服的情形,当然其中有一些好的做法是值得借鉴的。 2. 什么样的软件研发管理体系适合我们的发展 从项目及产品的研发角度来看,发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式,由于项目的特点及人员的组织结构等因素,项目开发及产品研发的周期往往较长,较难适应市场快速变化的需要,也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂,推行了敏捷研发模式,或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。 那么,针对当前我们所面临的一系列问题,究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展?我们需要重构我们的软件研发管理体系吗?我们有必要重构我们的软件研发管理体系吗?带着这些问题,我想主要思考几个方面的问题。 2.1. 能否快速适应未来业务的发展变化 技术是为业务发展而服务的,因此在考虑软件研发管理体系构建时,第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下,信息化能力是越来越多客户的第一选择,因此在业务的快速发展方面需要更加强有力的技术支撑,而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系,特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。 2.2. 在业务出现较大波动时能否弹性伸缩 另外一个问题就是,业务在发展过程中,受大环境等诸多因素的影响,定然很难一直都是呈现直线上升的发展趋势,这当中必然会有波峰波谷,只不过这个波峰波谷是大是小的问题。而我们面临的问题则是,当出现较大的波峰波谷的时候,我们的研发管理体系应该如何适应?特别是在软件业务处于相对低谷时,既能够继续保持对技术研发的持续投入,又能够在应用开发等方面有一定的可伸缩性,从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下,不同业务单元的发展会有不同的发展路径,对软件研发能力的诉求也有所不同,那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。 对于基础研发能力,个人认为应该是一个软件公司最内在的核心技术能力,往往很多时候基础研发工作很难像做行业应用开发那样立竿见影,但这项工作干得不好往往又容易成为行业研发能力的掣肘,这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。 对于行业研发能力,个人认为应该要从两个方面去考虑,一个是产品化的能力,其二才是应用开发能力。应用开发能力很好理解,就是目前我们这么多年以来一直在做的各种类型的项目开发,而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容,不过这条路上我们尚开始起步,还有很长的路要走,也还有不少坑要踩。个人认为,产品化的能力能否真正发展起来,其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发,应用开发更多是定制化的开发,是客户导向的软件开发,通常面向的是一个或少数几个的客户;而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发,是市场导向的软件开发,面向的是一个或多个的客户群体,甚至面向的是一个市场或跨界市场。 2.3. 新技术研发及成果转化能否跟上业务变化 最近几年,新技术层出不穷,在软件架构的发展方面也非常迅猛,历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看,我们有少量的项目/系统采用了SOA架构,然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看,我们在技术领域的持续跟进及成果转化方面已然有落后趋势,这方面需要我们奋起直追才行。当然,出现如今这种局面固然由众多因素催生而成。比如,已有开发框架前端兼容性的问题最近一两年以来常常被诟病,诚然有它内在的好处,然则最近一两年以来,用户对系统的用户体验要求更高了,不再是单纯地满足于功能实现层面,而是开始追求良好的人机交互和界面展现。因此,这方面势必对新技术的要求更加迫切。最近几年,当不少团队都在往前后端分离走的时候,我们至今的绝大部分软件项目开发仍然停留在前后端分离之前,对不少用户界面展现要求高的软件项目而言,难以快速有效响应变化,同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。 因此,能否在新技术的研发上抓住正确的方向并加快研发成果转化,为业务的快速变化提供强有力的技术支撑,是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看,研发架构方面,我们虽说不能完全抛弃传统的单体/垂直架构,但我们必须要往微服务架构方向迈进,除了与最新技术接轨之外,更重要的是如何进行业务解耦,沉淀行业积累,并反向推动人员组织层次的变革,提升软件生产效率,提高软件质量。 除此之外,对于人工智能、区块链等新领域,也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。 2.4. 在标准化和敏捷迭代之间如何平衡 标准化的软件研发道路固然有不少好处,有严谨的流程、规范的体系、固定的套路,当然更多的则是瀑布开发模式,虽然最近几年也陆续有迭代开发的模式,但更多的是被动式响应,而且这种迭代开发模式基本上是大阶段的划分,在每一个大阶段里面依旧是一个典型的瀑布开发模式,即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤,横跨周期往往较长,一旦发生需求变更,变动的代价过高。 敏捷开发强调以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 那么,问题来了,既然标准化项目管理模式下存在太多流水线作业及效率低下等问题,那么我们能够直接转向敏捷迭代模式呢?世界上万事万物都是对立统一的,个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面,在现有的以项目为主导的软件开发体系中,标准化模式是我们一直以来的主要做法,也积累了不少经验做法;另一方面,采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪,既能提高软件质量和软件开发效率,也能够保留一定的规范性和软件过程文档。例如,针对项目管理,通常是五个过程组:启动、规划、执行、监控、收尾,那么我们其实可以结合实际将规划提前,将监控贯穿于执行过程,这样就势必要求在启动时也要做好项目计划相关工作,在执行过程中抓住关注点并定期监控其执行情况,在收尾阶段做好项目回顾总结。 不论采用何种模式,我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 因此,我们的软件研发管理体系中是否应该引入DevOps,进而改善公司组织文化、提高员工的参与感、提高交付效率,我想这也是需要重点关注和考虑的。 2.5. 组织过程资产能否持续积累并盘活 组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标,项目组织在实践中形成自己独特的过程资产,构成组织的核心竞争力。 组织过程资产主要包括但不限于以下内容:项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训,其中既包括已经形成文字的档案,也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档,包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。 经过多年的软件开发,我们做了大大小小形形色色的软件项目和产品,也逐渐积累了一些行业化的软件项目,但总的来看,能够形成规模化效应的软件产品尚较为匮乏,更多的是以定制化开发为主的软件系统,当然也积累了不少项目经验。在这过程中,也积累了不少标准、规范、流程、模板等各类软件过程资源。然而,从目前掌握的情况来看,这些资源是分散的,不够体系化的,还谈不上真正意义上的资产,至少在价值的发挥上还不充分。况且,软件行业这几年的人才流动率明显加快,人员更替的速度以及未能体系化的过程资产积累,加剧了组织过程资产的盘活难度。 那么,构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分,也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中,其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产,这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”,是一项涉及知识库、过程资产、环境和交流等元素的整合过程,所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言,我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。…