Estrategias de acceso y participación

Comunidad Empresa
1

¿Qué tan cerca deben estar los clientes de sus equipos?

Dediqué algo de tiempo a pensar en esto la semana pasada, influenciado en parte por las discusiones que hemos tenido sobre involucrar más a nuestro propio equipo aquí en Meta.

Diseñar límites saludables entre los clientes y los equipos de producto

La forma en que los equipos de producto interactúan con los clientes en su comunidad variará ampliamente entre organizaciones, así que hablaré desde nuestra experiencia con Meta.

Nuestra situación es bastante única en el sentido de que estamos probando nuestro producto en tiempo real con nuestros clientes (dogfooding). Durante los primeros años del proyecto, todos en nuestra organización trabajaron directamente en el producto, por lo que ser parte de la comunidad era una parte necesaria del trabajo. Con el tiempo, esto ha cambiado y ahora tenemos que fomentar activamente la participación del personal fuera de las categorías de soporte.

Algunos miembros de nuestro equipo admiten que no dedican tiempo a Meta porque no saben cómo involucrarse. No hay preguntas para las que se sientan capacitados para responder, y no sienten que tengan la profundidad de conocimiento necesaria para liderar discusiones interesantes o relevantes. Aquí hay algunos de los desafíos que hemos identificado que impiden que nuestro equipo participe más en Meta; estoy seguro de que otras organizaciones experimentan desafíos similares.

Barreras para involucrarse en la comunidad

  • Respuestas inexactas, desactualizadas o inconsistentes a las preguntas. (No saber la respuesta correcta o el miedo a dar una incorrecta detiene a muchos de involucrarse.)
  • Los miembros más vocales pueden tener una influencia desproporcionada sobre nuestro equipo, potencialmente en detrimento de otros miembros. (Algunos miembros requieren mucha energía para interactuar con ellos diplomáticamente, y no todos tienen la paciencia necesaria.)
  • La confianza se erosiona si cambiamos la hoja de ruta sin una comunicación suficiente o si pedimos comentarios y parecen ignorarlos. (Algunas personas se sienten más seguras trabajando en privado para no establecer expectativas que no pueden cumplir.)
  • Fatiga de notificaciones por ser etiquetados personalmente en temas que no tienen relevancia debido a la impaciencia de la gente. (Algunos miembros tratan la presencia visible como una invitación a solicitar soporte personal cuando están estresados.)
  • Gestionar la frustración cuando los miembros sienten que no se les escucha. (A veces, la participación puede ser agotadora debido a su naturaleza confrontacional, incluso cuando nadie es culpable.)

¿Dónde ha funcionado bien la interacción directa entre clientes y producto en su organización, y dónde se ha vuelto difícil?

11 Me gusta
2

Esto es interesante. Creo que la suposición natural sería que las personas que diseñan y construyen el software serían algunas de las mejores para abordar este tipo de preguntas y discusiones. ¿Profundizó más para descubrir qué impulsa esta falta de confianza?

5 Me gusta
3

No todos los miembros del equipo son ingenieros o diseñadores :slight_smile:

5 Me gusta
4

Creo que tendría una suposición similar para Gerentes de Producto, Soporte al Cliente, Soporte Empresarial, Marketing, Ventas y similares. Sería bastante complicado desempeñar bien esos trabajos sin el conocimiento necesario. :person_shrugging:

3 Me gusta
5

Creo que todos nos sentimos así en ocasiones. Creo que eso es algo en lo que las comunidades basadas en foros tienen ventaja sobre las redes sociales. El ritmo más lento de las conversaciones y la permanencia de los temas dan a los usuarios la oportunidad de «hacerse una idea» de los demás usuarios y, finalmente, sentirse más cómodos participando.

Estar «cualificado» para responder depende de las preguntas que se hagan. A veces, cualquiera con cualquier conocimiento, aunque sea remoto, de Discourse puede ayudar porque el usuario no tiene ni idea. En el otro extremo de la escala está cuando alguien pregunta algo muy específico sobre algo muy técnico. En esos casos, normalmente me aseguro de que la pregunta incluya suficiente información para que, cuando un miembro cualificado llegue al hilo, tenga lo que necesita para ayudar (número de versión, ese tipo de cosas).

De nuevo, creo que esto es en parte naturaleza humana. Y la ironía es que las conversaciones interesantes a menudo provienen de muchos lugares inesperados.

5 Me gusta
6

No estoy seguro de poder responder directamente al tema, pero tengo algunas observaciones relacionadas con Discourse:

En ocasiones he encontrado a miembros del equipo diciendo: «Vaya, no sabía nada de [esta función o cualquier aspecto de Discourse]», a pesar de ser desarrolladores o tener cualquier otro cargo trabajando directamente en el software.

Al principio me sorprendió, pero no por mucho tiempo.

Los entusiastas como yo, que amamos Discourse, lo promovemos y a veces somos administradores de Discourse nosotros mismos, tendemos a tener (o en mi caso, solía tener) un muy buen conocimiento general de Discourse y podemos responder a muchas preguntas sobre el software. En algunos casos, incluso con más precisión que un miembro del equipo. Lo cual, diría yo, puede considerarse un tipo de éxito o logro por parte de CDCK :hugs:

No espero ni siquiera que un desarrollador de Discourse sepa cualquier cosa sobre las funciones de Discourse. Simplemente hay demasiado que saber, gran parte de ello quizás no relacionado con lo por lo que les pagan, y muchas preguntas sobre Discourse pueden estar fuera de su especialidad. Eso no los hace menos valiosos, obviamente. Son expertos en su campo.

Por supuesto, cualquiera puede pensar que sabe algo, responder a una pregunta y terminar equivocado. Le sucede a todos, tanto a miembros del equipo como a otros. Me ha pasado muchas veces, y admito que a veces me sentí un poco avergonzado, ya fuera como usuario habitual o no en ese momento.
Incluso los expertos pueden equivocarse de vez en cuando, y está bien.

Recuerdo una vez, cuando estaba en CDCK, salté con confianza a resolver un problema de CSS de un cliente pensando que lo arreglaría fácil y rápido (ni siquiera era mi trabajo). Estaba completamente equivocado. El problema era mucho más complejo de lo que esperaba y dejé que los expertos lo solucionaran en su lugar. :laughing: Sí, fue vergonzoso, pero honestamente no fue gran cosa y lo superé rápidamente.

Bueno, en realidad no estoy abordando lo que cité; en este punto, más bien estoy compartiendo anécdotas.

Es un callejón de doble sentido. Creo que las interacciones tensas con algunos miembros del equipo fueron una de las pocas cosas que siempre me molestaron (un poco, nada grave) en Meta; desde el primer día hasta hoy, ocasionalmente.

Creo que simplemente se debe a la personalidad, el estado de ánimo, el temperamento y la cultura de las personas. La mayoría de las veces no puedo ni culpo a las personas que encuentro a veces duras en sus interacciones.
Lo veo como las crestas de las olas en un mar de lo contrario tranquilo. La expresión de la naturaleza humana.
El objetivo de las interacciones entre el equipo y la comunidad no debería ni puede ser «perfectamente libre de fricciones», sino «mayoritariamente libre de fricciones». Creo que ese es el caso en Meta, aunque siempre haya margen de mejora.

Pero bueno, sí, no puedo responder a la única pregunta del tema, así que, lo siento por desviarme un poco del tema :face_with_tongue:

7 Me gusta
7

Sí, creo que esto es importante tenerlo en cuenta. ¡Por frustrante o vergonzoso que pueda ser intentar hacer algo mal, es mejor que si nadie lo intenta en absoluto! No estamos trabajando en nada que vaya a explotar, no hay demasiados casos en los que hacer algo mal cause daños irreparables.

Con un poco de paciencia lo resolveremos y aprenderemos algo en el proceso… en mi experiencia, el 99% de las personas que usan Discourse y han venido aquí a discutirlo entienden esto.

4 Me gusta
8

Me estoy desviando lentamente hacia temas fuera del tema, pero lo que dices me recuerda a una cita de un destacado streamer de Trackmania sobre niños, fracasos y aprendizaje:

[Los niños] tampoco tienen miedo. Los niños generalmente no piensan demasiado, […] no les da miedo equivocarse. Esa es la mejor manera de aprender, ver qué no funciona. Pero si comienzas a aprender una nueva habilidad como adulto, te da un poco de miedo equivocarte. Los niños están mucho más dispuestos a intentarlo y fallar que los adultos. Como gritar la respuesta incorrecta con confianza si el profesor pregunta a alguien si tiene una idea. Y este tipo de mentalidad moldea cómo aprendes las cosas.[1]

Algo que tener en cuenta, supongo :slight_smile:

(fin del tema fuera de tema)

  1. https://youtu.be/Hr2nBfa-yaM?t=1970 ↩︎

4 Me gusta
9

¡Hola, James! :slight_smile:

¡Así fue! Creo que es una combinación de comprender los costos ocultos de la participación y contar con un marco para la misma.

El costo interno del compromiso del personal

La participación significativa requiere más que el tiempo y el esfuerzo dedicados a responder preguntas. Las personas necesitan acceso a información, apoyo de moderación, marcos de seguimiento, vías de escalación y claridad sobre qué pueden discutir, qué ejemplos pueden compartir y a qué clientes pueden mencionar.

Los equipos de comunidad generalmente absorben este trabajo invisible porque saben a qué expertos en la materia deben involucrar, tienen relaciones con los miembros, poseen las habilidades para mantener las conversaciones productivas y tienen el tiempo necesario para asegurarse de que nada se quede sin atender. Esto garantiza que se mantengan los niveles de confianza y que la comunidad ofrezca valor a todos los participantes.

Nuestro equipo comprende el valor de esa confianza y cuánto tiempo toma construirla, por lo que el miedo a hacer algo que la erosione es suficiente para disuadir a algunos de participar.

Construir confianza sin abrumar a los equipos internos

La confianza proviene más de un comportamiento predecible que de una disponibilidad constante. Los clientes/miembros no necesitan acceso continuo a tu equipo si tienen confianza en tus procesos. Necesitan saber:

  • dónde dejar sus comentarios
  • qué sucede con ellos
  • quién los lee
  • qué discusiones reciben respuestas
  • cómo se toman las decisiones
  • cuándo informaremos
    necesario

Debe haber algún tipo de ciclo de retroalimentación continua que sea confiable: es preferible ser confiable con límites que estar muy disponible pero ser poco fiable. Nadie invertirá tiempo dando su opinión si se siente como que habla al vacío. Necesitas suficiente contacto directo para comprender las necesidades de los miembros, junto con suficiente estructura para que todos sepan qué valor obtienen de la interacción.

Esto me interesa: llamemos a @mae y le preguntemos qué opina sobre responder preguntas técnicas sobre productos. Creo que podría ser bastante revelador.

Estoy de acuerdo contigo, Andrew; probablemente siempre haya un puñado de preguntas que cualquiera pueda responder, pero la visibilidad puede ser un problema en esos casos. Me interesa saber cómo otros equipos manejan esto.

No creo que se haya desviado del tema; creo que hay algo bastante valioso que podemos extraer de eso. Necesitamos comprender mejor por qué tenemos miedo de fallar.

4 Me gusta
10

Esto es lo que hago cuando no estoy seguro de una respuesta…

primer paso: miro cuánto tiempo lleva la pregunta sin respuesta.

si solo han pasado una o dos horas o es fin de semana, la dejo un rato y espero a ver si alguien más listo que yo la contesta.

Si es una pregunta muy específica y han pasado 24 horas y solo hay crickets :cricket: entonces empiezo a sentir lástima por esta persona. Intentaré ayudar, aunque sepa muy poco sobre el tema de la pregunta. En esta situación a veces hago una búsqueda rápida y veo si hay alguna documentación a la que pueda dirigirles. Podrían hacerlo ellos mismos, pero mucha gente no RTFM sin importar lo desesperada que esté. O si es un error, intento reproducirlo.

Si creo que sé la respuesta pero no estoy seguro, digo «creo que…»

Si creo que sé la respuesta pero no estoy 100% seguro, digo «estoy casi seguro…»

Si no tengo ni idea, digo «aquí solo estoy adivinando…»

En muchos casos con un tema que ha estado ahí un tiempo, alguien que responda de cualquier manera es mejor que los crickets. Al menos el usuario sabe que no está siendo ignorado. Y a menudo la respuesta hace que el tema suba y otros se unan.

Esto creo que es importante. (y muy bien dicho) Un equipo súper receptivo que parece respuesta automática y luego no sigue la pista no sirve para nada.

Pero creo que esto también se relaciona con lo que la gente dice en el otro tema sobre la disminución del compromiso comunitario. Si un foro de soporte no responde o tarda horas en responder, la tentación de preguntar a la IA y obtener una respuesta inmediata es aún mayor.

Por cierto, creo que meta hace un trabajo realmente bueno para lograr un buen equilibrio en esto.

ESTO es donde creo que un foro comunitario alcanza la masa crítica.

Como alguien que intenta poner en marcha un foro comunitario, esto es lo que espero lograr algún día.

Cuando un foro, especialmente un foro de soporte, gana suficientes usuarios veteranos conocedores participando, de modo que cuando un usuario hace una pregunta, hay un grupo entero de personas que están ahí respondiendo preguntas solo por diversión, entonces estamos cocinando con gas. Si la audiencia está distribuida en suficientes zonas horarias para que siempre haya alguien despierto y respondiendo, ahora estamos explotando realmente el poder de la ‘world wide web’.
Y hay algo que la IA no puede darnos pero una comunidad sí… una comunidad

7 Me gusta
11

Fue una lectura interesante, pero no creo que abordara el aspecto principal que me generaba curiosidad. Me interesaba más esto en concreto:

Esto simplemente me parece contraintuitivo. ¿Quién mejor situado que ellos para saber más, y en un espectro tan amplio de sitios y casos de uso? Claro, nadie puede saberlo todo, pero seguro que saben un buen trozo más que el lince medio.

Habrá departamentos bastante alejados del producto (por ejemplo, finanzas o legal), así que si esta retroalimentación proviene únicamente de ellos, es más comprensible; pero si fuera una explicación tan sencilla, supongo que lo habrías mencionado antes.

Esto me suena a una trampa… :slight_smile: Imaginaba que marketing y ventas tendrían una especialización ligeramente distinta a las preguntas técnicas, pero quizás estoy pensando demasiado. No prejuzgaré. :slight_smile:

Aunque sí estoy de acuerdo con lo de dónde aplicar mejor tu tiempo/recursos, pero eso es un tema aparte de no sentirse capaz de contribuir si uno quisiera hacerlo.

1 me gusta
12

¿Le pedirías a un entrenador de baloncesto que te enseñara tenis? Ambos son deportes, pero querrías a alguien que realmente juegue al juego. Es la misma idea aquí: prefiero orientarte hacia el experto adecuado antes que dar una respuesta torpe para la que no estoy cualificado.

Puedo hablar todo el día sobre posicionamiento, mensajes y cómo contamos la historia de Discourse, pero los aspectos técnicos profundos pertenecen a las personas que realmente lo construyen.

Dicho esto, creo que el Marketing y las Ventas deberían tener un papel más importante en Meta y podrían ser impulsores de contenido menos técnico. Esta es una prioridad para mí en el tercer y cuarto trimestre.

Si alguien tiene alguna idea de contenido menos técnico que le gustaría ver en Meta, no dude en contactarme o etiquetarme en los temas. :slightly_smiling_face:

5 Me gusta
13

Sí, me encanta esto. Creo que es el enfoque perfecto.

Pensamiento muy interesante, sin duda tienes razón. ¿Crees que la gente recurriría por defecto al bot aquí (o en otro foro), o iría completamente a fuentes externas? Podría ser interesante medirlo.

Mi respuesta fue un poco enrevesada, pero lo que quería decir era esto específicamente:

Y para aclarar, sí, es el lado empresarial de la organización quien siente esa barrera para participar. En realidad no mencioné preguntas técnicas, así que eso ha quedado mezclado. :slight_smile:

14

Cierto. Si alguien se acercara a mí con una consulta básica sobre Discourse, diría que podría responderle con bastante confianza. Pero cuando se trata de configuraciones muy avanzadas o fallos de instalación que resultan ser errores ocultos en lo más profundo, eso está muy por encima de mi conocimiento.

Hace unos meses hubo un periodo en el que publiqué considerablemente menos. No porque simplemente no estuviera por aquí (estaba; aún leo Meta a diario), sino porque las preguntas se volvieron mucho más técnicas y, debido a las zonas horarias, solo las veía mucho después. Informes de errores muy específicos o preguntas demasiado concretas para que pudiera aplicarlas en mi(s) instancia(s).

Fue entonces cuando me di cuenta de que, en última instancia, lo que sé apenas araña la superficie en comparación con los desarrolladores que trabajan en el producto real o personas como Moin y Lilly.

¿Mi punto? Aunque uno interactúe regularmente con Discourse, la capacidad de configuración de Discourse asegura que la información sea casi infinita. Es demasiado personalizable (no es algo malo, aunque sea) y puede ajustarse tanto que apenas se parece a un foro estándar. Así que si el personal no lo sabe todo sobre el software, está bien: se especializan en diferentes partes y cada uno puede ser consultado como ‘experto’ en esa parte.

4 Me gusta
15

Vaya, sabía que las probabilidades estaban en contra, pero con la descripción «reveladora» había empezado a esperar que entraras en acción con algún conocimiento arcano sobre scripts de migración de Flarum o la configuración de un túnel de Cloudflare. :slight_smile:

Aunque, como dices más adelante en tu mensaje, ciertamente hay otras áreas menos técnicas en las que estás aplicando tu conocimiento especializado de Discourse, así que al menos no eres parte del comentario original sobre «falta de confianza». :partying_face:

Creo que las empresas deben ser realistas sobre qué departamentos y personas esperan que participen en la comunidad. Una política generalizada o una expectativa única probablemente no encajará bien, incluso en organizaciones más pequeñas. Creo que preguntar «¿cuáles son los beneficios para este departamento/persona al participar?» es ciertamente una pregunta clave al evaluar una estrategia de inclusión.

También pensé que era una adición incongruente a la conversación. :slight_smile: ¿Algún tipo de fallo de IA o algo así?

7 Me gusta
16

Me preguntaba de qué estabas hablando y tuve que releer toda la conversación para ver dónde se había introducido, porque por lo que yo sé, no hay ninguna IA involucrada aquí. Pero entonces vi…

¡Lo confundí! No tengo ni idea de por qué añadí la palabra «técnico». Al releer, solo puedo asumir que malinterpreté lo que decías. Nadie pregunta aquí sobre marketing; pensé que sugerías que todos tenían conocimientos del producto. Mi culpa.

5 Me gusta
17

Creo que el «conocimiento del producto» y el «conocimiento técnico del producto» son capas diferentes de la cebolla. Parto de la suposición de que los departamentos de marketing y ventas sí tienen «conocimiento del producto», ya que imagino que intentar comercializar y vender un producto del que se sabe muy poco sería bastante limitante. :slight_smile: Aunque también pienso que es completamente razonable que una empresa evalúe «cuál es el beneficio» y decida que esos departamentos concretos no encajan bien en su espacio comunitario (o que su tiempo y recursos se aprovechan mejor en otras áreas). Por el mensaje anterior, parece que Mae considera que aquí hay un potencial, y a menudo la comunidad se engloba bajo el paraguas del marketing en la estructura corporativa, por lo que también existe ese vínculo, pero no creo que haya necesariamente una respuesta correcta; cada empresa tendría que tomar este tipo de decisiones por sí misma.

Otro aspecto práctico a considerar junto con «qué departamentos» es cuántos miembros del equipo esperas que participen, con qué nivel de actividad, y si tu comunidad es lo suficientemente grande para absorberlos de forma saludable. Cada cultura comunitaria es diferente, y cada combinación comunidad-empresa también tendrá un matiz ligeramente distinto, por lo que esto dependerá en gran medida del contexto; pero creo que vale la pena reflexionar sobre qué efecto podría tener inyectar 20, 30 o 50 miembros activos del equipo en tu comunidad. Dominar el espacio puede ser lo que pretendes, pero si no es así, creo que tener en cuenta esta posible consecuencia puede ayudar a suavizar el impacto. Por ejemplo, delimitando espacios o categorías donde consideres que su participación sería más adecuada, o estableciendo algunas directrices sobre cuándo reservar participación y dejar que la comunidad tenga la primera palabra, etc.

Crear una categoría privada como espacio de pruebas para ayudar a integrar a estos miembros del equipo en la comunidad también puede facilitar su transición. Simplemente un lugar apartado donde puedan familiarizarse discretamente con la plataforma antes de sumergirse en las áreas públicas. Cosas sencillas como cómo citar, cómo crear encuestas o conocer las normas de etiqueta existentes del foro, etc., para que ganen confianza y no se lancen todos de golpe pareciendo novatos. :slight_smile:

Además, la cuestión de si hacer la participación obligatoria… Personalmente, siento que esto debería evitarse en la medida de lo posible. Cuando la gente se siente obligada a participar, a menudo transmite una sensación errónea, y las interacciones forzadas, incómodas o arrogantes pueden hacer más daño que bien a largo plazo. Creo que convencer a la gente de los beneficios de participar es un motivador mucho más deseable. (Aunque, una vez más, mucho depende de la cultura de tu comunidad y de tu empresa :slight_smile:)

2 Me gusta