如何在工程项目管理中进行有效的沟通

如果你是一个工程项目经理，或者是一个团队领导，或者是任何类型的“老板”，那么以行动为导向是这个行业的基本工具。问题是，项目经理/小组领导/老板通常只代表一小部分人——相对于实际执行工作的广大工程师来说，他们只占少数。因此，在项目中以行动为导向是每个人的责任，而不仅仅是项目负责人。

例子:

• 工程师1在一个具有重要代码标准的站点工作，并且正在实现一些新的程序代码。
• 该工程师正在执行详细的测试用例，并发现一个需要解决的小代码错误。(出于本例的目的，假设代码错误很小，与安全无关，但仍需要纠正。)
• 工程师，为了确保团队的其他成员意识到这个问题，写下了如下注释:

亲爱的团队,

今天在现场工作时，我遇到了场景XYZ，不幸的是，它将导致代码行为ABC。为了解决这个问题，您需要下载附件中修改后的版本。请在当前程序中解决此问题并下载到控制器。”

上面的问题是，几乎没有人会真正做被要求做的工作。好吧，也许很少有工程师会这样做，但在一个20人的团队中，很少有可能真正把bug修复好。为什么不呢?没有提供名称、日期和实际标准来创建有效解决方案的反馈。对于技术机构来说，将通信比作“开环控制”。你发出信号，然后希望有人关闭这个循环。

让我们修改一下工程通信的这一关键部分:

亲爱的团队,

今天在现场工作时，我遇到了场景XYZ。在我们当前的所有版本中实现这个代码修复是非常重要的。为此，我们要做好以下工作:

• 更新您的程序代码，根据所附说明。这些笔记包括一个简短的“操作指南”和屏幕截图。
• 为了确认代码修复已经完成，还包括一个测试计划。请打印这个测试计划并执行它，在你去的时候检查方框。
• 我希望团队的每个成员在周二下午2点之前把他们的测试计划放在我的桌子上，以确认修复已经实现。
• 同样，我在下面列出了每个团队成员，并将每天发送列表，删除那些已经完成任务的人。

感谢所有的支持，非常感谢。如果有任何关于工作的问题，或者完成标准是什么，请给我回邮件。提醒一下，我周五不在办公室，所以你必须在那天通过手机联系我。

这两种沟通方式的主要区别是什么?

• 每个资源都有一个“地图”来帮助他们完成这项工作。示例、测试计划和关于该做什么的说明都很清楚。
• 有特定的名称和日期:团队成员明白忽略消息是不可取的。
• 有关于联系信息的额外细节。如果你在周五发了一封邮件却没有得到回复，那就没有借口了。

以下是每个参与工程项目管理(PM)的人都需要认识到的:

• 第二封邮件需要更多的工作……对每个人来说!
• 不那么好笑的讽刺是，电子邮件#1花费的工作量更少，但几乎什么也没完成。

作为参考，有很多关于这个话题的信息，一般来说，网上。(我建议从维基百科上的“做事”帖子开始。https://en.wikipedia.org/wiki/Getting_Things_Done)。对于工程师来说，大多数工程师(尤其是技术工程师)都是非常注重任务的人:他们喜欢“把事情做完”。我还发现(尽管我没有任何数据来证明这一点)，大多数工程师也倾向于“内向”的性格。您最终得到的是，有时，真正希望影响更改(例如与团队就潜在的代码问题进行沟通)，同时又希望避免冲突(例如让同行对实现修复负责)。

对于更有经验的项目经理，或者那些专注于领导/PM方面工作的人来说，上面的信息将是旧新闻。我想说的是:

• 不仅仅是总理要对这些事情负责。每个人，在各个层面上，都需要确保他们的沟通是可操作的。这意味着你，技术工程师或合作学生。
• 如果你写了一封像上面第一个一样的电子邮件，没有人做任何事情，你不应该感到惊讶。
• 写第二封邮件可能会让人不舒服，因为你要让别人负责，这需要信任、所有权和跟进，但最终，这是“完成任务”的唯一真正方法。

-自动化系统集成博客汇集了来自Callisto Integration的专家建议，提供制造咨询和系统集成。这个博客提供从工厂到企业的车间控制、制造执行系统(MES)和制造咨询方面的集成建议。安德鲁·巴克，p.p。Callisto Integration编写了这些建议。www.callistointegration.com

请参阅下面链接的其他自动化系统集成博客帖子。

Callisto Integration是一个相2015年3月1日成为会员

您是否具有本内容中提到的主题的经验和专业知识?您应该考虑为我们的CFE媒体编辑团队做出贡献，并获得您和您的公司应得的认可。点击在这里开始这个过程。