45、远程交付与固定投标项目管理全解析

远程交付与固定投标项目管理全解析

在项目管理领域，远程交付和固定投标项目有着独特的挑战与机遇。寻找新的价值点不仅能助力客户实现业务增长，还能为我们带来更多合作机会，这一过程被形象地称为“为客户挖掘价值点”。在固定投标项目中，很多客户愿意为变更的需求付费，或者单独为新增需求付费，这也是固定投标项目合同的本质所在。然而，客户往往认为自己明确了需求范围，但实际上他们很难有一个准确的需求界定。

业务分析的注意事项

普通敏捷团队进行业务分析时通常遵循及时性原则，一般只为开发人员分析短期（一到两个迭代）的开发任务。但在固定投标项目中，这种思维需要转变。为了尽量减少不愉快的临时状况，确保项目完成成本相对准确，我们应提前开展分析工作，最好能提前至少五个迭代，并提前完成对定义不清晰和高风险功能的分析。同时，由于客户可能无法及时回应大规模的需求故事卡，我们需要加强与客户的沟通。

充分利用原始故事卡

项目启动时产生的原始故事卡非常重要。交付团队收到的需求列表代表了需求范围，其中应包含我们的估算，这些信息都要体现在与客户签订的合同中。作为业务分析师，我们要对原始需求故事卡进行深入分析，估算每个需求的工作量以及最坏情况下的总体工作量，从而更全面地了解项目需求范围。

项目启动后，我们会制定需求列表，每个需求都有前提条件和预期达成的效果。开发过程中，任何偏离这些需求的情况都应视为需求增加，需仔细记录并在每个迭代中通过邮件与客户确认细节。原始需求卡对包括开发人员在内的所有人都有效，每张故事卡都对应着一些假设，忽略这些假设可能会导致工作超出需求范围，增加团队成本。

监控项目进度

普通时间资源导向型项目的进度跟踪方法同样适用于固定投标项目。成功的固定投标项目关键在于更严格的进度管理手段和流程。通过早期分析和关注变更，我们能够灵活成功地交付项目。每个故事卡都有最可能的估算工作量和应对不确定性的缓冲，关键是要有效管理潜在的意外情况。

当项目进行到某个特定迭代时，如果发现某组故事的估算工作量比原始估算增加了 10%，我们需要思考需求扩展是否具有系统性，是所有原始需求故事卡都被低估，还是部分故事卡有需求扩展。同时，要将所有新需求添加到原始需求列表中并明确标记，我们和客户都要清楚哪些是新增需求。

以敏捷方式处理变更需求

传统固定投标项目有大量前期分析和严格的范围控制，非原始需求列表中的任务会被视为需求变更。在敏捷开发中，我们应采取更灵活的方式，不能简单地将所有需求变更排除在计划之外，这违背了敏捷开发的基本原则。

处理变更需求有两个选择：一是增加预算完成新需求，二是用相同工作量的新需求替换原需求，但这都需要在项目开始时与客户协商。如果项目早期未明确规则和达成共识，后期很容易产生纠纷，因为客户关注业务，我们关注成本。例如在物流管理系统项目 L 中，由于亚太地区用户对数据矩阵模板提出异议，我们最终帮助客户申请了额外预算，并将重新设计路线的两周工作量纳入新需求。

为了应对需求变更，我们应在设计产品时采用高内聚、低耦合的理念。高内聚指功能模块最好只完成一个独立子功能并出色完成；低耦合指模块尽可能独立，连接少、接口简单。微服务架构就是这种理念的完美体现：
- 独立团队 ：在单体应用中，开发团队成员即使只开发小功能也需了解应用的各个部分，在部署规划、版本控制、数据迁移等方面要密切合作。而在微服务架构中，每个微服务围绕小业务能力构建，由独立团队管理，团队只需了解其他服务提供的接口并遵循自身提供的接口，每个微服务可独立部署。
- 专注一事并做好 ：微服务架构类似于 Unix 哲学，即专注做一件事并做好，这也是 Unix 系统数十年不过时的原因之一。微服务应设计为专注一项功能并能应对各种情况。
- 故障隔离 ：如果应用中的报告生成模块出错，在单体应用中可能需关闭整个交易应用，但在微服务架构中，只有报告生成模块会受影响，未使用该模块的用户不会察觉异常，核心业务仍可正常运行。

变更需求的决策

无论变更如何实施，都需要有明确的组织或个人来决定。决策方法需具备以下特点：
- 参与者要有同意变更的权利，包括用新功能替换旧功能以及认可因范围和支出变化导致的预算变更。
- 变更控制委员会同意的变更级别要得到各方知晓和认可。
- 对于无法达成一致的变更，要有商定的向上级领导汇报的方式。

结束固定投标项目

离岸团队必须明确项目的结束标准，这是商业合作的重要部分和项目成功的关键因素。固定投标项目中，最严重的成本超支是项目超出预期结束日期，为维持团队规模和开发速度，开发过程中通常需增加人力。

如果项目无法完美收尾，常见问题是原合同中验收条件的最终定义不清晰、定义错误或存在未达成一致的事项。我们要尽快找出团队忽略的点，明确目标并及时弥补工作。

定义项目结束标准时需考虑以下几点：
|考虑因素|具体内容|
| ---- | ---- |
|交付接受时间点|是开发完成部署到生产环境的时间，还是部署后的某个时间？|
|系统可接受的缺陷数量|不能过于乐观或悲观，否则可能导致合同结束后仍需投入大量人力修复缺陷，这本应是客户 DevOps 的工作。|
|与客户商定的非功能需求|业务分析师要与开发人员讨论这些指标，例如项目 L 中数据导出到 Excel 表格的性能问题，最终与客户协商采用 CSV 格式。|
|知识转移计划|制定与客户的知识转移计划。|

业务关注点

管理客户期望在项目管理中至关重要，尤其是固定投标项目。我们团队要努力实现客户需求，让双方明确各自责任。团队需更严格地管理需求变更，尽力提供满足客户期望的最小可接受功能。客户要明白新需求超出原协议，我们有权控制变更并可能要求增加预算。双方需要在项目开始时就明确复杂详细的变更控制流程。

在将交付计划转化为业务提案时，还需考虑以下事项：
- 对客户业务领域的了解程度。
- 对项目所用技术的熟悉程度。
- 合适的团队规模。
- 是否需要担心项目规模。
- 是否要同意繁琐的非功能需求。
- 是否对客户进行了提前风险评估。
- 关键成功因素是否明确。

如果采用敏捷开发，与客户讨论项目成本会比较困难，因为固定总价项目意味着工作量固定，外包团队可能不希望按照敏捷开发理念修改功能。

固定投标项目的风险

不确定需求的项目不适合采用固定投标合同。但如果不幸接手了这类项目，也有应对策略。项目成员需牢记以下几点：
- 与客户商定的项目成功关键定义要与目标一致，项目经理要在团队中传达这些信息。
- 团队成员要重视完成所有商定功能，关注项目进度，确保在规定时间内完成承诺的工作量。
- 固定投标项目要持续进行风险管理，尽早开展风险评估，必要时邀请客户参与前期工作，双方共同承担风险。
- 离岸团队承担固定投标项目的风险比按人天计费的项目大，且风险早期通常不明显，不能掉以轻心。
- 严格管理需求变更是否超出合同规定范围，妥善处理这些边界是成功交付离岸固定投标项目的基石。
- 固定投标项目强调尽量减少要完成的可接受功能以按时履行合同，但也要让客户最终满意交付成果。不必要的功能不应纳入计划，所有新需求都要进行变更控制，因为可能会产生额外成本。
- 对于普通离岸团队来说，维持项目需求范围已是一项显著成就。

建议、提示和可能的陷阱

固定投标项目常涉及“软性”交付（如评估、分析等），表面上风险比交付软件小，但如果不明确分析范围、文档内容和评估后的跟进，容易出现问题。准确理解交付内容对制定估算和有效管理项目完成至关重要，理想情况下要从项目第一天到最终交付完成都与客户进行频繁审核，确认是否符合期望。

我们还需认真考虑以下几点：
- 软件在哪个阶段移交给客户（代码冻结、用户验收测试，还是客户团队完全接受软件）？
- 解决软件缺陷的责任是什么？
- 软件需要部署到哪个环境？
- 软件的其他相关需求，如安装和配置管理。
- 避免在项目后期添加资源，除非是相对独立的模块，否则会增加上下文沟通成本。

项目开始时，要确保固定投标项目的客户有增加预算的能力。如果客户确认不增加预算，报价时应增加一定比例的溢价。项目后期常出现大量需求变更，因为客户开始使用软件后会产生新想法，这也是项目逾期和预算超支常见的原因。

如果客户有遗留系统且我们需要其功能，可假设遗留系统正常运行，但如果功能异常，客户需安排开发人员解决。如果客户没有开发人员维护该系统，我们要假设这部分功能无法正常工作。

与客户工作的衔接

离岸团队与客户的联系主要发生在项目启动和结束阶段。如果开发过程需要与客户密切协调，则整个项目周期都需要频繁沟通。

启动阶段，我们从客户业务人员处接手需求，与客户确定设计方案和技术开发计划，然后生成交付计划。结束阶段，交付物移交给客户的 DevOps 部门，但有时我们需要在项目初始阶段就考虑最终交付物。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(项目启动):::process --> B(接手需求):::process
    B --> C(确定设计与技术计划):::process
    C --> D(生成交付计划):::process
    D --> E(项目开发):::process
    E --> F{是否需密切协调}:::process
    F -->|是| G(频繁沟通):::process
    F -->|否| H(正常开发):::process
    G --> I(项目结束):::process
    H --> I
    I --> J(交付物移交):::process

总之，在远程交付和固定投标项目管理中，我们需要全面考虑各个方面，灵活应对各种挑战，以确保项目的成功交付和客户的满意度。

远程交付与固定投标项目管理全解析

项目启动与客户需求对接流程

在项目启动阶段，我们需要遵循一套严谨的流程来对接客户需求，确保项目的顺利开展。以下是详细的步骤：
1. 需求接收 ：从客户的业务人员那里获取详细的需求信息，包括业务目标、功能要求、非功能要求等。
2. 需求分析 ：对接收的需求进行深入分析，识别出关键需求和潜在问题。
3. 设计方案制定 ：根据需求分析的结果，制定初步的设计方案，包括系统架构、模块划分等。
4. 技术开发计划确定 ：结合设计方案，确定技术开发的具体计划，包括技术选型、开发进度安排等。
5. 交付计划生成 ：综合以上步骤，生成详细的交付计划，明确各个阶段的交付物和时间节点。

步骤	具体内容
需求接收	与客户业务人员沟通，获取需求文档、业务流程说明等
需求分析	识别关键需求、潜在风险，评估需求的可行性和合理性
设计方案制定	确定系统架构、模块划分、接口设计等
技术开发计划确定	选择合适的技术栈，制定开发进度表
交付计划生成	明确各阶段交付物、时间节点、验收标准

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(需求接收):::process --> B(需求分析):::process
    B --> C(设计方案制定):::process
    C --> D(技术开发计划确定):::process
    D --> E(交付计划生成):::process

项目执行中的风险管理

在固定投标项目执行过程中，风险管理至关重要。以下是一些关键的风险管理措施：
1. 风险识别 ：在项目开始前，对可能出现的风险进行全面识别，包括技术风险、需求风险、人员风险等。
2. 风险评估 ：对识别出的风险进行评估，确定风险的可能性和影响程度。
3. 风险应对策略制定 ：根据风险评估的结果，制定相应的风险应对策略，如风险规避、风险减轻、风险转移等。
4. 风险监控 ：在项目执行过程中，持续监控风险的状态，及时发现新的风险并采取相应的措施。

风险类型	可能影响	应对策略
技术风险	导致开发进度延迟、质量下降	提前进行技术调研，选择成熟的技术方案
需求风险	需求变更频繁，导致成本增加	加强与客户的沟通，严格控制需求变更
人员风险	人员流失、技能不足	建立人才储备机制，提供培训和发展机会

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(风险识别):::process --> B(风险评估):::process
    B --> C(风险应对策略制定):::process
    C --> D(风险监控):::process
    D -->|发现新风险| A

需求变更管理流程

在项目执行过程中，需求变更不可避免。为了有效管理需求变更，我们需要建立一套规范的流程：
1. 变更请求提出 ：客户或项目团队成员提出需求变更请求，并说明变更的原因和内容。
2. 变更评估 ：对变更请求进行评估，包括变更的影响范围、成本、时间等。
3. 变更决策 ：根据变更评估的结果，由变更控制委员会做出是否批准变更的决策。
4. 变更实施 ：如果变更请求被批准，项目团队按照变更计划进行实施。
5. 变更验证 ：变更实施完成后，对变更的结果进行验证，确保满足客户的需求。

步骤	具体内容
变更请求提出	填写变更请求表格，说明变更原因和内容
变更评估	分析变更对项目进度、成本、质量的影响
变更决策	变更控制委员会根据评估结果做出决策
变更实施	项目团队按照变更计划进行开发和测试
变更验证	对变更后的系统进行测试和验证

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(变更请求提出):::process --> B(变更评估):::process
    B --> C(变更决策):::process
    C -->|批准| D(变更实施):::process
    C -->|拒绝| E(结束):::process
    D --> F(变更验证):::process
    F -->|通过| G(结束):::process
    F -->|未通过| D

项目结束阶段的关键要点

项目结束阶段是确保项目成功交付的最后环节，需要关注以下关键要点：
1. 交付物验收 ：按照合同要求，将项目交付物提交给客户进行验收，确保满足客户的需求。
2. 知识转移 ：将项目相关的知识和经验转移给客户的团队，包括系统操作手册、技术文档等。
3. 项目总结 ：对项目进行全面总结，分析项目的成功经验和不足之处，为今后的项目提供参考。
4. 客户满意度调查 ：开展客户满意度调查，了解客户对项目的评价和意见，以便改进服务质量。

关键要点	具体内容
交付物验收	提交交付物，配合客户进行验收测试
知识转移	提供系统操作手册、技术文档，进行培训
项目总结	分析项目的成功经验和不足之处
客户满意度调查	了解客户的评价和意见，改进服务质量

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(交付物验收):::process --> B(知识转移):::process
    B --> C(项目总结):::process
    C --> D(客户满意度调查):::process

持续改进与最佳实践分享

为了不断提高项目管理的水平，我们需要进行持续改进，并分享最佳实践：
1. 经验教训总结 ：定期对项目进行复盘，总结经验教训，形成知识文档。
2. 最佳实践推广 ：将成功的项目经验和最佳实践在团队内进行推广，提高整体项目管理能力。
3. 培训与学习 ：组织团队成员参加相关的培训和学习活动，不断提升专业技能。
4. 客户反馈收集 ：积极收集客户的反馈意见，根据客户需求调整项目管理策略。

改进措施	具体内容
经验教训总结	定期召开项目复盘会议，形成经验教训文档
最佳实践推广	组织内部培训和分享会，推广成功经验
培训与学习	参加行业培训课程，学习最新的项目管理知识
客户反馈收集	通过问卷调查、客户访谈等方式收集反馈意见

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(经验教训总结):::process --> B(最佳实践推广):::process
    B --> C(培训与学习):::process
    C --> D(客户反馈收集):::process
    D -->|反馈| A

在远程交付和固定投标项目管理中，我们需要从项目启动到结束的各个阶段都进行严格的管理和控制，同时注重风险管理、需求变更管理和持续改进。通过遵循科学的流程和方法，我们能够提高项目的成功率，满足客户的需求，实现业务的增长。