我从项目实践中看到的ODC演变

几年以前，我曾经很关注国外的招聘价格，刚毕业的新人月薪可以低到1,500美元，而普通项目经理价格又可以达到10,000美元以上，项目中技术骨干则要高出更多。而在当时我们的ODC小时报价达到30美元（月报价约4,800美元）的已经是很厉害的程序员了。

假设国外市场更成熟稳定，为什么这几个角色价格差要远大于国内行情呢？这个疑问一直没有答案直到我后来做了服装业某客户的项目。

我们做好了项目开始所需要的一切准备

三年前在美国办公室工作期间，得到了一个机会与美国的一家咨询公司一起为这个客户提供技术支持与维护服务。

在项目初期，我与咨询公司的同事花了近两个月的时间讨论流程、角色，建立了一整套完整的适合项目特点的SLA，包括详细的支持、开发、报告、应急一系列严谨且可行的流程，几乎准备好了项目正式支持所需要的一切。直到现在看来，我也认为我们在这个阶段的工作完成的很出色。

努力的工作换来了一塌糊涂的结果

然而，紧接着到来的实践却不是预期的那样一帆风顺，尽管我们（盛安德和美国咨询公司）合作还算不错，至少严格按照约定好的流程来执行。客户方面仍然是不时地抱怨问题不能得到及时解决。从统计数据来看，平均Ticket解决时间和月Ticket数量也确实都没有减少的趋势。

凭心而论，我们确实很努力也很认真地想要证明我们可以胜任技术支持的工作，美国团队和我们几乎每天都要额外工作2小时以上。然并卵，客户终于在8个月后忍受不了我们低劣的服务，派出了检查小组分别到美国咨询公司和盛安德来检查，目的是重新定义支持工作的团队组织结构甚至重新选定支持供应商。

经过激烈的撕*大战（本质上确实是这样的），我们凭借成本、技术以及机智胜出了，成为唯一的技术支持团队。当然，这并不意味着客户对盛安德之前的工作是满意的，但是又有什么办法呢？很多客户在面对软件供应商不都有相同的问题吗？

角色转变，所有的问题都奇迹般地消失了

项目“重新”开始，经过一周几乎完全是浪费时间的业务培训之后，团队又整理心情重装上阵。这期间，我们仔细地讨论了为什么之前的服务存在问题，讨论结果是我们做的所有的事情理论上都是对的，几乎无懈可击。那也就意味着我们其实是永远不承担责任的，所有的问题解决方案、问题产生的原因、技术分析结果都要与客户确认。换句话说，反正我都跟你说清楚了，不能再透明了，你同意了我才这么做的，出事了可不能怪我咯。

到这里，似乎问题出来了，问题就在于我们做的一切都太“正确”了，我敢肯定不是客户想要的服务。于是我们勇敢地提出了要转变角色，盛安德变成了系统的所有者，提供所有相关的服务。带来的变化就是我们的工作从流程上的透明升级到业务层面上的透明，我的精力从解释技术方案转到了与用户讨论需求和解决方案。我们来制定发布计划，通知用户什么时间解决哪些问题。仅仅三个月过后，我们的Ticket数量就变成了原来的大约三分之一；六个月过后，与我们一起工作的三个客户同事都因为这个重要系统的重获新生得到了升职（至少我认为是这个原因）。

现在我们的团队与三年前有同样的ODC合同条款，但报价变了，角色变了，服务也变了。回到开头，我也找到了成熟稳定市场的IT从业者价格差别的原因。