精华内容
下载资源
问答
  • 将项目组视为独立的预算机构,则“采购体系+质量体系”即构成交付体系的全部,包括项目组成员的工资,广义讲,也可以认为是“大采购”的一部分。 成熟的交付体系将衍生出产品体系,一方面将经常发生的“采购体系”...

    将项目组视为独立的预算机构,则“采购体系+质量体系”即构成交付体系的全部,包括项目组成员的工资,广义讲,也可以认为是“大采购”的一部分。

    成熟的交付体系将衍生出产品体系,一方面将经常发生的“采购体系”货物内化,另一方面将相关人员内化,第三将对应的质量体系内化,即形成企业经营的产品体系。产品体系需要投资,需要承担风险。通过交付体系验证方向和可行性是必要的。

    完全脱离采购体系的产品体系是不完整的,完全脱离质量体系的产品体系是不完整的。产品体系不能断了给养来源,否则很容易变成闭门造车、死水一滩。

    不能掌控质量体系的产品经理是不合格的,不理解采购体系的产品经理是不合格的,不懂交付的产品经理是不合格的。

    项目经理应高度重视采购体系和质量体系的建立,从“大采购”和“大质量”的视角审视项目过程,洞悉人员关系的本质。

    展开全文
  • 项目交付体系

    千次阅读 2020-08-05 13:56:46
    项目是为了提供独特产品或服务而暂时承担的任务,项目的特征是临时性和唯一性。伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率...建立项目交付体系,提升项目交付

    项目是为了提供独特产品或服务而暂时承担的任务,项目的特征是临时性和唯一性。伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率,将项目交付批量化、产品交付成熟化、产量化,实现此过程的前置条件有哪些,距离当前的目标还需要做哪些事情,本文将从道(目标、战略、远景)、法(制度、规范、保障机制)、术(方式、方法以及熟练度)、器(环境、工具、产品)、人(意识、心态、欲望、人性)五个层面分别阐述说明。

    明以道

    道是根本,是规则、自然法则,上乘。建立项目交付体系,提升项目交付率,实现项目交付批量化的顶层构建依赖于“道”。“道”类于产品架构设计属于顶层规划设置,在“道”里提下“势”、顺势而为,在国际、国家、行业整体大趋势下决定公司的发展方式与方向,顺大势而行软件行业经由无纸化办公至信息化整合乃至现在更为广泛的产业互联网、5G、云物移大智等。道与势结合,在道的规划结合势的辅助更可将事情事半功倍,取得更好的成果。

    1.行业聚焦

    人的精力是有限的同样公司的精力也是有限的,作为公司的运营及发展同样需要聚焦行业,作为公司的运营能够“广撒网多捕鱼”固然有一定成效,但是“专精”才是公司的立身之本。在公司有广泛涉猎的同时需要聚焦行业,深耕行业,了解行业的发展历程、趋势、特点,结合客户的业务特点丰富、完善平台的功能及交互模式。如:地产行业下主数据管理是围绕地产项目为全生命周期管控的,而过程中可能还会涉及基础数据与项目间的关联如房源、期、栋等;业财集成过程中会涉及到成本对接、四费回写(开发间接费、营销费、管理费、规费类)。

    2.项目筛选

    在公司当前阶段不是力求“广而杂”,而是需要“专而精”,主要聚焦于集成领域,意在为企业尤其是集团性企业搭建“一站式”整合平台,构建柔性IT架构,公司战略层面明确公司的专业的领域,当前公司主要精力在集成开发、开发集成两大类项目,致力于公司整理的运营方向及发展方向,公司主力的营业范畴,包含数据治理、统一身份认证、数据治理分析、统一门户集成、统一流程集成几个方向,主要行业在于制造业、建筑业、房地产等多以项目制度为管理方式的行业领域。在商机落地、项目承接选择阶段需要甄别项目是否符合公司发展且是否能够为公司带来价值。

    如公司目前主营对接方案ESB、IDM+ESB、MDM+ESB、ESB+MDM、MDM+ESB+DAP的主要承接侧重要点如下:

    1. ESB应用对接:主要解决客户有3~5套系统间的表单数据对接,服务开发提供的情况;
    2. IDM+ESB统一用户管理:实现客户信息化系统用户统一、认证统一、权限统一、审计统一的4A管控,实现用户账户密码统一无需在系统间返回切换登录,提供工作效率;
    3. MDM+ESB基础数据治理:实现客户主数据治理及规范,建立基础数据管理体系,保障数据的一致性、完整性、准确性,为客户应用集成及数据分析结果的准确性提供坚实的基础支撑;
    4. ESB+MDM应用集成对接:实现客户信息化系统集成,结合主数据时间系统数据映射的管理,为后续数据治理规范奠定基础;
    5. MDM+ESB+DAP数据治理分析:沉淀企业业务数据建立企业自身数据仓库,挖掘企业内部数据价值,将数据可视化、趋势化、价值化。

    3.方案匹配

    匹配公司主营领域及主要行业领域对应项目类型均需要匹配对应的落地方案给予支撑,方案不仅限定于售前沟通方案、项目落地解决方案及同行业案例分享等。

    1. 售前沟通方案:方案主要体现在几个层面如:项目领域的意义与价值,项目主要背景需求,解决客户问题及痛点分析,典型落地方式及优劣比较,同行业对应的案例类比分析。
    2. 落地解决方案:侧重体现结合客户的实际情况针对客户的痛点如何落地解决,通过什么方式解决哪些问题,预计带来什么效果,需要哪些投入及能够输出哪些产出。
    3. 同行业案例分享:主要体现当前案例的背景,痛点,解决方案及实施效果,侧面印证、体现同行业其他公司确实由此方案受益颇多。

    行尊法

    法是措施方法,是实现价值的方式及方法,项目交付过程中仅依赖于框架的体系理论同时对于项目人员思维意识,思维转变也是重中之重,由程序思维转变为用户思维,用户思维转化为产品思维,产品思维晋级为商业思维,只有这样才能很好的实现产品有自己用向友商用及面向用户的交付。同时加快交付、成体系的交付、实现项目做好、做快、做规范、做批量。

    1.体系支撑

    “没有规矩不成方圆”,公司层面关于整体管理体系需要不断的充实、完善,对于公司运营的全生命周期的管控均需要建立完善体系制度,如:商务体系,售前体系,人员体系,项目管理体系,实施体系,奖惩体系。

    1. 商务体系:明晰内部商务、外部商务之间的衔接关系,促进商务与客户间的对接,提升商机的落地促成的几率。
    2. 售前体系:明晰售前沟通、汇报、交流、跟进的各周期的工作内容及工作边界,配合商务促进商机的成单率。
    3. 人员体系:对于人员培养,意识、方法、工作方式、沟通、汇报、学习、管理等多方面全方位系统化培养模式;
    4. 项目管理:项目全生命周期管理,需求、设计、开发、测试、上线、交付、验收、运维,8位一体的全生命周期管理,各里程碑注意事项等;
    5. 实施体系:项目现场交付注意事项,沟通机制、汇报机制的明晰与管理,与客户不卑不亢,与友商化敌为友,与伙伴共进同退;
    6. 奖惩体系:明晰项目的奖惩管理,以奖励促进成员的积极性,更加助力于项目推动及交付。

    2.绩效考核

    公司员工潜能的开发需要鼓励与鞭策并存,在鼓励的同时与压力并存,在压力的临界点伴随鼓励共同推进,一方面有压力驱动员工向前推进,一方面有鼓励增加推进项目工作的动力。建立项目绩效考核体系,有奖励有惩罚双管齐下,同时不仅面向项目交付团队,对项目管理人员,销售人员均需要具有全面的考核体制,管理人员关心KPI才会关注项目实际推进情况,销售人员具备考核指标能有效保证项目相关动作的推进,交付团队明细目标才能够保证项目的交付。

    • 项目管理制度

    1. 阶段划分:不同阶段的侧重点、工作内容、交付输出物的明确与规范且需要输出样例文档;
    2. 需求明确:项目调研过程中明确客户需求,不要含糊而过,将自己的理解与客户确认,框定项目的需求范围。
    3. 设计细致:结合项目需求进行可落地的详尽设计,明确功能约束,技术要点,设计需要详细明确出相关功能的涉及到的基于预研、落地实现。 
    4. 计划精细:项目计划需要明确到人、详细到人天,同一项工作不能有多人同时负责,如果是多人负责则需要把工作进行再次拆分直至明确至个人,计划在实施过程中需要不断完善、精细,周计划明确至人、天,日计划细粒度至少0.5人\天。
    5. 人员分配:不同角色的职责划分,什么人什么时间应该做什么事情;
    6. 汇报管理:按风险、日、周、月、里程碑不同粒度对项目负责人、销售同步项目情况,保证消息的对称性;
    • 绩效考核制度
    1. 考核指标:规范考核指标,考核与绩效挂钩,不同完成度的奖励及惩罚机制,成体系落地执行;
    2. 节点考核:对项目各里程碑节点、收款节点、工作完结阶段需要明确标记出来,以各环节节点倒逼工作管理,输出工作审查情况;
    • 人员晋升制度:分角色、分岗位的晋升制度,不同岗位有明确的职业规划方向,员工可选择自身的规划及发展方向,明确对应T级的晋升制度;

    3.人员培训

    建立员工培训体系,除平台基础操作外需要模拟项目实际进行内部演练,保证新员工对项目整体过程及不同类型项目有整体的意识及交付的概念,明确什么是好的什么是不正确的。

    1. 公司认知:公司为平台产品的提供商及技术解决方案的提供商,对于普遍的承接项目研发公司存在着本质性的不同,对于公司员工需要明晰公司的立身之本,公司的盈利项及公司的发展方向。
    2. 项目认知:作为项目交付需要明晰项目验收是项目完成的基本盘,而项目衍生二次商机,项目运维服务盈利才是项目的本质目标,而实现目标的前提则是为项目提供友好的服务为客户解决实际问题。
    3. 意识方法:项目交付过程中需要具备团队意识、敏感度、责任心,遇见问题暴露问题,解决问题而不是等着事态爆发,一发不可收拾的状态。
    4. 职责明晰:项目交付过程明细各岗位职责,项目经理对项目整体进度负责,把控项风险;技术经理对项目过程中技术问题支持,保证项目技术落地;技术顾问保证自己负责项目工作的进度,同时熟悉项目整体流程及注意事项。
    5. 策略技巧:无论是哪一类型的项目最终都是需要与人打交道,在此过程中不要与客户发生矛盾,与客户关键人建立友好的沟通渠道,权衡其中关系,更好的推进项目。

    精于术

    术是体现,是具体手段。通过法具备方向的指导,结合术的手段落地,项目交付过程中在建立规范的同时需要能够对规范实现落地而不是“空中楼阁”遥不可及。在落地实践的过程中进一步完善、夯实整体的体系,将概念转变为认知,认知转变为下意识。

    1.项目管理

    项目管理主要是实现项目时间、成本、质量的管理,在有限的时间保证项目高质量的交付控制项目成本实现项目质量好、服务好、成本低、满意度高的最优交付。

    1. 需求管理:项目实施推进过程中,客户需求出现变更/增加是常态,从项目管控来说需求变更是不可避免,而对于项目交付而言需要尽量收口项目过程中的变化,引导用户收口或者下期推进,避免整体项目需求跑偏。
    2. 进度管理:项目推进过程中各里程碑节点的管控,以节点倒逼工作进度是否存在跑偏的情况,实时跟进项目进度,进行项目推演,及时暴露问题,避免问题的发生,而不是事后补偿。
    3. 团队管理:需要明确失败的团队没有成功的个人,需要明晰团队成员的动向,团结一心推进项目的工作,在项目中增加团队成员的配合度及默契,出现问题快速解决而不是互相推诿。
    4. 资源管理:领导也是资源,或者说领导是更为有效的资源,销售同样被视为资源的一种,项目最终是以结果论成败,项目管理人员需要以项目风险为优先级,协调各类资源保障项目的平稳推进。

    2.规范落地

    建立项目管理规范后续要进行规范落地,而不是仅有规范而不切合实际,更多时候人更倾向于自己信服的事实。可能规范总结的经验教训但员工自身没有体会其中奥妙没有转化为自己的下意识。而由知识转变为技能,技能转变为下意识的过程因人而异,各有不同。需要在项目实战过程中不断淬炼,增加个人的认知及能力模型的丰富,如:

    规范说明

    枚举说明

    售前管控

    售前人员熟悉方案,沟通前内部演练模拟客户沟通情况,将方案演绎、产品演示划分分别进行,输出各产品的演示关键点、演示方案

    项目管控

    建立文档标准、里程碑标准、考核标准、汇报标准、沟通标准、结算标准

    实施体系

    项目实施过程中建立项目管控体系,项目日汇报、周总结,计划滚动更新;暴露问题解决问题,项目进展极端推演,控制项目需求范围,把控项目各工作进度节点

    测试体系

    内部产品、公司项目均需要遵循测试体系进行详尽测试,按照不同角色、人员从使用、操作、维护角度进行测试,从安全、性能、功能层面进行自动化脚本测试,生成测试报告,交付对应的负责人员

    运维体系

    项目交付后进行内部交接,遵循项目运维体系,明确项目内容、背景等信息,对项目中遗留问题解决,产品层面问题反馈至研发部门进行解决,客户反馈问题及时响应,提升客户的信任度

    3.模拟演练

    建立规范的同时是纸面的通知,而真实的“触感”需要来源于一线的直观认知。而在员工并不具备实际项目参与的能力是时,可通过公司内部项目实现实际项目过程的模拟演练。感受项目整体流程,项目各里程碑是什么情况,与理论的认知有什么不同。

    1. 项目生命周期:6个周期节点从项目售前、合同签订、项目立项、蓝图确认、项目上线、项目验收,各阶段的关注事宜及输出产物。
    2. 项目沟通技巧:与客户、与伙伴、与领导、与商务面向不同群体的沟通方式及技巧,如何推动才能让同事更好的助力项目的推进,不同层面的工作人员的关注点,言简意赅保证工作推进。
    3. 项目封闭标准:项目在实施阶段的目的是验收,将项目封闭实现项目闭环,项目封闭后标志当前项目节点闭环,进入运维工作及二期推动工作。
    4. 项目意义价值:项目不同层面对项目的意义价值有自己的理解,项目追踪需要作为项目案例资源,项目结束后需要明晰项目的价值及意义,客户的价值及公司的价值以及团队的价值。
    5. POC搭建演练:以公司自有业务为需求原型,模拟不同方案下项目的实施方式,一方面作为技术人员的培训,提升员工对项目的熟悉度,另一方面也可演练验证产品的完备性,提升产品的质量。

    利其器

    器是用具提高效率将复查的问题简单化,经过公司对主营的行业领域及主营的范畴细后,项目甄别当前能不能做,而器有效的提升如何将项目做好,如何提高项目交付率,如何将项目交付批量化的工具。通过产品+管理结合,提升盈利;从产品层面考量,面向用户级别产品,打造“无脑式”产品线;项目交付层面:统一、标准、体系、积累、夯实;

    1.成熟产品

    公司本身为产品型公司,想要项目批量化交付则需要产品不仅能为公司员工使用同时需要能够面向伙伴、面向用户都具备较好的交互操作能力。对于平台的安全、稳定、扩展、交互均需要具有极佳的用户体验,且除平台技术能力本身的保障外,对于依赖于产品的方案,使用手册、维护手册、项目典型方案、应用场景及对应场景的落地方案标准文档均需要不断的完善和充实。

    产品名称

    应用场景

    ESB企业服务总线

    做企业服务总线ESB来实现异构系统的对接;

    在数据整合/数据中心项目中,作为综合数据交换平台负责业务数据上传、汇聚,基础数据(主数据)的下发、分发;

    综合集成项目实现跨系统业务流程重组;平台协作及支撑

    MDM主数据管理平台

    主数据管理的用户是各业务系统、数据集成系统、应用集成系统、业务流程再造系统、BI智能决策分析系统。通过主数据管理,改变企业数据利用的现状,从而更好地为企业全方位的信息整合做好铺垫。

    BPM流程集成平台

    流程集成平台一般用于跨异构系统的流程集成,或者实现业务流程间相互调用;也可以做工作流系统来用,为特定业务系统做为工作流引擎提供用户与流程信息交互的接口,实现诸如完成、挂起、加签、回退、签收等改变引擎流转的操作

    IDM身份管理平台

    搭建统一用户中心实现用户统一、认证统一、权限统一、审计统一的四位一体的统一管控,建立统一管理体系

    DAP数据分析平台

    挖掘企业数据价值,将企业沉淀数据可视化、资产化,建立企业自身的数据管理体系及数据存储模型

    Portal门户集成平台

    搭建单一的信息门户、知识门户、数据门户、应用门户、移动门户、开发社区及综合办公门户,通常及到AEAI ESB应用集成平台来协作,用于提供数据服务或者进行相关的数据加工汇总;

    2.管理系统

    项目管理同样需要信息化进行支撑,建立项目管理制度的同时匹配对应的项目管理系统,支持项目管理标准的落地,结合系统有效的对项目风险进行评估及展现,避免人为性掩盖事实。结合系统的统计情况真实、有效、实际的展示项目当前的进展状态,风险评估状态,项目里程碑节点,项目收款节点,项目当前进展状态及后续推进计划。

    • 如典型项目管理系统功能:
    1. 项目信息管理:项目管理可以看到项目信息和项目计划,用于创建项目的基本信息,比如项目的成员,周期成本合同周期等等,项目计划为每个人分配的任务,具体每天都要干哪些功能,进行一个统一的管理;
    2. 项目过程管理:对于项目周计划、日计划的滚动管理,项目计划填写完毕后并且总监对计划也进行确认,确认后项目经理就可以进行项目周报的填写,项目开发人员完善项目日报;

    3.办公环境

    工欲善其事必先利其器,生活的周边环境也是一种器的体现,大到欢愉的公司氛围,办公环境,网络带宽,小到使用的电脑、手机甚至是居住环境均会影响个人的思绪和心情进而影响办公的效率及积极性。这些环境因素往往是对办公情绪影响最大的但却是最容易解决的,如:居住环境在外出出差实施项目租赁房屋时选择比较符合心意的房子,一方面提升居住的舒适感,另一方面舒适的环境也是缓解工作的疲劳和压力的有效途径。

    常见的办公环境因素如下:

    环境说明

    匹配优选

    公司氛围

    • 公司氛围一定程度决定公司发展,选择公司氛围融洽,专心做事、敢打敢拼、全攻全守、

    生活环境

    • 居住环境:项目租赁房屋可优选居住舒适度较好的房屋,提升居住舒适度,缓解异地负面情绪
    • 网络环境:优先选择可控带宽的运营商,提升办公速率

    办公工具

    • 电脑:在经济允许的情况下选择性价比高的办公电脑,便携、速度是重要考核指标

    交通环境

    • 可控范围内选择便捷的交通环境,如公司选择在是地铁周边,交通便捷的地方,方便员工的出行

    皆由人

    “尺有所短寸有所长”无论是对公司还是对于个人而言均是广泛涉猎的同时需要有自身立足的根本需要具备深度的挖掘,呈T字型发展趋势。对于公司而言在具备广泛产品系列的同时需要有自己的深耕行业及“明星”产品,一方面在这一领域各类瓶颈了如指掌,另一方面通过产品切身实际的解决用户问题。对于个人而言,人的精力是有限的需要做好个人的“精力”管理,有自己的专业领域在专业领域内不断深入,提升自身的竞争力。

    1.自我约束

    历览前贤国与家,成由勤俭败由奢,懒惰的所有人的天性,而自我约束才是能够提升自我,超越非凡的本质。不以恶小而为之不以善小而不为虽是表述是非之道,从自我约束的角度来看也是同样的道理不要因为事情繁琐就拖延,不要因为工作简单就推进。自我约束管理,越忙越要整理计划,梳理工作项目;越慢越要倒逼原因找出本质而不是得过且过,不求有功但求无过的蜗牛心态。

    1. 时间管理:利用闲散时间总结规划当天的工作项及对应工作的完成情况,哪些工作需要协调哪些资源,预计需要多少时间;
    2. 心态建立:责任心、主动性、积极性需要化被动为主动,积极迎接变化,面对问题解决问题,不断积累形成正向循环;
    3. 习惯培养:主动汇报、积极涉猎,带着好奇心工作,对工作涉猎的知识点及周边知识点进行学习,由点到线,由线到面搭建知识体系。

    2.洞察人性

    无论是售前、实施、运维最终都是与人在打交道,在不同阶段与不同的人员沟通交互,每个人都有着自身的性格标签,需要结合个人性格特点有分别的进行交流。

    1. 与客户:与客户不同层面的人沟通时需要注意,有人风风火火,有人沉稳冷静,有人内敛涵养,面对不同性格的人需要建立良好的沟通渠道,保证工作推进的顺利;
    2. 与伙伴:与伙伴交流的过程中注意不同人承担的角色,销售辅助推进配合,交付并肩推进,管理明晰工作;
    3. 与领导:与领导需要言简意赅,明晰工作进度,问题点及潜在的风险点,不要盲目乐观,报喜不报忧导致问题爆发;
    4. 与团队:与团队成员建立并肩作战的情谊,失败的团队没有成功的个人,明晰整体团队的目标齐头并进。

    3.一往无前

    置之死地而后生,只有摒弃后路方可一往无前,每个人都有无限的潜力等待被激发,在成年人的世界没有永远的敌人只有永远的利益,不同的人可以为共同的目标一起努力,而在团队管理的过程中需要激发团队成员的欲望,激励成员的斗志,保持清醒的战意。向目标齐头并进为实现一往无前。

    对于员工而言更多的不是惧怕吃苦受累,而是没有目标和方向。作为管理者需要帮助员工明确公司未来发展方向及个人发展规划,为员工制定目标,将员工目标、公司目标相互融合,使得个人收益与员工收益互相联系。激发员工由被动接收转变为主动进取,且匹配对应的考核奖励制度。实现员工有盼头、得甜头、足劲头进而形成正面良性的体系。

    ​​​​​​​4.厚积薄发

    仅仅依靠任务的关系去维系项目推进是不足以作为项目推进支撑的,项目实施的本质还是要落地项目中客户的需求,消除客户使用的痛点,提升客户的使用满意度。本质上还是需要以实力取得客户的信任,提高客户对公司、平台、团队的信任感,而对于个人而言需要不断累积自身的实力,没有量的积累很难实现质的飞跃。在此过程中个人需要不断提升自我认知,提升个人能力,将硬实力与软实力结合,保证项目交付。

    道法术器人思想虽然源自历史长河,但内涵精髓却经久不衰,其理论方法被不断延续用于现代企业的管理,道:是方向、理念、价值观;法:是组织架构、经营模式、管理体系、规章制度;术:是策略、技能;器:是工具(硬件、软件等),人:是基本元素、成败关键。五者结合,以道义来承载智术,“术”要符合“法”,“法”要基于“道”,道法术,通过最好的技术和工具,人是“道、发、术、器”的承载着,五者兼备做出最好的策略。

    展开全文
  • 本文为大家介绍持续交付体系在高德的演进落地。2.持续交付正如前序中所总结的,我们需要构建一套持续交付体系,从而保证在质量不下降的前提下,在业务价值交付上有更进一步的突破。那么我们先了解一下什么是持续...

    1.  前序

    对于工程团队来说,构建一套具有可持续性的、多方面质量保证的交付体系建设,能够为业务价值的快速交付搭建起高速公路,也能为交付过程中的质量起到保驾护航的作用。本文为大家介绍持续交付体系在高德的演进与落地。

    2. 持续交付

    正如前序中所总结的,我们需要构建一套持续交付体系,从而保证在质量不下降的前提下,在业务价值交付上有更进一步的突破。那么我们先了解一下什么是持续交付以及集团在持续交付的建设上有哪些指引。

    2.1 持续交付概念

    引用Martin Fowler大师在2013年时发表的文章,对于持续交付的概念有如下的解释:Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

    在上述文中,可以提取几个关键词:

    1. 软件开发的标准化准则

    2. 可以做到随时随地的发布

    什么情况下就可以算是团队达到了持续发布的状态呢?Martin Fowler大师也给出了标准的答案:

    1. Your software is deployable throughout its lifecycle

    2. Your team prioritizes keeping the software deployable over working on new features

    3. Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

    4. You can perform push-button deployments of any version of the software to any environment on demand

    那么基于以上的观点,我们在建立自身的持续交付体系时,需要抓住以下几个重点:

    1. 标准化流程流转

    2. 当有变更进入时,能够快速、准确且自动的得到反馈

    3. 解决部署问题的优先级高于功能开发

    4. 一键发布

    2.2 集团的持续交付建设

    从理论基础上对于持续交付有了初步了解后,我们从集团层面了解一下是如何定义持续交付的能力,并且对于持续交付提出了哪些效能改进目标,参见阿里技术公众号的文章 《如何衡量研发效能?阿里资深技术专家提出了5组指标

    文章中将持续价值交付的能力拆分为3个层面的5组指标,从不同角度对持续价值交付能力进行了衡量。

    有了上面专业层面的衡量指标,那我们是如何定义一个优秀的持续交付衡量目标呢?

    管理学之父德鲁克说:“如果你不能度量它,就无法改进它”。度量帮助我们更深刻认识研发效能,设定改进方向,并衡量改进效果,所以想要进行效能提升的前提是先能够识别交付过程中的质效瓶颈。

    因此,集团在基于部分BU的优秀实践下提出了2-1-1的愿景。

    • 1小时的发布前置时间是对于基础设施能力的要求,需要保证当达到交付标准后,通过交付流水线能够达到1小时内的打包、部署和验证的能力;

    • 1周的开发周期涉及产品需求拆分、研发QA协作能力、持续测试以及快速反馈能力方面提出了挑战;

    • 2周的需求交付周期是以前两项为基础,不仅是涉及到产研测三方,还包括其他协同部门的通力合作才能保证业务价值的快速交付。

    3. 持续交付在高德

    在基于集团愿景的指导下,反观现有高德服务端的交付流程,我们发现在整个流程中,存在很多效率上的竖井,这些效率问题汇总起来,便会成为整个交付流程上的效能瓶颈,进而影响业务价值的尽早交付。

    我们先从一个整体的Milestone来回顾一下整个持续交付所经过的一些重要时间节点:

    • 2018/08 构思与工程能力建设:项目启动阶段,工程效率团队与业务线明确了持续交付的目标,并启动了工程能力建设

    • 2018/12 初步落地与试点:项目试点阶段,完成了初步的持续交付流程搭建,并在一个项目中验证流程卡点以及质量标准的基础能力验证。最终建立了基础的质量标准以及降低流程中的耗时

    • 2019/04 推进接入与平台优化:项目推进阶段,持续交付项目质量项优化并在高德的服务端的6条业务线中进行推广,在9月份完成6条业务线以及11个应用的持续交付落地

    • 2019/09 复盘与展望:项目推进总结,对整个推进过程进行复盘与后续持续交付如何落地进行复盘与展望,整体产出业务推进中出现的问题以及改进方法

    • 未来:在交付流程上进行贴合业务线的微创新,并对效能瓶颈点进行纵深挖掘。结合各纵向平台进行纵深挖掘,例如:覆盖率与精准回归、云歌Case平台、代码扫描平台等

    通过milestone的展示,对于高德持续交付体系的演进有了大致的了解后,下面对于落地的过程以及改进的内容进行一下详细的梳理。

    3.1 接入持续交付前的交付流程

    首先先介绍一下在接入持续交付体系之前,高德的服务端是如何进行迭代的开发与上线的。

    与大部分互联网公司一样,我们将软件的交付拆分为多个周期,进行迭代式的交付,以便增量式的进行用户价值的交付。上图描述了一个正常迭代周期内的研发、测试以及发布的流程,我们可以拆分为以下几个方面:

    1. 迭代周期起始于代码库的变更

    2. 在功能开发完成后,研发通过CI系统进行冒烟测试验证,保证服务可以正常启动以及基础功能可用

    3. 在规定的提测时间前,研发将Feature分支通过CR和MR合并到迭代分支,部署到日常环境进行提测

    4. QA在收到提测邮件后,参与到日常环境的测试中

    5. 当日常环境测试完成后,QA会进行测试报告的产出,并确认日常环境测试通过,可以发布到预发环境

    6. 部署到预发环境后,会进行流量回放等测试,并最终通过线上的灰度验证,最终发布到正式环境

    通过上述的图片和描述,我们可以看到在看似完善的软件交付过程中,却仍然存在如下一些质量、效率问题:

    1. 需求堆积提测、发布:

    目前高德服务端大部分服务采用的是固定迭代周期进行需求发布,规划到迭代周期内的需求,无论需求大小,均需要等到迭代提测时间点进行提测,在迭代的发布窗口进行发布上线。在这种模式下,好的一点是有固定的版本节奏,整体迭代规划性比较强。但是由于提测、发布窗口固定,从而也带来了整体业务价值交付上的等待。因此,需要通过需求拆分来降低需求内部的耦合性,通过改变研发、QA的开发测试模式来降低需求提测中间的竖井等待,从而提升业务价值交付的效率。

         2. 质量标准不透明,无法及时反馈:

    从代码提交一直到最终产品发布,一般情况下,会经历日常、预发、灰度、正式发布几个阶段,每个阶段均有每个阶段需要重点解决的问题以及对质量上的要求也不尽然相同。目前结果的收集汇总和通知都是通过跟版人进行人工收集和统计,并邮件通知项目成员。这样所有的标准控制都是有每个版本的跟版人进行把控,存在信息不透明,反馈不及时的问题。通过质量项标准的建立,以及大盘结果透明和及时的通知,能够解决沟通层面的低效以及在传递过程中信息损耗,从而提升沟通效率,并且避免沟通中的误解。在解决了当前透明化和及时通知的问题后,我们需要进一步从以下两方面进行优化:

    • 将通知进行分类以及优先级处理,降低通知带来的负面影响

    • 通过信息内容优化,辅助业务进行问题的快速定位与排查

       3.部署与流程流转过程需要人工参与:

    对于持续发布流程来说,有人工参与的地方势必会影响到其中的效率。所以我们将部署和阶段流转拆分为两个方面看:

    • 阶段流转:结合上述的阶段标准,通过程序来计算是否能够满足当前的质量情况是否可以进行阶段的流转,从而排除人为因素以及在阶段流转中的耗时,做到准确

    • 部署:提取相应环境的配置信息,结合Docker化,将打包、部署、健康检查等一些列活动转换为机器的标准化执行,通过标准化来避免人为参与所造成的误差或部署失败的问题

         4.多机房正式发布验证人工监督:

    目前在应用的正式发布流程中,由于涉及的机房和机器数量较多,业务上会进行分批验证,每发布完成一批机器,研发会通知QA进行这批机器中部分机器的抽检(部分自动化测试),在这其中也存在着效率上的问题。所以如何节约每次上线过程中的人力损耗,也是在追求效能极致上需要解决的问题。

    上述的每个细节的问题,都在我们通往快速业务价值交付的道路上设置了障碍。因此,为了达成更早(快)的交付业务价值的目标下,我们必须要在交付效率、质量标准以及结果快速反馈这几方面的进行优化。

    3.2 持续交付在高德的落地

    基于上节拆分出来的4方面的问题,从工程角度来说,由于迭代的排期,需求的分解与拆分需要进行长期的实践与规划,并且依赖于产、研、测、项乃至于其他部门的支撑,是一个需要进行逐步探索和调整的过程。所以我们将着眼点放到后3方面的建设上,期望在短期内先建立起快速发布的能力,清除在交付过程中效率低下的点。

    那么在解决效率问题的建设上,借助于集团提供的发布流程以及较好的部署能力,我们将目前拆解为如下几个维度的抓手:

    1. 依托于集团的发布流程,在持续交付体系中建立与集团发布流程对应的标准化流程流转机制

    2. 建立服务端质量标准体系,拉通质量标准,去人工化

    3. 打通各环节的快速反馈机制,并对发布流程进行管控,让变更结果随时可见

    4. 降低发布过程中的人为参与,让整个发布流程做到全程无人值守

    通过下面持续交付流程图,我们通过接入后的流程图中看一下以上4个抓手是如何串联起整体高德持续交付流程,并且这几项是如何在高德服务端交付流程中进行落地的。

    • 建立标准化的流程流转机制

    FY19高德服务端发生的线上问题中,其中由于变更或发布引发的问题占比约12%。通过这组数据,我们期望能够通过建立一套完整的交付流转流程,实现对于变更的控制和管理,降低或避免此类问题的发生。

    基于以上立论,我们结合当前服务端交付特点,首先先确立以集团标准发布流程为试点,打通整体持续交付流程;其次,针对各应用中不同的需求,例如:需要性能环境、覆盖率环境等,结合流水线配置,将整个持续交付的流程流转进行优化;最终沉淀为各服务的标准化流程流转机制。通过这种先僵化,后优化,再固化的方式,最终在服务端落地了多套标准的交付流程,避免了在交付环节上的遗漏,以及不规范的操作。

    • 拉通并落地服务端质量体系标准

    在高德现有的交付流程中,整体的质量保障手段大部分是在日常阶段进行的,在迭代交付的过程中,各项质量保障手段执行了哪些,执行结果是什么,目前还是通过QA人员进行人工问题收集与汇总,并判定阶段结果的通过与否。在这种情况下,会出现由于跟版人交替导致的质量项遗漏,以及质量标准难以把控的情况。

    所以基于这几方面的问题,我们希望通过用机器把控替代原有的人工把控的方式,通过建立标准化的质量模板,来避免整体执行标准不透明,执行结果无沉淀的情况。并且,通过拉通标准,也进一步的规避掉了非重点服务质量检查点遗漏的情况。

    通过与业务团队的沟通,我们在第一阶段将现有服务端的质量保证手段进行拆分,提取了在不同阶段中相对重要的12项质量项,通过机器监督替代原有的人为统计的方式。具体覆盖了如下几个维度:

    • 代码维度

      • 静态扫描

      • 安全扫描

    • 测试维度

      • 冒烟结果

      • 新功能结果

      • 回归结果

      • Fuzz测试结果

      • 流量回放结果

      • 兼容性测试结果

      • 压测结果

    • 监控

      • 预发、线上监控

    • 需求/Bug管理平台关联

      • 当前版本需求进展

      • 当前版本Bug情况

    • 打通各环节的快速反馈机制,并对发布流程进行管控,让变更结果随时可见

    当建立起有效的质量体系后,在各阶段有了质量要求以及准入准出标准,解决了信息收集方面的问题,那么接下来我们要思考的就是如何将收集上来的各种信息,有效的反馈到项目中的各个干系人,以便进行后续的决策支撑,并且当未达到阶段准出标准时,有效的控制项目的阶段流转。

    我们将问题拆解为两方面看,一是有效反馈、决策支撑,二是流程流转的管控。

    从有效反馈、决策支撑方面看:

    • 在接入持续交付之前,各业务线的针对不同类型的自动化测试任务,大部分都有通过Jenkins或测试用例工程反馈结果的通知。但是此类反馈有一个致命的问题,就是通过单项反馈无法纵观全局,不足以支撑后续的决策。

    • 在接入持续交付后,除了原有业务上的反馈机制,平台提供能针对当期版本的整体状态全览,可以通过平台随时观测到当前版本是否达到可发布的状态或者仍然存在哪些不足。将两者结合起来后,针对项目执行人仍然可以通过原有反馈机制了解到单点的质量结果;对于跟版人、一线、二线管理者这类需要纵观全局的角色来说,通过质量大盘,可以有效且明确的知道当前版本与待发布状态的差距,并支撑后续决策以及调整关注的重点

    从流程管控方面看:

    • 在接入持续交付之前,可部署的产物无论是否经过阶段验证,都可人为的部署到任意环境下,虽然灵活性比较高,但是也存在一定的质量风险。

    • 在设计持续交付流程时,对于灵活性以及规范性的取舍方面,我们也与业务同学进行了讨论。从全局看,为了避免流程不规范引起漏测或其它线上事故,最终确定在初版时先保证流程流转的规范性,从而降低灵活部署上所带来质量上的风险。平台通过集团实验室插件与集团的部署发布系统打通,当阶段中存在质量项尚未达标的情况下,阻止发布流程进入到下一阶段(环节)。

    • 当基础的持续交付流程落地后,为了满足业务上对灵活性的要求,目前我们也在尝试通过自定义流水线来进行多环境的分发与部署,从而在保证主要阶段流转有管控的同时,增加部署的灵活性,以适应不同的业务形态。

    • 降低流程发布过程中的人为参与,让整个流程做到全程无人值守

    我们知道,线上环境部署的复杂程度要远高于在日常和预发环境的部署。由于部分业务线,线上的机器数量众多,且分布在不同机房,为了保证部署时的服务可用性,线上部署时会将上千台机器拆分为多批次进行部署。

    • 在接入持续交付前,为了保证部署后服务的可用性以及对质量上的高标准要求,在每批次部署完成后,QA都需要针对当前批次进行全批次验证或抽测验证,当验证通过后,再进行下一批次的发布以及后续验证。虽然验证本身是通过自动化脚本进行验证,但由于机器和批次比较多,整个发布和验证流程会持续数小时,存在较大的效率问题。

    • 在了解到业务上此效率瓶颈后,通过打通上下游系统,集团标准流程、集团发布系统以及原有业务的线上验证工程,针对不同业务的发布场景,进行发布验证策略的配置化。通过感知部署时的消息,获取当批次部署的机器列表,依据各业务的验证策略配置进行自动化的验证。并且结合线上阶段的报警监控,当某批次发布验证出现问题后,系统可以第一时间定位到具体是哪一批次中的哪台机器发布出现问题,帮助业务进行部署问题的快速定位。

    • 持续交付体系的业务架构

    4.  落地效果

    整个持续交付体系建设,目前在高德服务端落地已经有一段时间了,截止到目前为止:

    • 业务线覆盖:整个持续交付体系已经覆盖了高德服务端大部分重点业务

    • 各阶段质量项建设:12项

    • 正式发布阶提效:50%~90%

    在获得以上成果的同时,除了上述量化指标外,更有价值的是隐含在背后的研发、测试习惯上的变化。从研发、QA和项目主动发起的缩短项目周期,到QA对于质量项上提出更多的诉求等等,无一不感知到大家对于尽早且高质量的交付业务价值这件事情的重视。当然对于更早(快)的交付业务价值这个目标还有一定的差距,这个也是后续我们与业务线需要共同解决的问题。

    5. 持续交付的未来

    有人将持续交付形容为在价值交付上的高速公路,持续交付的落地,标志着价值交付到用户的快速路已经建立完成。但是最终是否能做到更早(快)的交付业务价值,还取决于在这条快速路上行驶的车辆。

    根据这个理论,我们除了要保证这条高速公路上不出现坑洼的同时,还要兼顾车辆本身的能力,以及车辆的性能。因此,在车辆出发前,我们更需要通过对车辆的车况进行检查,保证在高速路上行驶的车辆不会因为自身的原因提不起速度。

    5.1 车况检查

    目前,已有的持续集成系统,仅能够保证车辆在这条路上是能开起来的,车况的检查都是在上了高速后才开始的(大部分的质量保证手段是部署到日常环境后才开始)。所以基于上面描述的指导方针,我们需要尽早的做检查,并且需要做更全面的检查(质量保障手段左移)。

    基于这个目标以及结合集团内其他BU的优秀实践,后续我们希望能通过代码门禁的手段,尽早落地这类全面的检查。若要将代码门禁落地,无论是对于工程效率团队亦或是业务研发与QA团队,都有着不小的挑战,我们需要做到以下的转变:

    • QA

      • 质量保证的同期化能力建设

      • 质量保证的稳定性与耗时优化

    • RD

      • 研发提交代码流程的改变

      • 单元测试能力的建设

      • Code Review的常态化落地以及规范总结

    • 能力支撑

      • 代码覆盖率,业务场景覆盖率的支撑

      • 代码合并的门禁管控能力

      • 代码扫描结合CodeReview的总结的落地

    当逐步完成以上任务的落地后,能够消除批量交付业务价值交付中相互等待的时间,并且也能够保证车辆在持续交付这条高速路上行驶得更快更稳定。

    5.2 车辆性能提升

    前面车辆检查可以说是在车辆上路之前的检查与保障,将质量保证手段左移到研发阶段。相对的,我们希望通过车辆性能提升的方法,在车辆上路后,能够让车辆行驶提速更快,拉高速度的上限。

    • 纵向测试能力提升

      • 精准回归:通过感知代码的变化,推导出代码变动所影响的Case,让质量保障更为精准且耗时更少

      • 场景覆盖:结合线上流量回放,通过代码覆盖、场景覆盖进行查缺补漏,让质量保障更完整

      • 问题定位:结合失败用例,快速的进行问题定位与反馈

      • 同期化能力:结合云歌Case平台,通过接口定义进行测试代码与研发代码同期化编写能力的加强,以及降低Case编写和维护成本方面的探索

      • 降低数据干扰:基于高频、隔离和用完即抛的理论实践,降低日常环境的数据干扰,让质量保证更有效

    • 与线上数据挖掘结合

      • 大数据分析:

        • 利用线上日志分析,产出线上真实场景模型,降低压测平台语料准备耗时,场景筛选上做到精确、高效

      • 大数据运用:

        • 结合线上真实场景以及场景覆盖率,构造线下回归Case集,降低业务回归Case维护成本,提升Case有效率,并且能够快速定位问题

        • 利用场景回放,以及记录回放中间产物,解决在单测时场景构造问题

    随着持续交付快速通道的搭建完成,期望通过以持续交付体系为契机,在多个纵向维度进行深入挖掘,并完善整个持续交付体系,最终在更早(快)的交付业务价值的前提下,能够有更高的质量以及更低的人工成本,保证市场竞争的先机,让高德在激烈的竞争中优势更为明显。

    编辑:黎露(实习生)


    相关阅读

    高德全链路压测平台TestPG的架构与实践

    觉得好看,请点这里 ↓ ↓ ↓ 

    展开全文
  • 听说你还在满世界找认识QS-9000要求——质量体系要求——搬运、贮存、包装、防护和交付?在这里,管理资...该文档为认识QS-9000要求——质量体系要求——搬运、贮存、包装、防护和交付,是一份很不错的参考资料,...
  • 0.1、总则:采用质量管理体系是组织的一项战略决策,能够对组织的长远发展带来帮助;组织可以获得潜在巨大的好处(满足顾客,是顾客满意,应对风险机遇等);标准没有强制完全按照体系的要求执行,可以灵活变通,...

    前言:本标准是由ISO(国际标准化组织)制定的,ISO9001:2015是第五版标准。

    引言

    0.1、总则:采用质量管理体系是组织的一项战略决策,能够对组织的长远发展带来帮助;组织可以获得潜在巨大的好处(满足顾客,是顾客满意,应对风险与机遇等);标准没有强制完全按照体系的要求执行,可以灵活变通,但标准是最低要求,可以保证质量的下限;标准采用过程方法,以过程管理为核心,结合了PDCA循环(所有的过程都是一个环)与基于风险(预防控制)的思维。

    0.2、质量管理原则:一切以顾客为中心;领导者的重视;全体员工的参与;过程改进的方法;各方关系的管理;

    0.3、过程方法:单一过程的因素包括输入源(前一过程)、输入、活动(起点、终点)、输出、输出接收方(后续过程)、监视和测量过程的控制和检查点;PDCA循环包括策划、实施、检查、处置;基于风险的思维(质量管理非常重要的一部分);

    0.4、与其他质量体系标准的关系:ISO9000是质量管理体系的基础和术语,为正确理解和实施9001提供基础;ISO9004是质量管理方法的介绍,提供超出9001的质量管理要求。

    1、范围:证实具有提供满足顾客要求和法律法规要求的产品和服务的能力;应用质量管理体系,增强顾客满意;标准通用;

    2、规范性引用文件:ISO9000:2015 质量管理体系 基础和术语

    3、术语和定义:ISO9000:2015 界定的术语和定义适用于本文件

    4、组织环境

    4.1、理解组织及其环境:与目标和战略方向相关的内部因素和外部因素,包括正向和负向的,并不断监视和评审这些因素。

    4.2、理解相关方的需求和期望:有利益关系的人或组织是相关方,确定相关方并不断监视和评审。

    4.3、确定质量管理体系的范围:内外部因素、相关方要求、组织产品和服务的要求;

    4.4、质量管理体系及其过程:按照标准,建立、实施、保持和持续改进质量管理体系,包括所需的过程及其相互作用(输入、输出、顺序、准则和方法、资源、责任权限、风险与机遇、变更、改进等);形成文件(过程运行,符合策划);

    5、领导作用

    5.1、领导作用和承诺:最高管理者证实对管理体系的领导和承诺(体系有效性、质量方针和目标、质量体系与业务的融合、过程与风险思维、资源保障、有效沟通、确保预期结果、激发全员参与、推进改进、支持下属);以顾客为关注焦点(明确顾客要求和法律法规要求、风险和机遇、增强顾客满意);

    5.2、方针:质量方针的建立(适配组织和战略方向、质量框架、满足要求承诺、持续改进承诺);质量方针的沟通(成文、不断宣传);

    5.3、组织的岗位、职责和权限:质量管理体系符合要求、过程输出、绩效及改进、顾客为焦点、变更完整性;

    6、策划

    6.1、应对风险和机遇的措施:实现预期结果、增强有利影响、避免不利影响、不断改进;应对措施、整合实施、评价有效性;

    6.2、质量目标及其实现的策划:质量目标的建立,应与质量方针一致、可测、适用、相关性、监视、沟通、更新,并成文留存;策划时,确定措施、资源、责任人、时间点、审核评价;

    6.3、变更的策划:变更目的及后果、体系完整、资源可获、责权分配;

    7、支持

    7.1、资源:包括内部资源和外部资源,如人员、基础设施、过程运行环境(社会因素、心理因素、物理因素等环境)、监视和测量资源(监视和测量活动、测量溯源)、组织知识(内部来源、外部来源);

    7.2、能力:确定人员能力、提供机会、提升能力、成文信息;

    7.3、意识:质量方针、质量目标、质量贡献、质量后果;

    7.4、沟通:沟通什么、何时沟通、与谁沟通、如何沟通、由谁负责;

    7.5、形成文件的信息:包括标准要求和超出要求的文件;注意文件创建和更新(标识、说明、格式、评审及标准等);文件控制(路径、权限、保存、变更控制、检索等);

    8、运行

    8.1、运行策划和控制:确定要求、建立准则(过程、接收)、确定资源、过程控制、成文、变更、外包过程受控;

    8.2、产品和服务的要求:顾客沟通(提供信息、处理信息、获取反馈、处理财产、应急措施)、要求确定(法律法规、组织要求)、要求评审(顾客规定的、未明示但有必要的、组织规定的、法律法规要求、描述差异的要求,形成文件)、要求更改(更改后确保文件信息同步及相关人知晓);

    8.3、产品和服务的设计和开发:策划(活动性质-时间-难易度、过程、验证和确认、职责和权限、内外部资源、接口需求、过程需求、后续要求、控制水平、成文信息)、输入(功能性能要求、活动信息、法律法规、标准和规范、失效后果)、控制(获得结果、评审活动、验证活动、确认活动、必要措施、成文信息)、输出(满足输入要求、过程充分、监视测量要求、产品和服务特征)、更改(设计开发变更、评审结果、变更授权、采取措施);

    8.4、外部提供过程、产品和服务的控制:外部控制、控制类型和程度(体系控制内、输出结果控制、验证活动)、外部供方的信息(要求充分,包括过程-产品和服务、内容批准、能力、接口、控制和监视、验证确认活动);

    8.5、生产和服务提供:生产和服务提供的控制(成文信息、监视和测量资源、监视和测量活动、基础设施和环境、人员及资格、结果确认、防止错误、实施活动)、标识和可追溯性(识别输出、监视和测量输出、控制唯一标识)、顾客或外部供方的财产(妥善管理、识别-验证-保护-维护、不适用汇报)、防护(必要防护)、交付后活动(法律法规、不期望后果、产品和服务、顾客要求、顾客反馈)、更改控制(评审和控制、形成文件);

    8.6、产品和服务的放行:验证符合要求、未验证完成放行需批准、形成文件;

    8.7、不合格输出的控制:识别和控制(纠正、采取隔离-限制-退货/暂停、告知、让步授权)、形成文件(不合格描述、措施描述、让步描述、不合格标识);

    9、绩效评价

    9.1、监视、测量、分析和评价:评价绩效和有效性、形成文件、顾客满意(监视满足感受、信息获取-监视和评审)、分析与评价(产品服务符合性、顾客满意、体系绩效和有效性、策划实施、风险和机遇有效性、外供方绩效、体系改进);

    9.2、内部审核:内部审核(符合组织体系要求、符合本标准要求、有效实施和保持)、组织行为(审核方案、准则和范围、实施审核、结果报告、纠正和措施、形成文件);

    9.3、管理评审:实施评审、管理评审输入(以往评审、内外部因素、体系绩效及有效性、资源充分性、风险和机遇有效性、改进机会)、管理评审输出(改进机会、体系变更、资源需求);

    10、持续改进

    10.1、总则:改进需求和期望、纠正-预防-减少不利、改进体系绩效和有效性;

    10.2、不合格和纠正措施:不合格处理(应对措施、采取活动、实施措施、评审有效性、更新风险与机遇、变更体系)、形成文件(不合格性质及措施、纠正措施结果);

    10.3、持续改进:持续改进体系的适宜性、充分性和有效性。

    展开全文
  • 8000字干货:那些很厉害的人是怎么构建知识体系

    万次阅读 多人点赞 2019-09-29 11:18:27
    本文约8000字,正常阅读需要15~20分钟。...小张准备通过跑步锻炼身体,可因为之前听说过小腿变粗、膝盖受伤、猝死等等跑步有关的意外状况,有点担心自己会掉进各种坑里,就在微信上问朋友圈一直晒跑步...
  • RationalRATIONALRational交付平台:软件组织质量治理[1]软件测试本文描述了IBMRational软件交付平台的各种优异特性,帮助软件组织创建质量治理体系以适应如今来自技术进步所引起的组织转型需求……软件环境中的治理...
  • 本文来自于:零缺陷文化中心 零缺陷读后感:本文写的非常清晰到位,重点介绍了华为公司质量管理前后的发展历程,同时也给我们一些质量管理的思路和指引。希望感兴趣的同学能够领悟下质量管理的精髓。从2000年开始,...
  • ISO9001:2015标准用于证实组织具有提供满足顾客要求和适用法规要求的产品的能力,目的在于增进顾客满意度。随着商品经济的不断扩大和日益...作为顾客对供方质量体系审核的依据;企业有满足其订购产品技术要求的能力。
  • 如何做好质量体系建设,这是个比较大的话题,包含的范围很广,也没有固定的衡量标准。 打开一个互联网公司招聘网站,搜索「测试工程师」岗位时,你会发现几乎全部 JD 都包含一条要求「建设或者参与建设所负责业务的...
  • 更切实的说法应该是 —— 如何在有限投入(时间或人力资源约束)的情况下,在保证整个产品/平台质量达标的条件下,缩短每次需求从构思到现网的交付时间。 公司和大家是否能活的滋润,从某种程度上说是由交付效率 + ...
  • 质量属性、风险驱动的架构检查表有助于更高效、更一致地交付更高质量的产品。 虽然许多这种风格的清单,但大多数重叠并且不涉及现代(2010+)应用程序开发。 此清单旨在让您和您的团队专注于: 质量-高度关注和...
  • 服务器IP地址申请单 封面页 申请人姓名 张三 申请日期 联系电话 服务器型号 ...年 月 日 联想万全R520 主管领导 机房负责人 网络管理员 分配IP日期 签字 年 月 日 过程名称 服务交付过程-信息安全管理 文档名称 文件状
  • 软件质量管理体系-ISO 9000

    千次阅读 2009-09-10 23:07:20
    ISO标准软件企业的质量管理体系自从1987年公布ISO 9000族标准以来,ISO 9000族标准已经成为全球最有影响的质量管理和质量保证标准。ISO 9000族标准的制订和实施反映了市场经济条件下供需双方在进行交易活动中的...
  • 本文主要对于软件行业适用的几种质量管理体系进行简单介绍,进行基础了解 一、CMMI质量管理体系 过程管理 OPD:(Organizational Process Definition)组织级过程定义。建立和维护有用的组织过程资产。 OPF:...
  • 手机淘宝高质量持续交付探索之路

    千次阅读 2015-02-05 14:52:57
    手机淘宝高质量持续交付探索之路 作者 杨强 发布于 2015年2月2日 前言 随着移动互联网的迅速普及,手机淘宝业务在迅速的成长,目前已经发展成为拥有40多个bundle(业务模块)的超大APP产品,在这后面有着数百...
  • 我们一直都知道,高质量交付从来都不是一件轻松容易的事情,所以当每开启一个项目的时候,有三个问题要问自己:1、项目的验收标准是否确立并得到共识?不成熟的委托方会希望验收标准是模糊的,大致上会有两种原因,...
  • 课程交付:混合| 7周14节 课程学分:3学分| 37.5座位时间| 75小时总 学习成果 在课程结束时,学生将能够... 比较和对比软件体系结构选项和设计模式,以做出明智的选择。 生成精美的伪代码以快速描述如何解决问题。...
  • 摘要: IT 运维服务的质量问题越来越引起相关客户和服务提供商的重视,对 IT 运维服务外包项目进行监督管理是一种较新的探索。建立三权分立的运维服务组织管理框架、采用螺旋迭代式项目实施策略,对 IT 运维服务监督...
  • 构建高效的软件测试知识体系

    千次阅读 2018-08-09 06:22:49
    2018年6月8日,作为第一届TMMi中国峰会圆桌会议的嘉宾,我参与讨论了“如何建立适合测试组织的测试规范体系”这个测试主题,其中分享了我对该话题的一些想法和经验。现在通过文章的方式将当时讲解的内容进行了一些...
  • 软件环境中的治理 没有比交付... 一家软件依赖型公司要想成功,它必须拥有在运行时环境中持续良好运行的应用--这些应用必须是高质量的,并且需要在部署前经过彻底的测试。这需要软件交付具有敏捷的业务流程,用以适应
  • 即:如何基于云服务打造一条DevOps持续交付高速公路,打通从代码到服务的通道,让我们的交付过程快速顺畅,通过实现快速可靠的部署和发布,提升研发、运维各环节的效率和整体的交付效率和质量。希望能在这里和大家...
  • 导语 | 贝壳用户需求和用户量的不断增长,对系统的高可用性提出了更高的要求,服务端的质量保证工作该如何开展?本文是对贝壳找房-基础平台中心-质量平台赋能部总监——项旭老师在云+社区沙龙o...
  • 软件体系结构设计模式笔记

    千次阅读 2012-12-26 22:35:35
    软件体系结构设计模式笔记 第1章软件体系结构概述 ü SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计和交付的整个过程中的原则和指导方针。 ü Mary Shaw和David ...
  • 再谈软件研发管理体系建设

    千次阅读 热门讨论 2019-09-24 08:10:31
    在前面的文章中,我曾和大家分享了软件研发管理体系建设的一些见解,其中涉及对软件...今天要谈的这个话题主要包括以下几点: 1、研发体系框架 2、人员组织能力 3、项目管理能力 4、技术研发能力 5、持续交付能力 6...
  • 软件体系结构笔记

    千次阅读 2020-07-12 13:27:12
    软件体系结构笔记 软件开发流程 1.软件开发流程_简介 1.1从管理角度 即从业务和经济的角度来看,软件的生命周期包括四个主要阶段: ​ 起始阶段:有一个好的想法:具体构想产品的设想和它的业务案例,确定项目的范围 ...
  •  质量管理:执行组织确定质量政策、目标职责的各过程和活动,从而使项目满足其预定需求。  质量政策:由高级管理层颁布,确定组织质量工作方向。  项目质量管理产品质量管理的比较:    说明:  客户...
  • 计算机网络体系结构 当前计算机网络主要以分层结构来看待,从功能上进行描述 每一层依赖底层提供的服务完成一种特定的服务/功能 遵循一定的协议、通过层内动作完成本层的功能,并以此向上一层提供服务 即 计算机网络...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,702
精华内容 11,480
关键字:

交付体系与质量体系