写点什么

成功交付离岸项目的三个步骤

  • 2015-01-05
  • 本文字数:4967 字

    阅读完需:约 16 分钟

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

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

  • 一起工作,分开就座
  • 外包团队如何选对人?

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

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

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

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

理解工作

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

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

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

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

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

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

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

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

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

跟踪进度

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

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

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

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

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

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

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

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

整合工作

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

规划成功的整合

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

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

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

结论

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

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

关于作者

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

查看英文原文: Three Steps to Success in Delivering Your Offshore Project

2015-01-05 02:118190
用户头像

发布了 479 篇内容, 共 157.3 次阅读, 收获喜欢 49 次。

关注

评论

发布
暂无评论
发现更多内容

曾国藩家书嘉言钞(六)

熊小北同学

曾国藩 曾国藩家书 嘉言钞

远程办公钉钉使用体验

冯夷

钉钉

本地开发环境搭建利器--vagrant

aoho

DevOps 运维 vagrant

从高盛的技术“开源”看金融业软件发展未来

FinClip

open-source 金融科技 数字化生态

高性能交易系统设计原理

廖雪峰

架构

读 Guide to Java String Pool

shengjk1

Java string pool

Filebeat + Kafka + Elasticsearch + Kibana 实现日志收集与管理

AlwaysBeta

大数据 kafka elasticsearch elastic 数据分析

OKR实践中的痛点(2):对不qi,对不qi

大叔杨

OKR Scrum 敏捷 敏捷开发

如何写作一本书(1):写前须知

英子编辑

技术 写作 读书

告诉你一个学习编程的诀窍(建议收藏)

ithuangqing

学习 编程 自学编程

spring-cloud-stream 集成 rocketmq

再见孙悟空

RocketMQ Spring Cloud

程序员不可不知的:2020年测试六大趋势

禅道项目管理

人工智能 开源 DevOps 敏捷开发 测试

100字:对数时间复杂度

韩小非

算法 时间复杂度

SpringBoot+Mybatis Plus多租户动态数据源

zane

数据库 Spring Cloud mybatis

招聘小思考

水色

ANTLR 入门(二)

zane

编程语言 ANTLR

字节码编程,Javassist篇一《基于javassist的第一个案例helloworld》

小傅哥

Java 字节码编程 字节码插桩 小傅哥

一个平凡者的阅读故事

卷尚

程序员到底应该学习什么语言好?

页面仔小杨

变革之路的思考

龙眼果

Laravel 7 新特性 - 流畅的字符串操作

Middleware

php laravel string

《代码整洁之道》原则整理

insight

编程

讲一个程序员如何副业月赚三万的真实故事

非著名程序员

程序员 副业 副业赚钱 提升认知

Ruoyi Vue前后端分离版本添加UReport设计器

赵欣

Vue Ruoyi uReport

从少儿编程讲讲开发行业的大趋势

kimmking

在线教育 少儿编程

ANTLR入门(一)

zane

编程语言 ANTLR

字节码编程,Javassist篇二《定义属性以及创建方法时多种入参和出参类型的使用》

小傅哥

Java 字节码编程 字节码插桩 小傅哥

彻底明白如何设计一个良好的 API

Yezhiwei

JDK源码分析之 ArrayList

Wh1

源码分析

DDD 实践手册(1.Get Started)

Joshua

领域驱动设计 DDD 系统架构 架构模式

翻译: Effective Go (3)

申屠鹏会

翻译 gol

成功交付离岸项目的三个步骤_文化 & 方法_Andy Jordan_InfoQ精选文章