📘

数字化环境下项目管理的变革与关注点

回贴
0
279
2024-03-11 09:29:04
路婕
  • 访问次数 801
  • 注册日期 2021-12-14
  • 最后登录 2024-07-23
  • 我的积分 2295
楼主

中国正处于从制造大国向创新型国家转变和数字化转型升级的关键期,党的二十大报告强调“ 加快实施创新驱动发展战略,加快实现高水平科技自立自强”的新发展理念。新产品研发是科技创新的重要方面,新产品开发项目管理对于提升企业的研发能力、自主创新能力,推动企业的高质量发展具有重大意义。


在过去十年,各类产品、服务和解决方案中采用的软件呈指数增长,数字化技术和数字化产品的大量出现,特别是大数据、人工智能、基于云的能力和新的商业模式驱动了新工作方式的发展创新,软件能够促使这种增长继续变化。


因此,软件开发项目管理备受关注, 与传统的工程建设项目和大型装备研发项目不同,软件开发项目呈现需求不确定性、易变性等特点,为适应这些特点,软件开发项目的组织模式也发生了转型,新的项目工作和团队结构不断产生,从而需要对项目的开发方式和产品交付的节奏进行调整。


未来,随着各行各业数字化转型的进一步提速,产品、服务与软件更加融合,基于“ 产品—服务—软件”的系统促进了数字化项目管理的价值创造。因此,以软件开发项目为代表的新型项目管理方式,将对传统项目管理模式产生重要的影响,并由此带来了项目管理的新理念、新方法、新思路。本文对软件开发项目管理的特点和主要关注点做了分析,包括软件开发项目的产品生命周期与项目管理的关系、开发方法与生命周期、价值交付与战略拆解等。


产品生命周期及需求管理

01 软件开发中项目管理与产品生命周期管理间的关系

项目管理与产品管理之间的关系密不可分。在软件开发过程中,项目组合、项目集、项目与产品管理的相互关联性正逐渐加强。通过了解产品管理的生命周期,能够使项目开发团队更关注价值交付和收益。


新产品开发的目的是设计、提供满足用户需求的产品,并通过产品的使用/ 运营实现用户的价值。对于软件产品来说,在产品引入阶段,通过初始创建的项目或项目集,为客户提供满足基本需求的产品;在产品的成长期,需要通过启动新的项目集或项目,对产品添加新的功能、特性或新的内容,以便为客户和组织创造新的价值;在产品的成熟期,仍然需要通过启动新的项目集或项目,对产品的功能进行修订,以延长产品的生命周期;在产品的衰退期,可能需要通过开展新的项目,使产品退出市场。新产品开发的过程,实际上是一个投资的过程,因此,在整个产品生命周期,组织需要建立项目组合治理的机制,对各阶段的项目和项目集进行整合管理,以更好地管理收益并为组织创造价值。


在软件产品生命周期中,需要通过大量的项目和项目集为产品添加新的功能,以满足不断变化的用户需求,因此,软件开发项目的需求管理显得格外重要。


02 软件开发项目的需求管理

软件开发项目涉及一系列阶段和活动,包括组织的战略拆解、商业论证、业务需求的提出、业务/ 商业需求文档(Business Requirement Document,BRD)的编写与评审、产品需求文档(Product Requirement Document,PRD)的编写与评审、概念设计、研发测试排期、详细设计与开发、测试、上线等关键活动。


启动开发项目是一个投资的过程,组织通过新项目来实现其战略目标。因此,项目首先来自组织的战略拆解和商业论证,在此过程中,需要综合考虑用户、市场、竞品和组织自身的能力等各方面因素提出业务需求,该阶段的控制门是预研立项评审。立项评审通过后, 需要编写BRD 文档、PRD 文档,在此基础上, 开展概念设计和排期,该阶段的控制门是研发立项评审。


对于软件开发项目来说,业务/ 商业需求文档(BRD)和产品需求文档(PRD )是需求分析阶段的两个重要文档,项目团队常常要花费大量的时间进行沟通、协调。BRD 是基于商业目标或价值所描述的产品需求文档,主要内容包括市场分析、销售策略、盈利预测等,主要阐述:要实现什么样的用户需求,即产品应该是“ 什么”(What)。BRD 评审由业务侧主导。


产品需求文档(PRD)是将BRD 从技术的角度用更加专业的语言进行描述,主要内容包含系统产品方案( 系统逻辑、系统改动点、系统依赖、依赖影响等)、系统需求列表、子功能、产品用户、接口需求等,主要阐述从技术上如何实现业务/ 商业需求,即“ 如何实现” (How)。PRD 评审由技术侧主导,评审人有业务产品、研发和测试人员、架构师等。


完整、准确、全面地识别商业/ 业务需求, 并将其转化为技术上可行的产品需求,是软件开发项目管理的关键。由于软件产品的需求具有较大的不确定性和易变性,因此,选择与需求和交付物相适应的开发方法对项目的交付效果有重要影响。


开发方法与生命周期

软件开发项目的开发方法与生命周期的阶段划分密切相关,应选择与项目交付成果的交付节奏相适应的开发方法。典型的开发方法模型包括:瀑布模型、迭代式模型、增量模型、螺旋模型和原型法等。当用户需求比较确定时, 通常采用瀑布型的开发方法。


开发方法与生命周期绩效域涉及与项目的开发方法、节奏和生命周期阶段相关的活动和功能。项目可交付物的类型对选择何种开发方法有重要的影响。可交付物的类型和开发方法会影响项目交付的次数和节奏,可交付物的开发方法和所期望的交付节奏决定了项目生命周期及其阶段。在考虑交付节奏和开发方法时, 开发方法和生命周期绩效域与交付绩效域紧密相关,交付节奏是确保项目价值交付与组织收益的重要因素。


从传统的预测型方法到敏捷环境下的适应型方法,迭代性和增量性逐渐增加,介于中间状态的是混合型方法。对于软件产品来说,通常采用适应型开发方法;对于传统的硬件为主的产品来说,通常采用预测型开发方法。实际上,即使是传统的硬件产品,也都包含各种数字化的功能和软件,如目前的汽车包含各种智能功能、现代的建筑也包含各种智能家居的功能。因此,绝大多数的产品,都适合采用混合型的开发方法,即一部分的功能组件采用预测型的开发方法,另一部分的功能组件采用适应型的开发方法。


预测型方法(即瀑布型)适用于在项目开始时就可以定义、收集和分析项目和产品需求的项目。当涉及重大投资、对交付物有严格质量要求的项目可以采用预测型方法(如建筑工程项目、卫星研制项目等),这种情况下,在项目生命周期的早期阶段便已经基本明确相对稳定的范围、进度、成本、资源。


适应型方法( 迭代型、增量型)适用于需求面临高度的不确定性和易变性,并且可能在整个项目期间发生变化的情况。适应型方法在项目开始时确立了明确的愿景,初步需求会根据用户反馈、环境或意外事件不断完善、更新或替换。


敏捷软件开发(Agile Software Development) 是一组强调在不确定和混乱的情况下适应软件需求快速变化的、基于迭代式开发的软件开发方法和实践,敏捷方法是一种主流软件开发方法。敏捷方法可以被视为具有适应性,某些敏捷方法需要持续一至两周的迭代,在每次迭代(冲刺)结束时,客户会对具有功能性的可交付物进行审查。


价值交付与战略拆解

01 关注价值交付

与传统的工程项目不同,软件开发项目的交付物主要是程序代码,相对抽象而非具象。因此,传统项目管理关注交付物的管理,而在软件开发项目中,更关注交付物所产生的价值,即价值交付(如是否通过软件开发项目实现了某一用户需求)。这种观念的变化,对于传统的项目来说,同样具有重要的意义,即项目的最终成果是否为相关方(尤其是顾客)交付了价值。


价值交付是项目成功的最终衡量标准和驱动因素。项目是组织计划实现的一个或多个商业价值的载体,项目成功的标志是在一定的约束条件下实现预期的价值。价值具有一定的主观性,同一个项目对于不同的人和组织具有不同的价值。由于项目包括不同的相关方,因此, 必须考虑为每个相关方群体产生的不同价值, 并将这些价值与整体价值进行平衡,同时优先考虑客户价值。对于组织来说,价值包含短期财务收益、长期收益及非财务要素。


价值聚焦于可交付物的成果。所以,项目团队应将原来的重点关注可交付物转到关注预期的成果。聚焦于成果,可使项目团队通过评估进展对项目进行适应性调整,从而使期望的价值最大化,而不是简单地创建、交付特定的可交付物。虽然可交付物可能会支持预期的项目成果,但它可能无法完全实现项目的价值。


例如,客户可能需要特定的解决方案的某一产品(如我国为某发展中国家建设高铁项目),仅仅产品交付物本身(即高铁)并不能实现该项目的预期价值,若增加一项新的活动,如提供使用、维护该高铁设施的培训,就可以更好地实现用户价值。因此,项目团队应关注是否为相关方(尤其是用户)交付了价值和预期成果,而非仅仅是交付物本身。


当项目是某一项目集的组成部分时,需要在项目集层级对价值交付做出完整、全面的评估,且应考虑项目输出的全部背景和整个生命周期。


02 战略拆解与效能提升

大型工程研发项目通常有较长的生命周期(如航空航天项目通常长达十余年),且一个组织中,通常正在研发项目的数量有限。而软件开发项目的周期通常比较短(通常数周或数月),且在一个组织中(尤其是互联网企业),常常有大量的软件开发项目在同时进行,因此,如何判断这些项目是否与组织的战略一致,如何将组织的战略拆解为一个个具体的项目,显得尤为重要。


某知名互联网企业的组织战略拆解基本过程,如图1 所示。通过建立“ 端到端”管理实现项目价值交付。“ 端到端”是指从需求提出(组织战略的拆解或业务需求的提出)到满足业务需求的整个过程。在这个金字塔型战略拆解体系中,金字塔的顶端采用战略屋的方法, 将组织的经营目标拆解为若干的项目组合(称为“ 必赢之战”);进一步,为了实现各个“ 必赢之战”,将其按照年(季)度拆解为一组项目和项目集,同时,项目是为了满足用户/ 业务需求,将“ 需求挂项目”;然后,为这些项目和项目集分配产研资源进行交付;最后,需要将项目分解为一个个任务,同时,做好资源分配和成本管控工作。上述过程实现了战略从部门到团队(项目)及个人的拆解和落实。

图1 战略拆解金字塔(图片来自网络,侵删)

端到端的项目管理可以使业务战略规划与协同形成合力;集中力量动态调度聚焦产研资源,提升项目交付质量和价值;交付更多项目与需求,加快业务发展。


由于一个组织常常同时开展大量的软件开发项目,因此,从组织的角度来说,更加关注组织/ 团队的研发效能(Effectiveness),而非单个项目的绩效( Performance)。尽管学者们对效能的定义不尽相同,但效能通常指效率和能力,即高效率、高质量地持续交付有效业务价值的能力。应建立端到端的效能度量体系, 从而实现数据驱动提升效率的目标,达到用有限的资源“ 用正确的方式做更多正确的事”的目的。
研发效能的度量可划分为产能、资源、价值和质量四个维度,如图2 所示。
图2 效能度量体系(图片来自网络,侵删)

由图2 可以看出,研发效能度量的第一个维度是产能维度。产能维度反映了产研团队的交付能力和对业务的响应速度,即用有限的资源做更多的事情,度量指标包括产研交付周期、研发交付周期、需求吞吐量、需求规模、产研团队流效率等。


第二个维度是资源维度。资源维度主要关注产研资源投入的方向,可以为资源聚焦及优化提供数据支持,度量指标包括资源投入分布(集团及部门)、战略资源投入占比、产研配比、研测配比等。


第三个维度是价值维度。价值维度主要关注用有限的资源做更有价值的事情,度量指标包括战略与项目闭环度、战略达成度、项目收益达成率等。


第四个维度是质量维度。质量维度主要关注团队的过程质量和对质量问题的处理效率,体现了高质量交付业务需求的能力,度量指标包括线上缺陷密度、故障恢复时间、缺陷关闭率、严重缺陷占比、缺陷平均关闭时长等。


在效能度量的基础上,可以进一步开展效能提升,即全局和局部的改进方案或举措。应采用数字化平台工具,以实现效能提升过程的线上化、标准化、度量化、数据化。基于数据度量和分析可以为组织提供高效的决策信息。


结语

当前,在大数据、云计算、5G 和人工智能等数字化技术驱动下,新产品开发的环境发生了显著的变化,开发项目的流程和组织变革蕴藏着巨大的机遇与挑战,以软件开发为代表的数字化产品呈现爆发式增长。相应的,传统的项目管理也面临数字化环境下的挑战。


在以软件开发为代表的项目管理中,项目开发团队应更关注于价值交付,而非交付物本身,同时,聚焦于成果也可使项目团队通过评估进展,对项目进行适应性调整达成目标愿景。


在数字化环境下,软件开发项目具有需求不确定性、易变性的特点,采用适应型的开发方法有助于根据用户的反馈和变化的环境,不断调整、完善项目交付成果。软件开发项目更加关注通过组织的战略拆解,使得项目与组织的战略保持一致。同时,在软件开发项目中,也更加关注提升组织的效能,而不仅仅是提升单个项目的绩效。


[本文是国家自然科学基金(71929101,72271022和71872011)项目成果之一。]
杨青,北京科技大学教授,博士生导师,研究方向为项目管理、数字化驱动的项目管理、依赖结构矩阵。
庞佳怡,北京科技大学硕士研究生,研究方向为项目管理。
宋丽萍,京东零售项目总监,京东零售项目通道会长。

内容来源 | 《项目管理评论》2023年第1期

原文链接 | https://mp.weixin.qq.com/s/qlzifQFPCQzvu83gOEAwfA


返回顶部
魏中显
高级客户经理
18561939726
1746749398
统一服务热线 4006-8899-23
我要提问提问有任何问题,您都可以在这里提问。 问题反馈反馈点击这里,让我们聆听您的建议与反馈。