成功交付离岸项目的三个步骤_最新动态_新闻资讯_程序员俱乐部

　　英文原文：Three Steps to Success in Delivering Your Offshore Project

　　当你思考外包项目的一个或多个因素时，你最担心的是什么？错过截止日期？交付质量太差？项目范围不准确或是不完整？风险变高？还是这些都担心？

　　你很可能会说：“这些都担心。”不过你知道吗？远程团队担心同样的问题。当你要与和你彼此分离的团队一起工作时，所有人都担心地理位置的区隔会带来问题。虽然没有必然的成功之路，但是，在在项目规划阶段一起工作，同时意识到你们有同样的担心，这对提升成功几率很有帮助。这也是我在这篇文章中想要说明的，本文属于外包主题的系列文章，之前该系列文章包括：

• 一起工作，分开就座（Working Together, Sitting Apart）
• 外包团队如何选对人？（How to Select the Right People ）

　　服务提供商和项目经理首先要认识到一点：你们都是一边儿的。很多远程的关系都建立在不互信的基础上，特别是如果我们处理与采购方或者供应商之间的关系，而不是同一组织中不同部门之间的关系。在最根本的层面上，所有人都希望项目成功，也都需要一种协作的方法开展项目，使得大家能够一起顺畅工作，最后成功交付项目。

　　协作需要从项目规划阶段开始。在最基本的层面上，项目规划是很直接的：工作拆分成多个不同任务，要找到它们之间的关系，度量它们，然后为它们分配资源。然而，当工作外包之后，有很多需要考虑的地方，这些点会让规划变得相当复杂：

• 外包的工作是否得到完全理解？如果某项工作要给到外部团队（无论是组织内部还是外部），必然就会有学习曲线，远程团队需要理解项目，理解别人对他们的期望值等等。项目经理及其核心团队（代表项目功能的关键团队成员）需要理解远程团队的责任边界。如果工作是外包出去的，这就会变得更加负责，因为核心团队中缺少专业知识，可能不知道哪些能做，哪些不能做。
• 跟踪进度的难度如何？如果项目使用敏捷方法，或者工作本身就有中间阶段交付物，那么风险就没那么高；如果工作只包括单一的可交付物，在外包任务结束时交付，那么风险就大多了。如果没有明显的中间阶段里程碑，每个参与者就更难以确定工作没有偏离轨道。
• 将外包工作与项目其余可交付物整合的难度如何？如果外包工作是一项单独的组件，那就不必过分担心。但要是必须与项目其他部分集成，那么规划中不仅要考虑完成外包工作的时间，还要留出学习曲线、调整等工作的时间，比如两个不同元素之间的整合。

　　让我们分别详细考虑这些内容，然后思考它们如何影响项目规划，以及你可以做些什么，确保在与远程团队一起工作时，这些元素能够得到正确处理。

　　理解工作

　　这是包含远程或者外包工作的项目面对的最大挑战。很多时候，很难马上发现缺少理解，甚至存在误解。我见过很多情况，厂商和采购方都觉得存在共同理解，但后来却发现交付的成果与期望值天差地别。发生这种情况，有很多原因。在本节中，我们将会重点讨论如何为这样的情况做规划，让我们来看看。

　　步骤1：规划时间，促进大家共同理解要做的工作

　　规划出时间，促进大家共同理解要做的工作。这件事情从一开始就要启动，甚至要早于签署合同或是分配团队之前。很多组织的错误在于：他们在定义需求时，会从特定交付物的角度，思考自己需要什么，比如：功能特性、颜色、设计元素等等。实际上，你应该聚焦于从如下两方面定义业务需求：

• 待开发解决方案的整体目标：要用它做什么，如何使用，它如何带来相关好处等等。
• 解决方案如何配合组织的整体目标：你们所处的行业，收入模型等等。

　　这些领域中，你的项目和采购团队应该有足够的专业知识，这也能为厂商提供最有意义的信息。虽然这些信息也许无法进入项目规划中，不可能成为某项特定的工作，但却是制定成功项目规划的关键。

　　这些讨论应该扩展，覆盖到外包中即将用到的模式、每个团队即将完成的工作等等方面；当大家彼此理解谁（在整体上）负责哪些工作、如何管理等方面的时候，整个关系就建立起来了。很多时候，你的组织会有自己的项目经理，而且几乎完全控制整体上的产品关系，即便厂商要完成最多的交付工作。当然，所有这些规划都要花时间，而且这些时间应该反映在项目前期规划中。

　　有了清晰记录而且内部彼此认可的业务需求之后，下面的事情就更容易了：

• 工作拆分、厂商与客户所有权切分、估算、资源分配。项目的不同角色之间将会有更明确的边界，每个团队都能制定自己的规划，以满足业务需求，这就可以避免“谁负责什么”这件事情上的不确定性。项目经理将会保留最终责任权，以确保项目规划中包含了所有需要的工作，但是不同领域的相关专家要提供细节。当不同团队成员在项目规划阶段共同工作时，这种方法也能帮助大家彼此了解。
• 验证工作——根据具体场景不同，“如何”测试和验证工作可能还很难确定，但成功包含“哪些”因素却更容易理解了，因为事先已经在业务需求中定义出来。这有助于判断一个解决方案是否存在问题，避免彼此不同的意见，也就是常见的“你不会得到你需要的，你只会得到你要求的”情形。在规划阶段，只要对于最终完整的解决方案应该满足哪些条件达成一致，就能避免潜在的问题；这样的情形，我见得很多。

　　这种方法常常有一种结果：项目经理面对的交付日程，与此前设定的项目日程有冲突。很多时候，这会导致厂商压力十足，从而用更少时间交付，但是工作却没有完成！虽然项目日程和最终截止日期确实很重要，但是要知道：有些信息可能会覆盖现有的工作估算，这些信息来自某个领域的专家，然而某个团队却不知道这些信息，这样做的后果，最好的情况是出现一些问题，最糟糕的结果是导致一场灾难！

　　跟踪进度

　　对于外包工作，组织还常常担心无法了解工作进展情况。因此，很多客户常常对基于敏捷的方法很热衷，他们强迫厂商定期提供中间交付物。然而，这种做法不是总可以发挥作用，总会存在一些情况，除非工作完成，否则不会有可交付物，特别是要交付的与业务而不是技术相关的时候。举个例子，我曾与一个销售团队共事，他们外包了制定全新销售薪酬模型的工作，后来看到这样的情况：因为不同元素之间存在依赖关系，只有模型完全定义结束，他们才能看到成果。这不是说工作因此无法跟踪。然而，一句俄国老话用在这里很合适：“doveryai, no proveryai”，翻成中文大概的意思是：“相信，但还是要验证”。

　　步骤2：确保进度跟踪合适而且客观

　　完成工作的小组，无论是内部的远程部门，还是外部厂商，都应该得到信任。如果双方的关系没有信任作为基础，就会在人和人际关系上耗费太多精力，工作上的精力就不够了。然而，信任不应该导致无视真相，应该试图验证一切进展顺利，需要做的，就是将这方面的工作放到项目规划中。

　　规划应该包括定期检查点，要双方明确同意期望得到什么：这些检查点的成果要能表现出项目的进展。成果可能不是实实在在的可交付物，但它们仍然可以是“真实的”。在销售的例子中，我们让厂商展示不同的元素，这些元素是他们打算放到薪酬模型之中的，还有正在制定的不同角色和职级、影响提成的变量等等。分开来看，这些东西毫无意义，但是它们表明一切正在向最终目标行进，更重要的是：它们是客观的度量方法，而不是主观判断。

　　存在某种倾向认为：比起验证外部厂商的工作，验证同一组织内部远程团队的工作更容易；事实并非常常如此。如果是内部部门，参与工作的人可能更清楚如何“逃避责任”，如果他们想这么做的话；所以在我看来，不管远程团队来自内部还是外部资源，我的验证总是一视同仁。

　　除了在周会上提供定期的进度更新外，在协作工具中分享，项目主管之间的“必要”谈话，这些都有必要。对于项目经理不太能够了解的工作，我总是要确保他们安排更多时间，以进行正式的工作任务评审。形式上，可能是在某些项目关键点的某种结构化讨论，对于项目通过某个关卡、达成中间阶段里程碑的相关工作任务，所有利益干系人都要评审与其相关的“检查列表”。其中可能包括中间阶段交付物交接，但也可能仅仅是展示已经完成的数据模型、设计确认等。这些检查点应该视为确认厂商的工作在按进度进行，如果可能，还要跟付款日程绑在一起。如果有必要，它们也可以用来发现和批准纠正不当行为的机会。此时，就要考虑“相信，但还是要验证”：如果多方之间没有信任关系，那么可能会隐藏问题（或者假定已经隐藏了问题），将来也就不在有机会就某种实际的纠正计划达成一致意见，即便这样的计划能够帮助确保项目成功。

　　即便存在信任关系，大家仍然有可能对当前情况有不同理解。厂商可能觉得延迟两天没问题，但客户却有可能觉得这会导致严重问题。因此，我总是要确保：这些规划好的评审中，要记录成功条件，同时大家要达成一致。成功条件可能包括任何东西，从签署一份文档，到完成某些模块的工作。我甚至见过这样的成功条件：雇人完成工作和文档交付相关的度量数据。关键在于：大家在项目开始时就认可各个里程碑上成功的意义，这样在评审中就不会参杂主观的谈判。这样一来，大家都可以同意延迟的时间长短、超出成本高低等等。这些就会在每个里程碑评审触发相应纠正措施。因此，评审本身就会成为一种对比，对比规划中应创造的价值和相应的真实情况。

　　安排这些评审时，项目经理应该确保评审频度，避免问题失去控制，但也要留出足够时间，确保工作能够推进。而且，评审不能开始得太早，要在工作真正有可以评审的实际产出时再进行，但也不能太晚，要能有余地提供时间来恢复正常和纠正问题。

　　整合工作

　　很多项目中，为整合工作的安排的时间总是不够。在日程充满压力的项目中，将多个项目元素整合为一个整体解决方案，这样的工作总是到后期才能进行，而项目经理常常为了“节省”时间，压缩整合工作的时间。这样做很少有效，当加入外包因素时，结果往往是一场灾难。应该指出：整合不仅仅是技术层面，可能是要将技术整合到业务运营之中，其中的复杂度相当可观。

　　规划成功的整合

　　项目一开始，就要针对整合做规划，要准备好整合可能很困难，需要不同组件、不同来源做出调整，才有可能整合到一起。如果没有中间交付物，保证整合执行顺利就变得更加重要了。这个项目阶段没有发现的问题，将会进入最后的发布版本，也就是说：最终用户将会发现问题。我此前提到的销售薪酬模型项目中，组织高层和厂商要到其他国家出差，向员工给介绍模型，3 个月后还要回访，回答问题，缓解担心，这种整合确实很花钱，但是有助于事情顺利推进。对于你的项目来说，这种做法可能小题大做了，但是你也要考虑：当所有不同项目元素形成一个完整的解决方案时，可能出现哪些问题，最后，还是你自己的组织要直接提供支持、面对问题。

　　从规划的角度，如果某些工作外包了，当开发工作还在进行时，我就会开始整合活动。至少，团队可以进一步了解整合将如何进行，这有助于帮助他们发现潜在问题。这种方法也会将学习曲线前移到项目早期阶段，避免在整合开始时的快速学习过程，进一步降低犯错几率。

　　为了进一步确保整合成为项目开发工作中的自然延伸，我还要保证整合规划是早期工作的自然延伸。整合规划不应该与其他正在进行中的工作隔离开，为需求、设计等工作制定的文档和工件，应该自然地进入到整合规划活动中。

　　结论

　　那么，把这些放到一起，我们会得到什么？在当今的经济环境中，组织想方设法要将更多精力放在核心专业领域上，而技术的变化越来越快，交付项目需要的专业职能必将越来越多。这就意味着：无论是内部还是外部，使用远程团队的项目将会不断增加，因为组织要寻找专业职能。如果组织没有认识到这些项目的管理与过去不同，他们将会注定失败。

　　组织需要认识到：使用外包工作者，能够大幅提升自身的成功可能，但项目必须管理恰当，要认识到这些项目与其发起地不同，在发起地，所有资源都存在同一个地点。没有什么银弹解决方案，但是用上一些时间和精力，把这个简单的三部曲结构化，就能在未来帮你避免落入陷阱。

　　关于作者

　　Andy Jordan 是 Roffensian Consulting Inc.，的总裁，该公司位于加拿大的安大略省，是一家管理咨询公司，长于组织转变、资产管理和 PMO 相关事宜。在欧洲和北美，Andy 曾经成功管理众多重要业务项目、项目群和资产组合，涉及行业众多，包括：投资银行、软件开发、呼叫中心、电信和企业教育等。Andy 还常常根据需要准备演讲和主持，他能够以引人注目和风趣的风格，讲述发人深省的内容；同时，他也是项目管理相关课程的指导者。他总是努力提供引人深思的演讲，帮助自己的观众挑战常规，同时还能落实到行动上，可以在现实世界中推进。Andy 的第一本书《Risk Management for Project Driven Organizations》现在已经可以购买。