管理沉思录系列(三):你不知道的ODC服务

我们整个公司ODC的业务占了很大的比例，我们分公司做过的大部分的项目都是ODC. 那么是不是我们所有人对ODC项目都有一个正确/恰当的认识呢？我觉得不尽然，所以我想写写我对ODC的认识。一个是让我们公司的工程师知道ODC是什么，另外让客户知道真正的ODC服务是什么(除了销售的介绍，不妨听听正真服务人的想法)，他的优势是什么，如果处理不好，ODC的问题又是什么？

ODC的片面理解？

在公司经常听到以下一些对解释：

ODC就是按月付费

我觉得按月付费只是ODC服务的一种付费形式，他根本不是一种服务。

ODC就是按时间付费

这个也是片面的，1个小时也是时间，一个月也是，一年还是时间。几天的服务算是ODC吗？我认为不是。

ODC是Offshore development center

这个解释也太过“干瘪”，离岸开发中心？ 离岸研发中心？如果这样理解，他就是离岸的一个办公地点而已嘛！

ODC到底是什么？

对我们公司来说，我觉得ODC是一种合作方式，他的产出是一种服务，这个服务可以是如下一些交付物：

• 软件——-交付高质量的软件
• 咨询服务—-企业信息化(软件项目的立项，软件项目的规划, 开发商的评估等等)

而ODC服务要做好的几个主要的部分，我觉得是：

• O (Open): 双方都必须开放，必须透明，只有这样，才能做好互信，才能更好的信息共享。

• D (Development): 这个部分是开发，或者咨询服务的实施过程

• C (Coperation): 合作，我们知道客户合作胜过合同谈判。

ODC的模式好处有哪些?

我认为ODC有几个很主要的优势：

1. 软件开发，需求很难固定，尤其是现在这个变化极快的时代，一旦需求固定，将失去竞争力，拿现在手机开发来说，如果一开始定义了一个手机，而且严格按照计划来，一年以后等你上市时，发现大部分手机都有了指纹功能，而你的没有，那么你的手机就毫无竞争力，让之前的付出瞬间付之东流。

2. ODC的合同一般更倾向于长期客户，这样可以让团队成员能够更稳定，让熟悉的人能够长期服务于这个客户，大大降低了产品的风险。不然，A做的东西让B接是很需要时间的，如果A已经离职或者服务于别的项目，那么很可能导致项目难以持续。

3. ODC的付费形式是按月付费，可以大大降低客户的成本风险，以及可以节约现金流。

4. ODC的服务的交付大部分都是增量式，比如2个周一个迭代，客户可以尽早发现项目中的问题，尽早给予反馈进行修复。甚至尽早终止项目来减少损失。

5. ODC服务需要把双方都理解为自己的同事，开放(O), 合作(C). 没有信息影藏，双方都是想把产品或服务做好。

6. 更容易激发双方的创造，不用过于盯着一开始定义的功能，不用过于在乎KPI (Kill people idea), Business value才是最重要的。

7. ODC使开发人员有更长时间来不断加强对客户的业务领域的理解，从而提交更好的产品和服务。

8. ODC使的软件提供方更容易做出计划，从而可以让开发人员更专注于一个客户的项目，想想固定价格的项目，很多友商固定价格的项目常常一个人同时做好几个，根本没时间来深入理解客户到底需要什么。

9. ODC的项目也更容易规划开发人员的个人发展，更容易做出一个长期的计划，从而增加员工对公司的认同，一个能留住人才的公司，肯定是可以提供更好的服务的。

ODC的好处远远不止这几点，我们使用ODC成功提交了大量的项目，当然单单使用这种合作模式也是不够的，软件行业想在ODC服务模式下提供高质量的服务依然没有那么简单，具体怎么做，欢迎阅读我的

ODC的问题

ODC的模式固然有很多好处，但是这世界上从来没有任何一个模式是完美的，经过这几年的服务，ODC也有几个常见的问题, ODC一个最大的好处是可以让人员稳定，可以留住人，但是最大的问题也是留人问题：

项目周期太长，开发人员觉得枯燥

有的项目做的时间比较长，比如5年以上，那么开发人员使用的技术就没有那么新，虽然这个对项目本身问题不大，但是技术人员第一都是喜欢追求新技术的。其次开发人员和别的项目或者开发人员讨论，觉得自己的技术已经没那么时髦了，容易产生浮躁的心里。

其实，解决这个问题的方法有几种：

• 在现有的项目里使用新技术，比如很多公司在使用的Powerbuilder可能需要更换为WEB系统或者新的技术，不然将来谁来维护？

• 部分功能或者子系统使用新技术，比如部分使用NoSQL, Elastic Search，Cloud等新技术除了提高系统的性能，降低维护的任务外，开发人员也可以学到很多新东西

• 更换部分人员，更换部分新成员到项目，老成员可以做别的项目

但是，这些都需要客户方的大力支持，ODC提供方是很难单方面进行改进。

报价增长太慢，不符合开发人员薪水增长预期。

这个也是一个常见问题，程序员的薪水每年都希望提升，而大部分公司程序员薪水的提升是和程序员给公司能带来的价值/收入来决定的，也就是基本上和报价关联度比较大。当然，我们可以不关联，那么如果不关联会带来更多的问题。这里面出现的矛盾是，正常情况我们和客户都会说每年有一个百分比的报价提升，但是这会受到几个因素的影响，一是这个百分比是否和整个市场薪水变化同步，而是部分开发人员能力提升较大，自己期望高于这个百分比的薪水涨幅

这个问题解决方法其实也是有三种：

1. 降低利润
2. 客户接受对应报价的提升。
3. 人员离开项目

在人员的生产效率没有降低的情况下（理论上每年应该都有提高，因为对项目业务更熟悉，使用的技术更熟练），我个人一直觉得第二种是对客户最好的一种方式，因为 报价的提升是恰恰是成本最低的，同时想想这个开发人员对项目的过去几年已有的贡献，他应该享受某些程度上的不可替代带来的回报提升。

开发人员同一项目时间长了，皮了！工作效率下降。

当我们很多东西都熟练的时候，我们原来8个小时的工作量很多时候6个小时做完了，虽然某种程度对客户的产出没有变化，那么时间长了，我们人就比较消极，在一种消极的情况下，稍微有一点有挑战的新任务，都会没有好的产出。

这种解决办法，我觉得只有一个，那就是换人！

“富成一个废人”

ODC项目时间长了以后，大家压力不是太大，所以容易进入舒适区，舒适区呆久了，一旦换个项目，很可能适应不了新的节奏，新的知识或者丧失了学习的能力，从此“富成一个废人”。

这种解决办法，就是ODC我们也需要不断提高我们的质量和效率！使用正确合适的开发过程来避免这些发生，参考我的敏捷系列

总结

废话少说，最后几句重要的。

1. ODC 卖的不是时间，是服务呀，时间人人都有哇
2. ODC 是一种合作方式
3. ODC 的产出是服务 （软件或者咨询)
4. ODC 是为了提高质量和效率，不是为了多挣钱, 多挣钱只是ODC的附属产物
5. ODC 是为了更好的员工发展规划做基础，员工Happy，才能做好服务，客户才能Happy