44、以客户为导向的离岸团队项目管理策略

以客户为导向的离岸团队项目管理策略

在项目管理和软件开发的过程中，我们会面临各种不同类型的项目和复杂的情况。如何更好地应对这些挑战，以客户为导向进行项目交付，是我们需要深入探讨的问题。

情绪管理与项目应对

在项目进行过程中，我们可能会遇到情绪不稳定的情况，此时做出的决策可能比较激进。当我们经历情绪大幅波动时，可以采取以下行动：
- 加强沟通，确定真正的责任人，避免出现“冤案”。
- 把让我们纠结的事情先放一放，等冷静下来再思考。
- 将手头的工作转移给其他人。
- 当发现是客户的错误时，不要情绪化，因为坏情绪可能会让自己成为替罪羊，最终遭受损失。

客户意见决定交付质量

无论我们设定了多少指标、检查了多少表格、审查了多少代码、编写了多少测试，对客户来说，唯一重要的是软件能否正常运行。相对于代码质量、性能、设计和可用性，客户反馈是决定质量的唯一因素。我们需要从客户的角度来审视我们的产出。

这涉及到同一事物的内在价值和商业价值。客户的关注点与我们不同，是因为他们更关注商业价值而非内在价值。以瓷器和玻璃的历史地位为例，瓷器和玻璃在不同历史阶段出现，决定了它们在人们心中的地位。瓷器可作为餐具、杯子等，玻璃也能如此，且玻璃成本更低，还有透明的特性。但我们总认为瓷器更高端，玻璃只是廉价的象征。这就是玻璃与瓷器有相同内在价值，但商业价值却远远落后的原因。

离岸团队每天与本地团队互动，要像一个团队一样工作。但不同团队隶属于不同的本地公司或分支机构，各有老板。所以在处理棘手问题时，必须清楚坚持原则和教条主义的界限。

在工作中，我们要和其他团队的人密切合作，就像在同一个团队，但要记住我们仍代表自己的公司，维护公司利益是不可推卸的责任。例如，固定报价项目的需求增加，需要我们投入更多。我们不仅要关注事情本身，还要关注事情所处的环境。所有事情都会随环境变化而调整，不同环境决定了事情的调整程度。

与客户合作时，妥协很常见，但我们要有回到正轨的路线图，而不是一味让步。每个人都要明白，妥协只是权宜之计。比如，为了提高开发速度而减少测试覆盖范围，会产生“技术债务”，我们必须尽快填补这个缺口。

对于结对编程是否从头到尾都必要，判断标准是看它是否有额外价值。我们要判断两人能否分享知识，能否有有价值的分享。简单的代码堆砌可能会让人昏昏欲睡或无聊到只想刷微信。

在应对客户需求变化时，要区分变化和不变的中间线。接受变化时，要区分不必要的变化，同时帮助客户避免为不必要的事情付费。不断问自己是否为客户创造了价值，这样做决策会更容易。

按人天计费的交付项目

这种项目中，客户根据我们团队成员的工作时长付费，中国大多数海外外包项目采用这种方式。

这类项目的客户承担更多风险和压力，但好处也很明显。首先，客户对需求有更强的控制权，包括范围和优先级，可随时灵活调整。其次，这种合作方式适用于对用户体验要求高的项目，客户能控制用户体验的满意度。对于固定报价项目，需求总量必须固定，需求范围的任何变化都需要客户调整预算，项目返工也需单独付费。如果对用户体验要求高的项目采用固定报价，我们和客户难免会在用户体验这个边界模糊的需求上产生纠纷，实际情况可能更糟。

近年来的项目，启动时很少有固定的交付需求范围。为了最终满足用户，项目团队在开发过程中要收集用户反馈，同时调整产品方向。这样既能使产品功能尽可能完整，又能最大程度优化用户体验。大多数用户反馈要等用户看到产品效果或亲自试用后才能提交，所以固定报价合同不适合软件开发项目。

对于按人天计费的项目，离岸团队也要关注进度。和固定报价项目一样，故事卡的估算结果也代表团队对客户的承诺。客户也关心开发进度，更快的开发速度似乎能降低超预算的风险。

有时离岸团队的开发人员在决定技术栈中某个功能的级别上有一定自主权。特别是前端开发人员，采用不同技术栈产生的效果不同，不一定能达到客户想要的效果，当然也可能超出客户预期。作为专业软件服务行业的一员，我们要勇敢面对挑战，向客户展示最好的交付团队是什么样的。

由于开发团队只开发已发布的部分需求，另一部分根本不开发，所以不会因需求变更产生浪费。可以说，敏捷开发模式甚至鼓励我们为了促进开发而修改需求。过去，需求修改是软件外包项目无法完成的主要原因。

这种服务模式让离岸团队更容易陷入舒适区。无论是个人成长还是整个团队管理，都要努力让每个人跳出舒适区。

固定报价交付项目

固定报价项目的合同必须包含相对固定的需求和交付日期两点。很多客户，尤其是国内客户，倾向于签订这样的合同，因为可以将部分风险转嫁给供应商。所以，如果离岸团队从事固定报价项目，会承受更大压力。

开发这类项目并不复杂，但与普通的人天项目不同，我们仍需关注以下五个因素：
- 如何衡量项目的规模和价格？
- 如何管理需求变更？
- 如何管理客户期望？
- 如何管理风险？
- 商业因素

工作量和价格估算

接手固定报价项目时，我们需要相对准确地估算其整体工作量。虽然投入更多人力和时间进行估算会得到更可靠的结果，但我们必须尽快完成估算过程，因为无论投入多少，结果始终是估算值。

为了满足国内客户的需求，ThoughtWorks作为敏捷开发模型的发起者和领导者，在多年的快速启动项目实践后，创建并实践了一种让敏捷开发团队妥善处理固定报价项目的方法，即“快速启动”。该方法要求项目团队在最短时间（通常两到三周）内与客户深入合作确定需求，同时确认每个需求的范围，并为不同风险预留必要的缓冲。但这种方法不适用于启动时无法确定所有需求的项目。

固定报价项目的工作量估算与其他普通项目类似，内容包括故事卡列表、业务分析、迭代计划安排、测试策略和工作量等，与项目类型无关。

固定报价项目的特殊性在于，这个过程中的不确定性更重要，因为交付团队承担更多风险。对于原估算为1000人天的项目，我们是否应报价1200人天呢？这样能帮助我们覆盖一些额外投资。任何超出计划预算的额外资源投入都会降低项目利润。如果利润低于一定水平，项目将被视为失败。最糟糕的情况是项目严重超预算，但我们仍需投入额外人力和工时继续工作。

我们计划交付的所有需求都来自项目启动时的产出。当然，我们不需要对整个项目需求进行模拟操作并生成分布式结果集。完成这个固定报价项目的过程并没有什么神奇之处。我们预计最终结果可能是一个区间，所以最好估算三个结果（最小值、最可能值和最大值）。这非常重要，因为可能的结果会直接影响项目的商务谈判。简单来说，我们可以通过查看所有最小值、最可能值和最大值的总和，得到一个不太科学但有参考价值的结果。如下表所示是一个项目中得到的三个结果：
| 估算指标 | 数值 |
| — | — |
| 估计最小人天 | 203 |
| 最可能人天 | 283 |
| 预期最大人天 | 477 |

这就是我们科学应对意外情况的方式。显然，与以时间和资源为导向的项目相比，固定报价项目中处理意外情况更为重要。在估算阶段，常见的做法是增加一些缓冲，如在估算结果上增加20%。如果涉及固定金额，通常会在最后加上固定的价格溢价，以弥补我们作为供应商承担的固有风险。

估算固定报价项目时，需要特别注意以下因素：
- 不确定需求导致的意外情况。即使需求确定，我们也没有足够时间将其细化到包含验收条件的所有细节。通过估算最可能值，我们能准确了解需求明确的部分。即便如此，我们仍要谨慎，为未知情况留有余地。即使出现最坏的情况，即客户要求增加需求，我们也应能在不增加预算的情况下，从需求范围中移除（范围内且不少于新增工作量）的故事卡。
- 固定报价项目中容易忽略非功能需求。无论是从所需成本投入还是合同角度，我们团队在项目启动时都要尽可能考虑，尤其是非功能需求。在资源投入方面，根据合同，明确项目的完成指标至关重要。如前文所说，做固定报价项目的风险之一是项目不能按时完成。届时，除非对项目结束有明确界定，否则很容易与客户产生纠纷，即系统当前是否“可接受”。在协商前期计划时，我们应讨论并记录所有非功能需求，这些可能包括响应性能、平均无故障时间（MTBF）、故障转移、吞吐量、灾难恢复计划和支持文档等许多指标。这个领域可能隐藏着大量工作量，在签订固定报价协议前应明确其范围。
- 验收标准。成功的关键因素是明确定义整个项目，即什么构成了客户可以接受并付款的最低成功交付。此外，验收标准还应明确项目阶段。没有明确的成功衡量指标，各方会有不同的表述，这也是离岸团队与客户团队关系最终破裂的原因之一。虽然政治上模糊的表述有助于双方求同存异、奠定合作基础，但明确的项目指标才是合作的基础。
- 需求故事列表。合同签订意味着我们与客户达成了共识，故事列表代表项目需求的范围。这个需求列表必须作为严格的基线来监控需求的变化，包括增加和减少。如果需求范围大幅增加，这个列表可作为对我们有利的证据。
- 项目启动。启动速度在所有项目中都至关重要，尤其是固定报价项目。团队初始环境设置需要花费大量时间。我们必须确保这些任务已包含在向客户的估算报价中。否则，肯定会影响前几次迭代的预期交付成果。我们可以直接找团队外专门部署开发环境和持续集成环境的人，这需要一周时间，而我们的团队成员可以专注于技术研究和需求开发，以确保团队的生产力。我的一个团队曾在这方面吃过亏。团队成员在设置环境方面缺乏经验，不得不花时间学习相关特殊技术，这极大地影响了项目进度，迫使我们通过多次迭代采取补救措施。
- 估算审核。所有估算都需要独立第三方审核，整个发布计划也需要审核以减少错误。我们通常邀请其他项目中有经验的技术总监来审查我们团队的估算结果。除了获得额外的视角，我们还可能获得一些现成的技术经验，如其他团队做过的类似单点登录（SSO）功能。
- 架构和技术方面都要充分考虑。我们需要评估技术风险，这是我们必须承担的风险之一。必要时，我们可以创建一些技术卡片并放入故事卡列表中。
- 管理依赖关系。我们应严格管理需求对客户方的依赖关系。如果客户团队负责交付部分相关内容或集成上下游内容，这些问题必须在合同中明确规定各方的责任和义务以及重要时间点。我们应从头到尾关注这些问题的进展。不要让对方的义务影响我们的工作，一旦产生影响，应立即书面通知客户。

以下是固定报价项目估算流程的 mermaid 流程图：

graph LR
    A[开始估算] --> B[确定需求范围]
    B --> C[估算工作量（最小、最可能、最大）]
    C --> D[考虑缓冲和溢价]
    D --> E[审核估算结果]
    E --> F[完成估算]

固定报价项目的管理

围绕固定报价项目的一个基本问题是完成项目的成本，包括所有人力资源投入和差旅费。我们需要一个工具来快速轻松地管理这些成本。通过输入已发生的数据和未来预计发生的数据，我们可以尽可能了解整个项目的成本和时间。这对项目是否超预算或其他风险具有良好的实时管理意义。这个工具可以支持持续数据更新，每次数据更新后，结果都更接近项目的实际成本。

在项目实施过程中，当发现交付可能延迟时，我们需要增加人力以加快项目进度，或者说服客户增加预算。我们可以采用股票市场中的逢低买入和摊薄成本的做法，增加少量工作量，尽可能促使客户增加预算，以在项目交付和客户满意度之间取得平衡。过去，为了帮助客户增加预算，我们曾添加一个集成功能模块，目的是帮助客户公司的其他部门轻松访问物流数据，从而从其他部门获得了50万元的预算，最终以紧张的预算完成了这个项目。

了解团队成员

如果你成为这类项目的一员，我想说“恭喜你”，你选择了一条充满挑战的道路，你不会满足于敷衍工作，会忍不住关心项目的范围、成本和进度。由于这些特点，团队中的每个人必须有统一的认识。虽然我们可以继续推广敏捷和协作的团队文化，但必须严格管理一些变化。特别要注意的是，我们的重点必须放在满足客户需求的最小功能上。我们应该对原始需求的故事卡进行基本估算。对于业务分析师和开发人员来说，确保变更后的需求不超过最初估算的工作量至关重要。当然，我们会遇到一些偶然事件，所以要始终保持谨慎，尤其是在项目早期。团队成员需要清楚了解这些变化是增加还是减少了工作量。此外，需要强调的是，任何超出原始需求的工作都应由客户记录并签字。当然，这并不是说我们要教条地对待客户需求范围，绝不妥协。如果工作量不大，为了维护客户关系，我们的离岸团队也可以自行消化。例如，在一个300万美元的项目中，坚决拒绝额外三天的工作量是不明智的。如果客户打算为新增需求增加预算（强烈推荐），我们可以考虑同意，或者使用一些策略争取更多预算。

除了原始需求范围之外，我们还应该考虑为客户带来更多价值的功能，并始终牢记这一点。特别是对于小型项目，这一点尤为重要。通过不断为客户创造价值，我们不仅可以提高客户满意度，还能为项目的成功交付和公司的长期发展奠定坚实的基础。

总之，无论是按人天计费的项目还是固定报价项目，以客户为导向，合理管理项目的各个方面，关注团队成员的状态和能力，都是确保项目成功交付的关键因素。我们需要在实践中不断总结经验，灵活运用各种方法和策略，以应对不断变化的项目环境和客户需求。

以客户为导向的离岸团队项目管理策略

项目管理中的决策与应对策略

在项目管理过程中，我们会面临各种复杂的情况和决策，尤其是在应对情绪波动、客户需求变化以及项目交付压力时。以下是一些关键的决策和应对策略：

• 情绪管理与决策 ：当我们情绪不稳定时，做出的决策可能比较激进。此时，我们可以采取一系列措施来稳定情绪并做出更合理的决策。例如，加强沟通，明确责任人，避免“冤案”；暂时搁置让我们纠结的事情，待冷静后再处理；将手头工作转移给他人；遇到客户错误时，保持冷静，避免成为替罪羊。

• 应对客户需求变化 ：客户需求的变化是项目中常见的情况。我们要区分变化和不变的中间线，接受变化的同时，区分不必要的变化，帮助客户避免为不必要的事情付费。不断问自己是否为客户创造了价值，以此作为决策的依据。

• 项目交付与妥协 ：与客户合作时，妥协是常见的，但要有回到正轨的路线图。例如，为了提高开发速度而减少测试覆盖范围，产生的“技术债务”要尽快填补。在项目交付可能延迟时，我们可以增加人力或说服客户增加预算，采用股票市场的策略来平衡项目交付和客户满意度。

不同类型项目的特点与管理要点

按人天计费的项目和固定报价项目各有特点，管理要点也有所不同。

按人天计费的项目

这类项目中，客户根据团队成员的工作时长付费，中国多数海外外包项目采用此方式。客户承担更多风险和压力，但对需求有更强的控制权，适用于对用户体验要求高的项目。离岸团队在这类项目中要关注进度，开发人员在技术栈选择上有一定自主权，但要勇敢面对挑战，展示专业能力。

项目特点	详情
客户控制权	对需求范围和优先级可随时灵活调整
适用项目	对用户体验要求高的项目
团队关注点	进度和开发速度

固定报价项目

固定报价项目的合同包含相对固定的需求和交付日期，客户倾向于签订此类合同以转嫁部分风险，离岸团队承担更大压力。开发这类项目需关注多个因素，包括工作量和价格估算、项目管理等。

• 工作量和价格估算 ：要尽快完成估算过程，考虑不确定性和风险，估算三个结果（最小值、最可能值、最大值）。同时，要特别注意不确定需求、非功能需求、验收标准、需求故事列表、项目启动、估算审核、架构和技术、管理依赖关系等因素。

估算结果	数值
估计最小人天	203
最可能人天	283
预期最大人天	477

以下是固定报价项目估算的关键步骤列表：
1. 确定需求范围
2. 估算工作量（最小、最可能、最大）
3. 考虑缓冲和溢价
4. 审核估算结果
5. 完成估算

• 固定报价项目的管理 ：需要一个工具来管理项目成本，实时监控是否超预算。在项目实施中，若交付可能延迟，可增加人力或说服客户增加预算。

团队协作与价值创造

在项目中，团队协作至关重要。离岸团队与本地团队要像一个团队一样工作，但也要维护自己公司的利益。同时，要关注团队成员的状态和能力，确保团队成员对项目有统一的认识。

• 结对编程 ：判断结对编程是否必要，要看它是否有额外价值，能否促进知识分享。

• 为客户创造价值 ：除了满足原始需求，还要考虑为客户带来更多价值的功能，尤其是小型项目。不断问自己是否为客户创造了价值，有助于做出更合理的决策。

总结与展望

项目管理是一个复杂的过程，涉及情绪管理、客户需求应对、不同类型项目的管理以及团队协作等多个方面。我们要以客户为导向，合理管理项目的各个环节，关注团队成员的状态和能力，不断为客户创造价值。

在未来的项目管理中，我们需要不断总结经验，灵活运用各种方法和策略，以应对不断变化的项目环境和客户需求。同时，要加强团队协作，提高团队的整体能力，为项目的成功交付和公司的长期发展奠定坚实的基础。

以下是项目管理关键要点的 mermaid 流程图：

graph LR
    A[项目启动] --> B[需求确定]
    B --> C[工作量估算]
    C --> D[项目管理]
    D --> E[团队协作]
    E --> F[客户价值创造]
    F --> G[项目交付]

通过以上的分析和总结，我们可以更好地理解项目管理的要点和策略，为实际项目的开展提供有力的支持。