离岸开发-改善的工作是双方的
做里离岸开发时，onshore经常会要求offshore进行各种改善。例如，工作效率要提高，细节要注意，内部review要充分，要站在onshore的角度想问题，等等。
这时我们就有一种感觉：onshore从来都是对的，他们让我们做什么，我们就应该做什么。
事实的确如此吗？
onshore也是普通人，他们也一定会犯错，他们难道就没有需要改善的地方？
onshore总是抱怨我们影响了他们的工作效率，他们就不会影响我们的工作效率？
在做离岸开发工作时，我们也需要时刻注意这样的问题：onshore的做法是否正确，他们是否有需要改善的地方。
在很多做offshore的人看来，onshore给我们活干，我们才有工作，现在反而要去指责onshore的问题--这不是没事找事吗？而且就算
你指出了问题，onshore能不能听你的都是个问题。
没错，是onshore给我们活干，但是请记住一点：onshore不是客户。onshore的活也是从客户那里拿来的。对于客户来说，onshore和offshore是一个整体，任何一方出了问题，在客户看来，都是你们这个公司的服务质量有问题。
站在面对客户的角度上来说，如果onshore真的有问题，工作方式真的需要改进，只要我们提了出来，onshore没有理由不去接受这个请求。
对于onshore那边做实际工作的人来说，被offshore指出了问题可能无法接受，有抵触情绪，但是对于onshore那边的管理者来说，只要指出的问题是正确的，对于今后的客户满意度是有帮助的，那么onshore就一定会接受这个问题，然后去改善他们的工作方式。
有些人觉得这是在和onshore“打仗”，打赢了，有面子，以后继续打；打输了，没面子，以后不打了，onshore说啥我干啥。
这主要还是心态在作祟。不要把这当成和onshore的“打仗”，其实我们的目标只有一个：更好的为客户服务，改善工作中不足的地方。正所谓“有则改之，无则加勉”。如果抱着“打仗”的心态，那就和初衷相违背了。
在一个开发项目中，就有类似的例子。首先说说我们的工作范围：从onshore那里得到需求，然后做设计、coding、单元测试、集成测试。
在做集成测试的时候发现，需求里的一个地方写的不对，和另一个功能冲突了。于是马上和onshore联系，报告了情况。
onshore确认了问题以后，花了2天时间重新修改了部分内容，我们又修改部分的设计、coding，然后再次测试。
如果事情到这里结束就没有问题了，可是onshore那边的一个manager突然来了一封email：这个问题，为什么没有在单元测试阶段中发现出来？反而在集成测试阶段中发现了？你们的单元测试是不是有问题？
对于做离岸开发的offshore来说，这是一个多么熟悉的场景：我们仔细工作，避免了问题的扩大，结果onshore反而指责我们做的不好。这一定会导致负面的情绪。
对于上面的问题应该怎么处理？
有的人会这样：遭了，又被他们指出问题了，赶紧想想怎么回答吧，以后怎么改善--其实这也是onshore预期的。
对于这件事，我们的处理方式有所不同。我们是这么回答给onshore的：
1、首先这是需求错了。为什么你们onshore没有把需求确认正确？请分析一下原因，并改善。
2、单元测试阶段，或许可以发现问题，但是这不是最终的保障，也不是这次问题的根本原因。
3、这个项目规模很大，onshore负责需求。各个功能之间相互关联，不能完全指望单元测试去保证质量。
4、我们尽力在单元测试中发现问题。
上面这四点，主要明确的意思：onshore的工作目前有问题，要改进。我们尽量配合。
显然onshore的manager没预料到这样的回答。于是双方开始了你来我往的拉锯战。
不过我们把握住道理，坚决不让步。
由于项目快到期了，所以争端先放后边，先对应需求的变更。之后我也离开了这个项目，这个争端也就不了了之了。
在我参与的维护项目中，有过这么一件事。onshore那边新来了一个毕业生，人还不错，但是有一个问题，就是对系统不熟悉，而且技术能力太差。
在我们的维护项目中，主要是onshore给我们安排任务。新来的毕业生由于业务不熟练，技术也一般，就导致了经常给我们下达一些错误的指示。本来20分钟能干完的活，得干3个小时。
有的时候我们虽然指出了他错误的地方，他还轻易不相信，需要花一些时间去给他说明白。他这种意识倒是没问题，我们可就痛苦了。
经过一段时间后，我们发现他确实在影响我们的工作效率。于是就和onshore那边的manager沟通了一下。具体的情况说明以后，明确要求onshore进行改善。onshore接受了我们的要求。
让onshore进行改善并非什么过分的请求，但是，还是需要掌握一些沟通的技巧。
1、清晰的地阐述你的问题
当onshore的做法存在问题，达到不得不报告的程度时，一定要先保持冷静。
当你比较激动时，写出来的报告几乎都是调理不清晰的，很容易写出混乱的内容，反而再次被onshore指责。
所以在你写一个报告之前，最好先溜达几分钟，或者过一天再写。也可以先和别人聊聊要写的内容，听听别人的建议。
在头脑中把问题理清楚了以后，剩下的就是如何清晰的表达出来了。
建议采用分条目来写。例如:
【背景】
onshore某某人，由于对业务掌握不足，导致调查某某功能时，花了3个小时去说明业务。
【问题点】
某某的业务掌握不足，已经影响到了offshore的工作效率。
持续下去，恐怕会影响对客户服务的质量。
【期望】
希望onshore能想一些办法，提高某某的业务水平。
例如：进行一些内部的培训。
上面的内容写完以后，一定要自己多读几遍。然后自己再站在onshore角度上去看看这些内容，是否存在有疑问的地方。
如果有的话，把报告的内容再补充一下。
2、必须有足够的证据
我们虽然按条目把问题阐述清楚了，但是还有一个重要的部分是不可或缺的：证据。
不管你把问题阐述得有多清楚，如果没有足够的证据，那么onshore那边是很难认可的。
那么什么是证据呢？可以是如下的东西：
·邮件记录
·聊天记录
·业务系统的记录
（例如我们使用一个内部讨论的工具来与onshore进行沟通）
当我们提出一个问题时，一定要同时把相关的证据准备好--因为onshore一定会看看当时的记录是怎样的。拿不出来，或者过几天再拿
出来，都会让自己陷入被动的局面。
也由此可见，邮件等能够记录的东西是多么的重要。重要的决定，一定要用邮件记录下来。
为客户提供服务，是onshore/offshore双方共同配合的工作，改善也是同样如此。offshore必须时刻有这种意识，为了工作更顺利地进行，如果必要，就让onshore也去改善吧！
1 楼 zhongli 昨天 理想状况这样最好。现实让客户方这样做比较困难
