您的开发人员将为 wiki 做出贡献，因为他们有一个有形的文档，每个人都可以在其中查看可以看到他们为客户贡献了多少。
让客户感觉好像他是开发过程的一部分，
因为 wiki 实际上是一个协作文档，每个人之间都会出现一种通用语言。 它可能与使用客户的语言不同，但它将是客户和开发人员语言的组合。
Create a wiki. Create a page for your customer which contains pictures, business information, things to look out for, etc.
Have everyone contribute to the wiki, including the customer.
As time goes on, this page (or pages if you split the information on numerous pages) will allow
new developers to understand the customer faster
see the possible problems that may arise
your developers would contribute to the wiki since they have a tangible documentation where everyone can see how much they have contributed to the customer.
make the customer feel as if he is part of the development process
since the wiki is, by effect, a collaboration document, a common language will appear between everyone. It might not be the same as speaking your customer's language, but it will be a combination of your customer's and developer's language.
We've had a somewhat similar situation when we did "Beta programs" for select customers. When the customers had questions, they could only turn to the developers at that stage of the project because e.g. the helpdesk was not yet familiar with the new features.
We also used a "middle man" for doingt the communication with the customer and then passing it on to the developers, and this has worked quite well for us. What were the advantages? The customer alsways knew exactly whom to contact, the communication was consistent, some on the simpler questions could be answered without the need to "bug" the development team at all while some more difficult questions could be "boiled down" from a superfluous explanation to the real problem before handing the question over to the developers, both giving the developers more time to concentrate on what they do best.
Of course, if you want this to work, you'll have to make sure you pass on information between development and the customer in a timely manner, but I think it can be worth the effort (and in fact, our developers prefer it that way).
Communication skills are arguably more important than technical skills. A programmer that doesn't communicate well may well cause enough disruption to negate what they bring to the table technically.
Having said that, you still have to realize that not everyone is the best person to be "customer facing". You might designate one or more members of the team as liasons to your customers, and have the communication go through them when possible.
The developers should be shielded from the customers. Developers are usually hardcore technical people who eat C++ templates at breakfast. The customers are often very non-technical. A customer asking a badly formulated question on some trivial issue to the developer usually irritates the developer a lot causing at least a temporary loss of productivity. So it's better to have special paid people that work in between.
Don't underestimate the value of being in the same place. If communication skills are lacking, being able to point and say "look at this" can be far quicker and more effective than trying to explain everything in a meeting or email. But from "they consider us as their own department just sitting somewhere else" this doesn't sound like it is an option for you.
Generally I expect that at least some of your developers will be open to learning proper communication with the customer. Involve those developers with the communication (even if it's painful at first). English is a pretty universal language and your customer will probably be able and willing to speak it.
Shield the developers that DON'T want to communicate or learn to communicate with the customers. They may damage your relationship with the customer and you will damage your relationship with your employee.
Be careful about allowing written contact between the customer and your developers. Written communication often gets interpreted wrong, especially when written by people who do not have much experience writing carefully balanced e-mails, memos or letters.
As you build your relationship with your customer, you'll get to know eachother's personalities, and communication will be smoother.
发布评论
评论（6）
创建一个维基。 为您的客户创建一个页面，其中包含图片、商业信息、需要注意的事项等。
让每个人都为 wiki 做出贡献，包括客户。
随着时间的推移，此页面（如果您将信息拆分为多个页面，则为多个页面）将允许
Create a wiki. Create a page for your customer which contains pictures, business information, things to look out for, etc.
Have everyone contribute to the wiki, including the customer.
As time goes on, this page (or pages if you split the information on numerous pages) will allow
当我们为特定客户提供“测试版计划”时，我们也遇到过类似的情况。 当客户有疑问时，他们只能向项目该阶段的开发人员求助，因为例如帮助台还不熟悉新功能。
我们还使用了一个“中间人”来与客户进行沟通，然后将其传递给开发人员，这对我们来说效果很好。 有什么优点？ 客户总是确切地知道该联系谁，沟通是一致的，一些更简单的问题可以得到回答，而无需“bug”开发团队，而一些更困难的问题可以从多余的解释“归结”为在将问题交给开发人员之前先解决真正的问题，这都让开发人员有更多时间专注于他们最擅长的事情。
当然，如果您希望这一点发挥作用，您必须确保及时在开发人员和客户之间传递信息，但我认为这是值得的（事实上，我们的开发人员更喜欢这样）方式）。
We've had a somewhat similar situation when we did "Beta programs" for select customers. When the customers had questions, they could only turn to the developers at that stage of the project because e.g. the helpdesk was not yet familiar with the new features.
We also used a "middle man" for doingt the communication with the customer and then passing it on to the developers, and this has worked quite well for us. What were the advantages? The customer alsways knew exactly whom to contact, the communication was consistent, some on the simpler questions could be answered without the need to "bug" the development team at all while some more difficult questions could be "boiled down" from a superfluous explanation to the real problem before handing the question over to the developers, both giving the developers more time to concentrate on what they do best.
Of course, if you want this to work, you'll have to make sure you pass on information between development and the customer in a timely manner, but I think it can be worth the effort (and in fact, our developers prefer it that way).
沟通技巧可以说比技术技能更重要。 沟通不畅的程序员很可能会造成足够的干扰，从而抵消他们在技术上带来的成果。
话虽如此，你还是要认识到，并不是每个人都是“面向客户”的最佳人选。 您可以指定团队中的一名或多名成员作为客户的联络人，并在可能的情况下通过他们进行沟通。
Communication skills are arguably more important than technical skills. A programmer that doesn't communicate well may well cause enough disruption to negate what they bring to the table technically.
Having said that, you still have to realize that not everyone is the best person to be "customer facing". You might designate one or more members of the team as liasons to your customers, and have the communication go through them when possible.
开发商应该免受客户的影响。 开发人员通常是早餐吃C++模板的铁杆技术人员。 客户通常非常不懂技术。 客户就一些琐碎的问题向开发人员提出错误的问题通常会极大地激怒开发人员，导致至少暂时的生产力损失。 因此，最好有专门付薪水的人在这两者之间工作。
The developers should be shielded from the customers. Developers are usually hardcore technical people who eat C++ templates at breakfast. The customers are often very non-technical. A customer asking a badly formulated question on some trivial issue to the developer usually irritates the developer a lot causing at least a temporary loss of productivity. So it's better to have special paid people that work in between.
不要低估在同一个地方的价值。 如果缺乏沟通技巧，能够指出并说“看这个”可能比试图在会议或电子邮件中解释所有内容更快、更有效。 但从“他们认为我们是他们自己的部门，只是坐在其他地方”来看，这听起来并不适合您。
Don't underestimate the value of being in the same place. If communication skills are lacking, being able to point and say "look at this" can be far quicker and more effective than trying to explain everything in a meeting or email. But from "they consider us as their own department just sitting somewhere else" this doesn't sound like it is an option for you.
一般来说，我希望至少有一些开发人员愿意学习与客户的正确沟通。 让这些开发人员参与沟通（即使一开始很痛苦）。 英语是一种非常通用的语言，您的客户可能能够并且愿意说它。
屏蔽不想与客户沟通或学习与客户沟通的开发人员。 他们可能会破坏您与客户的关系，您也会破坏您与员工的关系。
请谨慎允许客户和开发人员之间进行书面联系。 书面交流经常会被错误地解读，尤其是那些没有太多撰写仔细平衡的电子邮件、备忘录或信件经验的人所写的。
当您与客户建立关系时，您将了解彼此的个性，沟通也会更加顺畅。
Generally I expect that at least some of your developers will be open to learning proper communication with the customer. Involve those developers with the communication (even if it's painful at first). English is a pretty universal language and your customer will probably be able and willing to speak it.
Shield the developers that DON'T want to communicate or learn to communicate with the customers. They may damage your relationship with the customer and you will damage your relationship with your employee.
Be careful about allowing written contact between the customer and your developers. Written communication often gets interpreted wrong, especially when written by people who do not have much experience writing carefully balanced e-mails, memos or letters.
As you build your relationship with your customer, you'll get to know eachother's personalities, and communication will be smoother.