2012年8月，我从布朗大学（Brown University）毕业几个月后加入Delphix，担任软件工程师。在Delphix工作一年多后，我被邀请承担一项额外的责任，并成为我们下一个主要版本Delphix 4.1的发布负责人。作为一个强烈认同工程师的人，企业软件服务，我很紧张！我只知道，我会负责让我们的工程团队按时完成任务，并确保最终交到客户手中的产品质量。我已经看到了之前三个版本的实际应用——它们都对我们在Delphix使用的流程、集成的功能以及开发流程的总体方向产生了巨大而持久的影响——但我仍然不知道他们的职责是什么，我确信我没有掌握成功所需的所有技能。然而，发布管理团队故意创造了一个环境，即使是我，作为一个刚毕业的大学生，也能够咬紧牙关，犯一些错误，而不会有任何真正的失败风险。出于这个动机，我去了。有效沟通101一开始，我对编码有很多了解，尤其是在我以前工作过的领域，但对其他方面却知之甚少。到目前为止，我在工作中必须学习的最困难的技能是如何在一个由70人组成的组织中进行沟通。我遇到的第一个挑战是指导发行版的创意生成阶段，在这个阶段，我的角色是接触那些我几乎没有和之交谈过的人，他们通常都经验丰富得多（支持主管、整个工程部的经理、我们的一些顶级开发人员等），并询问他们在我的发布过程中，他们认为哪些功能是重要的。把这个小错误、多年项目和愿望清单项目的集合变成一个潜在项目的优先列表是一项巨大的任务，我学到了发布管理的第一课：总是记笔记——尤其是当你不知道别人在说什么的时候！回首过去，想想"当我和平台团队经理交谈时，我真的只理解了他们建议的项目的一半内容"是很幽默的，但如果我没有做笔记，让我在事后通过查阅产品文档和bug跟踪器来加快速度，那就没那么好笑了。通过做这些事情，我学到了很多关于我们产品的知识，这使我能够预见到以后不熟悉项目的技术问题，大大提高了我作为发布主管的效率。我遇到的下一个限制是我自己的带宽，简单明了。当你试图在一个由70人组成的组织中跟踪进展时，比如说，一个工作日有10个小时，你不能花超过9分钟的时间与每个人交谈来获得状态更新——你也不应该。尽管在关键项目上与人接触并获得尽可能多的接触点是很诱人的，但我很快发现自己在无谓的会议和电子邮件中跋涉，我的个人生产力急剧下降。我必须学习的一项困难的技能是最大化交互，这样我（以及与我同步的工程师）将有时间真正完成任务。这主要归结为提前为会议准备问题，但思考谁是问题的合适人选，或者什么会议的利益相关者人数最多也是重要的方面。由于达到了带宽限制，我也意识到我应该依靠那些可以帮助我的同龄人的优势，而不是自己承担一切。项目负责人和项目经理的存在是有原因的：他们是各自领域的专家，我们相信他们能够向上传达团队的问题。虽然一开始很难退后一步，但我开始严重依赖我的同事对他们的项目状态进行诚实的评估，我发现数据点少了很多，根本没有妨碍我完成工作的能力。除了跟踪项目状态之外，发布主管还戴着许多其他的帽子：在发布结束之前不断地推动人们去处理他们的老bug，确保测试和后台移植遵循正确的流程，回答关于bug优先级的一般性问题，等等。我发现，为每一项选择正确的沟通方式对有效地完成工作至关重要。对于一个随时间变化不大的过程或策略，编写或改进wiki页面是最好的方法，因此您只需回答问题一次。另一方面，如果我需要大量的人来及时完成一些通常低优先级的任务，那么一封大范围的电子邮件或wiki文章根本帮不上忙——我真的不得不对每个人进行ping。在这样的时候，我发现IM是我最喜欢的工具；我可以一次进行5-10次简短的对话，记录下所说的每一句话，并让人们有效地承担责任。最后，我了解到，当你做了一件影响很多人的事情时，至少有几个人一定会问你有关它的问题。这是一件好事——它对不必要的官僚主义和复杂性起到了很好的反作用，免费的数据分析软件，并防止你犯下意外错误——但你需要做好解释自己的准备。我最后的沟通课也许是最简单的：在你的行动中要有目的性，企业网站自助建站，在回答有关他们的问题时要坦诚，淘客服，即使你犯了错误。结论作为发布负责人对我来说是一次极好的学习经历，跳出我的工程师的工作范围，与公司的大部门合作是很有趣的。我对整个公司有了更深入的了解，这个角色很容易让我在我的工作中产生最广泛的个人影响（诚然很短！）事业。我也再次对Delphix优秀的工程团队表示赞赏。作为发布主管，你的生死取决于你的同事在沟通他们项目的障碍方面的技能，泛在电力物联网，他们在截止日期前调试关键问题的能力，以及他们创造性和彻底的测试方法。拥有一支优秀的工程师团队，最终使功能打包的产品更新成为可能。（我差点忘了提——我们正在招聘！）