HAWK
(Hawk)
1
客户应该与你的团队保持多近的距离？
上周我花了一些时间思考这个问题，部分灵感来自我们近期关于让自家团队更深入参与 Meta 平台的讨论。
设计客户与产品团队之间的健康边界
产品团队与其社区中客户的互动方式在不同组织中差异巨大，因此我将结合我们在 Meta 的经验来谈谈。
我们的情况相当独特，因为我们正在与客户实时“内部试用”（dogfooding）我们的产品。在项目的前几年，我们组织里的每个人都直接参与产品开发，因此融入社区是工作的一部分。随着时间的推移，这种情况已逐渐减少，如今我们必须积极鼓励员工在支持类板块之外参与互动。
我们团队中的一些人承认，他们不在 Meta 上花时间，因为他们不知道该如何参与互动。他们觉得自己没有资格回答任何问题，也不认为自己具备引导有趣或相关讨论所需的知识深度。以下是我们发现的阻碍团队更多参与 Meta 的一些挑战——我相信其他组织也会遇到类似的问题。
参与社区的障碍
- 对问题的回答不准确、过时或不一致。（不知道正确答案或害怕给出错误答案，让许多人望而却步。）
- 声音响亮的成员可能对我们的团队产生不成比例的影响，甚至可能损害其他成员的利益。（与某些成员进行外交式的互动需要耗费大量精力，并非每个人都有此耐心。）
- 如果在没有充分沟通的情况下更改路线图，或者在征求反馈后似乎无视这些反馈，信任就会受损。（有些人觉得在私下工作更安全，这样就不会设定无法实现的期望。）
- 由于他人缺乏耐心，被个人标记到无关话题中，导致通知疲劳。（有些成员将可见的在线状态视为请求个人支持的邀请，尤其是在他们感到压力时。）
- 当成员觉得自己的声音未被倾听时，管理他们的挫败感。（有时，即使无人犯错，参与互动也可能因其对抗性性质而令人疲惫。）
在你们的组织中，直接的客户与产品互动在哪些方面取得了成功，又在哪些方面变得困难？
12 个赞
这很有趣。人们通常会自然地假设，设计和构建软件的人应该是回答这类问题和参与讨论的最佳人选。你是否深入挖掘过，找出导致这种缺乏自信的原因？
6 个赞
我想，对于产品经理、客户支持、企业支持、市场营销、销售等职位，我大概也会有类似的预设。如果没有相应的知识储备，要想把这些工作做好是相当困难的。
4 个赞
我想我们大家有时都会有这种感觉。不过，我认为基于论坛的社区在这方面比社交媒体有优势。对话节奏较慢，话题寿命较长，这让用户有机会了解其他用户，最终更自在地参与讨论。
是否有“资格”回答取决于提出的问题。有时，任何对 Discourse 有一丁点了解的人都能帮忙，因为提问者完全摸不着头脑。而在另一个极端，当有人提出非常具体的技术问题。在这种情况下，我通常只是确保问题包含足够的信息，这样当有资格的成员进入该帖子时，他们就能获得所需的信息来提供帮助。（版本号之类的信息）
同样，我认为这在一定程度上是人性使然。而讽刺的是，有趣的对话往往来自许多意想不到的地方。
5 个赞
Canapin
(Coin-coin le Canapin)
6
我不确定我能否直接回答这个话题，但我有一些与 Discourse 相关的观察：
我有时会遇到团队成员说“哦，我不知道 [某个功能或关于 Discourse 的其他事情]”，尽管他们是开发人员或从事该软件本身工作的其他职位。
起初这让我感到惊讶，但很快我就习以为常了。
像我这样热爱 Discourse、为其倡导、有时甚至是 Discourse 管理员的爱好者，往往拥有（或在我这种情况下曾经拥有）非常扎实的 通用 Discourse 知识，能够回答许多关于该软件的问题。在某些情况下，他们甚至比团队成员回答得更多或更准确。我认为这可以被视为 CDCK 取得的一种成功或成就 
我甚至不指望 Discourse 开发人员了解 Discourse 的 任何 功能。需要知道的内容实在太多了，其中大部分可能与他们受雇从事的工作无关，许多关于 Discourse 的问题也超出了他们的专业范围。这当然并不意味着他们的价值降低。他们各自领域的专家。
当然，任何人都可能有时自以为知道答案，尝试回答问题，结果却是错的。这种情况对每个人都会发生，无论是否是团队成员。我自己也发生过很多次，我承认当时无论我是普通用户还是其他身份，都感到有点尴尬。
即使是专家偶尔也会犯错，这没什么大不了的。
我记得有一次在 CDCK 时，我自信满满地接手了一个客户的 CSS 问题，心想能轻松快速地解决（这甚至不是我的本职工作）。结果我完全错了。这个问题比我预期的要复杂得多，于是我把修复工作留给了专家。
是的，那确实有点尴尬，但老实说没什么大不了的，我很快就翻篇了。
好吧。我甚至没有真正回应我引用的内容，我现在更像是在分享一些轶事。
这是双向的。我认为与某些团队成员的摩擦性互动是 Meta 上唯一一直让我（稍微）感到困扰的事情之一；从第一天到现在，偶尔会发生。
我认为这主要取决于人们的性格、情绪、气质和文化。大多数时候，我不会也不应该责怪那些在互动中有时显得严厉的人。
我将其视为平静海面上的波浪峰值。这是人性的表现。
团队/社区互动的目标不应也不能是“完全无摩擦”，而应是“大体无摩擦”。我认为 Meta 的情况就是如此，尽管仍有改进空间。
不过，是的，我无法回答主题中的那个唯一问题，所以，抱歉有点跑题了 
9 个赞
是的，我认为这一点很重要，需要牢记在心！虽然尝试出错可能会令人沮丧或尴尬，但这总比没人尝试要好。我们处理的不是什么会爆炸的东西，出错导致不可挽回的损害的情况并不多见。
只要有一点耐心，我们就能找到解决办法，并在此过程中学到一些东西……根据我的经验，99% 使用 Discourse 并来这里讨论的人都理解这一点。
5 个赞
Canapin
(Coin-coin le Canapin)
8
我慢慢地跑题了，但你的话让我想起了一位知名《Trackmania》主播关于孩子、失败和学习（无论是在国际象棋中还是总体上）的一段话：
[孩子们]也没有恐惧。孩子们通常不会想太多，[……]他们不害怕犯错。这是最好的学习方式，看看什么行不通。但如果你成年后开始学习新技能，你会有点害怕犯错。孩子们比成年人更愿意尝试和失败。比如，如果老师问大家有没有想法，他们会自信地喊出错误的答案。这种心态塑造了你学习事物的方式。
我想这是值得记住的一点：)
（跑题结束）
4 个赞
HAWK
(Hawk)
9
嘿，James。
我确实做了！我认为这是理解参与带来的隐性成本以及拥有参与框架这两者的结合。
员工参与的内部成本
有意义的参与不仅仅需要花费实际回答问题所耗用的时间和精力。人们需要获取信息、获得版主支持、后续跟进框架、升级处理路径，以及明确他们可以讨论什么、可以分享哪些示例、可以提及哪些客户。
社区团队通常会承担这些隐形工作，因为他们知道该邀请哪些主题专家参与，他们与成员建立了关系，他们具备保持对话富有成效的技能，并且他们有时间确保没有任何事项被遗漏。这确保了信任水平的维持，并使社区为所有参与者提供价值。
我们的团队理解这种信任的价值以及建立信任所需的时间，因此，害怕做出任何损害信任的事情就足以让一些人完全不愿参与。
在不压垮内部团队的情况下建立信任
信任更多来自于可预测的行为，而非随时待命。如果客户/成员对你们的流程有信心，他们就不需要随时接触你们的团队。他们需要知道：
- 在哪里提供反馈
- 反馈会如何处理
- 谁来阅读反馈
- 哪些讨论会得到回应
- 决策是如何做出的
- 我们何时会进行汇报
需要有一种可靠的持续反馈循环——有边界且值得信赖比高度可用但不可靠更优。如果人们觉得是在对着虚空呼喊，就不会花时间提供反馈。你需要足够的直接接触来了解成员的需求，同时具备足够的结构，让每个人都清楚他们从互动中能获得什么价值。
这引起了我的兴趣——让我们叫上 @mae，问问她对于回答技术产品问题的感受。我觉得这可能会让人大开眼界。
我同意你的观点，Andrew，可能总有一些任何人都能回答的问题，但在这些情况下，可发现性可能是一个问题。我很想听听其他团队是如何处理这一点的。
我认为这并不跑题，我认为我们可以从中汲取一些非常有价值的东西。我们需要更好地理解为什么我们害怕失败。
5 个赞
如果我不确定答案，我会这样做……
第一步：我会看看这个问题挂在那里无人回答多久了。
如果只有一两个小时，或者是在周末，我会先放一放，看看有没有比我更聪明的人来回答。
如果是一个非常具体的问题，而且已经过了24小时还是一片寂静 
，那我真的会为这个人感到难过。我会尝试帮忙，即使我对这个问题涉及的主题知之甚少。在这种情况下，我有时会快速搜索一下，看看是否有我可以指引他们的文档。他们自己也可以这样做，但无论多么绝望，很多人就是不读手册（RTFM）。或者如果是一个bug，我会尝试复现它。
如果我觉得我知道答案但不确定，我会说“我想……”
如果我觉得我知道答案但不是100%肯定，我会说“我几乎可以肯定……”
如果我完全没头绪，我会说“我只是在瞎猜……”
在很多情况下，对于一个已经挂在那里一段时间的话题，以任何方式回复都比一片寂静要好。至少用户知道他们没有被忽视。而且通常回复会让话题浮起来，其他人也会加入进来。
我认为这很重要。（而且说得非常好）一个反应超快但像是自动回复且后续没有跟进的团队毫无价值。
但我觉得这也与另一个话题中人们所说的社区参与度下降有关。如果支持论坛不回复或需要几个小时才回复，人们转向AI以获得即时答案的诱惑就会更大。
顺便说一句，我认为Meta在这方面做得很好，取得了很好的平衡。
我认为社区论坛达到临界点的关键就在这里！
作为一个试图建立社区论坛的人，这是我希望有一天能实现的目标。
当一个论坛，尤其是支持论坛，拥有足够多的知识渊博的老用户参与，以至于当用户提问时，有一群人只是为了乐趣而聚集在那里回答问题，那时我们就真的成功了。如果受众分布在足够多的时区，总有人在线并回复，那时我们就真正发挥了“万维网”的力量。
而且，社区能给我们而AI不能提供的是……社区感。
8 个赞
这篇文章读起来很有趣，但我觉得它没有涵盖我最好奇的主要观点。我对此特别感兴趣：
这似乎有点反直觉。还有谁比他们更合适，能在如此广泛的网站和使用案例中知道更多呢？当然，没有人能无所不知，但肯定比一般的潜水者知道得多得多。
有些部门与产品相距甚远（例如财务、法务），所以如果这些反馈仅来自他们，那就更容易理解——但如果解释起来这么简单，我想你早就说了。
这感觉像是个陷阱…… 我原本以为营销和销售在处理技术问题上会有稍有不同的专长，但也许我想多了。我不会先入为主。
不过我确实同意关于如何最好地分配时间/资源的观点，但这与“即使想贡献也觉得自己无法做到”是另一个问题。
2 个赞
mae
(Mae Woods)
12
你会请篮球教练来教你打网球吗？虽然两者都是运动，但你会希望找真正打过网球的人来教。这里也是同样的道理，我宁愿把你引荐给合适的专家，而不是勉强给出一个我不具备资格回答的答案。
我可以整天谈论定位、信息传达以及我们如何讲述 Discourse 的故事，但深入的技术细节应该交给实际构建产品的人。
话虽如此，我认为营销和销售团队应该在 Meta 上发挥更大的作用，并推动更多非技术类内容的产生。这是我第三季度/第四季度的优先事项。
如果大家对希望在 Meta 上看到的非技术类内容有任何想法，请随时联系我或在相关话题中标记我。
6 个赞
HAWK
(Hawk)
13
没错，我很喜欢这个观点。我认为这是完美的做法。
这个想法很有趣——毫无疑问你是对的。不过，你认为人们会默认在这里（或其他论坛）使用机器人，还是会完全转向外部平台呢？或许可以对此进行一些测量。
我的回答有点绕，但我真正想表达的是这一点：
另外需要澄清的是，是的，确实是组织的业务部门感受到了参与这一特定障碍。我实际上并没有提到技术问题，所以这一点被混淆了。
没错。如果有人向我提出关于 Discourse 的基础问题，我有信心能给出相当可靠的回答。但一旦涉及非常高级的配置，或是那些深藏不露、最终被证实为 bug 的安装故障，那就远远超出我的知识范围了。
几个月前有一段时间，我发帖的频率明显降低。这并不是因为我不在这里（我确实在，我依然每天阅读 Meta 论坛），而是因为问题变得更加技术化，加之时差原因，我往往要过很久才能看到它们。那些非常具体的 bug 报告，或是过于特定以至于无法直接套用到我实例上的问题，都让我难以应对。
那时我意识到，归根结底，我所掌握的知识与那些致力于产品开发的开发者，或是像 Moin 和 Lilly 这样的人相比，不过是冰山一角。
我想表达的观点是：即使一个人经常参与 Discourse 的讨论，Discourse 的可配置性也意味着其相关信息几乎是无穷无尽的。它的可定制程度太高了（这并非坏事），可以调整得如此彻底，以至于几乎不像一个标准的论坛。因此，如果工作人员并非对软件的方方面面都了如指掌，那完全没问题：他们各自专注于不同的领域，在各自的专长范围内，都可以被视为“专家”。
4 个赞
啊哈，我就知道希望渺茫，但从那个“令人眼界大开”的描述中，我开始抱有希望，以为你会跳出来分享一些关于 Flarum 迁移脚本或配置 Cloudflare 隧道的深奥知识。
不过正如你稍后在帖子中所说，确实还有其他不太涉及技术的领域，你正在那里应用你专业的 Discourse 知识，所以至少你并不属于最初提到的“缺乏信心”的反馈范畴。 
我认为公司需要现实地评估期望哪些部门和人员参与社区。一刀切的政策或放之四海而皆准的要求，即使在小组织中也可能并不合适。我认为在评估包容性策略时，“该部门/个人参与的好处是什么”无疑是一个关键问题。
我也觉得这与对话内容格格不入。 大概是某种 AI 故障之类的吧？
7 个赞
HAWK
(Hawk)
16
我一开始没明白你在说什么，只好把整个对话从头翻了一遍，想看看这话是从哪儿冒出来的，因为据我所知，这里并没有涉及 AI。结果我看到了……
我把两者搞混了！我也搞不懂自己干嘛加了“技术”这个词。回头再看，我只能假设是我误解了你的意思。这里从来没人问营销方面的问题，我以为你是建议大家具备产品知识。我的错。
6 个赞
我认为“产品知识”和“技术产品知识”是洋葱的不同层次。我假设营销和销售部门确实具备“产品知识”，因为在我看来，试图营销和销售一个你几乎一无所知的产品，其局限性会很大。 不过，我也认为公司完全有理由权衡“这样做的好处是什么”，并决定这些特定部门不适合他们的社区空间（或者他们的时间/资源最好用在其他地方）。从上面的帖子来看，Mae 似乎认为这里存在潜力，而且在公司架构中，社区通常归营销部门管辖，因此这也存在现有的联系。但我认为并没有绝对正确的答案，每家公司都需要自行做出这类决策。
除了考虑“哪些部门”，另一个需要实际考虑的因素是：你期望有多少员工参与，参与的积极性如何，以及你的社区规模是否足够大，以便以健康的方式吸纳他们。每个社区的文化的都不同，每个社区与公司的组合也会呈现出略微不同的风味，因此这在很大程度上取决于具体背景——但我认为值得思考一下，向社区注入 20、30 或 50 名活跃团队成员可能会产生什么影响。主导社区空间可能正是你的意图，但如果不是，那么留意这一潜在后果有助于减轻其影响。例如，可以划定你认为他们最适合参与互动的版块/分类，或者制定一些关于何时应克制并让社区成员优先发言的指导方针等。
设置一个私有版块作为沙盒，帮助这些团队成员融入社区，也有助于使他们的过渡更加顺畅。这只是一个稍偏角落的地方，让他们在深入公共区域之前，可以 discreetly（悄悄地/不引人注目地）熟悉这个平台。一些简单的事情，比如如何引用、如何创建投票，或了解现有的论坛礼仪等，这样他们就能建立自信，而不会一拥而入显得像个新手。
此外，关于是否将参与设为强制性的问题……我个人认为，如果可能的话，应避免这样做。人们感到被迫参与时，往往会散发出错误的气场，而在长期来看，僵硬、尴尬或傲慢的互动可能弊大于利。我认为，说服人们认识到参与的好处是一种更理想的动力。（不过，同样地，这在很大程度上取决于你的社区和公司文化 )
3 个赞
在这类话题中，我真的很享受阅读大家的发言，并从每一则回复中学习，这种体验别处难寻。
我出生并成长于一种截然不同的文化之中；如今我意识到，我们所有人其实共享着相同的情感与恐惧。当我的人生将我带入“艺术家”领域后，我开始明白，你在此处提到的核心问题，其根源在于变化。
变化是永恒的，也是我们作为生命本身的全部。Meta 也在像我们一样不断变化。起初这很难（过于技术化，过于中立），但现在对每个人来说都更加舒适和轻松。这不仅体现在开发领域，也体现在人工支持、互动和创造力等方面。
仅供参考
4 个赞