Nov 2019
目录
2.1.1 敏捷开发可以快速应对瞬息万变的市场和客户需求 6
5.6 改善员工绩效考核（KPI）制度, 建立更加完善、全面的奖惩制度 17
1.金融行业环境现状及趋势分析
21世纪初开始，快速的市场变化引起了金融产业的快速更新，众多产品上线的同时，质量变得无法保障，产品失败率随之提高。2002年，在中国软件行业协会的支持下，人民邮电出版社出版了国内第一套敏捷书籍极限编程系列，标志着国内大规模敏捷知识传播的开始。在2008年全球经济危机的刺激下，中国金融业改革迫在眉睫。2010年起，一些中国金融业敏捷转型的先驱者开始尝试引入敏捷或精益的方法。此时，经过近十年的发展，敏捷方法已经在我国的软件行业得到了广泛的传播和应用，敏捷软件开发方法在我国已经具备了全面传播也发展的可能性。至此，我国金融业正式进入了敏捷1.0时代。在这个敏捷的试验期，Scrum方法占据的绝大多数市场，由于这是一种较易操作的框架，比较适合作为最初导入的切入点。作为敏捷的初尝试，这个阶段的敏捷团队大多是选择了一个主流的敏捷框架，模仿其团队组建和工作流程的方法论，进行敏捷转型的初步尝试。这个时期进行敏捷转型的企业是勇敢，有前瞻性的，但大多数也是照本宣科的，形似而神不似的“敏捷”。
从2015-2016年开始，敏捷方法论逐渐成熟，越来越多的传统行业意识到传统管理方法的落后性，令大量准备尝试敏捷转型的公司目不暇接。各类敏捷思想如雨后春笋般涌现，渗透到各行各业中，正式宣告了敏捷2.0时代的到来。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的敏捷项目实施人员有相应的培训，同时也有很多敏捷服务提供者将前沿的敏捷思想研究透彻并结合公司实情提供定制化的敏捷转型服务。这个时期进行的敏捷转型，不再仅仅是生搬硬套敏捷框架，而是团队级、大规模、可缩放的客制化敏捷改革。
而从2019年起，随着我国经济飞速发展，金融业也呈现出突飞猛进的势头。在整体金融行业一路高歌的发展中，大多数国内传统金融机构进入敏捷3.0时代，大部分企业结束敏捷初尝试，有的成效显著，有的还只是浮于表面，只有流程上和形式上的改变，而无法落到工程指标上。这阶段应该充分结合Devops等新的治理模式，进行精细化、可监控、可度量、可优化的客制化大规模敏捷。在量化管理级水平上，企业的敏捷转型不仅要形成一种制度，而且要实现量化与数字化的管理流程，实现管理的精度，降低项目实施在质量上的波动。从管理流程到工程工具，自上而下做到全方位的、成果可监控的敏捷，降本增效，实现企业组织快速决策和持续迭代，在保证金融服务水平的基础上，提高金融服务效率与金融服务能力，以应对不断升级的消费需求、顺应消费迅速升级的市场趋势和加速发展的全球一体化的经济趋势。
1.1新兴金融模式的出现及对传统金融的冲击
随着信息化和数字化时代的发展，一些新型金融模式应运而生，为金融行业带来更多创新模式和机遇。互联网的繁荣推动着商业银行进行基于互联网的业务升级和转型，推行零售金融、网络金融、移动金融等集金融服务与客户体验于一体的综合服务。由于我国经济转型对消费的刺激、扩大内需、调整经济发展结构的需求迫切、居民收入、消费能力提升，我国新型金融市场取得快速发展。新兴的金融模式拓宽了人们的消费渠道，增加了人们的消费方式，降低了对传统服务渠道的依赖性，越来越多的人开始利用网络借贷服务进行消费就是很明显的例子。在多种消费渠道的带动下，人们的需求变得更加复杂，更加灵活多样，更加难以预测。传统金融被新兴金融模式的急速发展大大压缩了生存空间，故而亟需从战略高度深入分析内外部环境和产业链现状，看清发展思路，明晰自身优劣势，提高市场竞争力。
1.2 传统金融应对新兴金融模式的困难
面对复杂的消费需求、多样的消费渠道、及被压缩的市场空间，传统金融有些应对乏力，具体表现在：
1.2.1开发团队各级沟通效率低
传统金融行业的开发周期流程是典型的瀑布模型，即需求分析、系统设计、软件编程、软件测试及软件维护依次进行。这些开发步骤相互独立，不同部门之间沟通的成本高、效率低，极易出现协作时信息不对称、相互推卸责任等问题，从而导致协作效率底下。
1.2.2运营系统维护成本高，开发压力大
新兴金融模式的出现不仅影响着传统金融开发的整体流程，而且对传统的技术也是一项十分严峻的考验。在新兴金融的冲击下，项目开发对科技支持的要求越来越高，对于更先进，更全面，更高效的技术的依赖性也越来越强，技术部门无论是引进新的科技还是自主研发升级现有技术，无疑都会产生巨大成本。组织信息化的不断投入，硬件设施和软件系统的不断增加，这些在一定程度上都会增加IT运维的复杂性。尤其对于系统复杂性高，业务持续性要求较高，上下游产业链完整的企业，系统一旦出现任何故障，都势必会造成巨大的资金损失。
1.2.3传统金融行业IT架构灵活性不足
自2000年以来，银行业开始全方面投入建设全国集中的核心业务系统，这种集中式系统框架构成稳定，可靠性强，是金融业务和信息化建设的基础。伴随国家实施安全可控战略的落地实施，移动互联网金融的兴起，普惠金融业务量迅速提升，集中式架构略显疲态，逐渐出现例如故障容错率能力和弹性扩展能力不足、对基础软硬件产品依赖度高、核心技术受制于人等诸多局限性。因此，传统金融行业的IT架构亟需转型。
1.3 金融行业与大规模敏捷开发结合的趋势
2018年5月24日，第165届银行业例行发布会在北京召开，其提倡的“以金融科技为转型核心，打造最佳客户体验银行”为金融业的转型与发展拉开了序幕。随着科技的发展，金融自身产业结构的变化将比以往任何时期更剧烈。消费升级、技术进步、市场竞争，以及利率、汇率机制的进一步市场化，将改变客户体验方式和金融服务方式，金融机构不再是单一的产品提供者，客户也不再是单一服务需求者。传统金融业正面临着来自业务创新、敏捷开发、智慧运营、成本掌控等多维度挑战。如何做好数字化生态银行，创造更好的市场、更好的体验，提供更高效的服务，是每个金融活动市场主体必须面临的战略课题。为了解决传统开发模式需求变动迟缓，沟通成本高，运营系统压力大，开发周期长等诸多问题，金融公司需要拥抱技术，拥抱敏捷，把“敏捷”注入到自己公司内部血液当中，让开发过程“跑”起来，实现更快，更灵活，更敏捷。敏捷转型的核心就是传统企业必须直面新兴金融带来的产业发展和消费者行为变迁，对整个企业商业模式进行重新探索与思考，对内部的管理体系、业务流程进行再造和升级。
2.大规模敏捷开发介绍
2.1 敏捷开发的主要特点
2.1.1 敏捷开发可以快速应对瞬息万变的市场和客户需求
互联网时代给金融业带来的一个明显的转变，是从注重内部效率到注重对外响应力的过渡，即从过去“以自身服务为中心”，到现在“以客户为中心”。以前以自身服务为中心的时候，金融业的管理方及技术实践都是围绕效率来做的；但是现在，显然要求从客户的角度来思考问题，所以就需要更加关注响应力。敏捷开发以用户的需求进化为核心，重点放在快速高效地响应客户的需求上。除此之外敏捷开发的优势还体现在对需求不确定性的把控上，所谓需求不确定，是指客户的需求可能随着时间的变化而变化，有可能最开始客户的需求与最后交付时客户的需求大相径庭，所以这就要求开发团队在面对需求变化时展现出良好的适应性，即灵活地适应各种变化以满足客户需求。
2.1.2 敏捷开发可以促进项目的高效交付
大规模敏捷开发在产品开发上采用了迭代开发的模式，其产品增量开发的特点可以很好地保证产品质量，保证产品与客户需求有着很高的契合度。相比于传统开发模式中客户只能在长时间开发周期末端见到产品，敏捷开发将一个长时间的开发周期分解成多次、连续的开发过程，通过短期的、持续的交付来实时跟进客户的反馈，保证每一次对产品的加工都能符合客户的预期要求。在满足客户需求的同时，持续的产品改进提升了产品质量，增加了产品价值。此外精细化的项目管理加强了对产品质量的把控与监督。敏捷团队在项目开发过程中还运用了新兴的开发工具，大幅度地提高了开发效率。高效的开发过程以及过硬的产品质量增加了产品在市场中的竞争力，提升产品在市场中的占有率。
2.2敏捷开发主要框架及应用分析
现在市场上常见的几种敏捷开发的框架有：Scaled Agile Framework (SAFe) ，Large-Scale Scrum (LeSS) ，Scrum of Scrum (SoS) 等。
Scaled Agile Framework （SAFe）使用了精益和敏捷原则，并将它们结合到针对大规模项目的方法中。基于常规的敏捷框架，SAFe定义了一个可扩展的敏捷框架模型，它适用于大型团队的合作开发，可以帮助提高团队之间的协作性，降低团队管理复杂性。SAFe提供了一套在企业的投资组合、价值流、项目群和团队各个层面的完整的工作指南。
Figure1 SAFe开发框架[1]
Large-Scale Scrum (LeSS) 应用于为同以产品服务的多个团队，它并不是一种新的和改进的Scrum, 它是一种使大规模应用Scrum尽可能简单的解决问方式和原则。LeSS不会增加多余的角色，工程和流程，会以更精简的过程来高效地完成工作，并且它专注于了解客户的实际问题并解决这些问题。LeSS根据团队的数量有针对性的提供了两种框架，LeSS和LeSS Huge。LeSS 针对与2至8个团队的开发规模而LeSS Huge 针对8个以上团队的开发规模
Figure2 LeSS框架 [2]
Scrum of Scrum (SoS)广泛应用于大规模敏捷的初创推广阶段，SoS相比于其他方案更加轻量，且无需设置过多的职能，可以保持组织的灵活性；同时也可以在必要时进行扩充。但随着市场化进程的加快，已逐渐减少使用频次。
3.金融行业大规模敏捷开发的成功经验
当前的中国金融行业，在思考如何依托互联网快速抢占市场、提升产品与市场契合度的同时，也面临着快速发展的新兴金融模式的不断冲击。金融公司需要在安全准确的前提下，追求更快、更灵活、更敏捷。从2010年开始，国内的金融公司纷纷追随国外同业的步伐，开展了不同形式的敏捷转型之路，但是可以实现规模化有效运转的成功案例仍旧非常有限。敏捷转型失败的金融公司普遍在试点过后的推广期反复徘徊犹豫不决，其中的原因多种多样，比如对于企业级转型的战略规划不确定、组织架构转型中职责边界划分不清晰、核心人员对敏捷知识的不理解不认同、成熟商业化框架落地方法的经验不足，以及管理实践与工程实践合作机制不成熟等。与此同时，也有一些金融机构成功实现了敏捷转型，在此，以区域性银行和股份制银行为例，说明一些金融行业大规模敏捷开发的成功经验。
3.1 区域性银行的敏捷之路
3.1.1区域性银行在市场中的痛点
随着市场经济的快速发展和金融改革的不断创新，我国区域性中小银行迎来了巨大的发展机遇，同时受互联网快速崛起、创新技术广泛应用的影响，也正面临着产品市场日益出现新的挑战。在敏捷开发流程中，区域性银行自主可控性相对较弱，其大部分开发流程以外包为主。区域性银行在项目开发时通常只有思路，从设计到最终交付很有可能外包给其他开发公司来做，基于这种情况，区域性银行在项目开发过程中更多的是听取其他公司的意见，对于整体项目开发的想法与设计很大程度上取决于外包公司。相对地，股份制银行的工程基础通常较好，在项目开发中，从需求分析到开发测试有能力全部由自己公司完成，其核心想法完全捏在自己手中。另外，相比于大型的股份制银行，区域性银行在技术方面的投入通常导致其研发能力稍显逊色，需要打通开发环境、使用版本等工程方面的关键障碍以优化流程。
3.1.2应对方法
由于区域性银行财力有限，需求失败率高是对公司极大的消耗。区域性银行更需要在控制成本、保证安全和提升竞争力中找到平衡点。对于趋于稳定的系统，为了保证其安全性和可靠性，需要完备的开发流程和详尽的后期维护信息；而对于新兴功能，其稳定性不强，需求变化较大，更强调对市场的快速响应和灵活开发，需要形成敏捷的闭环管理，即在敏捷开发的所有流程中保证所有项目支持敏捷开发模式，完全执行敏捷开发，使所有部门步调统一，形成整体性的敏捷开发。其次，区域性银行还有打破技术上的难点，打通环境以支持敏捷开发。区域性银行的项目工程的基础相对薄弱，应当建立成熟的管理机制，扫清技术障碍，优化流程。
3.2 股份制银行的敏捷之路
3.2.1股份制银行在市场中的痛点
对于股份制银行，其开发投入大，后端技术支持机制完善，对于敏捷开发工具使用熟练都是其特有的优势。但股份制银行由于自身体量较大，对于需求的变更可能需要大量大范围的调研，所以在对需求的收集，整合和管理上难度颇大。另外，由于股份制银行自身的公信力和巨大客户基础，也面临着更加严格的市场监管，公众对其应对新兴技术的能力有着更高的期待。
3.2.2应对方法
针对股份制银行需求管理整合难度大的问题，公司可以实施“科技前置”：技术部门培养一些具备业务分析能力的技术精英，并使其加入到业务部门参与项目设计，基于技术开发的经验和对客户喜好的了解，从技术和业务的双重角度为项目出谋划策，使得项目与客户预期的契合度更高。其次，股份制银行可以利用灰度发布的方法持续追踪项目成果的质量，邀请部分客户直接参与到产品研发过程的测试中，在正式版本发布前收集客户反馈，更加有效地调整产品与客户需求的契合度。另外，基于扎实的技术基础，股份制银行在开发过程中可以结合更多的新兴技术，例如物联网（Internet of Things）,人工智能技术（AI），区块链技术（Block
Chain），云技术（Cloud），大数据（Big Data）等。运用这些新兴技术可以更高效地支持开发流程，增强客户的体验感。
4.金融行业在“敏捷之路”上的挑战
4.1敏捷开发模式在团队管理理念上的突破
大规模敏捷开发要求开发团队负责人在团队管理理念上进行适当的转变。传统团队负责人的角色是给下属分派任务，最终决策权和团队中心主要在领导层。这样的团队模式使得员工的工作仅限吩咐办事儿，不参与决策，或许不能在对应职位上发挥专业特长。另外，传统的开发模式中，团队间较少互相交流进程，长期以往就会造成信息的不对称，各个部门之间流程出现偏差，影响总体效率。敏捷开发理念源于西方概念，有些敏捷开发模式中的理念对于中式理念有着不小的挑战。例如，敏捷开发模式让开发人员参与决策，项目负责人的主要职责则从发号施令转化为服务于开发人员的需求。这样的团队模式能充分发挥员工的专业能力，并且在管理者的帮助下提升工作效率。另外，大规模敏捷开发强调透明性（transparency），即各部门之间的进度与需求要保持一定的透明性，各部门直接需要积极地交互现在的进度，并且清晰地告诉对方自己对于其他团队支持的需求。
4.2 金融公司很难形成统一的“敏捷”战略意识
大规模敏捷开发模式强调以用户为中心和高响应能力。然而，某个人或者某个部门的响应能力高低并不能代表整体，更有可能出现的情况是个体的敏捷被其他部门拖慢节奏，让已经实现敏捷开发的个体或部门熄火。只有在所有相关部门内形成整体敏捷，机构才能拥有真正意义上的高响应能力。但是让所有部门全部实现敏捷开发必须面临着大型改革，甚至是重新定义规则框架，这需要领导层有决心，有毅力，有魄力打破原有的组织结构、管理模式、管理理念，也需要公司员工贯彻领导层理念，形成全机构自上而下的统一改革意志。
4.3敏捷开发需要优化团队间协作机制
金融行业有着清晰的部门划分，每个部门都分工明确，各自负责相对应的业务，都有各自的行为准则，业务标准以及事务优先级。这就导致各部门员工习惯性地把如何优化自身业绩作为一切行动的判断标准，而弱化了对部门外整体战略的敏感度和配合度，从而拉长各部门之间的响应时间，拖慢整体节奏。想要实现高效的团队配合，缩短响应时间，就要求所有团队创造一个整体的目标。以敏捷开发的角度而言，应为单一项目目标创建一个包含各个角色的敏捷团队，实现集中办公，并由项目经理负责团队内部的各项沟通和协作。将金融机构组织架构彻底推翻重构需要承担巨大的风险，所以有效的办法是在现有组织架构的基础上做出不同维度管理的调整。围绕关键的业务环节或者业务范畴建立多个跨部门的敏捷组织，再按照产品、渠道或者客户群体等划分出单独的敏捷项目组。这样单独的项目小组可以在各司其职的基础上实现跨小组的沟通配合。除此之外，敏捷小组成员应该从原有部门体系分离出来，严格遵从敏捷团队的办事规则，最后由敏捷小组负责人进行绩效评判。
4.4 建立精简高效的运营流程
组织架构的转变打破了各部门之间的隔阂，实现了不同部门之间的无障碍沟通，此外，我们还需要打破整体运营流程上的堡垒。运营流程的快慢反映了整体进度的效率，想要让敏捷项目团队“快起来”，就得让运营流程“跑起来”。传统的运营模式要求层层审批，最后执行，但是这种模式审批流程过长，效率低下，每一步的流程都需要经历漫长的过程。对于运营流程更改的一个挑战是权力下放，优化层层审批制度，打造更简洁、高效、健康的流程。敏捷小组的项目负责人在项目初期应该得到相应的决策权和特事特办的快速通道，各部门担任不同职责的员工也需要获得必要的部门授权。这样让权力下放，不仅可以让一些决策下放给专业性更强的员工，缩短流程链条，增加办事效率，还会提高员工的参与感和责任感。
4.5 技术部门角色的转变
生态化、场景化的金融服务，以及数字化、智能化等技术，已经对银行的支付、征信、风险技术、理财、客户获取等核心领域产生极大冲击，互联网技术创造的平台经济、共享经济，也推动着金融服务模式的创新，银行不加快技术转型就会被未来淘汰。首先，金融机构的IT部门是对整个公司负责的，当公司任务叠加在一起时，IT部门势必会根据任务的先后顺序或重要程度进行优先级排序，这样就会造成敏捷项目延期，资源分配不均，投入项目不精等问题。IT部门就像是大班课的教师，要负责全班每一个孩子的问题，如果要求老师投入全部经历去照顾一个孩子，这很显然是不可能的。但是敏捷开发恰恰需要的就是这种一对一形式的服务，需要技术部门全程陪同敏捷开发流程，提供全方位的，针对性强的，时效性强的支持。其次，技术部门的另一个挑战是要从中后台走向前端，从原来只是为开发部门提供支持的角色逐渐转向在提供支持的基础上也要为开发部门提供启发的角色。技术部门需要参与到项目的开发过程中，以技术的角度为团队出谋划策，提供灵感。
4.6 流程工具的改造挑战
4.6.1适应新型敏捷管理工具的挑战
为了达到让项目流程管理更顺畅更高效的目的，要在改造组织架构和工作流程之后，对原本流程漫长的工具也进行更换和升级。由于原本组织架构中不需要共享各自团队的资源储备，所以大部分资料都以文档的形式各自保存在各团队的共享盘（或类似的文档管理工具）里。因此，搭建一个团队各角色共用的流程管理工具成了必然之选。接受并使用新工具对于系统更新缓慢并且已经完全习惯于文件管理系统的银行内部从业人员来说是个非常困难的过程。并且新的管理工具与传统系统必须要有效结合，避免冲突，实现一加一大于二的效果。
4.6.2如何创建新工具的运营环境
目前比较主流的开源管理工具都具备基本的产品管理、需求管理、缺陷管理、任务管理、文档管理、权限管理及统计和搜索功能。可以让客户、产品经理、开发人员、测试人员及运维人员在同一系统中各司其职，快速交流和反馈信息，让软件开发顺利并快速进行，朝设定的目标迈进。然而，一般银行业内部的数据对外都有极其严格的保密和安全机制，所以对于新系统的引进都会非常谨慎。该系统是否存在版权、安全和合规问题会成为领导层首要考虑的问题。所以如何找到一个合适的系统并快速引进和搭建是个艰巨的挑战。
5.通向“敏捷之路”的关键因素
5.1 寻找适合自己公司特点的敏捷战略
在进行敏捷转型的过程中，要从企业高层开始转变思维，要清楚敏捷开发不仅仅在于接受新技术或聘请开发人员，更在于转变处于流程底层的企业文化。在此过程中不能迷恋敏捷，要根据实际情况判断敏捷的特点及优势，分析如何在企业内落地。例如在公司现有的若干项目和系统中，有些功能较为固定、作用较为单一的系统可能在长期之内都没有更新版本的需求，如果一味追求敏捷，会造成资源浪费和用户体验感差；而有些与用户使用反馈密切相关的功能，可能就需要经常更新和优化，这些团队就有必要进行敏捷转型。
5.2 受益者推动—研发部门主导
传统的敏捷转型推动者是质量管理部门，在流程管理、质量保证上有着更丰富的经验。但是很多失败案例告诉我们，由质量管理部门推动的变革往往会有更大的困难。因为敏捷转型的核心是研发部门，其工作模式变化最大、变动量最多，敏捷转型的受益也是最多的。生活经验告诉我们，当你理解一个理论，你才有可能认同，执行也就才会有效果、有思考、有持续改进的可能。当研发部门从敏捷转型的被动执行者转为主动推动者，身份的变革赋予了团队更多思考的机会和权力，当事人从自身实际情况出发，逐步学习、理解、认同、执行、优化，使得敏捷转型是积极的、主动的、简单的、有思考的、有效果的。
5.3敏捷方法论和精益Lean思想的形而上学
精益思想（Lean Thinking）源于20世纪80年代日本丰田发明的精益生产，其主要原则是消灭浪费，创造价值。结合银行的现状，我们找出与精益思想相悖的痛点，比如传统瀑布式开发带来的人力资源配置不合理的问题、交付与需求不匹配的问题、产品功能复用性差的问题，利用精益思想的方法论，在确保流程完整、质量过关的前提下降低人力成本，优化开发流程。在这样的方法论指导下，银行建立了敏捷方法，形成了低成本、高效率的工作流程，这极大地提高了项目之间的联动性，更合理的分配了项目资源，真正意义上实现了消灭浪费。敏捷方法不是最终目的，其背后的精益思想才是取之不尽用之不竭的宝藏。敏捷开发是一种开发方式，是一种新兴的开发理念，它没有很明确的量化指标，从而无发很明确的评判开发团队的表现，所以判断开发团队是否贯彻了敏捷理念就需要实物上的呈现，做到从无形的理念转化为有形的实物成果。敏捷团队在判断流程进度时，可以通过周报，月报等开发报告落实团队敏捷思想。在一段周期后，敏捷团队应当完成一些可展示的实物成果，供需求方进行评定。通过一些精益计算，团队管理者可以计算出具体的指标来直观的判断敏捷团队的效率，例如缺陷占比，缺陷密度，缺陷率，资源分配占比等。敏捷团队还可以根据计算制定团队指标，来规范团队开发效率。
5.4敏捷方案落地的灵活性，
大量国内金融公司生硬地套用框架，使得敏捷效果甚微，形似而神不似。银行需要从中得到启发，意识到软件研发的过程及其复杂性和不确定性，各个公司之间的流程存在巨大差异。学习基于理论和商业的敏捷框架是敏捷转型的基础工作，但是学习之后应该伴随着深刻的理解和对现实的思考，然后灵活落地。当敏捷小组运用Scrum框架、Kanban应用和SAFe理论时应做到根据机构特点进行变更，以对敏捷精神和精益思想的追求和落地作为最终的目标。
5.5注重敏捷开发的可持续性发展
可持续性是指可以长久维持的过程或状态，如何把敏捷开发与可持续性结合在一起是机构实现大规模敏捷的重要一环。在传统开发模式下，一个部门在完成一项任务后可能就会离场，例如在瀑布模式的开发中，产品设计部门在交付设计方案后，在后续的开发过程中很难再看到设计部的身影，如果后续过程需要之前部门合作或者对产品进行调整，沟通难度或重启项目的难度可想而知。敏捷开发团队成员应当是专项人员，从团队的形成开始跟随团队，直到产品的交付，以保证开发人员的持续性。并且敏捷开发团队应当持续关注产品成型后的效果，持续追踪产品问题，各部门应随时做好准备应对需求的变化，保证每一次的升级调整完全解决市场需求。
5.6改善员工绩效考核（KPI）制度, 建立更加完善、全面的奖惩制度
在战略、组织架构和工作模式都做出调整后，人事管理也要顺应整体变化而做出相应调整。单独计算人员的利用率已经不再适用于改革后的组织结构，如何让产品快速上线成了更高优先级的评判标准。原本的单一部门单维度一年一次的绩效考评明显不适用于这种快速交付的敏捷团队。多维度立体地在每次重点交付后的绩效评定更为及时、准确、让人信服。多维度主要体现在原生主管和项目经理在不同角度对员工做出评定，甚至可以参考与该员工有密切工作交互的人员的反馈。整个绩效考评的标准应以项目成果为重点，兼顾个人在项目中的个体贡献。同时随着数字化发展趋势，技术成为了一个越来越重要的支柱，技术人员的重要性也逐渐的凸显。如何为技术人员打造一条和业务人员等同的职业晋升途径也变得尤为重要。只有将绩效指标，奖励制度和晋升途径逐渐完善，员工才可能走向敏捷的道路。
6.参考文献
[1] SAFe 框架图: https://www.scaledagileframework.com/
[2] LeSS 框架图：https://less.works/less/framework/index.html
