极具技术性的思维过程对于项目开发十分必要。给项目和代码写上说明（注释）能够训练你的高度文字思维。但作为一个开发者，你会发现并不是所有的工作都和编码相关。
An extremely technical thought process is required for building software. Writing instructions for interpreters and compilers necessitates this type of highly literal thinking. But as a developer, you’ll find that you won’t always be working with code.
试想一下这个场景：
产品对两名开发提出了修复bug的需求。第一位非常详细地描述了可能包含错误的代码部分以及修复它的各种方法，列出了其中的复杂性。第二位给出了更直接的响应 - 说明问题是什么，并粗略估计修复它的时间。
Think about this scenario.
A product owner asks for updates from two developers fixing bugs. The first developer starts rattling off about the intricacies of his bug. He describes in great detail the parts of the code that could contain the bug and various ways to fix it. The second developer gives a more straightforward response – she simply states what the problem is and a rough estimate of the level of effort to fix it.
发现区别了吗？
在与非技术人员交流时还保留着编码的思维是一个巨大的错误。
Notice the difference?
It’s a huge mistake to remain within your coding bubble when communicating with non-technical coworkers.
在与非技术同事交流时，请务必记得在必要时脱掉你开发者的“帽子”。
所以怎样才能更好地和他们接触呢？下面，是避免尴尬对话的七个策略。
Remember to take off your developer hat when necessary hipster-dev
So how do you step out of your perspective to better engage them? Avoid an awkward conversation with these seven strategies.
1）认识到你和他们之间的真正障碍
开发人员写代码。设计做布局。经理组织带领团队。但这些岗位之间的差异不会直接造成这些角色之间的障碍。相反，沟通障碍是由个人独特的观点造成的。
观点的形成受许多因素影响。自身环境、个人喜好和岗位只是其中的一部分。每种因素都会影响他们独特的工作偏好。而不同的性格，往往也会决定倾向扮演的具体角色。
了解这些不同的观点是打破沟通障碍的关键。 作为开发，你需要跨过代码库，接触和学习其他同事的想法。
1) Recognize the Real Barrier Between You and Them
Developers write code. Designers craft layouts. Managers organize and lead teams. But the differences between these actions don’t automatically create communication barriers between these roles. Communication barriers are instead created by the unique perspectives that precede these actions.
These unique perspectives are formed by many factors. Natural strengths, personal preferences, and placement in the organization are just a few. Each factor will play into an individual’s distinct preference for how they want to work. Different personality types tend to gravitate towards specific roles and are an important factor too.
Learning these different perspectives is pivotal to breaking down communication barriers. As a developer, you need to take action in going beyond your codebase and learning how other coworkers think. This brings us to the next strategy.
2）表现得像一个面试官
了解非技术同事观点的最佳方式是抛出问题，关键是从他们的角度了解他们特别重视的东西。
也许上面的产品需要的只是一个高级更新，他可能更注重于实现一个功能，而不是技术细节。或者也许和你合作的是一个技术好的产品经理，他可能会更欣赏你编码的细节。
通过随时提问来了解同事的需求，将能够了解如何与他们进行最佳的沟通。比如，你可以向项目业务分析师询问他们如何定义接受标准。或者可以问设计师，他们喜欢如何迭代设计。
这种方法还有另外一个方面。
为了能够理解你队伍之外的同事，你需要培养你的好奇心。变得真真正正得对如何让你团队里的人或事顺利完成感兴趣才是切入点。
2) Act Like an Interviewer
The best way to learn about a non-technical coworker’s perspective is to ask questions. The key is to learn what they specifically value from their perspectives.
Perhaps the product owner above just needs high-level updates. They may be more focused on the realization of a feature than it’s technical details. Or maybe you work with a manager who is highly technical. They may appreciate the granular details of what you’re coding a bit more.
Clarifying expectations is a great way to begin learning about what your other coworkers value. For example, you could ask your project’s business analyst about how they like to define acceptance criteria. Or you could ask the designer you work with about how they prefer to iterate on designs with developers. Learning about your coworkers by asking questions over time will allow you to hone in on how to best communicate with them.
There’s another part to this equation, though.
To take the steps needed to build empathy for coworkers outside of your team, you need to foster a curious mindset for yourself. Becoming genuinely interested in how the people and processes in your organization work together is the starting point.
培养好奇感 - 那才是超越编码的存在
Foster a sense of curiosity – that’ll get you beyond learning just about coding
Outside of just the code itself, there are a million different angles to analyze when it comes to the process of building software. Think about software from the context of being built at a particular time and place, by particular people and serving specific needs.
Think about a feature. Who designed it? Who developed it and how? What’s the historical context for why it was designed and built this way? What business requirements were involved?
Or, think about your manager. What management style do they have? What traits do they value in their direct reports? What’s their vision for your team? How do they prefer to communicate with other teams?
This process of investigation is similar to what’s required to dig into a legacy codebase or build a new feature. Thinking about things at different angles and from various perspectives will help with both your technical work and your communication skills. Hell, it probably helps in any aspect of life.
3）交流而不是交谈
当与非技术同行合作时，与他们交流，而不是与他们交谈。 这里有一个微妙的区别。 前者对他们的观点有着重要的意义。
要做到这一点，你必须先了解你交流的目的。是讨论新功能？考虑架构决策？还是 Scrum 更新？专注于交流的真正目的，尽量不要跑偏了。
例如，传统的 Scrum 会议会涉及到已经完成的工作、正在进行的工作和更新遇到的问题。尝试解决问题并不在其目的范围之内。
通过记住真正目的，从共同点进行交流。
3) Avoid The Silly Way to Speak with Non-Technical Coworkers
Use the knowledge gained from learning about the perspectives of your coworkers. When working with your non-technical peers, speak with them and not at them. There’s a subtle difference here. The former places a sense of importance on their perspective.
To do this you must first understand what your conversation is about at a high level. Discussing the requirements for a new feature? Mulling over architectural decisions? Scrum update? Focus on the true purpose of the conversation, and try not to modify it to include your own agenda.
For example, traditional scrum meetings involve giving updates about work completed, work in progress, and impediments. Trying to solve a problem or venting at a scrum is outside the scope of its purpose. This can give the signal that you’re more concerned about yourself than your listeners.
By remembering the true purpose of the conversation, you can communicate from common ground.
4）合适选择措辞
开发技术迭代很快，来自全世界的新知识在不断涌现。对于开发者来说，跟上自己的专长就已经是颇具挑战的事了。保证整个软件开发团队与所需的知识保持同步是非常困难的。更别说是和非技术同事同步这些知识了。
所以，拥有共通的词汇是从共同点进行沟通的关键。除非你的利益相关者想知道你正在使用的 MongoDB 实现的细节，否则最好不要去谈起它。当然，有些时候你需要以某种方式在团队间传达技术细节。
当讨论技术时，请记住，听众可能不了解这个特定领域的知识。在谈话中注意听众的反应，并确保你们都有相互理解。保持你的沟通简短和有效。
此外，可视化不管是在编程中，还是会议中都很重要。
4) Know Why Word Choice Matters
Software development is comprised of entire worlds of domain knowledge. It’s often challenging enough for a developer to keep up with their own specialty. It’s significantly harder to keep software development teams in sync with required knowledge. And even more difficult than that is communicating about domain knowledge with non-technical coworkers.
Having a shared vocabulary is key to communicating from common ground. Unless your stakeholder wants to know the specifics of the MongoDB implementation you’re using, it may be best to avoid bringing it up. But there will be times when you’ll have to convey technical details in some way across teams.
Cultivate a common language between yourself and non-technical coworkers
When you do discuss tech, remember to be aware that your listeners may not understand your specific domain knowledge. Reserve plenty of room in the conversation for questions. Be mindful of your listener’s reactions and ensure that you both have a mutual understanding.
Additionally, try to stay as high-level as possible. Visualize what speaking in a high-level programming language would look like compared to speaking in Assembly. Start with higher levels of abstraction, and dig deeper into specifics if necessary.
Imagine that you’re building a new feature but you discover that legacy code has to be rewired before you can start. If it inhibits a project schedule, it’ll require a technical explanation to a Product Owner or stakeholder. You could explain by describing how the legacy code constrains the new feature at a high-level. What you probably don’t want to do is give a meandering analysis of the software architecture.
By remembering to draw from shared language and knowledge, you can keep your communications brief and effective.
5）练习讲述你的故事
理解听众是有效沟通的一半，理解并正确表达自己的想法是另一半。这需要足够的自我知识和实践共享，能有效地扩展你的影响力。
第一步是知道你的观点是什么。要形成作为软件开发人员的偏好和意见，需要有足够的技术知识。努力成为你的领域的专家，学习新技术和语言，阅读博客，并观察与其相关的开源项目。
除了这些硬技能，了解软件开发如何与诸如商业、营销、运营等其他相结合。开发过程因组织而异，了解所在的企业是如何利用软件开发来做业务的，并得出你自己的结论。
当对自己的观点有强烈的感觉时，会使你更容易表达自己。
5) Practice Telling Your Story
Understanding your listener is half the equation in effective communication. Knowing yourself and expressing your thoughts is the other half. You’ll need an adequate amount of self-knowledge and practice sharing it to effectively extend your influence beyond your software team.
The first step is to know what your perspective actually is. To form your preferences and opinions as a software developer, you’ll need to have enough technical knowledge. Strive to become an expert in your craft. Learn new technologies and languages, read blogs, and observe open-source projects that are relevant to you.
Outside of those hard skills, learn how software development fits together with other functions like business, marketing, operations, etc. Development processes vary by organization, but it will be beneficial to understand how they impact your ability to contribute. Learn how your workplace utilizes software development for their business and come to your own conclusions about the benefits and drawbacks.
To form your unique perspective, gather enough preliminary knowledge first
Form opinions based on both your technical and organizational knowledge. As you discover information, be open to changing them. Your perspective will naturally evolve over time as you gain experience.
Having a strong sense of your own perspective will allow you to more easily express yourself. When working outside of the development team, remember to share your point of view and the value that you provide. Part of this entails “educating” others about your role as a software developer in a sense.
This is important because non-technical folks might not know the level of effort that certain tasks require in software development (i.e. we’re not just wizards). Also, the value of non-visible development work such as infrastructure changes are also not immediately evident to outside roles. Becoming a software developer that can discuss and evangelize the value of your work will greatly expand your influence.
6）当觉得有必要争取时拿出勇气去争
有时，团队在构建某些功能时可能会发生冲突。如果项目落后于计划，开发可能争取的是质量代码，而产品可能更多的是想临时解决方法，设计师可能争取的是用户体验，而管理层担心的是没有资源继续维持。
当有冲突时，当你不同意别人的意见时，学会以你作为一名开发者的视角说话。尽可能寻找共同点，并从相互理解的立场进行辩论。如果你能在上面的例子中说清楚保持高质量代码能带来的长期好处，可能别人会做出妥协。
记住在正确的场合用正确的方式分享你的意见。记住，你的语气也同样重要。
6) Have the Guts to Do This When Necessary
Sometimes, certain functions in an organization will collide when building software. If a project is behind schedule, developers may fight for quality code while a product owner might settle for a temporary workaround. User experience designers may fight for a design system while management is concerned that there won’t be resources available to sustain one.
Whenever there is conflict, learn to speak up with your perspective as a developer when you disagree. Look for common ground as much as possible and argue from a position of mutual understanding. If you can argue for the long-term benefits of keeping high-quality code in the above example, you may be able to make a compromise.
Remember to share these opinions in the correct mediums and in the proper way. It may be easier to discuss a compromise with someone in a leadership position one-on-one, for example, instead of among those they lead. Keep in mind your tone is equally important as well. Plenty of brilliant technical opinions are tainted by a rude delivery and inappropriate timing.
When sharing your opinions and asking for a compromise, you may find that sometimes your listeners are initially unwilling to work with you. But give it time. Sometimes people just need to take a step back and reassess new information before they can integrate it. Oftentimes, planting a seed and being hopeful for the future is enough to make an impact.
7）眼光尽量放长远
在团队中，为了一起共事，妥协很可能会出现在每个业务功能环节上，但最终目标应该始终是相同的 - 构建适合其用户的软件。这最终能使企业能够通过增加收入和/或降低费用来发展壮大。
保持长远的眼光能使你优先考虑团队的最终目标，并更容易理解和妥协其他功能。它将时刻提醒你什么时候适合去争论一些东西，什么时候可以放缓某种功能的开发节奏等等。
7) Always Remember the Bigger Picture
In an organization building software, software development is one piece of a larger puzzle. Compromises will be made by each business function in order to work together, but the end goal should always be the same – to build software specifically suited for its users. This ultimately enables a business to thrive by increasing revenue and/or reducing expenses.
Keeping this perspective enables you to prioritize the end goal of your organization and more easily understand and compromise with other functions. It should also remind you to pick your battles carefully. Certain debates, even if in favor of the development team, may not be worth starting in certain contexts.
去冒险，但请先做好打算
Take risks, but calculate them first
Each of the above tips will sharpen your soft skills as a developer collaborating with others outside of the development team. Practice these strategies consistently and you’ll be well on your way to becoming a much more versatile communicator.
翻译自：Cordial Coder / 7 Smart Strategies for Communicating With Non-Technical Coworkers