Succeeding with Remote Development

Succeeding with Remote Development

成功协调异地开发

One of the most common situations today is where the product manager is in one location, and the engineering team is somewhere else. I don’t only mean outsourcing to India either – the remote development team might be a consequence of an acquisition or merger, or possibly your organization is large enough where the developers are centrally located in a facility somewhere you aren’t.

今天最普遍的情况是产品经理和研发团队分隔两地。我不仅仅指的是外包给印度――异地开发团队可能成为收购或者合并的在一种结果或者有可能你的组织足够大,可以让开发人员集中在一个你不在的场所进行研发。

When the developers are not sitting right next to you, then all of the normal challenges of communication and execution are magnified, often to the point where many teams get extremely frustrated with remote development, and some challenge the benefits of the perceived cost savings.

当开发人员不在你身边时,所有的沟通和执行所带来的普通挑战会被放大,许多团队在这方面经常感到沮丧,可知成本节约的影响会成为挑战。

I have written earlier about some of the problems that come with outsourcing for the wrong reasons, but whatever the cause, if you find yourself with a remote development team, there are three critical things you can do to dramatically improve your odds of success:

我以前写了一些由于错的原因在外包过程中产生的问题,但是不管什么情况,如果你发现自己与一个异地开发团队合作,你有三件重要的事情要做来提高你的成功率。

1) The further away the team is from you, and the more the communication challenges of language, culture and time zones, the more pressure there is to ensure that you have done a very good job on the product spec. The nightmare project is where the product manager isn’t sure what he wants built (or keeps changing his mind) and the remote engineering team is thrashing. It’s like being on the wrong end of a whip. In the last article I wrote about the importance of a high-fidelity prototype as the basis of the product spec. I won’t repeat all the reasons for that here, but suffice it to say that if your team is remote, you absolutely positively want to make sure you use the high-fidelity prototype as your main communication mechanism. Both for communicating the actual spec, and for communicating changes. Written documents are hard enough to get people to read, but if it’s written in a language that isn’t native, and if you don’t have the author in the cube down the hall to interpret it to you, you’re just asking for big trouble.

1)离你越远的团队,语言、文化和时间差方面的沟通所带来的挑战就越多,确保在产品要求上你已经做的非常好的压力就越大。如噩梦般的项目是产品境界不能确定他想要做什么(或者经常改变想法)和研发团队备受煎熬。就像一根方向错误的鞭子。在最后的一篇文章中我要写到一个高保真的模型作为产品的基础的重要性。我不想重复做这个的原因,但还是要说明如果你的团队是分开的,你要绝对保证利用高保真的原形作为你的主要沟通手段,目的是为了沟通确切的要求,为了沟通的变化。文本文档很难被人理解,但如果不是用一种本土语言,如果你没有让作者给你解释,你会陷入大的麻烦中。

2) When a development team is local, if there are resource conflicts (for example, two different managers give conflicting instructions) then this is typically caught quickly and resolved.  With remote teams, you end up getting lots of unpleasant surprises, and literally months can pass before the disconnects are identified. This is usually because the remote developers are forced to make assumptions about who wanted what and how to interpret the various instructions, and the assumptions are rarely correct. It is critical to have someone local manage all coordination with the remote team. This doesn’t mean that all communication should be funneled through this person, but there should be no question as to who the engineering team is accountable to.  Sometimes this is a project manager (ask program manager) and sometimes this is a director or VP of engineering that is based locally (near the product manager).

2)当一个研发团队是当地的,如果有资源冲突(比如,两个不同的经理产生冲突)这会陷入僵局然后又会解决。如果和异地开发的团队在一起,结果是你会遇到很多不愉快的惊喜,在沟通中断被确认之前几个月就这么过去了。这常常是因为异地开发的人员被迫对谁想要什么和怎样去解释不同的指示作出假设,而这些假设很少正确。关键是要有人做好与异地开发团队的所有协调工作。这不意味着所有的沟通都要通过这个人来传递,但是关于研发团队向谁来负责是没有问题的。有时这是一位项目经理,有时这是一位主管或者基于本地的工程副总(接近于产品经理)

3) There are so many good communication mechanisms now. In addition to e-mail and instant messaging, video conferencing is much better, and VoIP has brought the costs way down for international calls. That said, there still is no substitute for establishing the personal relationships.  At least once a quarter, the product manager should get out to the engineering team, meet with the key architects and managers, and spend some quality face time. This will improve all the other forms of communication. Another great technique here is to have an exchange program where key developers come stay with you for a while, and you go there for a while.

3)现在有很多好的沟通机制。除了发email和IM,视频会议会有更好的效果,VoIP 已经成为降低国际通话成本的方式。也就是说,仍然没找到建立私人关系的替代者。至少一旦成为一个群体,产品经理应该从研发团队中走出来与重要的设计师以及经理进行高质量的面对面谈话。这将会提高所有其他的沟通形式。这里有另外一种好的方法就是交换机制――关键在于开发人员过来和你呆一段时间,然后你去他那里呆一段时间。

If you have a talented remote team, and if you are managing the relationship as I’ve described, you can actually come to enjoy this arrangement. Especially with engineers based in India, the time difference can make it such that every morning when you come in you see progress waiting for you, and you can spend your day (and their night) reviewing and testing and providing feedback. The result can actually be extremely fast cycle times.

如果你有非常棒的异地开发团队,如果正如我已经讲述过得正在处理这样的关系,你会真正体会到其中的乐趣。尤其是与在印度的研发人员打交道时,时间的不同会使每天早上当你来时会看到你的工作等着你,你要花白天(他们的晚上)检查和测试并且要反馈给对方。这种结果的确加快了时间的循环。

Note that you can also have your prototyping resources remote as well, but you’ll have to work a little harder on the communication and be more flexible on your hours, because of the very quick cycle times (several iterations a day).

注意你也同样可以建立自己的远程模型资源,因为非常快的时间循环。但你会在沟通中稍微有困难,你的工作时间更加灵活因为非常快的时间循环。

Yet another solution to the problems of dealing with a remote development team involves locating the entire product team together in the remote location.  I see this trend just starting, but I think it will be profound.  That said, you don’t have to worry about this just yet.  It has taken 10 years to develop the engineering and QA capabilities in these remote locations, and it’ll likely take another 10 before these locations have skilled product managers and designers as well.  But that’s a topic for a future article.

另外一种处理异地开发问题的方法是在异地开发的模式中牵涉到整个产品团队本土化。我发现这种趋势刚开始,但我认为意义深远。也就是说,你没有必要担心这个。在这些异地开发的过程中,得花十年的时间提高开发和QA的能力,同样要再花十年在这种模式中培养熟练的产品经理和设计人员。但那是另一篇文章的主题。

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址