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

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 新闻资讯 > 最新动态 > 成功交付离岸项目的三个步骤

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

 2015/1/5 22:32:38    程序员俱乐部  我要评论(0)
  • 摘要:英文原文:ThreeStepstoSuccessinDeliveringYourOffshoreProject当你思考外包项目的一个或多个因素时,你最担心的是什么?错过截止日期?交付质量太差?项目范围不准确或是不完整?风险变高?还是这些都担心?你很可能会说:“这些都担心。”不过你知道吗?远程团队担心同样的问题。当你要与和你彼此分离的团队一起工作时,所有人都担心地理位置的区隔会带来问题。虽然没有必然的成功之路,但是,在在项目规划阶段一起工作,同时意识到你们有同样的担心
  • 标签:成功 项目 步骤
class="topic_img" alt=""/>

  英文原文: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》现在已经可以购买。

发表评论
用户名: 匿名