程序员应该多久与管理层沟通一次？

Question

我正在努力寻找一个好的沟通媒介。在我们的工作中，似乎很容易迷失在代码中，忘记时间。为每一个小任务发送更新似乎也有些可笑。尽管我正在努力完成工作，但在一家其他部门之间沟通非常活跃的公司里，当我不经常更新我的状态时，这对我来说似乎很糟糕。然而，如果我正在做一个3-4小时的项目，我不会为我输出的每一行代码更新管理。

广泛，我知道，取决于人，公司等，但什么是有效沟通的好的一般经验法则？

Answer 1

你需要理解为什么经理需要你的沟通。我过去曾管理过开发团队，目前我是一名编程人员，所以我已经看到了沟通的两方面。

经理通常没有时间与您的编码密切相关，主要是因为他们还必须与您团队中的其他程序员、测试人员、高级管理人员、产品经理、客户、人力资源等打交道。

您的经理已承诺交付软件，并委托您交付部分软件。因为他没有时间和你打交道，所以他需要信任你。(S)他相信你会专注于你的工作并交付软件。如果你搞砸了，他也会受伤的。

沟通的目的是展示对目的的了解，展示焦点，展示结果。以下是主要的交流形式。

• 高级设计传达的信息是，您知道自己被委托交付什么。它不一定是花哨的。我对良好的数据模型的粗略草图、详细的关键用例以及与第三方软件的接口感到满意。
• 开发计划看似合理地表明您理解交付所需的步骤。我发现，无论我是经理还是程序员，交付工作用例都是最好的，因为这是独立验证有用工作完成情况的一种明确方式。
• 定期状态更新很好，因为它们体现了焦点。作为一名经理，我不关心你是否做过这样或那样的工作。我关心的是你交付了什么。从开发人员的角度来看，提交状态报告的最佳时机是将代码提交到源代码控制中。当然，你需要好的评论来表明你是按照计划交付的。这也是一个自然的交付时间，因为它代表了“流”的结束或“在区域”的一段时间。
• 标记障碍很重要，因为它展示了对目标和重点的了解。一个好的经理会帮你解决这些问题，但他必须了解这些问题。
• 处理bug是一个特别敏感的时期，因为bug代表了信任的崩溃，因为在经理的心目中，你没有实现你所说的事情。在这里保持额外的沟通是非常重要的。

随着时间的推移，良好的沟通将建立良好的信任，最终是你的工作的质量和数量将决定你的信任。

对于3-4个小时的项目，你必须在开始时、结束时和任何代码上进行状态更新(但如果你不这样做，也没什么问题)。

Answer 2

敏捷方法论认为你应该在代码开发上有两周的周期。我认为在大型项目的沟通上也是如此。我试着每两周进行一次重要的交流。这包括我在所有项目和所有东西上的状态。这可以是电子邮件、电话或面对面的形式。在我看来，比这更频繁地沟通的唯一原因是，如果你遇到了障碍，需要你的经理帮助你克服它，或者如果你正在处理一个项目或任务，他们在完成时需要反馈。通常，这会将不必要的通信保持在最低限度。

另一种方法是直接去见你的经理，问他们想要什么类型的沟通，以及多长时间一次。一般来说，好的经理只想在出现重大问题时或每周/每月更新一次。你需要与他们讨论什么才足以让他们保持在循环中，而不是浪费你或他们的时间。

Answer 3

这是一个有趣的问题，因为它突出了一个程序员的语言能力，他最终在编码的过程中消耗了所有其他似乎“无关”的东西，在那里，做了那件事却带来了灾难性的后果！

不要害怕说出来……

如果当你用简单的术语与他们进行code...try交谈时，有什么困扰着你，归根结底，管理层不想知道指针操作、TCP/IP协议栈、WM_PAINT上的控制更新、动态映射网络驱动器以获得一些data....you的内部细节。

说得清楚而简洁，在wrt中对say...pointer操作和seg错误说些什么，只要说“代码内部存在一些问题，导致它行为不正常，我会估计n时间来纠正这个问题，并将其记录下来，并将问题尽快解决”，其中n是一段时间，可以是分钟/小时/天/周，甚至更糟糕的月/年……

如果你遵循这种模式，这就是管理层想要听到的，如果他们听到了积极主动的方法，那就是你获得融洽和信任的地方，信任程度也会加深。当然，that...the管理上有一个“小故障”，最终可能会堆积起大量的信任，这等同于对你的谨慎负责，而不是在想“天哪，他们喜欢我”的同时让你背负着代码的“责任”而自欺欺人……在沟通和他们想要的东西之间有一个很好的平衡，I hear...by 讨厌为了取得成功而拍拍自己的屁股的概念...不要！

道德底线和底线(我是个耳聋的人，发现沟通非常令人沮丧，让我感觉自己被贬低了或没有被倾听，这很难处理，因为我很容易曲解或误解所说的话，这是我的经验)清楚地表达出来，不要害怕说出来，无论编码挑战是大是小，或者如果挑战是无法克服的，毕竟，这需要团队努力。与团队分享。如果什么都没有分享，团队中的每个人都处于孤立状态，什么也没说，我会很小心的……这是可疑的……