Download PDF version of this article PDF

外包:制定行动计划

哪些类型的项目适合外包?

Adam Kolawa,Parasoft

您的首席信息官刚刚召唤您履行职责,将关于是否将明年重写内部计费系统的大型开发项目外包的决策权交给了您。 这真是一项艰巨的任务! 您究竟该如何开始决定外包是否是贵公司的正确选择?

您可以遵循一些策略,以帮助您避免外包的陷阱并做出明智的决策。 外包不仅仅是一个技术问题,但它是一个架构师或开发经理通常最有资格做出的决定,因为他们最清楚哪些技术适合保留在内部。 决定哪些应该外包,哪些不应该外包是成功行动计划的关键。

在我们深入探讨策略和陷阱之前,先介绍一些关于外包的背景知识。 外包有两种类型:在岸外包是指在公司外部但在同一国家/地区内获得服务; 离岸外包是指不仅在公司外部而且在国家/地区外部获得服务。

当然,关于离岸外包的炒作比在岸外包更多。 在美国,争论的焦点是“离岸”对外包经济产生了负面影响。 为什么软件行业转向外包——包括离岸和在岸? 许多人认为,软件行业是一个不成熟的行业,正在经历任何成熟行业都已经经历过的成长阵痛。 例如,汽车行业在 20 世纪 60 年代正在经历与软件行业在 21 世纪 00 年代正在经历的完全相同的事情:学习如何专业化和碎片化以降低成本、提高质量和加快生产。

这种增长需要时间。 这就是外包的神话所在。 它通常被视为并实施为短期的省钱策略,但实际上它应该是长期战略的一部分,而不是节省少量资金的权宜之计。

后果和益处

最近一项关于软件行业外包的研究中,一些发现强化了外包的直接后果对美国经济具有负面影响。 然而,从长远来看,我们实际上看到外包对美国企业、就业率和经济具有积极影响。 该研究由 Global Insight 代表美国信息技术协会 (ITAA) 进行,ITAA 是一个由 375 家企业成员(包括微软和 IBM)组成的团体。 ITAA 发布了一份关于该研究的报告,该报告基于 Global Insight 首席经济学家 Nariman Behravesh 博士及其研究团队进行的调查和预测(离岸 IT 软件和服务外包对美国经济和 IT 行业的影响;http://www.itaa.org/itserv/docs/execsumm.pdf)。

最终,对您而言重要的是实施一个成功的项目并为贵公司的成功做出贡献。 外包对您来说是一个明智之举吗? 这绝对不是您想要盲目进行的策略。 从您开始考虑外包的那一刻到您的项目完成并交付的那一刻,都需要进行分析和制定策略。

有效外包策略的关键要素

如果您不正确地进行和实施外包,其影响将非常糟糕——不仅会危及您的职位,还会危及您同事的工作。 这些都是极端的后果。 然而,当外包项目失败时,贵公司内部的人员最终会做外包商未能正确完成甚至根本没有完成的工作。 失败的外包项目的其他后果包括项目成本和生产时间的增加——这正是您不希望实现的目标。 失败的外包项目会造成不必要的混乱,并且对公司没有任何好处。 为了启动一个成功的外包项目,以下是一些您可以考虑的策略

• 确定贵公司的主要重点。 您可以将任何对该重点无关紧要的事情外包。

• 分析,重点关注质量和产量的提高。

• 将您和您的团队的努力集中在公司的重点上。

• 与专业供应商建立并保持长期合作关系。

• 通过更高的质量提高生产力并降低成本。

让我们仔细看看这些领域以及它们带来的挑战。

确定公司重点

您应该采取的首要行动是确定贵公司的主要重点。 业务的核心到底是什么? 您可以通过回答以下问题来弄清楚

• 公司的竞争优势是什么?

• 公司真正的业务目的是什么?

• 公司试图完成什么?

确定重点非常重要,因为您希望将您和您的团队的精力集中在与公司主要重点相关的任何项目以及以任何方式为该重点做出贡献的项目上。 您甚至应该考虑外包的唯一项目应该与公司的主要重点无关(当然,还要确保您对公司重点的看法与高层管理人员的看法一致!)。

挑战

在确定重点时,可能会有很多干扰以及政治因素。 人们会提出各种各样的理由来解释为什么他们的项目应该或不应该外包。 我的建议是超越个别项目经理的利益,他们通常分为两类:(1)想要保留项目的人;以及(2)想要摆脱项目的人。 困难在于试图看穿项目经理所说的话,了解他们为什么这么说。

有些项目经理永远不会放手项目。 他们的理由通常是基于恐惧。 他们想保持他们建立的帝国。 也许他们害怕失去他们的影响力。 有些项目经理可能会为了保护他们的员工而坚持不放手,而另一些项目经理可能会试图保护自己的职业生涯。

然后是硬币的另一面。 一些知道他们的项目处于危险之中的项目经理可能会试图摆脱它们,以免危及他们的职业生涯。 他们可能还想摆脱无趣的项目、有问题的项目、他们不知道如何解决的项目等等。 相反,他们宁愿将其变成别人的问题。 注意这一点。 事实上,项目经理可能想要外包一个可能对公司未来成功至关重要的热门项目——仅仅因为经理不知道如何做。

分析您的公司

在您弄清楚您的公司真正从事的业务之后,重要的是评估和分析您正在考虑外包的任何项目的生产情况。 为了确定外包是否是最可行的选择,您需要回答以下问题

• 我真的需要自己构建这个部件吗?

• 我可以找别人更有效地为我构建它吗?

挑战

批判性地审视您公司的资源非常重要。 如果您问工程师他们是否可以构建某个部件,他们总是回答是。 我们工程师就是这样。 更好的问题是,“为什么这个部件对我的业务至关重要?” 换句话说,“我们是否有足够的内部见解和专业知识,比其他人更有效地完成这项工作?”

假设您可以在公司内部找到一个团队来构建该部件。 接下来,您找出成本和截止日期。 您发现这个团队可以高效地构建该部件。 如果是这样,您需要 выяснить 该项目现在是否对您的业务至关重要。 如果现在不重要,那么这个部件以后对业务至关重要肯定有原因。 否则,就没有理由在内部完成它。 使用别人的知识来构建它可能比使用内部资源更有优势。

当然,如果您决定走出公司围墙,请务必小心。 外包商不会告诉您他们会做粗制滥造的工作。 做您的功课, выяснить 他们是否真的有构建该部件的知识。

专业化

考虑到贵公司的重点,您可以真正开始集中您团队的精力。 您希望您的团队成员将他们的时间集中在提高业务专业性上。 这样做会增加您团队的价值以及他们对企业主要知识产权的贡献。

任何对您的业务重点不重要的项目,如果外包,都可能降低成本并提高产量。 让那些专注于该领域的专业人员为您集中精力——将您的精力集中在您擅长的领域。 您最终可能会得到比您自己生产的质量更高的部件,而且时间更少。 结果,您的团队将有更多时间专注于提高您保留在内部的工作的质量和生产力。

不要被“潜在的”成本节约所诱惑,尤其是在您谈论的部件是核心竞争力的情况下。 不幸的是,大多数外包项目仅仅因为价格标签而发生,而没有进一步的分析。

通常,当经理不确定如何提高生产力时,他们会关注价格。 不要仅仅因为价格合适就伸手抓住某样东西。 价格可能只是唯一合适的东西。

挑战

人们害怕专业化,因为它会缩小技能范围。 它可以让您变得更有价值,但如果您的领域消失了,那么您就变得毫无用处。 许多人潜意识里感觉到了这一点——尤其是架构师和开发人员。 他们害怕被锁定在狭窄的专业领域,因为他们知道总有一天很难找到工作或扩展他们的职业生涯。

这是一个棘手的问题,没有灵丹妙药。 说服您的团队专业化对他们的职业生涯有好处并不容易。 然而,成为一个成功的开发团队和一个成功的公司的一份子对每个人都有好处,而专业化可能是长期成功的关键部分。

建立和维护关系

如果您确定外包您的项目是一个明智之举,并且将使您的公司受益,那么您面临的下一个挑战是建立和维护良好、长期的业务关系。 更具体地说,一旦您了解了贵公司的重点,并确定了您的团队应该和不应该集中精力做什么,那么您的下一步行动就是找到合适的外包商,一个您可以与之建立持久健康的合作联盟的分包商。 这至关重要。 没有它,您的外包项目就不会成功。

在搜索期间考虑以下要点

• 人际关系。 让分包商在隔壁,以便您可以在团队成员之间建立牢固的关系,这是否有益?

• 地理位置。 地理位置重要吗? 地理位置是您需要考虑的事情吗?

• 文化。 如果地理位置不重要,那么文化呢? 保持在同一文化中是否重要,或者您可以走出文化之外?

当然,最重要的要求之一是质量。 如果您从本文中什么也没记住,请记住这一点:当您与一家专注于您需要的但对您公司的重点无关紧要的部件的公司建立健康的合作关系时,您可以大大提高最终项目的质量。 因为您和您的外包合作伙伴都将更多的时间集中在各自的专业领域,所以质量会提高。

然后,当然还有价格——一个重要的决策点,尽管显然不是唯一的决策点。 如果您完全根据价格做出决定,但没有获得您想要的结果,那么最低价格可能会变成最高价格:如果您的团队(或公司中的任何其他人)必须在外包商交付代码后重写代码,那么您就失败了。

挑战

人们常常害怕预先与他们的外包合作伙伴设定严格的指导方针。 他们担心这不好,或者认为这是具有侵入性或攻击性的。 这种想法可能会使合作伙伴关系走向失败。 良好的关系是艰难的关系。 在良好的关系中,每个人都会从中得到一些东西。 如果它在一个方向上过于偏颇,或者基于一方无法就时间、成本和要求提出棘手的问题,那么合作伙伴关系将会破裂。 例如,如果您认为您签署了一份对您非常有利的合同,您可以相信这种关系不会持续很长时间——当外包团队 выяснить 这一点时,他们可能不愿意为您付出额外的努力。 真正的关系意味着双方共同做一些事情,每个人都受益。

提高生产力并降低成本

现在,我们终于谈到了成本。 我们软件行业的第一个谬论是,降低生产成本的唯一方法是雇用更便宜的劳动力。 这种想法是短视的。 目前,我们可以绕世界各地去获得更便宜的劳动力。 我们可以去印度、中国,很快就会去非洲,然后我们将去哪里?

没有人知道我们需要多长时间才能完成这个周期。 可能需要 30 年。 最终,它会回到原点。 最终,最重要和需要改变的是生产力的提高。

提高生产力的主要困难之一是开发人员花费了他们大部分时间——80% 的时间——寻找和修复错误。 虽然这个问题肯定不会很快消失,但每个人都同意,如果我们能够预防错误,那么我们就可以提高生产力,从而降低成本。

挑战

当涉及到实施减少错误的方法时,信念因素是一个大问题。 在他们真正看到错误减少之前,没有人真正相信生产力会提高。 为了说服您的团队需要预防错误,而不是稍后修复错误,请考虑召集您最好的开发人员来实施商定的方法。 如果您可以展示(甚至记录)预先减少错误意味着从长远来看可以减少编码时间(并且您必须将所有构建后错误修复都纳入您的分析),您可能会在您的团队中看到许多赞同的微笑。

克服挑战和障碍

因此,既然您有机会使用五个关键策略来考虑外包项目,那么接下来会发生什么? 即使是计划最好的外包项目也注定会面临挑战。 如果您的外包商掉链子,再好的行动计划也可能会受挫。 在您完成计划并开始您的外包项目后,请务必牢记以下所有常见的外包陷阱。

外包商没有在您的代码上工作。 外包开发人员过度预订项目并不罕见,任何承包商都会这样做。 当外包开发人员这样做时,他们最终会争先恐后地赶上进度,并最终无法按时交付代码。 如果未按时交付代码的原因不是过度预订,则可能是外包商闲置时间过长或工作节奏过慢。

外包商不理解您想要什么。 换句话说,外包开发人员不理解您的需求。 他们说他们理解,但他们不理解。 最终,他们认为他们为您做得很好,但他们实际上所做的是编写了一些您不想要的东西。

外包商编写的代码不符合您的标准。 此问题的后果是您最终得到的代码存在错误、不灵活且不易与您已有的代码集成。

一旦您的外包项目开始进行,这些问题中的每一个都可能向下蔓延并导致国内出现问题——如果您的首席信息官要保持冷静,您需要快速解决这些症状。

最后的想法

当您制定外包行动计划时,有很多要素需要考虑并纳入您自己的情景中。 首先,考虑后果和益处; 考虑那些对您的组织至关重要的代码领域以及那些可以轻松移交的领域。 接下来,与您的外包合作伙伴建立牢固的关系,并确保外包商和外包方之间的沟通渠道畅通——双向畅通。 最后,采取预防措施以确保外包问题甚至无法开始恶化。 问

喜欢它,讨厌它? 让我们知道

[email protected] 或 www.acmqueue.com/forums

亚当·科拉瓦[email protected],是 Parasoft 的董事长兼首席执行官,他于 1987 年与一群加州理工学院的研究生共同创立了该公司。 他是一位著名的行业问题作家和演讲者,并于 2001 年荣获洛杉矶安永年度软件企业家奖。 他拥有理论物理学博士学位。

© 2004 1542-7730/04/1100 $5.00

acmqueue

最初发表于 Queue vol. 2, no. 8
数字图书馆 中评论本文





更多相关文章

Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - 在线事件处理
跨异构存储技术对分布式事务的支持要么不存在,要么遭受较差的操作和性能特性。 相比之下,OLEP 越来越多地用于在此类设置中提供良好的性能和强大的 一致性保证。 在数据系统中,日志非常普遍地用作内部实现细节。 OLEP 方法有所不同:它使用事件日志而不是事务作为数据管理的主要应用程序编程模型。 传统数据库仍然使用,但它们的写入来自日志,而不是直接来自应用程序。 使用 OLEP 不仅仅是开发人员的实用主义,而是它提供了许多优势。


Andrew Leung, Andrew Spyker, Tim Bozarth - Titus:将容器引入 Netflix 云
我们相信我们的方法使 Netflix 能够快速采用容器并从中受益。 尽管细节可能是 Netflix 特有的,但通过与现有基础设施集成并与合适的早期采用者合作来提供低摩擦容器采用的方法,对于任何希望采用容器的组织来说都可能是一个成功的策略。


Marius Eriksen - 大规模函数式编程
现代服务器软件的开发和运营要求很高:它必须始终在所有位置可用; 它必须在毫秒内回复用户请求; 它必须快速响应容量需求; 它必须处理大量数据和更多流量; 它必须快速适应不断变化的产品需求; 在许多情况下,它必须容纳一个大型工程组织,其众多工程师就像一个又大又脏的厨房里众多的厨师。


Caitie McCaffrey - 分布式系统的验证
莱斯利·兰波特 (Leslie Lamport) 因其在分布式系统方面的开创性工作而闻名,他曾说过一句名言:“分布式系统是指即使您不知道存在的计算机发生故障也可能导致您自己的计算机无法使用的系统。” 鉴于这种黯淡的前景和大量可能的故障,您甚至如何开始验证和确认您构建的分布式系统正在做正确的事情?





© 保留所有权利。

© . All rights reserved.