团队沟通(特别是通过电子邮件) - 默认打开或关闭?

时间:2009-03-23 04:14:53

标签: project-management collaboration

我是一位经验丰富的C#开发人员(约5年经验),最近我的第一个开发团队负责技术主管(在3-5个其他开发人员之间变化)。在这个角色的过去4个月里,一直存在的两难困境是试图在项目经理,客户经理,客户,设计师,CEO和我之间找到正确的沟通意识(特别是通过电子邮件)

一方面,我知道每个开发人员对项目总体方向的了解越多,他们就越能够理解他们的特定功能在大局中的范围。

然而另一方面,我的很多时间似乎在所有不同的利益相关者和管理者之间的电子邮件中丢失了,所以我想将开发人员隔离到“他们需要做什么一点点工作“将使他们免受干扰。

我认为只是BCCing所有的开发人员,所以他们可以过滤这些电子邮件,并基本上“选择”所有的电子邮件,但我担心一些开发人员会认为这是额外的噪音来处理。如果所有的开发者都希望为太多的讨论做出贡献,它可能为“太多厨师”敞开大门。然而另一方面,其他意见可以帮助我做出更好的决定(即众议院MD风格)。

Phew ......非常值得考虑。任何人都有这方面的明智指导吗?

7 个答案:

答案 0 :(得分:6)

答案 1 :(得分:5)

工程团队需要了解他们被要求在宏观层面上做事的原因。工程团队将从中获得理解和动力。但过多的喋喋不休是一个禁忌,正如你所说,你的工作的一部分是过滤,其中一部分意味着不要让它们暴露在大量的噪音中。您的开发人员可能对如何做特定事情或为何选择特定技术有意见和见解,并且应该根据他们在这些领域的专业知识进行调查。

绝对不要创造BCCing的文化。

一种选择是拥有感兴趣的各方可以订阅的单独邮件列表,但当然,并非所有聊天都在这些列表上。

当然,定期举行公司会议是必须的。让工程人员知道为什么业务依赖于提供稳定,完整的产品(或者即将到来的里程碑所需要的)。 20分钟,没有幻灯片,没有废话对我有用。你的团队和团队情况可能会有所不同。

答案 2 :(得分:3)

一种方法可能是不转发所有这些电子邮件,每周一次将所有相关信息,设计更改等汇总到每周会议中。我绝对不会向开发者发送大量电子邮件。当然,如果讨论一些关键问题,那么应该引起他们的注意。但是,请尝试每周回顾一下相关细节的讨论。

答案 3 :(得分:3)

我将使用Wiki,您不希望添加到电子邮件风暴中,您的开发人员也可以贡献和更改内容。它对于共享文档也非常有用,如果做得好,它将变得自我支持。

从电子邮件到维基的BTW剪切/粘贴似乎是一件很奇怪的事情,有没有人知道我可以通过电子邮件发送内容的光线.Net维基?

答案 4 :(得分:3)

这听起来像是技术性的,所以我会给你这个建议:关注Joel Spolsky关于项目经理做什么的建议。基本上,尽可能地隔离开发人员,以便他们尽可能高效。

他刚刚在最近的一篇文章How to be a program manager中简要地提到了这一点,但他之前对这个话题进行了更深入的研究。查看他过去的着作以获取更多信息:

  

一旦规范完成并且开发团队开始工作,我有两个职责:解决有关设计的任何问题,并与所有其他团队交谈,以便开发人员不必这样做。 / p>

如果您不是技术人员,那么您需要从您的团队中选择某人来帮助完成设计工作,他们必须与客户进行一点联系,以确定要求是什么以及最佳设计是什么。< / p>

编辑: 在Joel's home page上有两个标题为Tech Lead和Program Manager的部分。查看那里的文章,了解有关项目经理的更多信息,尤其是Human Task Switches Considered Harmful

答案 5 :(得分:1)

我在发布这个问题一年之后就看到了这个问题,但是我可以为我的案例添加一些特定数据的经验。对于该项目的2-3位开发人员,我大多数都是一对一的。很多时候我通过IM或手机这样做,因为我的团队大部分时间都花在家庭办公室。不时召开会议是不可避免的,大部分是在项目启动时(1-2个开发人员会议往往足以启动相当复杂的项目),但作为一项规则,所有与公司其他人的沟通都通过我和开发人员获得摘要。唯一的例外是当我直接将开发人员与用户(而不是管理人员!)联系起来以计算项目的细节时。

我倾向于避免定期会议(每周或每天),并且只在至少有两次会议按此顺序安排会议时安排会议:

  1. 重要信息(取决于紧急程度,可以等待一周)
  2. 开发人员在办公室,最好是出于其他原因(开发者与开发者会议)
  3. 客户端可用(那里没有多少选择,但我会尝试与客户进行会议并将开发人员与单亲实践专家联系起来)
  4. 我需要设计建议(因为我是技术主管,我负责大多数高级架构决策)
  5. 对于4-8人的团队(8人通常意味着两个团队)我发现每周大约一次30分钟的短暂会议足以让每个人都保持最新状态。当然,这是我每天为初级开发人员进行的一对一,对于高级开发人员每周大约两次。

    对于一对一,我更喜欢开发人员在他们寻找更多工作或者他们刚开始做任务时遇到问题时与我联系。对于我来说,如果没有开发人员需要考虑让我保持最新状态,这也是一个很好的方式来关注事情的进展。当IM足够时,我倾向于避免发送电子邮件,否则切换到手机(当有什么要解释或讨论时)和电子邮件:

    • 客户通过电子邮件报告错误
    • 有许多重要的小细节,开发人员可能会在实施过程中多次查看该电子邮件

    当需要协调某些事情时(例如,当Java和Javascript开发人员需要编制接口详细信息时),还有开发人员与开发人员会议。

    这种工作方式意味着我必须尽快响应IM,并且我通常会处理大量中断,以便开发人员只需处理我或其他开发人员的中断。哪个是好的,因为我的工作的重要部分是让开发人员有效。

    如果我需要和平编码(并且可以负担得起),我发现将客户沟通委托给非技术项目经理甚至是beta测试人员(他们的干扰比程序员好得多)。

答案 6 :(得分:0)

问他们喜欢什么。我认为他们宁愿不在每封电子邮件中使用cc,也会选择定期进行简短的口头更新。