我是一位经验丰富的C#开发人员(约5年经验),最近被我的第一个开发团队负责作为技术主管(在3-5个其他开发人员之间变化).在这个角色的过去4个月中,一直存在的两难困境是试图在项目经理,客户经理,客户,设计师,CEO和我之间找到正确的沟通意识(特别是通过电子邮件) .
一方面,我知道每个开发人员对项目总体方向的了解越多,他们就越能够理解他们的特定功能在大局中的范围.
然而另一方面,我的很多时间似乎都丢失在所有不同的利益相关者和管理者之间的电子邮件海洋中,所以我想将开发人员隔离到"他们需要做什么工作当前的工作" "将使他们免受干扰.
我考虑过只是BCCing所有的开发人员,所以他们可以过滤这些电子邮件,并基本上"选择"所有的电子邮件,但我担心一些开发人员会认为这是额外的噪音来处理.如果所有的开发者都希望为太多的讨论做出贡献,它可能为"太多厨师"敞开大门.然而另一方面,其他意见可以帮助我做出更好的决策(即众议院MD风格).
Phew ......非常值得考虑.有人在这方面有一些明智的指导吗？
回答得很晚,但仍然相信到目前为止给出了一些极好的建议.要回答你的问题,我们需要提高一级,因此需要长时间的回应.
你已经成为了一个负责团队的技术主管,虽然你日常工作的许多方面看起来都像你的开发日,但你需要去做的方式也发生了变化.在软件开发环境中,当您指定技术主管(您可能仍然坐在同一张桌子上,穿着相同的服装)而不是成为建筑工地或工厂的工头时,通常没有那么多切实的变化.令人欣慰的变化是,您现在被邀请参加所有这些会议,并开始从开发团队以外的人那里收到所有这些电子邮件和电话.
缺乏切实的改变可能会让你觉得你只需要保持对待你的工作大致相同.情况并非如此,您需要了解自己的行为和新行动中的重新行动.看起来你现在在外部有点"受到尊重"了,你可能倾向于分享一些内部的"尊重",发挥一点民主,一般都是公平的.
嗯,这不是关于公平或尊重,新工作是:
指导开发团队(主要通过个人示例并创建描绘目标的图像).
是团队和其他组织单位之间的抽象层.
与编程一样,您经常创建一个抽象层来封装和隐藏复杂性,组织中也是如此.你是层,是必须封装开发团队的接口.从局外人的角度来看,任何良好的封装:
隐藏与外部观察者手头的任务无关的内部复杂性(例如算法的具体实现).
使可能影响外部用户的内容显式化(可抛出的异常,任何限制和约束等).
始终提供有意义的反馈
行为一致.
这些原则同样适用于团队的外向沟通.遵循这些原则并非易事; 实际上,它涉及许多具体的工作,例如决定内部的细节和需要传达的事实以及何时,反馈需要如何最好地构建和以一致的方式呈现以及谁应该在外部通知什么,谁需要跟进和何时.这是很多工作,即使其中一些似乎只是琐碎的管理员.
现在进行内部,内向沟通.一种方法是广播.但它堵塞了内部网络,每个人都必须花时间决定沟通是否与他们有任何关联.这就像拥有一个非常通用的算法,无论输入总是完成相同的工作量.这肯定有可能,但你为什么要这样做呢？一种更有效的方法显然是根据输入调整处理,这里必须是某人的工作来决定团队应该如何处理,调度或转换输入:
确定需要采取的行动顺序,
或者只是确认并存储以备将来参考,
或跟进,
或者提出一个问题供以后审查,然后确保审查并反馈到决策循环中.
这也不是一项小工作,有人必须这样做.显然现在管理外向和内向沟通是你的工作,你必须花费你大脑的一些处理能力来做好,所以没有其他人必须和开发人员专注于他们的任务.
不管你的职称如何,还有一些其他很好的理由没有CC-ing或BCC-ing所有人:
TO表示"采取行动",CC - "记下以备将来参考",BCC - "窃听或群发邮件".当您使用一个或另一个电子邮件通知一组人时,您应该小心:
通过电子邮件发送单个人是一个直截了当的"TO",当通过电子邮件向一群人发送"TO"时,您需要采取行动(包括简单的确认).这是默认含义,在任何其他情况下明确告诉他们预期的内容(即FYI,不需要采取任何行动等).
CC只有这些你想要注意的信息供将来参考.如果您希望在达成协议之前来回发送许多电子邮件或解决问题,请不要"CC",最好稍后向需要通知的其他方发送摘要确认.除了节省每个人的时间和避免误解,因为有人注意到非最终的沟通,这将有助于使交流更加个性化,更自然地流动,并减少形式主义和繁文缛节.通常CC-d电子邮件正式处理,这并不总是一件好事(但有时候恰好是你想要的).
使用BCC几乎从来都不行.如果有人窃听您的谈话,那么这些知识很容易破坏您的可信度.这只是一个"何时"的问题.您的团队是否应该担心您可能会将他们的谈话转交给其他人？在大多数情况下通过BCC进行群发邮件也是错误的,它会产生一种印象,即电子邮件专门发送给收件人.
转发,CC-ing和BCC-ing需要很少的努力,但是会增加噪声并稀释信号.值得一提的是,在撰写之前,你需要一个人做什么以及他们应该知道如何对你的沟通采取行动.
有些对话最好完全"离线"(电话或更好的面对面),因为它给你更多的空间.写作中的广播或形式化就像把自己置于角落里一样.您可以随时以书面形式确认.
转到技术主管责任的第二部分(指导团队通过个人示例和描绘目标的图像).为了实现这一目标,您无需向收集在收件箱中的每一条信息传递给团队.你必须创造一个故事,任何好的故事都是真实事件的抽象,只包含特定受众的相关和有趣的细节.根据您的日常经验创建这个简短的故事,并判断相关和有趣的内容,然后定期向团队介绍它也是一项相当重要的工作.
但是不要忘记,通过指导团队并充当抽象层,您可以帮助开发人员和外部世界更有效地进行交互,完成更多工作并解决更大的复杂性,这项工作有一定的意义.
工程团队需要了解为什么要求他们在宏观层面上做事的商业原因.工程团队将从中获得理解和动力.但是过多的喋喋不休是一个禁忌,正如你所指出的,你的部分工作就是过滤,而其中一部分意味着不要让它们暴露在大量噪音中.您的开发人员可能对如何执行特定事项或为何选择特定技术有意见和见解,并且应该根据他们在这些领域的专业知识进行调查.
绝对不要创造BCCing的文化.
一种选择是拥有感兴趣的各方可以订阅的单独邮件列表,但当然,并非所有聊天都在这些列表上.
当然,必须定期举行公司会议.让工程人员知道为什么业务依赖于提供稳定,完整的产品(或者即将到来的里程碑所需要的).20分钟,没有幻灯片,没有废话对我有用.您的团队和情况可能会有所不同
京公网安备 11010802040832号 | 京ICP备19059560号-6 