深入了解原厂商产品的个性化定制

真正棘手的是易谷网络在投标过程中所引进的管理套件，这是一个无法预计的问题。招标时，客户并没有给出详细的30万字需求说明书，仅仅提供点对点技术应答书。根据点对点要求，易谷网络采用了国外成熟的管理套件，当时并没有过多考虑定制化这些成熟软件会产生的开发费用。然而，等拿到详细的需求书以后，发现客户需求与成熟产品之间有相当大的差异，仅仅靠产品本身的功能根本无法满足要求。风险识别出以后，易谷网络的工程师立即找出其中的差异点，并与原厂商的专业服务团队进行了多次沟通，希望可以通过原厂商提供的开放接口进行定制化开发来满足客户的所有要求。但是沟通后发现，这样的方法仅仅能处理60%的差异化需求。这时还有一个办法，就是要求原厂商修改其产品，尝试后发现这简直是天方夜谭，原厂商修改区的6个汉化问题竟然要花去1个月的时间，如果要求其对成熟产品进行重构，不仅会耗费大量的时间，其要求的开发费用也将是一个天文数字。

为此，易谷网络项目组和客户召开了一次专项会议并达成一致：第一批次先按照产品的既有功能上线，从第二批次开始，易谷网络将利用原厂商提供的接口进行深度定制化，以满足客户的需求。对于通过接口开发也不能支持的功能，易谷网络将为客户重新开发。这是一份沉甸甸的承诺，很有可能让易谷网络既要付出原厂商产品的采购成本，也要对某些产品重新开发。尽管过了眼前这一关，但是成本不可控风险的种子也已经埋下了。

当然，对易谷网络来说，任何增加工作量的承诺都不见得是坏事，对原厂商产品深度定制化的承诺可以加强对原厂商产品的理解，定制过一次以后，再遇到类似的需求就轻车熟路了。如果原厂商产品确实满足不了客户的要求，需要重新开发的话，对易谷网络来说，也是一件好事，这就相当于客户提出需求，开发出产品后，由客户负责测试，等到客户使用以后，又可以获得一个宝贵的客户案例。从充实公司产品线、获得经验、增加案例的角度来看百利而无一害，这就是产品公司的思维。

但是，如果将自己看成是项目公司，其目标是用最小的成本完成客户交付，所有增加工作量的任务都会变成公司的成本。项目经理就必须不停地就开发范围问题和客户进行无休止的争论，最后在双方都极度不满的情况下，费力地推进项目。

如果将自己看成是人力资源外包公司，思考问题的角度又会不一样，目标又变成了用最低的人力成本实现利益的最大化。乙方不仅仅不关心产品的丰富与经验的获取，甚至也根本不关心项目是否成功，其关心只有一条，能否招到更便宜的人力用更高的价格包给客户。(www.xing528.com)

易谷网络是一家“产品＋项目”型的公司，既关注产品的丰富性、经验的获取、案例的增加，又关心交付成本。尽管有时候这是一个两难的选择，但是也必须找到当中的平衡点。后来发现，这个点应该由产品经理与项目经理共同把握，也就是说，必须能够识别出什么是产品，什么是定制化。说起来很简单，客户的共性需求是产品，而个性化需求是定制化。但是，在实际操作中的把握尺度却很有讲究，需要长时间的磨合才能适应。

这也是本书前面的一个观点：客户应该鼓励科技公司开发产品，而不应该仅仅是外包项目，或是外包人力。在项目中很难开发出好的产品，但是好的产品却需要在多个项目中历练。优秀的人才也需要历练，对人才来说，其基本素质很重要，企业应该用合理的待遇去招收高素质人才，给予其历练与培训的机会，不断提高其能力。当然，在这个过程中要动态提供与其能力相匹配的待遇，不然容易造成人力资源的流失。

不可否认，当时的决定也有将问题后置的嫌疑，后期的流程证明，在大型银行中引进成熟的管理产品是不明智的。先不说中外差异，各家大银行的业务流程也往往是独一无二的，流程固化的管理类产品根本无法通用。大型银行的管理类产品适合轻引擎、大中台的开发方式，所谓的轻引擎，是指产品的核心引擎一定要轻量化，要独立于流程又能够被所有流程所调用，这样的引擎一定要完全开放；所谓的大中台，就是将流程管理模块标准化、组件化，以便快速实现业务流程的开发，这一特点是易谷网络在1年后悟到的，当时并没有这么清晰的认识。