精华内容
下载资源
问答
  • 交付确定结果
    2020-08-16 10:01:17

    可交付成果先后应该经过哪些人确认

    4.3指导与管理项目工作 (产出可交付成果)

    • 指导与管理项目工作包括执行计划的项目活动,以完成项目可交付成果并达成既定目标。
    • 本过程需要分配可用资源并管理其有效使用,也需要执行因分析工作绩效数据和信息而提出的项目计划变更
    • 指导与管理项目工作过程会受项目所在应用领域的直接影响,按项目管理计划中的规定,开展相关过程,完成项目工作,并产出可交付成果

    8.3 控制质量 (团队已经确认的可交付成果,可供客户验收)

    • 控制质量是为了评估绩效,确保项目输出完整、正确且满足客户期望,而监督和记录质量管理活动执行结果的过程。
      = 本过程的主要作用是,核实项目可交付成果和工作已经达到主要相关方的质量要求可供最终验收。控制质量过程确定项目输出是否达到预期目的,这些输出需要满足所有适用标准、要求、法规和规范。本过程需要在整个项目期间开展。

    5.5 确认范围(客户确认可交付成果)

    • 确认范围正式验收已完成的项目可交付成果的过程。
    • 本过程的主要作用是,使验收过程具有客观性;同时通过确认每个可交付成果,来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。

    4.7 结束项目或阶段( pmp第六版123页)

    • 达标要求
    • 合同
    • 经验教训
    • 移交
    • 建议
    • 满意度
    更多相关内容
  • 需求交付周期的分析

    2022-07-20 10:18:56
    需求交付周期的分析

          某公司需求交付的活动分为四个阶段:

          1、需求确认:当客户提出一个需求时,需要和客户沟通需求的真正含义,双方理解达成一致。

          2、等待开发:需求确认后,等待安排开发计划。

          3、需求研发:实现需求,并完成测试。

          4、需求验收:在客户接收完成的功能之前,对完成的功能进行上线前的测试,并确认上线准备妥当。

           需求交付周期为从客户提出需求到客户验收通过完成的功能为止,每个阶段都记录了其周期。公司的管理目标是快速交付需求,确保能够在50天交付需求。为了量化管理该目标,收集了316个需求的交付周期,以及4个阶段的处理时长(天),这些数据分属于两个产品线,如表1所示。应该如何分析这些数据呢?

    表1 需求交付周期数据

    需求编号

    产品线

    交付周期

    确认周期

    等待周期

    研发周期

    验收周期

    1

    CP

    30

    15

    2

    9

    4

    2

    CP

    30

    15

    2

    9

    4

    3

    CP

    30

    15

    2

    9

    4

    4

    CP

    30

    15

    2

    9

    4

    5

    PV

    41

    14

    1

    10

    16

    6

    PV

    28

    0

    2

    10

    16

    7

    PV

    28

    0

    2

    10

    16

    8

    PV

    28

    0

    2

    10

    16

    9

    PV

    28

    0

    2

    10

    16

    10

    PV

    28

    0

    2

    10

    16

    11

    PV

    28

    0

    2

    10

    16

    12

    CP

    49

    4

    5

    34

    6

    13

    CP

    49

    4

    5

    34

    6

    14

    PV

    暂未验收

    13

    2

    14

    暂未验收

    15

    PV

    43

    3

    8

    21

    11

    限于篇幅,中间数据略

    310

    PV

    37

    13

    4

    14

    6

    311

    PV

    37

    13

    4

    14

    6

    312

    CP

    42

    10

    6

    10

    16

    313

    CP

    42

    10

    6

    10

    16

    314

    CP

    42

    10

    6

    10

    16

    315

    PV

    17

    2

    7

    6

    2

    316

    CP

    24

    11

    5

    7

    1

            第一步:数据清洗。

          在这316个需求中,有的需求暂未验收,没有交付,可以把这些数据删除掉。有的需求某个阶段的处理时长为0,需要探明原因,然后确定是否删除这些数据。经过数据清洗,删除掉12行数据。

            第二步:方差分析。

          这些需求分属于两类产品,需求交付工期与产品线是否相关呢?可以先画箱线图进行观察,如图1所示。

    图 1 需求交付工期的分类箱线图

          由图1没有发现两类产品线有明显的差异。我们可以做单因子方差分析。

    表2单因子方差分析结果

          由于P值大于0.05,因此我们判断需求交付周期与产品线无关。

          第三步:分布分析。

          把每个需求每个阶段的周期除以总的需求交付周期,可以得到每个阶段的工期占比,这样就可以对每个阶段的工期占比建立性能基线了。在建立性能基线时,要删除掉异常点。

    图 2 各阶段工期占比的性能基线

           由图2所示的性能基线可知,研发阶段工期占比最大。

           那可不可以对每个阶段的工期直接建立性能基线呢?也可以尝试一下,但是有个前提,即不同需求的规模与复杂度应该相差不大,此时他们的工期才有可比性!

          第四步 敏感性分析

          研发阶段工期占比最大,并不代表最应该从研发阶段着手进行改进,而是应该进行敏感性分析,看看总工期对那个阶段最敏感。计算四个阶段与需求交付工期的秩相关性系数分别为:

    表3秩相关分析结果

          对秩相关系数求平方,并归一化后可以得到敏感度如图3所示:

     

    图3 需求交付周期的敏感度

          综述:

          1)需求交付周期与产品线类型无关;

          2)虽然需求等待阶段的工期在进行占比分析与敏感度分析时都是排名最靠后的,但是需求等待是非增值的活动,是最应该缩短的!

          3)除了需求等待以外,需求确认周期是最应该采取措施缩短的。可以继续对需求确认阶段的活动进行细分,也进行价值流的分析,识别在这个阶段的等待,量化这个阶段的各个活动的工期,进行敏感性分析;

          4)可以通过各阶段工期占比识别异常点,当某个需求的某个阶段的工期为异常点时,可以识别特殊原因。

    展开全文
  • 4 模型开发说明书 修订记录 日期 版本 修订描述 作者 目录 1 . 模型简述 2.... 3.... 4.... 5.... 5.2 模型结果 6. 模型评估 6.1 冠军者确定 6.2 验证集数据评估 6.3 验证器数据评估 7. 模型部署 8. 附件
  • 在Thoughtworks,我们通过对最佳实践(Sensible Default Practices)、能力和度量的持续治理和改进,在保障交付正确的客户价值和减少浪费的基础上,使交付质量更好,速度更快,反馈更及时,从而达到追求工程卓越和形成...

    在敏捷交付中,大家可能会遇到各种各样的问题,从而会影响最终的交付效果,甚至可能导致交付的失败。因此,如何在交付过程中进行有效的治理,提高交付效能,对于交付的最终效果会起到至关重要的作用。不可否认,交付效能和治理涵盖的范围很广,具体的实施还是需要根据实际情况进行细化,落地,跟踪, 反馈和改进。

    框架的引入

    在引入框架之前,很重要的一件事情是,让大家思考为什么要进行交付项目的工程效能的治理和改进。建议通过下面两个问题来作为和大家对话的开始:

    1. 在交付项目中,你区别于其他竞争对手的价值体现在什么地方?
    2. 你需要做什么来持续性地确保交付价值,甚至产生新的交付价值?

    上述两个问题每个人可能会有不同的答案,但是我们希望通过这种方式来让大家不断地思考,从而形成一定的共识。这种思考是持续性的,在不同的项目中,大家遇到的交付情况和挑战通常会有一定的区别,甚至较大的不同,但是无论项目如何变化,最终的目的是要成功地交付,因此持续性地思考,复盘,改进交付能力,从而提高交付竞争力,对于最终的交付结果以及后续产生的影响力会产生积极的作用。

    基于多年的在敏捷交付领域的探索和实践,我们逐步沉淀了一些方法,经验和教训,从而形成了本文中介绍的针对交付工程效能和治理的框架。

    框架

    概述

    在Thoughtworks,我们通过对最佳实践(Sensible Default Practices)、能力度量的持续治理和改进,来在保障交付正确的客户价值和减少浪费的基础上,使交付质量更好,速度更快,反馈更及时,从而达到追求工程卓越和形成发展工程师文化的目的,最终产生客户影响力。

    虽然这个框架主要针对的是Thoughtworks的场景,但是任何以目的和价值为导向的组织都可以从中受益, 而你需要考虑的是如何把该框架和你的组织的目的和价值对齐。尤其是针对分布式敏捷交付中,对齐目的和价值会对在不同地点工作的员工能够更有效地协作具有更积极的意义。

    终极目标

    我们的终极目的是通过交付来产生客户测的影响力,这个影响力可以通过两个渠道去产生:

    • 商业价值 - 通过产生客户价值来催生影响力,这个客户价值可以是客户的OKRs(Objectives and Key Results),也可以是客户侧的商业价值
    • 工程卓越和文化 - 通过不断追求工程卓越以及形成的工程文化来从侧面影响客户

    你可以根据组织的目的和愿景,来设定真正符合组织需要的终极目标,但是商业价值应该是在以价值驱动的敏捷交付中比较通用的目标。

    北极星目标*

    在产生客户价值的过程中,需要用以下北极星目标来作为指引方向:

    • 交付正确的价值
    • 减少浪费
    • 快速交付,快速得到反馈
    • 高质量

    *北极星目标通常指公司制定的发展目标,就是寓意要像北极星一样指引公司前进的方向。

    这些目标是交付的动力,因此在交付过程中,亟待解决的问题都需要最终向这些目标看齐。如果解决的问题和这些目标不一致,那就要思考为什么需要解决这个问题,这个问题是否是你目前的工作重点,它对交付能产生的影响到底是什么?

    下面这个最佳实践,度量指标和北极星目标之间的价值映射关系图,可以用来来判断是否在解决正确的问题,从而评估工程效能的治理方向是否正确。

    黄金三角

    基于上述的北极星目标的指引,如何更有效地进行交付并提高工程效能呢?这里需要从以下三方面考虑:

    • 最佳实践 (Sensible Default Practices) - 这是我们在交付过程中的默认的最佳实践。这里的实践不仅仅是针对开发的,还包括针对BA, QA, UX, PM以及其他角色的最佳实践。这些实践是通过20多年的实际经验和教训积累出来的,因此这也是我们称之为default的原因。基于组织的不同情况,可能会有不同的最佳实践,更重要的是了解,应用并且不断改进这些最佳实践
    • 度量 - 你需要运用不同的度量手段来评估交付工程效能,以发现其中存在的问题以及需要改进的地方。这个度量需要从量化和非量化的手段综合考虑,并且需要从交付效果,工程实践,能力,安全,团队士气等多方面进行考量
    • 能力 - 这里的能力包括在交付过程中需要的多方面的能力,包括技术和非技术能力,例如TDD,结对编程, 任务分解, 安全建模, 估算及交流等


    上述三要素是相互联系,而非孤立存在的。最佳实践的实践程度以及能力的不断培养可以让度量更加成熟,反之度量的结果可以帮助识别在实践方面的问题以及能力上的欠缺。最佳实践需要相应的能力作为支撑,而能力的提高也会帮助去更好地执行最佳实践。但是真正能够达到优秀甚至卓越的程度并不是一蹴而就的事情,这需要团队去持续地复盘,改进,提高, 而组织的改进则要始终以北极星目标作为指引。

    框架落地

    理论要和实际相结合,那么如何让这个框架落地呢?下面的这个价值图的方式可以让团队理解真正“优秀“的工程效能是什么样子的,并且通过这个工具来帮助团队了解理想与现实的差距,然后通过Ray Dalio在“原则”一书中提到的解决问题的五个原则来持续地改进,提高交付工程效能。


    每个交付的项目会有不同的流程,上述价值图只是作为一个示例来帮助大家理解在交付的各个环节(图中绿色方框)中,从开发的角度,需要什么样的最佳实践(图中粉色方框),与之匹配的能力(图中紫色方框),相应的度量指标(图中深蓝色方框)。虽然这个价值图示例是从开发角度设计的,但是你也可以基于此模版设计针对不同角色的价值图。对于同一角色,不同团队的价值图内容可能有所不同,但是在基本内容方面需要具有一致性,尤其是一些默认的或者标准的实践,能力和指标等,以保证组织特有的价值能够具有传承性。

    按照Ray Dalio的5原则方法,在确定好目标后,接下来就需要对团队的现状进行评估,识别现实与目标的差距,然后制定相应的计划进行改进。有的团队可能起点较低,有的团队可能已经做的很好了,但是这并不代表差的团队就掉队了,好的团队就可以停滞不前,**我们希望看到的是每个团队不断改进的过程和结果 **(下图中的示例就是我们希望看到的改变)。差的团队可以根据优先级以及自己的节奏一步一步的走,即使走得慢也没关系,关键是要走的直,走的稳,并且在不断前行。好的团队可能离目标很近,但是不代表已经达到真正优秀的水平,即使达到了,也可以去思考下一个目标是什么,是否可以有所创新来创造新的价值,因为在追求卓越这条道路上是永无止境的,而且技术的不断革新和发展以及对未来的不可预测性也会促使我们需要不断地思考,改进和创新。
    5.png

    成功的衡量标准

    在交付过程中,你如何确保当前的交付是按照即定的目标执行的,并且确保做的事情是正确的?尽管交付价值可能是你的最终目标,而衡量交付的客户价值可以帮助了解目标是否实现,但也应该考虑其他衡量标准来评估工程效能的提高,包括但不限于:

    • 北极星目标 - 需要找到相关度量指标来衡量质量,交付和反馈速度,成本、资源和流程上的浪费,以确保走在正确的道路上;
    • 能力提升 - 雷达图可以用来展示需要的能力以及现有的能力,这样可以很容易地告诉你哪些能力可以满足现有的交付需求,哪些能力则需要改进;
    • 团队士气 - 可以结合使用量化和非量化指标来评估团队的士气,这是工程效能的重要组成部分;
    • 最佳实践的成熟度 - 需要了解团队对最佳实践的认知、执行的程度,是否能够长期地应用这些最佳实践,并且能够持续地改进;
    • 度量指标 - 监控和分析过程和结果指标不仅可以了解工程效能和交付效率,而且也可以为后续进一步的改进提供相关指导信息;
    • 创新理念 - 在遵循标准或最佳实践的同时,应鼓励每个团队思考他们还可以做些什么来不断地改进,例如是否有任何新的模式、能力或指标可以用来评估、试验并且采用。

    总结

    我们希望通过这个框架和工具能够帮助团队在交付工程效能的提高和治理方面达成一定的目标共识,同时能够以此为基础进行落地,催生相应的能够实施的针对最佳实践、度量、能力培养、价值交付、技术等方面的工程治理流程。虽然每个治理流程侧重点不同,但是都具有一致的目标和治理原则,以此帮助大家在交付效能治理的道路上,走出一条符合组织自身特色的并具有实践性的路线出来。


    文/Thoughtworks Wilson Gao
    原文链接:敏捷交付的工程效能治理-Thoughtworks洞见

    展开全文
  • 本文旨在了解客户对孟加拉国不同商业进度银行的替代交付渠道的认知水平。 考虑到技术和可持续性的重大发展,孟加拉国的银行业通过... 因此,管理层的注意力可能会有效地集中在本研究中已正确确定的此类部门的发展上。
  • 项目交付体系

    千次阅读 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.厚积薄发

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

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

    展开全文
  • 如何提高项目交付效率

    千次阅读 2020-03-18 11:06:06
    道法术出自老子《道德经》,道,是规则、自然法则,上乘。...日常工作中新知识学习、新技能扩充、未知问题解决、项目实施交付,都可以从道、法、术、器这几个层面入手,找对解决方案,选对解决措施,将问题逐一击破...
  • 本次我们总结下项目的执行的核心:可交付成果(Deliverable)。 1 定义 项目章程是一个项目启动的依据,描述了高层级的目的、目标、预期成果/验收标准、及钱/人等约束条件,其中可交付成果是一个关键内容。 可...
  • 持续交付2.0(一至三章)

    千次阅读 2021-08-09 02:03:35
    传统的瀑布软件开发模型每个阶段都花费属于的实际那,需要花费大量的经历确定需求的范围,审核繁杂的需求规格说明书,确定需求范围复杂。 2、敏捷软件开发 提倡面对面沟通,拥抱变化,提倡通过迭代和增量开发今早...
  • 项目管理过程仅仅围绕产出的交付物(交付价值)服务,项目交付聚焦干满足需求、范围和质量期望,产生预期的可交付物,以推动想要的项目成果,如何在多重约束条件下管理好交付是项目管理的重中之重。
  • 软件交付的演进历程

    千次阅读 2019-08-29 14:58:17
    相应的,这也允许我们确认每次小的迭代的效果是否能达到用户的需求和我们的业务底线。 业务流程被相互协调的团队所代替,这些团队必须交付业务所需的产品。该团队实验并迭代需要开发的产品理念,从而确保可以达成...
  • 目的是确定设施交付强度对AMTSL的正确做法以及提供其他人工和交付干预措施的影响。 方法:2016年,在达累斯萨拉姆的四个公共卫生机构进行了横截面分析研究。 高交付强度设施(HDIF)与低交付强度设施(LDIF)相比,...
  • 企业在做敏捷转型中,需求无法按时交付的困扰你是否也遇到过呢?
  • 因此,在线食品交付服务提供商有必要确定消费者的喜好和看法,以使他们能够满足他们的期望。 通过这项研究,分析了历史背景,当前情况和可能的未来发展,以帮助在线食品配送服务制定更好的策略来提高销售额和增加...
  • 项目交付评审

    2019-10-05 09:42:25
    1、首先明确交付物: ...2、交付物在何时确定: 项目伊始,即项目启动阶段。首要任务就是要明确范围、交付物、里程碑等。 3、项目交付前评审的意义: 完成了交付物,就意味着覆盖了项目范围。 ...
  • 产品交付周期计算公式Delivery health is a key element of a healthy engineering team. At SafetyCulture we are not simply looking for delivery health. We aspire for world-class level excellence in how we...
  • 软件工程与计算II-20-软件交付

    千次阅读 2022-03-10 09:10:05
    软件工程与计算II-20-软件交付
  • jenkins持续集成与持续交付

    千次阅读 2022-03-20 14:30:41
    二、jenkins的部署1、环境准备2、安装jenkins3、更新插件源三、jenkins项目管理配置1、项目创建2、配置周期性检查gitlab变更3、配置实时监控gitlab变更4、自动构建docker镜像并上传到本地仓库5、添加docker交付任务 ...
  • 下图是持续交付的一个核心流程图,代码提交触发构建和单元测试,完成后触发自动化测试,根据自动化测试的结果进行审批是否进行用户验收测试,用户验收测试通过后进行发布上线。中间每一个环节都会产生反馈,一旦失败...
  • 否则,主机将数据报发送到一台路由器(称为默认路由器),由该路由器将数据报交付到目的地 主机与路由器处理IP数据报的区别:首先,我们注意到当前的大多数主机既可配置为路由器,也可配置为主机,很多家庭网络...
  • 交付团队管理 开始于:为什么需要构建软件? (Begin With: Why Do You Need To Build Software?) There are a many reasons why an organization needs to build and deliver software. Some examples might be: ...
  • 假如把开发工作流程分为以下几...选择持续集成系统是持续集成的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等,做好持续集成,可为持续交付与持续部署打好坚实基础。 2、持续交付 持续交..
  • 持续集成、持续交付、持续部署

    万次阅读 多人点赞 2018-11-27 12:56:23
    持续集成、持续交付、持续部署持续集成持续集成的优势持续交付持续部署DevOps总结参考资料 又到了例行的技术报告环节。想着在实验室里头絮絮叨叨的讲一些前端开发相关的内容,师兄师姐们不爱听,老大也会摆出经典的...
  • ADC—应用交付-AX系列

    千次阅读 2019-10-23 14:54:13
    一、ADC—应用交付 1.1 作用 负载均衡:服务器负载、链路负载、全局负载; 业务改造:网站IPv6改造、网站HTTPS改造; 网站加速:协议加速、内容加速。 1.1.1 详细划分 服务器负载: --基于域名的七层负载均衡...
  • 推动实现“电子访问”(即患者与医生之间的远程... 我们还描述了至少在其中一个维度上进行电子访问可能导致较差结果的环境。 我们的建模方法强调了考虑患者和医师对基层医疗干预措施的React以了解其全部影响的重要性。
  • 如何做到项目准时交付之需求管理

    千次阅读 2018-12-02 12:10:16
    根据需求沟通和需求分析的结果,进一步定义准确无误的项目需求。需求定义的过程更多的是对需求进行准确的描述,从需求方的角度、功能操作流程的角度等方面,对分析出来的真实需求做出完整、无二义性的定义,准确理解...
  • 在做项目产品的时候,发现有的功能交付了客户很久,但客户一直没有...才能做到以终为始,根据目标和结果导向,满足客户的需求。 3、可以更好的提高自己的产品力和服务能力。 (二)什么是交付意识? 站在用户的角度出
  • 处理器核设计之交付

    2022-08-19 18:50:04
    在流水线的执行阶段,理论上已经可以将分支预测指令的结果解析完成,因此有的微架构将交付功能在执行阶段完成。 在写回阶段进行交付。由于有的指令需要多个周期才能写回结果,并可能产生错误异常,因此有的微架构将...
  • 项目交付二三事

    2020-06-22 20:45:07
    项目具有独特性、临时性、不确定性特征,所以要准时精准的完成项目交付,本身就是一个识别项目项目相关方,管理项目风险的过程,准备工作做好,才能知道交付给谁,何时交付交付资产。 背景 随着信息技术的普及,...
  • 第1章 持续交付2.0

    2019-03-25 11:27:18
    持续交付2.0“8”字环周期 4个核心原则:坚持少做、持续分解问题、坚持快速反馈、持续改进并衡量 第一个环:探索环 目标:识别和定义业务问题,并制定出最小可行解决方案,进入第二个环 步骤:提问(定义问题)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 70,649
精华内容 28,259
热门标签
关键字:

交付确定结果