改善软件团队成员之间沟通的方法[关闭]答案

【问题标题】：Ways to improve communication between members on a software team [closed]改善软件团队成员之间沟通的方法[关闭]
【发布时间】：2010-01-29 19:28:42
【问题描述】：

随着我所在的团队致力于规范化和建立更多的开发实践，我发现沟通似乎在以下几点上失败了：

在关于项目的非正式对话中，大脑火花时刻成为一项新功能/要求。这些“附加组件”似乎在一段时间后无法通过裂缝或细节变得模糊。
在没有明确委派目标或任务的会议中，参与会议的成员对实际讨论的内容有不同的说明。
作为一个团队，我们不断受到挑战（现在更是如此，因为我们确实渴望编写它们）来生成质量规范和技术文档，以准确详细说明项目中需要具备哪些功能。
李>

我的问题是：有哪些建议和方法可以解决这些沟通瓶颈和效率低下的问题？没有程序员喜欢编写文档，但希望有一种方法可以让我们集中理解并在项目的生命周期中使这些信息更加可见和可用...

感谢您的帮助！

【问题讨论】：

投票结束...这不是与编程相关的问题，而是与团队管理相关的问题，同样的问题几乎适用于任何业务。
不确定我是否同意。程序员，尤其是年轻人，因不想记录任何东西而臭名昭著，根据我的经验，比其他商务人士更是如此。
与编程非常相关！很少有企业会遇到与程序员相同的设计问题，即使它与所有企业相关，也恰好是每个程序员最终都必须处理的问题。
@Andy E：“编程相关”与“编程特定”不同
我投票决定将此问题作为题外话结束，因为这是为工作场所提供建议，更适合工作场所.stackexchange.com

标签： communication methodology

【解决方案1】：

坚持议程。保持目标。当事情开始偏离轨道时，要么安排另一个会议，要么在会议结束后将其发送到电子邮件中。

以行动项目结束每次会议 - 一份书面清单，列明谁将在预期的时间做什么。是的，这意味着有人需要在会议期间编写/输入内容。

如果文档变得重要且需要，那么我强烈建议您提出简单的标准，然后坚持下去。

维基。维基。维基。所有对团队有用的“部落知识”信息都需要进入 wiki。如何搭建开发环境、常用调试技巧等。

【讨论】：

【解决方案2】：

记录一切，而不是在电子邮件中！

使用有历史的东西。我一直很想使用 Google Wave 来跟踪项目的“开发”（不断变化的需求、解释等）。 wiki 也可以，但编辑障碍更高，更新的人可能更少。 Campfire 也是一种很好的方法。

新方法（Campfire/Wave）本质上是记录的聊天日志，您始终保持打开状态。 Campfire 没有办法“促进”重要决策，我认为它们会在一般对话中迷失——但使用 Google Wave 和 Wiki，您可以不断删除不相关或旧信息。 Wiki 将为您提供更多重新格式化新内容的能力。

实际上，Wave/Wiki 的组合可能是最好的。只需使用 wave 进行日常 IM 类型的谈话，并将重要的线程/决策拉到 Wiki 上。

XP（敏捷）中的一些实践在这里也有帮助。如果您使用 FULL ON xp（不仅仅是将您的日常会议称为“Scrums”），您会发现一些重要的帮助，例如跟踪不断更新的卡片上的需求或让客户在现场回答重要问题。 XP/Agile 的整个理念是基于这样一个事实，即需求发生变化，这些变化需要被跟踪，并且它们会影响发布计划。

【讨论】：

向上的勾表示“不在电子邮件中”

【解决方案3】：

在结束会议之前，领导会议的人应说明行动项目，当然还有谁将执行这些行动，并征得指定人员的同意。应该指派某人创建会议记录并发布它们。您可以尝试轮流记笔记，以便每个人有时都必须这样做。你可以试试 scrum master（如果你正在做 scrum）。

尝试使用 wiki 获取注释。会议记录应包括行动项目。所有操作项都应该有一个与之关联的日期。

如果您无法让任何人认识到您所做工作的记录很重要，那么您的开发人员就遇到了严重的问题。当然你可以给白板和笔记拍照，但这无助于阅读和维护问题。

许多程序员（包括我自己）都非常喜欢编写文档。

【讨论】：

【解决方案4】：

我发现在 Wiki 或便利贴上记录决定的原因很重要。没有它，在可以实现两个选项的关键项目上，您将看到一位开发人员反转另一位开发人员的某些代码。两者都可能有正当理由，但这是缺乏沟通的明显迹象。

为避免此类问题，需要重复会议的关键决定，甚至在一个月之后。

【讨论】：

【解决方案5】：

为什么不将这些会议的笔记保存在 wiki 中，以便其他人可以看到，人们可以对其进行修改以澄清歧义，然后您就可以提醒您达成的共识。

然后您可以获取这些功能，并将它们放入您的错误跟踪软件中，这样您就不会忘记有等待实现的功能这一事实。

【讨论】：

这是我的第一个想法，但作为一般规则，没有人愿意花时间编写和维护文档。以高度可见的格式捕获信息是我正在寻找一种聪明的方法......
我们的团队已经尝试过：问题是许多程序员不会努力记录想法和会议，而更愿意只编写代码......现在怎么办？
让某人自愿帮助将信息放入 wiki，或者，当您完成后，为白板拍照，然后将其作为 wiki 中的数据捕获开始。你可以在会议期间给 wiki 写信，稍后人们可以清理它。如果程序员不关心良好的沟通，那么这就是你需要解决的文化问题。
人们通常会做他们得到奖励的事情，并避免他们受到惩罚的事情。研究所文件审查。
如果没人想记笔记，是时候长大了。保持良好的会议记录、wiki 等是专业编程的一部分。这是我们的工具之一，也是您必须做的事情之一。避免编写 30 页的技术规范，但保持部落知识的最新 wiki 至关重要。

【解决方案6】：

至于#1：一个新想法的便利贴怎么样？创建一个在工作环境中高度可见的区域。在讨论想法时，在便签上贴一张提醒便条并放在黑板上。保持板按类别划分（即 UI、性能改进等）。当需要添加细节或想法足够好以至于值得在设计中花费一些真正的精力时，负责任的成员可以负责将这些内容转录到完整的 wiki。

至于 #2：如果您的团队无法保持目标，那么 mtg 组织者肯定必须花时间准备议程并裁定对话保持主题并坚持会议按时结束。离开会议知道谁必须做什么。

至于 #3：必须有人带头，找到您喜欢查看的文档和规范类型的示例，并安排一些时间与团队一起审查和讨论。

【讨论】：

【解决方案7】：

我认为 wiki 或内部博客可以很好地为所有团队成员记录有用的程序。

但另一个有趣的点是当一些程序员对实现有疑问时程序员之间的沟通。例如：程序员不知道如何实现某些功能。因此，它可以在“短消息应用程序”中发布您的疑问，例如 twitter（但有超过 140 个字符）。然后，一些知道如何解决她的疑问的开发人员可以发布解决方案。所有消息将被存储，直到找到解决方案。因此，团队的所有其他成员将来都会关注这个解决方案。

我认为这种模式很好，因为有时开发人员不喜欢“浪费大量时间”在博客或 wiki 上写一篇文章。

【讨论】：

【解决方案8】：

我使用BaseCamp 来管理我的项目。会议变成有趣的头脑风暴会议，然后将工作委派到网站上。

【讨论】：

【解决方案9】：

如果我们正在讨论以取代语音和文字的方式保持联系，请查看http://CircleHubb.com。您不仅可以在同一组的成员之间进行讨论，还可以共享 pdf 和 word 文档、照片和视频。您还可以将您的群组设为私有或公开。他们的应用程序也应该很快就会推出。

【讨论】：