开发人员与非技术同事沟通的七个聪明策略
网友 网络收集

 做项目开发需要极具技术性的思维过程,但你会发现工作不仅仅只有编程,和其他同事合作才是你工作的重要组成部分。虽然其他开发者能理解你的技术工作流程,但非技术同事不会。摆脱编程的心态和这些不懂编程的人沟通至关重要。

 试想一下这个场景:

 产品对两名开发提出了修复 bug 的需求。第一位非常详细地描述了可能包含错误的代码部分以及修复它的各种方法,列出了其中的复杂性。第二位给出了更直接的响应 - 说明问题是什么,并粗略估计修复它的时间。

 发现区别了吗?

 在与非技术同事交流时,请务必记得在必要时脱掉你开发者的“帽子”,更好地与他们接触。下面,是避免尴尬对话的七个策略。

 1)认识到你和他们之间的真正障碍

 开发写代码,设计做布局,经理带团队。但这些岗位之间的差异不会自动在这些角色之间创建通信障碍。相反,沟通障碍是由个人独特的观点造成的。

 观点的形成受许多因素影响。自身环境、个人喜好和岗位只是其中的一部分。每种因素都会影响他们独特的工作偏好。而不同的性格,往往也会决定倾向扮演的具体角色。

 了解这些不同的观点是打破沟通障碍的关键。 作为开发,你需要跨过代码库,接触和学习其他同事的想法。 

 2)真正了解需求

 了解非技术同事观点的最佳方式是抛出问题,从他们的角度了解他们特别重视的。

 也许上面的产品需要的只是一个高级更新,他可能更专注于实现一个功能,而不是技术细节。或者也许和你合作的是一个技术好的产品经理,他可能会更欣赏你编码的细节。

 通过随时提问来了解同事的需求,将能够了解如何与他们进行最佳的沟通。比如,你可以向项目业务分析师询问他们如何定义接受标准。或者可以问设计师,他们喜欢如何迭代设计。

 3)交流而不是交谈

 当与非技术同行合作时,与他们交流,而不是与他们交谈。 这里有一个微妙的区别。 前者对他们的观点有着重要的意义。

 要做到这一点,你必须先了解你交流的目的。是讨论新功能?考虑架构决策?还是 Scrum 更新?专注于交流的真正目的,尽量不要跑偏了。

 例如,传统的 Scrum 会议会涉及到已经完成的工作、正在进行的工作和更新遇到的问题。尝试解决问题并不在其目的范围之内。通过记住真正目的,从共同点进行交流。

 4)合适选择措辞

 开发技术迭代很快,来自全世界的新知识在不断涌现。对于开发者来说,跟上自己的专长就已经是颇具挑战的事了。保证整个软件开发团队与所需的知识保持同步是非常困难的。更别说是和非技术同事同步这些知识了。

 所以,拥有共通的词汇是从共同点进行沟通的关键。除非你的利益相关者想知道你正在使用的 MongoDB 实现的细节,否则最好不要去谈起它。当然,有些时候你需要以某种方式在团队间传达技术细节。

 当讨论技术时,请记住,听众可能不了解这个特定领域的知识。在谈话中注意听众的反应,并确保你们都有相互理解。保持你的沟通简短和有效。

 此外,可视化不管是在编程中,还是会议中都很重要。

 5)练习讲述你的故事

 理解听众是有效沟通的一半,理解并正确表达自己的想法是另一半。这需要足够的自我知识和实践共享,能有效地扩展你的影响力。

 第一步是知道你的观点是什么。要形成作为软件开发人员的偏好和意见,需要有足够的技术知识。努力成为你的领域的专家,学习新技术和语言,阅读博客,并观察与其相关的开源项目。

 除了这些硬技能,了解软件开发如何与诸如商业、营销、运营等其他相结合。开发过程因组织而异,了解所在的企业是如何利用软件开发来做业务的,并得出你自己的结论。

 当对自己的观点有强烈的感觉时,会使你更容易表达自己。

 6)当觉得有必要争取时拿出勇气去争

 有时,团队在构建某些功能时可能会发生冲突。如果项目落后于计划,开发可能争取的是质量代码,而产品可能更多的是想临时解决方法,设计师可能争取的是用户体验,而管理层担心的是没有资源继续维持。

 当有冲突时,当你不同意别人的意见时,学会以你作为一名开发者的视角说话。尽可能寻找共同点,并从相互理解的立场进行辩论。如果你能在上面的例子中说清楚保持高质量代码能带来的长期好处,可能别人会做出妥协。

 记住在正确的场合用正确的方式分享你的意见。记住,你的语气也同样重要。

 7)眼光尽量放长远

 在团队中,为了一起共事,妥协很可能会出现在每个业务功能环节上,但最终目标应该始终是相同的 - 构建适合其用户的软件。这最终能使企业能够通过增加收入和/或降低费用来发展壮大。

 保持长远的眼光能使你优先考虑团队的最终目标,并更容易理解和妥协其他功能。它将时刻提醒你什么时候适合去争论一些东西,什么时候可以放缓某种功能的开发节奏等等。


CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢