如何与开发人员合作——非开发人员指南

软件开发者们，你们有没有被非开发人员的同事误解过？这种情况我们大多数人都会遇到，所以我写了这篇文章，希望能帮助大家理清一些最常见的误解、沟通不畅以及错失的机会。欢迎分享这篇文章给任何想更轻松地与开发人员合作的人。

下面，我将分享我（完全客观😉）关于如何与软件开发人员合作的观点。我的目标是，每位读者在阅读本文后，都能充满信心地利用我们将共同回顾的一些行之有效的工具和策略，与自己的开发团队高效合作。

开发人员：他们就像我们一样……或者他们真的像我们一样吗？

那么，为什么有必要进行这样的讨论呢？开发人员真的和普通同事有那么大的区别吗？

是的，是的，我们确实是。

以 Flatiron School 的工程团队为例。这是去年夏天我们一起在办公室外的公园里开心地工作的照片。

我们为什么在公园里？嗯，这是下午5点半左右，我们办公楼发生火灾，人员疏散后不久发生的事情。警报响起后，办公室里的其他人都做了意料之中的事：回家休息。

我们不是。没有任何预先计划或沟通，我们所有的工程师都拿起笔记本电脑，鱼贯而出，在最近的长椅上坐下，然后立即回去工作。

就像我说的，我们有点不同。

为什么要弥合差距？

作为一名训练营毕业生，我的职业生涯并非以程序员的身份开始的。我曾在多个不同的领域工作过——既有科技行业，也有科技以外的领域——在每个工作场所，开发人员和公司其他员工之间都存在着隔阂。

由于我曾经站在这一分歧的两边，所以我认为自己拥有独特的、见多识广的视角，而且据我所知，这些问题几乎完全是由于沟通不畅造成的。

这是件好事，因为这意味着只要双方多一点同理心，我们就能弥合分歧。我们也希望这样做，因为这样做的回报无疑是值得的。

在这里取得成功符合每个人的最佳利益。拥有一个快乐高效的办公室不仅对您的企业有益，而且对个人也大有裨益。能够与“对方”沟通是您可以带来的最宝贵的技能之一。

• 具有良好沟通能力的工程师被认为比具有更多技术技能但沟通能力较差的工程师更优秀。
• 同样，能够“说开发人员”的非技术人员被认为更有价值，因为工程师更有可能为他们完成工作。

那么，我们面临的障碍有哪些呢？我们来探讨一下其中最大的两个：词汇和误解。

词汇

开发人员、工程师、程序员

这些术语之间有什么区别？就你的日常工作而言，没什么区别。这些术语描述的都是写代码的人。没必要把事情弄得更复杂。

对于任何对技术区别感兴趣的人，请查看Alan Skorkin 的这篇博客文章。

功能开发

大多数公司的工程工作流程是什么样的？大多数初创公司都遵循某种版本的敏捷 Scrum 流程，产品、工程和 QA 团队的成员与利益相关者一起合作交付功能。

• 产品经理负责监督功能构思、管理积压工作。
• 产品经理与利益相关者和工程部门合作，确定冲刺所需的独立故事/票证集
• 产品经理（和/或工程经理）将票分配给开发人员。
• 开发人员通过每日站立会议和产品经理的反馈来处理故事。
• 工程和产品与 QA 合作在发布前进行全面测试
• 审查（最好进行“回顾”，让所有参与者提供反馈）
• 向利益相关者发布/交付
• 重复

这就是理想的流程。查看“真实”图片：http://www.projectcartoon.com/cartoon/2

故事/门票

在冲刺阶段，工程工作会被分解成多个故事（你可能也听说过“工单”）。每个故事代表一个独立的任务或工作单元。

任务通常分配给单个开发人员。

在 Flatiron School，我们喜欢使用 Github Projects 来管理我们的项目队列（在此处和此处阅读更多信息）。

堆栈

您可能会听到工程师提到“堆栈”。

“您正在使用哪种堆栈？”

“你的堆栈是什么样的？”

维基百科将软件堆栈定义为：

“创建完整平台所需的一组软件子系统或组件，使得无需额外的软件来支持应用程序” - https://en.wikipedia.org/wiki/Solution_stack

这是我们支持Learn.co 的堆栈的图表。

是的，我展示这个图主要是为了吓唬你。

如果你请一位工程师描述一下你公司的技术栈，他们可能会勾勒出类似这样的轮廓：实体和关系，与其说是详尽的细节，不如说是更高层次的抽象。对大多数人来说，这样的信息量已经足够了。比如汽车发动机。我们大多数人不需要知道它内部的具体工作原理。我们只需要知道油进去，然后油出来，驱动车轮的力就行了。

所以，不必担心完全掌握这些知识。它对每个人来说都很复杂，即使是最有经验的工程师。

后端 vs. 前端 vs. 全栈

您还会听到工程师们谈论他们在堆栈的哪个部分工作。

“我们正在寻找一位前端专家。”

“她是一名后端工程师。”

“我们希望我们所有的工程师都是全栈工程师。”

这些术语大致指的是工程师大部分时间花在代码库的哪个部分。

• 后端负责数据处理。
• 前端处理 UI/UX（用户界面、用户体验）。
• Fullstack 可以做所有的事情。

请记住，这些类别之间的界限是模糊的。很少有工程师只专注于其中一种。大多数工程师的工作涉及多个技术栈部分，这主要是出于必要。

请在此处阅读有关差异的更多信息。

API

API代表应用程序接口。​

API 定义了开发人员可以用来从数据源请求和接收数据的接口。

Flatiron School 的创始人Avi Flombaum喜欢用餐厅的比喻来解释 API。假设我去餐厅，特别想吃一个烤奶酪三明治。我不会直接走进厨房，开始拿三明治的配料。相反，有一个协议。我会向服务员要菜单，然后从菜单的预设选项中进行选择。我的点菜被提交后，服务员就会给我端上一个烤奶酪三明治。

把菜单想象成你的 API。它包含餐厅预先设定的选项，允许你请求和接收食物。

公共 API 的工作方式也类似。例如，如果我想在我的网站上发布 Twitter 消息，我可以使用Twitter 的 API请求推文数据，并遵循他们定义和记录的规则。

请阅读HandsConnect 博客上的更多内容。

:shipit: 松鼠

这个小可爱最初只是Github内部的一个玩笑，但它的可爱很快就传遍了整个行业。当你的代码获准发布时，你的队友会给你的代码加上 :shipit: 松鼠的标签，这是代码推送的通用吉祥物。

所以，如果你注意到你的工程团队分享了一堆松鼠图片，别担心——他们并没有疯。他们只是很兴奋地想给你的用户推送一些新代码。

请在此处和此处阅读完整的传说。

误解

误解1

对还是错？ “工程师……不喜欢和人说话。整天写代码很有趣，和人说话简直是折磨。”

错误的。

工程师和普通同事一样，也喜欢社交。我们只是非常珍惜自己宝贵（且有限）的注意力。

1. 根据情况选择合适的沟通渠道。

不同情况需要不同的沟通方式。请根据情况的紧急程度选择合适的渠道。

2. 尊重指挥系统

大多数情况下，您应该先与经理沟通，而不是与某位工程师沟通。经理最了解团队的空闲时间、能力和工作量。请相信他们会妥善处理您的请求。

误解2

对还是错？当你向工程师提出要求时，不要问得太详细。他们是专家，所以让他们决定怎么做。

错误的。

工程师是注重细节的问题解决者。模棱两可会减慢我们的速度；我们需要填补的空白越多，最终产品就越有可能让人不满意。

以下是Salesforce 工程团队的一个真实故事，讲述了精准的重要性。一位 Salesforce 产品经理要求“账户更新后，给账户所有者发一封电子邮件”。开发人员同意了。结果，账户所有者收到的第一封邮件显示“正确”。

记住要明确定义你期望的结果，而不是实现结果的方法。例如，利益相关者经常会要求提供特定格式的数据（例如 CSV），然后他们会将这些数据上传到 Google 表格，并花费数小时制作数据透视表等等。更简单的方法是直接告诉开发人员，他们需要从这些数据中获取 X。开发人员可能知道一种更简单、更快捷的数据分析方法（例如使用Periscope等工具）。

最后，不要对开发人员隐瞒任何事；如果您认为功能需求很快就会或最终会发生变化，请提前披露。这样，工程师就可以相应地调整设计，在灵活性和速度之间取得适当的平衡。

误解3

对还是错？工程师喜欢细节，讨厌开会，所以在项目开始前，最好先把所有事情都规划好，然后再让他们参与进来。

错误的。

尽早让工程师参与进来。他们的见解可以让你避免将时间和精力投入到不切实际的目标中。让他们参与决策过程，还能让他们感受到对项目及其成果的更多投入。

Cliff Gilley 很好地描述了这个问题：

“……许多公司倾向于将开发团队与‘业务’‘隔离’……这是一种非常偏颇的思维方式，通常会导致期望人们在不了解具体背景的情况下执行任务——不了解愿景、战略、战术，尤其是客户。问题就在这里——当人们拥有共同的未来愿景，并能在愿景中看到自己和自己的贡献时，他们最有动力。” [来源]

练习

让我们练习一下目前所学的内容。所有示例均由Flatiron School的顶级工程师之一Spencer Rogers提供。

对话 1：项目经理与工程师

项目经理：
密码重置功能进展如何？

开发人员：
我开始研究 Postmark API 并安装了他们的客户端库，但由于我们用于图像处理的库已经过时，我开始在开发环境中遇到一些问题。

粗略翻译： 我正在工作。

这会让项目经理感觉如何？ 困惑、焦虑、无助、不耐烦，甚至质疑开发人员的常识。

这是良好的沟通吗？ 不是。

哪些信息有意义？ 我需要了解你的进度，以便评估是否需要分配更多或更少的资源。

我应该说什么呢？ 我遇到了一个障碍，耽误了大约一天的时间。

对方该如何回应才能得到更好的答案？ 这会对最初的估算产生什么影响？你需要我做些什么来解决这个问题吗？

最初的问题可以怎样问得更好？ 我正在做下周的作业。你能快速更新一下密码重置功能的最新进展吗？

对话 2：市场经理与工程师

市场经理问开发人员：
您能在今天结束前为我们构建一个能够解决注册转化率问题的方案吗？

粗略翻译： 你能否在任意时间范围内做一些你不知道如何做的事情，而这些事情可能是现实的，也可能不是现实的？

这是良好的沟通吗？ 不是。

这会让开发者感觉如何？ 不知所措、得不到支持、不被尊重、感觉像机器里的齿轮一样，而且因为这个问题对他们的能力和现实如此无知而恼火，等等。

什么才是有意义的信息？ 我们需要构建一些东西来解决业务问题。

应该怎么说呢？

a) 新服务注册的人不多。你知道怎么解决这个问题吗？不知道？那我们想想办法，在截止日期前你能实现什么。

b) 新服务注册人数不多。你知道该怎么解决这个问题吗？是的？太好了。搭建这样的服务需要多长时间？（然后可能）这太长了，有没有更简单或者临时的解决方案？

对方该如何回应才能得到更好的答案？ 我可以尽力而为，但我以前从未这样做过，也不知道需要多长时间，也不知道是否会有效。

对话3：从工程师到CEO

开发人员：我刚刚用了一个非常酷的算法，用一种叫做“Levenshtein距离”
的东西来猜测相似的单词。数据一致性问题应该由EOD来解决。

首席执行官：
好的，但是登陆页面更新怎么办？

开发人员 粗略翻译： 我只是做了一些很酷的事情来解决问题并按时交付。

首席执行官 粗略翻译： 我希望你能解决这样的问题，那么真正能推动业务发展的事情呢？

这是良好的沟通吗？ 不是。

开发人员的感受如何？ 自豪，但又因自己的工作未获赏识而感到不开心，而且开发进度仓促。

CEO 的感受如何？CEO 感到很焦虑，因为他觉得公司在庆祝一件阻碍业务发展的事情，而他原本可以实现的愿景却还没实现。

两种观点：

1) 开发人员每天 99% 的时间都在开发一些别人无法看到或欣赏的东西。这很令人沮丧，尤其是当他们开发出引以为豪的东西，却连续数周都沉浸在其中时。

有些开发人员会降低自己的效率，仅仅是为了满足等待他们产品的用户的期望。如果没有一个可以信赖的窗口，评估起来会很困难。

成为一名“优秀”开发人员的方法有很多。在小型初创公司，一个好的衡量标准是开发人员是否为公司创造了价值，而这可能很难衡量。开发人员创造价值的很多方式对公司很多人来说都是看不见的。

CEO 的最终目标是公司取得成功。作为一名开发者（或任何人），你应该尽力理解公司的高层目标。

这并不意味着他们天生就刻薄。如果你有两家公司，收入完全相同，但一家拥有健康的文化，另一家拥有不健康的文化，你会选择哪一家担任CEO？

2）不过，最好找其他人来讲述你的酷算法。

对话 4：工程师到产品经理

开发人员对产品经理说：
我正在开发搜索功能，发现有些筛选选项放在一起不太合理。如果我们这样改一下会怎么样？

粗略翻译： 我当时正在处理这个问题，但我的常识突然发挥作用，让我意识到它说不通。不过我有个办法可以解决这个问题。

这是良好的沟通吗？ 是的。

哪些信息有意义？ 一切。

应该说什么比较好呢？ 或许可以对提案做一个估算。

这怎么会出错呢？ 如果开发人员在没有征求任何人意见的情况下就修改了内容，情况会怎样呢？这并不意味着他们必须放弃产品的全部所有权，但每个人都应该达成共识。很多人可能都在考虑这个功能。

这里的最佳行动方案并非适用于所有地方的最佳方案。务必了解这些措施的运作方式。

要点：为了伟大的利益你可以立即做的事情

1. 带工程师出去喝咖啡:)
   • 了解他们对这个问题的看法——他们对与开发人员良好合作有什么建议？
   • 询问他们正在做什么
   • 也询问与工作无关的事情
   • 总体来说：与其他部门的人一起度过游戏之夜、午餐、咖啡
2. 参加开放工程活动（演示、回顾、代码讨论）
   • 熟悉团队及其工作内容
   • 熟悉共享词汇和公司术语
3. 进入产品
   • 寻找与开发人员合作的机会（不一定是开发项目；可以是活动组织等）
   • 自愿帮助其他团队。以下是一些个人经历​​：
   • 协助 QA / 用户测试
   • 举办聚会活动（并协助布置/拆除）
   • 撰写博客文章
   • 用户拓展

最后，同样重要的是，当你欣赏开发者的成果时，请告知他们。谢谢！

有兴趣加入一支重视跨部门有效沟通的团队吗？Flatiron School 正在招聘！

资源：文章

1. Krzysztof Rakowski - 如何在 IT 项目中有效沟通
2. Julie Zhuo - 如何与工程师合作
3. Nicholas Zakas - 软件工程师的照料与培养
4. Cliff Gilley - 如何与工程师有效合作
5. June Cohen - 如何与工程师合作完成 Web 开发项目
6. Stella Garber - 与开发人员合作的 5 个最佳实践

资源：视频

1. Laura Klein - 打造像 Heist Teams 一样快乐的产品团队
2. Ryan Hughes - 弥合设计师与开发者之间的差距
3. Salesforce 案例研究 - 管理员和开发人员如何协作
4. Ron Lichty - 如何让你的开发团队喜欢你