技术风衣中的三个人类问题

在技​​术岗位上，我们总想当然地认为所有问题都能用技术解决。然而，软件开发离不开人，所以看似技术问题的问题，往往是披着技术外衣的三个人为因素造成的。

沟通需求

编写软件开发工单或问题单需要了解系统和工具，更重要的是，需要良好的沟通能力。一份好的工单应该清晰地说明当前情况和预期目标，并且能够理解开发人员的实际情况。

你或许会想：“我曾经费尽心思才找到解决办法，这让我成为了更优秀的开发者。他们也应该经历同样的挣扎。”或者“能够独立找到答案是一种技能。”重要的是要认识到，了解问题本身和浪费公司时间去猜测客户需求之间是有区别的。后者通常会导致多次返工。一定要给开发者留出空间，让他们自己摸索解决问题的方法。不要让他们束手无策。这意味着要根据不同技能水平的开发者，采用不同的工作方式来分配任务。

此外，如果你发现团队经常提交包含数十条评论的拉取请求（PR），那就需要调查一下了。需求需要在工作完成并提交审核之前进行充分讨论。反复看到相同的评论意味着是时候思考一下，在提交 PR 之前的沟通中，哪些环节出现了问题了。

当团队成员意见不一致时，一个简单的解决方案是创建易于查找且有文档记录的标准。然后尽可能使用代码检查工具、格式化工具和自动化检查功能来自动化这些标准。最后，使用 PR 和 issue 模板帮助大家记住一些细节。

工作跟踪很重要，有助于提高效率。然而，当项目不断膨胀、无法按时完成时，我们通常会本能地添加更多的图表、流程和跟踪措施。但实际上，查看那些在创建、分配和估算任务时没有明确列出的工作内容往往更有帮助。

将您的意见转化为反馈

代码审查是帮助开发者提升代码质量的良机，但也很容易演变成对抗。学习如何给出有效的代码反馈是工作的一部分。请摒弃“好代码”和“坏代码”这类带有道德评判色彩的说法。

缺乏依据的批评并不能提高代码质量，反而会让人们不敢轻易征求你的意见。建设性的反馈应该包含如何从当前状态过渡到理想状态。优秀的建设性反馈还包括解释概念和提供学习资源。

如果你用了“代码异味”这个词，最好紧接着解释一下你希望看到的最佳实践或设计模式。如果你只是说你不喜欢它，那它可能还会继续出现。如果你解释了你不喜欢它的原因以及你喜欢什么，那么收到反馈的人就可以把这种模式或概念应用到未来的工作中。可以利用像Refactoring Guru这样的资源，它们会用代码片段来解释各种模式。

编程很少是非黑即白的。通常，实现同一目标的方法有很多种。如果你与其他开发者交流，你会发现他们也考虑过你的方法，并且有充分的理由选择不同的方式。你很可能会发现，与各个级别的开发者进行开放的讨论也有助于你提升技能。

接受反馈

编程是一项创造性的工作。在解决问题之前，往往需要经历一番摸索。收到的代码反馈有时会让人感觉受到了极大的冒犯。但通常情况下，并非如此。事实上，反馈更多地反映了对方的感受，而非你自身的感受。

如果你知道自己很难记住这一点，那就开始留意你的回复，在回复前稍作休息，并建立一套能让你平静下来的习惯。如果文字反馈经常让你感到不安，那就安排时间和你的审阅者一起通过语音、视频，甚至如果可以的话，当面讨论你的代码。

创建协作反馈会议

创建协作反馈会议时，有两件事非常重要：心理安全感和了解你的团队。

泰勒·波因德克斯特（Taylor Poindexter）从领导者的角度发表了一场精彩的演讲，主题是“如何在团队中营造心理安全感”。作为团队成员，你也有责任营造一种氛围，让每个人都能安心地承认自己的无知，并提出看似愚蠢的问题。

我们都喜欢强制性的、有趣的团队建设会议，但了解你的团队也意味着了解他们的工作方式。如果 Suzanne 只在下午审核 PR，而 Charles 只在上午审核 PR，那么当你下午完成 PR 时，你就知道该找谁了。你可能会发现，没人会阅读 PR 描述，但每个人都会观看更改前后功能的两个屏幕录像。

让所有人达成共识的一个好方法是，将需求转化为 PR 描述中的验证步骤。例如，假设你的需求是添加一个按钮，点击后会打开一个模态框。

• [ ] 在本地运行分支
• [ ] 点击按钮
• [ ] 模态框打开

这样一来，不仅有人能立即看出你的新代码是否有效，他们还可能想到你没想到的测试方法。PR 合并后，这些步骤就可以发送给 QA 团队了！

赞美和GIF的重要性

在代码审查过程中保持积极的态度是与同事建立良好关系的最简单方法。如果你们之间的互动仅限于你对他们工作的批评，那么他们对你的了解也就仅限于此。花点时间指出他们代码中你喜欢的部分。如果你学到了新知识，感谢他们分享。留下你希望看到的认可信息。

安装GIF for GitHub扩展程序，别忘了添加替代文字！

GIF

考虑神经多样性和残疾因素

很多神经类型的人都难以应对批评，无论批评是建设性的还是其他类型的。不要指望别人能读懂你的心思或情绪。请就你需要的沟通方式提供建设性的反馈。

有时，为残障人士提供的沟通便利措施显而易见。例如，如果您的团队成员是聋人，每次通话都需要口译员或字幕员。如果团队成员有阅读障碍，您会在会议中朗读工单，而不是期望他们快速阅读。如果团队成员有书写障碍，您不会期望他们在您注视下填写工单。askJAN是一个很好的资源，可以帮助您了解您的团队成员可能需要哪些类型的便利措施。

许多认知障碍会影响人们分解工作的方式。大量的 PR 评论或冗长、模糊的问题单会加剧这种情况。如果您知道团队成员在这方面存在困难，定期沟通会有所帮助。在提交 PR 之前，最好先讨论一下工作的预期。对于在 PR 中反复出现的问题，只需评论一次即可，而不是每次都评论。研究和规划始终是项目构建过程中不可或缺的一部分，因此请务必将其明确纳入您的工作流程。

这些针对认知障碍的简单便利措施对每个人都有帮助。讽刺的是，它们往往是最难争取到的。我患有注意力缺陷多动障碍（ADHD）。我知道自己会忘记，所以不得不成为团队中最有条理的人。要求大家把事情写下来作为一项便利措施通常会被忽略，所以我自己把所有事情都写下来。我会在我的PR（Publisher，项目请求）上留下关于我决定的注释。这样，即使PR搁置数周，我和我的审阅者也能了解情况。这是一个很好的例子，说明我为了适应环境不得不学会做的事情，也是神经正常的人在意识到它对他们同样有帮助之后开始采用的方法。

当多人聚在一起时，无论神经类型如何，都难免会出现沟通问题。如果我和同事沟通时明显存在误解，我首先会问自己“下次我该如何改进？”。在任何团队中，一个好的经验法则是：如果用三到五条聊天信息都无法解释清楚代码中的问题，那就应该立即发起电话会议或临时会议。

人们通常都希望工作中冲突越少越好。如果沟通出现问题，双方都有责任努力寻找共同点。如果沟通问题频繁发生或已经越界，请毫不犹豫地寻求信任人士的调解。有时，真正的问题在于沟通实际上是其他人的职责，而他们却失职了。

不同的意见至关重要

在反馈过程中，纳入不同背景和经验的开发人员至关重要。资深开发人员从初级开发人员做起已经是很久以前的事了。要记住理解中级或高级主题所需的所有基本概念，并非易事。

在本文中，我多次强调，你需要了解开发人员的实际情况。这其中就包括认识到他们各自不同的技能。没有人是全能的，但每个人都有自己的长处。应该鼓励每位团队成员在有想法时畅所欲言。

结论

协作且心理安全的反馈流程可以迅速提高代码质量和生产力。而充斥着苛刻、缺乏依据的批评的反馈流程只会导致人员流动率上升。

如果您有关于如何改善软件开发团队沟通的建议，而我没有提到，请留言！