离岸开发-明确工作范围

这是一个最基本的，但也是最容易被大家忽略的地方。做什么东西onshore不是说了吗，有什么不明确的呢？

但是我们不要忘了，说是说了，认识上是否一致可就不一定了。

我们曾经做过这样一个工作。我们的代码服务器进行个更换。更换以后，onshore要确保代码没有更换错误和遗漏掉，所以需要检查一定范围的代码。onshore的指示是这样的：把所有编译相关的代码都检查一下。

负责的人对于“编译相关”的理解，就是java文件。他认为只有java文件是编译相关的。所以就告诉onshore3天后可以做完。
在做的过程中，进行review的人发现了这个问题，那就是“编译相关”的表述不明确，工作范围的定义有些模糊。

于是马上与onshore的人进行确认，结果onshore的理解是java文件，c语言文件，perl文件都是编译相关文件。这样工作的范围明显的扩大了，最终用了一个星期才结束代码确认的工作。

很多时候，offshore的人在没有明确工作范围的情况下，或者在自己的认识范围下就开始着手一个工作。辛辛苦苦地做完以后，满以为会得到onshore的赞赏，可没想到，双方的认识分歧比较大，别说赞赏了，还会被onshore指责了一通。
自己的辛苦，换来的是对方的指责。自己的价值被抹杀掉，填补上来的是烦闷的心情。
从此埋下了与onshore纷争的种子。

基本每个做离岸外包的人都有上面的经历。那么如何去避免这样的事情呢？其实很简单，就是首先要明确工作范围。
面对onshore过来的要求，一定仔细研究，琢磨内容，看是否有歧义和模糊的地方。正所谓磨刀不误砍柴工，这里花上一小点时间，将会避免后面花费几天时间的风险。

找到了认识模糊的地方，就要和onshore确认。确认也要讲究方法，不要直接去问：你这个地方写得什么意思？
应该把你的观点告诉对方，让对方看看对不对。这样会提高双方沟通的效率。

对于上面的例子，我们可以给onshore发邮件确认一下：我认为编译相关的文件仅仅是java文件，你认为怎么样？
onshore了解了你的想法后，会很快告诉你他的想法：编译相关的文件应该是java文件，c语言文件和perl文件。
工作范围明确以后，我们就可以估算正确的工作量和计划了，不会出现明明一个星期的任务，自己估算为3天完成的情况了。

初期的工作范围确认无误了，难道就万事无忧了吗？非也。
世界上没有一成不变的事情，工作范围也是一样。

工作中的微小细微的改变，让人毫无察觉的变更，才是最难以防范的。
我们经常会有这样的经历，在最初虽然与onshore就工作内容达成了一致，但是随着工作的进行，onshore今天说这里修改一下，
那里增加点功能，每次都是很小的改变。
作为offshore，当然希望与onshore之间保持良好的合作关系，所以这些细微的改动也就不计较了，顺手就给做了。
谁知越往后做，某些细微的改变就可能会带来稍微大的变化。几个稍微大的变化，就带来了非常大的变化。

这时，你突然发现工作的范围突然与最初不一样了！不仅成本增加了，而且规定的期限内也完成不了了。
怎么办？在这个过程中，对于onshore的要求你都答应了，你从来没说过成本增加，也没说过期限会变化---onshore自然也觉得没问题。
现在这个阶段你提出了这个问题，onshore自然也急了：你当初不是说没问题吗？！
这时你真的是有苦说不出啊！我好心好意的给你做了一些工作，到现在你竟然埋怨我！

这种细微的，难以察觉的变更，的确让很多开发人员吃尽了苦头。不仅受到onshore的责备，还会受到自己老板的责备。

所以，要想工作有价值，必须时刻关注自己的工作范围，不仅仅是最初，整个过程之中都需要关注。

过程中的工作范围的管理，有一个名词，叫“变更管理”，后面的文章中再继续介绍。