为什么我们邀请外部合作伙伴使用我们的内部松弛

创建了Slack来代替电子邮件地狱。 (我的意思是,它是为许多其他事物创建的,但目前它的采用率最高是为了取代电子邮件地狱。)

但是,即使那些已经成功杀死用于内部通信的电子邮件的组织仍然设法跳回“大邮件追踪” (或者您是通过短信发送该邮件?还是您将其留在Jira评论中?我们在哪里进行了对话?)与外部合作伙伴和客户合作时。

灵活并适应客户的任何一种沟通方式都是很诱人的,但是在Revelry,我们相信自己的流程,并且正在建立与之相适应的公司和解决方案。

我们有时会说:“客户为我们的流程支付的费用与为代码支付的费用一样多。” 因此,我们邀请客户和创新合作伙伴加入我们的交流流程。

为什么我们有意邀请客户参与我们的业务? 因为他们要求我们全力以赴!

我们的许多创新合作伙伴对与我们合作的过程感到兴奋,就像对结果感到兴奋一样。

运作方式如下:

Slack提供了一个集中的地方,所有协作和项目状态都在此流动。

Slack还提供了一个称为“共享频道”的功能来帮助解决此问题,但这不是我们要做的。

我们将它们带入我们的交流平台。

我们利用Slack中的多渠道和单渠道来宾功能邀请合作伙伴加入特定渠道。 这些来宾没有访问我们所有内部对话的权限; 仅针对他们的项目或公司的单个适当渠道。

我们对我们打算制造的每个产品部署相同的过程。 该项目拥有自己的Google云端硬盘,GitHub存储库(和相应的Waffle面板)以及Slack频道。 我们邀请从事该项目的狂欢者和主要利益相关者加入云端硬盘,存储库和渠道。 设置发行板,持续集成和其他适当的工具后,我们将通过Slack的集成功能连接通知结构。

在对话窗格的顶部始终可以看到频道主题,因此我们可以在其中放置指向最有价值的项目资源的链接。 我们的项目渠道全面采用相同的格式。 这是每个人在频道中任何时候都可以通过“主题”行看到并获得的帮助:

自述文件:这是项目的基础。 自述文件将包括联系信息,项目简介,指向Google云端硬盘和其他资源的链接,技术堆栈以及其他重要细节。
WAFFLE:链接到项目的Waffle板(这是一个看板应用程序,以有用的可视化布局列出了GitHub Issues。)

随着项目对话的进行,某些评论,链接或对话总是值得关注的。 线框的InVision链接,暂存/演示站点的链接以及其他方便的频道注释可帮助队友快速获取有价值的文档。 同样,自述文件中仍然提供了所有功能,但是,嘿,我们现在生活在一种即时满足的文化中,不是吗?

我们通过集成将所有用于启动和维护软件解决方案的软件,机器人,监视器和数据库连接到Slack渠道。 当构建中发生动作时,集成机器人会自动发布到渠道。

这有助于我们为项目增加尽可能多的透明度。

当然,通知和漫游器可以使对话更加混乱,但是我们彼此提醒我们和创新伙伴如何在嘈杂的环境中进行交流。

有时,当机器人弹出时,我们处于对话中。 它们是自动生成的,因此它们不能真正适时。 如果对话是同步进行的,我们相信每个人都将扫描经过机器人并查看人工响应。 如果对话是异步进行的,那么我们应该使用@mentions或线程答复,以确保注释不会在噪音中丢失。

但这并不意味着所有机器人流量都将被忽略。 我们链接到它是有原因的。

“但是,您让外部联系人直接与您的开发人员对话吗?”是的。 我们的确是。 “但是,您如何保护他们的时间?”好吧,在Revelry,我们的核心价值观之一就是“ 赚取和分配信任” 。 信任可以通过许多方式分配和获得。

一种方法是,我们相信每个队友都能阻止和保护自己的时间。 当我们的队友需要“平视”时间时,我们相信他们会关闭通知,以便在工作模式下不会打扰他们。 并且,我们相信他们会提供更新并在该时间段达到停止点时检查消息。

另一种方式是,我们信任我们的团队公开进行所有对话,并在发生任何不适当或无效的对话时予以报告。

查看原始帖子,了解有关有效Slack交流的更多提示


最初于 2017 年10月23日 发布在 revelry.co