软件开发中的项目管理是谁、为什么和如何

您正在冒险进入软件开发领域。 你有一个面向未来的想法、详细的要求、足够的技术专长和一个熟练的团队。 你只是缺少一个专业的项目经理。 鉴于上述情况，您完成该项目的几率是多少？

可悲的事实是成功的机会并不高。 各种研究表明，软件开发失败的主要原因大多与项目管理不善有关。

管理软件开发项目中导致失败的常见错误是项目目标的变化、沟通不充分、变更管理不善、成本估算不准确、风险不明等。

因此，为确保您的项目不会失控，您必须将健康的项目管理放在首位。 下面，我们分享我们在企业软件解决方案开发方面的专业知识，回答有关管理软件开发项目的尖锐问题。

项目管理对于软件开发项目的成功有多重要？

简而言之，非常。

软件开发项目通常非常复杂。 一个项目要被认为是成功的，它必须满足要求并保证高执行质量，同时按时并在预算内完成。 这就是项目经理的职责。

因此，雇用专门的人才来管理软件开发项目的好处包括：

• 降低风险
• 项目经理负责有效的风险管理。 在项目的一开始，他们就规划、记录和优先考虑潜在风险，并设计风险应对策略。

应对风险的四种常见方法包括：

• 避免：消除或放弃威胁
• 减轻：降低威胁的可能性或影响
• 转移：将威胁分配或转移给第三方
• 接受：承认威胁并选择不解决、转移或减轻它。

为了制定适当的风险应对策略，项目经理可能会与团队进行头脑风暴会议、诉诸故事板或采访来自各个运营部门的个人。 有了手头的风险管理策略，项目团队就更容易预见风险并及时预防。

• 更好地控制项目成本
• 成本超支在管理软件开发项目中很常见。 由于它们不仅会影响利润，还会阻碍项目的执行能力，因此经验丰富的 PM 会提出最佳的成本管理方法。
• 他们在整个项目生命周期中估算、预算和控制成本，旨在将支出保持在批准的范围内。 健康的成本管理还有助于为利益相关者设定期望、控制范围蔓延、提高项目投资回报率并监控长期成本趋势。
• 资源的最佳利用
• 软件开发中的健康项目管理有助于确保跨人员、他们的技能、时间、工具、设备和服务的所有项目资源得到协调和有效利用。
• 在项目的发现阶段，PM 估计、分配和计划所需的资源，并根据优先级分配它们。 在开发过程中，PM 跟踪资源利用率并消除可能阻碍项目完成的任何瓶颈。
• 更好地控制项目范围
• 管理软件开发项目的一个常见问题是，最好避免范围蔓延。 不受控制的变更会影响项目进度、预算、成本和资源分配，还会影响里程碑的交付。
• 在软件开发中进行项目管理时，PM 会设置变更请求程序，并确保每个新需求都遵循该程序。 目的是避免不受控制的范围蔓延，并确保项目按时交付并在预算范围内。 一旦新活动获得批准并添加到范围中，项目时间表和预算基准就会相应更新。

什么是软件开发中的项目管理？

软件开发中的项目管理是在可用资源和约束条件下规划、调度和跟踪项目活动的艺术。

如上所述，软件开发项目非常复杂，包括多个阶段。 项目经理计划并监督这些阶段的项目执行。

根据项目管理协会的说法，从 PM 的角度来看，软件开发生命周期中有五个关键阶段。

• 项目构想

项目构想阶段的主要目标是确定核心项目目标、定义业务需求和起草工作说明书。 后者首先应包括对未来解决方案的要求和项目交付时间表。 项目构想通常需要所有项目利益相关者之间的密切合作，由业务分析师和项目经理带头。

• 项目计划

项目规划阶段是项目经理和项目团队的合作努力。 项目团队设计解决方案的技术架构并提出其外观。 反过来，项目经理制定项目计划，制定工作分解结构，并准备项目进度表。 该阶段的最终目标是清楚地了解项目范围，并为项目绩效监控奠定基础。

在这个阶段，PM 还设置了沟通和进度跟踪工具，以及未来部署的计划，定义了验收标准。

• 项目启动和执行

在项目团队参与设计和测试未来解决方案时，项目经理会监控团队的绩效，消除可能阻碍项目工作的瓶颈，促进团队成员和项目利益相关者之间的沟通，记录项目进度，跟踪风险触发因素并报告给客户或高级管理人员。

• 项目验收

在项目验收阶段，解决方案或一组可交付成果被推出到暂存环境，并在其中进行 beta 测试。 如果需要，开发团队会提供必要的狐狸。 PM 确保解决方案按时完整交付，并保证交付的软件符合商定的验收标准。 在项目验收阶段的软件开发项目管理的另一部分涉及准备用户指南、安装说明和其他项目文档。

• 项目完成

项目完成后，项目经理会进行回顾性审查，评估并记录整个项目的起起落落。 他们还确保将所有可交付成果移交给客户/产品所有者，包括所有源代码、软件文档、开发环境等。

这些基本阶段可以线性地相互跟随，也可以允许更多的重叠——这取决于所选择的管理软件开发项目的方法。

软件开发中的项目管理：流行的方法

最广泛使用的软件项目管理方法包括 Scrum、看板（都属于敏捷家族）和瀑布。

软件开发跨度中其他不太流行的项目管理方法：增量开发模型、螺旋模型、PRINCE2 和 Rational 统一过程 (RUP)。

Scrum

作为软件开发中最流行的项目管理方法之一，Scrum 将开发过程分解为多个 sprint，每个 2 到 4 周。 通常在冲刺之前进行彻底的计划。 Scrum 非常适合具有高度不确定性的项目，它依赖于跨职能、自组织的团队，并接受基于观察和实验的增量开发理念。

软件开发中基于 Scrum 的项目管理与传统管理有点不同，因为没有这样的 PM。 相反，一个人的责任由产品负责人和 Scrum Master 分担。

看板

看板的特点是没有明确定义的迭代。 这是一种管理软件开发项目的精益方法，有助于可视化项目范围、限制正在进行的工作并确保工作顺利进行。 该方法使用代表团队独特工作流程的物理或数字看板。

由于其性质，该模型非常适合支持和维护项目。

看板的另一个特点是对正在进行的工作量实施限制。 该方法旨在平衡范围和资源。 任务在可用容量允许时被拉出，而不是在请求时被推入流程。

管理软件开发项目的职责通常由看板的两个基本角色分担：服务交付经理和服务请求经理。 前者负责提高工作流程的效率，而后者主要负责解释客户的需求和期望。

然而，没有必要雇佣额外的团队成员来适应看板规则。 实际上，经验丰富的 PM 通常同时兼任这两个角色。

瀑布

与敏捷系列相比，基于瀑布的项目管理将项目分解为不同的、连续的阶段。

传统上，一旦前一个阶段完全完成，新阶段就会开始。 然而，现代瀑布项目允许一定程度的重叠。 例如，测试团队在开发过程中开始验证单个功能是很常见的。

管理软件开发项目的瀑布式方法非常适用于范围可预测的项目，但它仍然会使开发团队措手不及，无法比竞争对手更快地进行调整。

由于瀑布和敏捷的项目管理有其特殊性，让我们深入了解主要区别。

瀑布和敏捷项目管理有什么区别？

现在让我们更详细地了解一下瀑布和敏捷项目中管理实践的不同之处。 我们正在比较这两者，因为它们比其他项目管理方法更常见，并且两者在项目工作的组织方式上存在显着差异。 后者影响项目经理（或敏捷中的相应角色）的角色和职责。

项目计划

在瀑布中，如果不彻底了解您正在构建的内容和原因，就不可能继续前进。 这就是为什么制定详尽的软件需求规范是瀑布项目中的第一要务。 通常，SRS 由业务分析师编写。 但是如果没有一个，项目经理可以接任。

另一方面，敏捷允许更大的灵活性。 随时随地引入产品和流程改进是敏捷方法的本质。 计划活动通常提前一个冲刺进行。 积压是在所谓的 sprint zero 期间创建的。

在 sprint 0 期间，团队提出了最少数量的用户故事，以将其转变为可行的产品，并且可以选择设置用于开发的基础架构。 冲刺通常保持轻量级和高级别的。

项目范围管理和预算

在 Waterfall 中，解决方案范围必须在整个项目中保持不变。 变更请求通过变更管理程序进行管理，并单独计费。 敏捷软件开发中的项目管理在范围管理方面提供了更大的灵活性，但很难评估范围变更对最终软件成本的影响。 这会影响项目预算的方法。

在 Waterfall 中，预算编制是自上而下的、受控的并基于详细的业务案例。 一旦提出和分析了需求，这种方法就可以给出现实的成本估算。 主要的缺点是这种方法在软件开发项目经常出现的多变、不确定和模棱两可的环境中不起作用。

敏捷管理软件开发项目成本的方式是响应变化的。 这既是优势，也是复杂性。 敏捷预算与项目的结构和时间表保持一致。 由于它也遵循 sprint 结构，因此团队更容易适应不断变化的环境——而不会影响整个项目预算。 项目经理只是在下一轮计划中重新校准支出。

项目交付

通过走敏捷路线，公司在每次迭代后都会获得新功能或其他可交付成果的增量——无论是技术愿景、工作特性还是 MVP。

另一方面，在经典的瀑布中，客户直到项目结束才真正得到任何连贯的、有效的解决方案。 全面的测试活动也在开发过程的后期进行，这可能会影响上市时间。

项目文件

根据 Waterfall 的说法，在管理软件开发项目时，必须进行适当的、记录在案的计划。 项目要求必须事先明确，每个团队成员都应该了解它们。 每个团队成员还应该了解他们在项目中的角色以及对他们的期望。 这些信息通常也被记录在案，并在项目团队中分发。

瀑布团队在整个开发过程中经常参考文档，以便更容易跟踪进度。 这是唯一的方法——考虑到通常根据 Waterfall 管理的项目的长度和复杂性。 文档在每个阶段进行，确保每个人都在同一页面上了解项目的进展，尽管模型的顺序性质。

虽然大量的文档有助于降低瀑布中的风险，但它降低了敏捷中对变化的适应性。 因此，在敏捷项目中生成较少的文档是很常见的。 如果它被生产出来，文件就会保持简洁。

但是，尽管有一个普遍的误解，敏捷方法论中并没有任何东西可以从本质上阻止团队创建他们需要的尽可能多的文档。 事实上，有些文件是绝对必要的。 必须将用户故事添加到积压工作、起草线框图和记录客户会议。 敏捷的建议是在文档过程中更聪明，并避免太长的文档。

项目经理的职责是什么？

根据管理软件开发项目的方法，项目经理的职责也会有所不同。 让我们看看 PM 或相应的敏捷角色在项目的每个阶段都做了什么。

在瀑布

项目经理是每个瀑布团队中最重要的角色。 他们对可交付成果的质量和按时完成的项目负责。 他们的主要职责包括监督项目活动和为团队成员指定任务。

现在让我们将 PM 的工作范围分解为多个阶段。

在敏捷中

敏捷项目经理为每个 sprint 确定待办事项的优先级，监控开发进度，并在团队内部以及团队与利益相关者之间建立有效的沟通。 他们还监控项目每个阶段的风险，并确保开发过程遵守敏捷原则。

这是项目经理在敏捷项目的每个阶段专门做的事情：

项目经理需要注意哪些陷阱？

管理软件开发项目成功的关键是能够预防和避免风险。 一个好的 PM 应该注意的常见陷阱：

无法控制范围

尤其是在敏捷中，客户经常在旅途中请求额外的功能，这常常使项目出错。 因此，项目经理需要制定明确的变更管理程序，以防止范围蔓延。 他们还需要确保利益相关者就变更对项目时间表和资源的影响达成共识。

不专注于满足交货日期

开发具有严格上市时间要求的产品，例如需要在学年开始之前发布的教育应用程序或必须及时推出的零售应用程序以进行圣诞节销售，PM需要罢工在准时和确保高质量之间取得适当的平衡。

他们需要投入额外的精力来确定功能的优先级并为要交付的每个功能设置截止日期。 质量要求也必须预先定义，以避免在推出后出现问题。

未能建立有效的沟通

软件开发中的有效项目管理需要有效和透明的沟通。 建立一个是 PM 的主要职责。 他们需要让团队了解利益相关者的决定，并定期向利益相关者通报所有项目活动、瓶颈和挑战。

未能建立清晰的流程

遵循软件开发过程对团队成员来说似乎是一种负担。 尽管如此，仍然有必要建立一个针对项目具体情况量身定制的清晰工作流程。 它将组织工作并明确期望。

依赖不熟悉的技术

项目经理需要确保工程团队在进行技术选择时专注于解决客户的业务问题。 他们还需要验证所选的技术堆栈是否符合工程最佳实践。

另一个与技术相关的陷阱是未能在产品开发的早期阶段规划可扩展性。 因此，我们建议预先定义可扩展性要求以及其他非功能性要求。

未能提前考虑推出过程

在开发的早期阶段，部署过程经常被忽视，这会导致部署过程中出现严重的延迟。 软件开发中的健康项目管理需要 PM 以确保在开发过程的早期就考虑到部署和安装问题。

如何在软件开发中进行项目管理：ITRex 的观点

我们与 ITRex 的首席 PM Alexander Belkavets 坐下来，就我们在 ITRex 如何处理软件项目管理问题采访了他。 这是我们学到的。

在为我们的客户选择合适的项目管理模型时，您依赖哪些因素？

Alexander：选择这样或那样的项目管理方法背后有很多因素。 最重要的是项目范围、预算和上市时间。

如果我们正在开发需要定期更新以持续为最终用户创造价值的产品，例如游戏应用程序，我们自然会选择 Scrum 或类似 Scrum 的方法。

另一方面，如果我们正在开发由政府实体委托的软件解决方案，这通常意味着预算是固定的，我们宁愿选择类似瀑布的方法来确保所需的可预测性。 但是，将开发阶段拆分为较小的迭代并不少见。 因此，我们经常采用混合方法，使我们能够从 Waterfall 的可预测性和敏捷的持续改进和交付速度中受益。

是否有其他因素影响项目管理方法的选择？

亚历山大：当然。 未来解决方案将用于的领域、认证需求、客户参与流程的意愿以及许多其他因素也会影响项目。

例如，在开发医疗保健解决方案时，通常会选择瀑布。 在美国，在销售一种新型医疗设备之前，他们必须获得 FDA 的批准； 这需要大量的文档，这不可能确保遵循敏捷。

您作为项目经理的角色究竟需要什么？ 您管理客户项目的主要目标是什么？

Alexander：我从两个角度看待我作为项目经理的角色。

第一个是：管理项目就是管理风险。 软件开发项目容易出​​现许多风险——从固有的错误需求到采购不足，再到不断变化的技术环境等等。 项目经理在这方面的主要目标是尽量减少风险对项目的影响，从而最大限度地提高软件成功交付的可能性。

第二个观点是：管理项目正在成为一种集成器，它使许多项目子系统（如开发、测试和部署）能够和谐地结合在一起。 PM 的主要目标是以触发更少风险并确保最大程度地利用资源的方式协调项目内的所有流程。

你能回想一个项目，其中选择的项目管理方法被证明是确保产品成功的决定性因素吗？

Alexander：我们正在为我们的客户开发一个移动应用程序，并且我们使用 Scrum 启动了这个项目。 一旦我们发布了应用程序的第一个版本并获得了第一个产品指标，我们决定切换到看板。

为了留住第一批用户，我们需要继续定期提供新功能，尽管不再需要两周的冲刺。 看板使我们能够根据新功能的复杂性调整 sprint 长度，平均 sprint 为 3 到 4 周，因此我们在不给开发团队带来额外压力的情况下保持交付速度。 结果，我们的客户设法留住并吸​​引了新用户。

因为敏捷团队的定位是自我管理，所以很容易相信一个项目也可以在没有专门的项目经理的情况下完成。 是这样吗？

Alexander：如果没有专门的 PM，那么一个人的职责就必须分散到所有团队成员身上。 人们仍然需要花时间来确定积压的优先级、采购资源、报告和执行其他基本管理任务。 但是在没有 PM 的情况下，这些任务将被委派给没有专业知识的人。 这无助于最大限度地利用人才。

无 PM 方法可能适用于 3-4 人的小团队，但当这个数字变得更大时，拥有一个专门的项目经理变得至关重要。

如果您对管理软件开发项目仍有疑问或愿意将指导您的项目的责任交给经验丰富的合作伙伴，请联系 ITRex。

最初于 2022 年 10 月 24 日在 https://itrexgroup.com 上发布。