为什么外包的项目很多坑？

编辑导语：本文阐述系统建设过程中甲乙方的差异与矛盾，以及如何帮助系统更好达成预期目标的措施，适合证券期货公司业务人员/项目人员/信息人员以及系统供应商从业人员阅读，希望对大家有帮助。

在供应商行业工作过并且也接触过大量的友商之后，才知道当初自己做甲方的时候为啥总觉得乙方的产品很差。话说回来，系统建设不好这事儿，真不能全怪乙方。

外包系统建设的流程大致如下，下文把它切分为六个阶段，重点阐述筹备、实施等环节的问题，文末分别针对甲方和乙方给出参考方案。

一、项目筹备阶段

对于证券期货公司来说，大多数项目是因为以前没有需要新立项，少数项目是由于系统的直接用户/领导难以忍受来通的bug或者无法负载需求而立项。

当系统建设需求产生后，一般由IT团队给出系统建设的意见，是自研还是采购。有的时候业务部门会因为需求急迫而希望采购“能直接使用的系统”，排除IT部门给出的自研或者合作研发方案。

我们不去讨论研发模式的选型问题，但是可以发现，不论是自研、采购或者合作研发等模式，都需要在项目推进之前，明确系统需要解决哪些场景的问题。

项目实施后往往会发现，因为前期需求不明确，而导致业务部门与IT自研团队产生的矛盾，与后期和乙方产生的矛盾是惊人的相似。业务部门会觉得自研团队响应很慢（开发速度慢），质量不好（系统有缺陷），功能不好用（需求理解和实现不一致），上线后逐渐就不再使用这个系统了。

尤其是对于新立项的项目，一定要在前期筹备阶段，就要想清楚这个系统用来解决什么需求，哪些需求由其他系统解决，哪些需求还需要澄清或者有其他替代解决方案。以及系统上线后，如何评价系统是否满足符合预期。

这些工作单纯的靠业务部门很难梳理清楚，我接触过大多数公司的业务同事基本都没有全局需求分析能力，更多只能从场景提出问题，所以提出的需求往往有遗漏。

所以IT部门一定要通过邀请不同的供应商来进行业务培训（系统培训）帮助业务团队形成需求概念，然后基于供应商提供的功能清单评估采购计划和简要需求概述，从而帮助业务团队形成项目背景和项目范围的描述。

否则项目验收时候会发现业务代表提了一堆缺陷或者问题，实际上对开发商或者自研团队来说是新需求，导致项目延期。

二、项目招标阶段

金融机构的系统发展到一定阶段必然会趋同，当IT部门邀请3~4家供应商讲解方案之后，基本就会发现几个系统基本一样只有某些环节或者某些功能的差异，究其原因也是因为需求一致，那么最优的解决方案也会趋于一致。

金融机构的业务系统并不存在绝对的竞争壁垒，一个供应商刚发布了新产品，可能两个月后另一个供应商也能够马上推出一款新产品（集中交易系统等这类复杂系统除外）。

对于供应商来说，第一个系统基本来源于定制化的产品，为某家客户提供了定制化的系统之后，再做一定的封装（为了对接异构系统），然后拿到其他客户处销售，然后再基于其他客户的需求在基线版本（标准版本）上进行迭代，产生不同的版本分支。

供应商是典型的企业服务类公司，这类公司的组织结构和收入结构也很清晰，利润=软件销售收入-人力/场地成本。

所以一套系统能卖的客户越多，那么这套系统的边际成本就越低。一个团队能拿收入和回款就有奖金，否则就被撤销。

为了提高人员利用率，供应商经常会安排一个人会参与多个项目的实施，这样导致了为什么给供应商提需求的时候，供应商的脾气器比自研团队的排期要晚的原因，不是供应商的员工刻意扩大工时，而是他们的员工不是专人专用。

此外在定价的过程中，并不是也无法按照一个标准的价格进行报价，往往采用了价格歧视的定价策略，基于客户的收入（证券期货业排名）和议价能力（自研能力）进行报价，这种报价策略会导致客户在评估真实价格的时候受到误导。

最终在报价的时候，由于多家厂商产品同质化竞争，会发现有的厂家会不计成本以低价进行销售，然后在项目后期迭代的时候赚回成本（后期迭代的时候甚至一个接口都会收费），或者在项目实施的时候配置极低的人力资源参与（比如刚毕业一年或者刚入职的员工）。

对于证券期货公司来说，理想的项目价格是通过需求估算其研发成本（或者其他公司的平均成交价）和改造成本，通过（研发成本+改造成本）x系数获得项目预算。而非一味的砍价而导致自己失去供应商优质人力项目资源的配置权。

三、项目实施阶段

系统实施项目最常见的风险是进度风险（是否能完成），其次往往由于赶进度产生了质量风险（验收上线不出问题）。项目进度也即项目计划一般被三个因素影响：项目范围、项目周期、项目人员。

确定供应商后，一般供应商就要进场和业务部门确认需求了。

问题往往在于，如果供应商可以隐瞒系统的缺陷或者体验不好的地方，业务部门是无法在确认阶段识别需求点的。尤其是对于新研发的项目，在没有产品可以体验的情况下，业务部门也难以基于直观感受给出需求反馈。这样往往导致在验收过程中业务部门才提出未实现预期需求的情况。

作为业务部门尽量在前期在IT部门的协助下，产出一份结构相对完善的需求描述，用于供应商评估和框定项目范围。

然后要求供应商基于需求描述产出详细的需求文档或者功能操作演示，由IT部门协助对业务场景、异常场景进行提问和解释整理出详细需求。然后对详细需求进行优先级排序产出研发计划，这个过程也能帮助供应商发现需要系统对接的工作。

要注意的是，业务部门不要抱有我付了钱所以都要做的想法来评估需求范围，而要站在是否为最优解决方案的角度来评估需求是否实现和需求优先级。在有限的项目周期内，良好的需求管理能够为系统对接和测试提供更充裕的时间。

新项目研发的周期一般不超过半年，否则会分1期和2期，已有项目的研发一般2个月左右就要求上线。

上线意味着要在有限的时间内完成系统对接、系统改造、功能测试、性能测试、系统部署等众多工作。

上面提到新系统在没有可以直观体验的产品下，业务部门难以给出需求反馈，即使采取上面描述的解决方案也很难保证业务部门不提出新的需求（需求总是会因为领导意见、流程变更、市场环境等原因而产生变化，所以项目周期不要做太长时间的规划）。

所以在项目规划的时候一定要在“上线后”（达成项目开始的计划后）额外预留1~2个迭代的时间给客户用于需求适配。

目前基本没有系统可以“拿来就用”，而且业务和IT部门也经常会有相关的需求，这就导致了虽然供应商想卖标准的系统，但是每套系统实施都会有产生人力资源投入的情况。

换句话说，系统卖的越多，人力成本就越高。供应商为了降低人力成本，往往一个产品的核心人员只会配置2~3个，负责团队管理和标准化产品设计，实际派出到客户的项目人员以初级员工为主，一般毕业0.5~2年，甚至很多供应商不会配置产品经理或者需求分析师，而是由研发人员或者项目经理兼任，难免在沟通和理解上出现差异。

对于客户来说，如果想保证项目质量或者控制风险，在了解乙方组织结构的情况下，要求他们的骨干人员直接参与项目，并且构建良好的沟通关系是最好的方式。

四、项目运维阶段

在项目研发和项目迭代过程中，会产生很多系统间对接的场景。

这些问题可能不会在项目实施和研发过程中暴露，但是会在项目后期迭代和运维的过程中产生重大影响，系统之间对接的越多，运维的成本接越高，一个系统升级要考虑对周边系统的影响，可能伴随着几套系统一起升级。

如果是面向终端用户的产品，还要考虑多个APP、PC版本共存的情况。

大多数供应商的人员流失率都很高，除了一人身兼多个项目外，也会被专业能力、薪酬福利、出差频率等各种因素影响。这也会给系统的二次开发带来负担，供应商接手的员工可能还没有客户的老员工对项目了解。

综上所述项目启动前，即使是业务部门主导的项目也要邀请IT部门，在需求确认后参与技术方案的评估和讨论，通过统一的技术方案如APP小程序架构、统一接入、微服务等技术基础设施实现系统直接的对接，来降低后期系统运维的成本。

对供应商来说，如果可持续性的完成多版本的迭代尤为重要。

在系统设计之初，就需要产品架构师和技术架构师做好充足的研究分析工作，以业务开发平台为核心理念，切割功能模块的职能，并且暴露好对外的接口。这样不论是大型复杂项目的团队协作，还是业务系统的持续迭代都不至于到后期“推翻重来”。

综上所述，对于证券期货公司而言，业务和IT需要紧密配合，在项目前期需要帮助业务梳理需求并且控制范围，并且确定技术对接方案并且评审技术实现方案。对于核心系统在项目后期参与运维和二次开发，管理供应商人员变更的风险。

对于供应商而言，在启动阶段多进行研究分析，做好领域设计工作。在需求阶段多与业务部门澄清需求，与IT部门确定系统对接模式。在实施阶段预留好需求变更的时间，用于管理客户预期。

 

本文由 @陆子樊 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议