Muchas gracias por tus orientaciones @tobiaseigen en relación con Discourse for Teams. Además, ¡qué excelentes noticias, @david! La gestión del trabajo pendiente será aún más sencilla a partir de ahora. Me encantaría aprovechar esta publicación para contarte cuáles fueron las características clave que nos hicieron cambiar a Discourse.
Antecedentes
Somos un equipo de desarrolladores de software, analistas funcionales y administradores de sistemas dedicados a crear soluciones de gestión empresarial para el mercado colombiano; sin embargo, el mundo entero está en nuestra hoja de ruta ;). Desarrollamos software personalizado para nuestros clientes y contamos con nuestros propios productos originales, pero actualmente nuestra principal línea de negocio consiste en ofrecer servicios y extensiones sobre el ERP Odoo. De todas las aplicaciones que incluye Odoo, nos hemos especializado en las de contabilidad, inventario y gestión de recursos humanos. Como puedes imaginar, utilizamos Odoo extensivamente y, desde nuestra fundación en 2015, su aplicación de gestión de proyectos ha sido nuestro mejor aliado, ya que, con su interfaz Kanban (estilo Trello), permite a nuestro equipo gestionar el flujo de trabajo de las tareas acordadas en cada proyecto de implementación. Sin embargo, la implementación de un proyecto es solo el comienzo de la relación con una empresa cliente, y es durante el periodo de mantenimiento donde las cosas pueden complicarse si no se proporciona una gestión eficiente y una comunicación orientada al usuario. Odoo cuenta con una aplicación de helpdesk que permite gestionar una comunicación basada en tickets con los usuarios del software mediante correo electrónico y, por supuesto, hemos estado utilizándola para prestar nuestros servicios de soporte. Responder rápidamente a preguntas funcionales ha sido sencillo con esta herramienta, pero cuando se recibe un informe de error complejo, es necesario generar un documento separado para apoyar el proceso de desarrollo. En estos casos, hemos utilizado Gitlab y GitHub Issues, e incluso archivos restructuredtext con control de versiones personalizados (analizados con herramientas desarrolladas internamente en Python) para establecer un formato de reporte de incidencias agnóstico al proveedor. Al final, nos encontramos en una situación en la que el trabajo pendiente debía buscarse en al menos tres lugares diferentes, utilizando interfaces y flujos de trabajo distintos. Tanto la comunicación externa como la interna para cumplir nuestras actividades diarias estaba en riesgo, lo que nos impulsó a buscar procesos y herramientas alternativas, incluso si eso implicaba fracturar nuestro “odoo-centrismo”. Discourse ha sido muy famoso como software de foro desde hace muchos años, pero solo recientemente, tras realizar algunas investigaciones, nos enteramos de sus funciones de gestión de trabajo. Lo que nos motivó a probarlo fueron tres cosas: comunicación asíncrona, homogeneización de la definición del trabajo y control del trabajo en curso (WIP).
Comunicación Asíncrona
Los mensajes de Discourse son como el correo electrónico, pero mejores. En un mundo de WhatsApp, Slack, Messenger, Mattermost, Odoo Chat y muchos otros, nos hemos acostumbrado a estar siempre en “modo alerta”. Como todo parece urgente, se te empuja a responder con respuestas cortas, rápidas y superficiales. No hay tiempo para pensar, ni para corregir. Solo escribe y envía. Escribir esta publicación, por ejemplo, me ha llevado mucho más tiempo del que habría anticipado, pero lo hago después de finalizar otras tareas más urgentes, por lo que puedo concentrarme en dar mi retroalimentación más sincera y elaborada (lo mínimo que puedo hacer, de hecho, por una herramienta tan agradable como Discourse). Escribir un mensaje es como enviar un correo electrónico, pero leerlo es toda otra historia. Una historia mucho mejor. Los mensajes están centralizados y compartidos entre todos los miembros de un equipo (o los autorizados). Se pueden buscar por su contenido o ubicación (es decir, temas y categorías) e incluso ser accesibles para usuarios externos o miembros del personal que no participaron en la conversación original, lo cual es excelente para almacenar el registro histórico de cómo se toman las decisiones y cuál ha sido su contexto. Nota rápida: Al observar cómo python.org adoptó Discourse como su aplicación de gestión de comunidades, en lugar de listas de correo u otras soluciones basadas en Python, se demuestra que lo que tenemos aquí es verdaderamente excepcional en términos de idoneidad, rendimiento y accesibilidad.
Homogeneización de la Definición del Trabajo
Esta es la razón principal por la que nos estamos mudando a Discourse. A partir de los antecedentes mencionados anteriormente, probablemente hayas imaginado un entorno de trabajo muy colorido e intrincado. Ciertamente fui un poco demasiado dramático, ya que efectivamente hemos tenido procesos documentados y herramientas digitales para gestionar nuestras actividades desde nuestra fundación. Pero lo que nos ocurrió con el paso del tiempo es que no logramos tener una única representación del trabajo dentro de la empresa. Sí, teníamos tareas para actividades de consultoría y tickets para soporte. El desarrollo se impulsaba mediante requisitos documentados en texto plano o los conocidos issues relacionados con Git. No se trataba de una falta, sino, por el contrario, de un exceso. Había demasiadas fuentes de información e incluso dentro de una aplicación común (por ejemplo, Odoo) había múltiples formatos (por ejemplo, Tarea, Ticket, Issue). Por supuesto, podríamos haber decidido elegir cualquiera de los instrumentos mencionados anteriormente como nuestra única fuente de verdad, pero ninguno nos proporcionaba un elemento crucial: retroalimentación externa integrada. Con solo un mes de uso de Discourse, finalmente sentimos que nos estamos conectando con los usuarios de nuestros productos. No hay distinción entre ellos y nosotros, ya que todos utilizamos la misma interfaz. Sin embargo, no tenemos que ceder el control sobre cómo gestionamos nuestro trabajo, ya que algunas áreas y capacidades pueden restringirse. Pero lo mejor de todo es que, a través de los Temas de Discourse, esos mismos artefactos, similares a comentarios de blog o tickets de helpdesk, que estamos utilizando para comprender las necesidades de nuestros clientes, pueden ser utilizados por nosotros en categorías internas privadas para representar tareas planificadas, incidencias a atender o actividades operativas a realizar. Para nosotros, un tema tiene múltiples sinónimos, todos válidos según su contexto: Incidencia, Tarea, Ticket, Actividad, Lista de verificación, etc. Una forma homogénea de trabajo que es abierta, accesible y gestionada centralmente. Leí que con Discourse for Teams planean lanzar un producto separado, diferente del foro de Discourse, o dicho de otra manera, que Discourse (Foro) y Discourse for Teams están destinados a implementarse como dos instancias diferentes. Te recomendaría que pienses en ello con paciencia, porque ese diseño inevitablemente fracturará la integración actualmente proporcionada entre las partes externas e internas de una organización.
Control del WIP
Finalmente, una de las mejores sorpresas que hemos tenido al usar Discourse es que finalmente podemos establecer un control sobre el trabajo en curso en la organización. Como el trabajo pendiente tiene toda la misma “forma”, es fácil definir políticas para limitar la cantidad de trabajo que la organización debería tener en cualquier momento. A través del plugin Asignar, las tareas se asignan a un responsable único que debe buscar ayuda según sea necesario (que es un ‘@’ de lejos) y, luego, utilizando una interfaz unificada (encontrada en ‘/g/staff/assigned/everyone’), se puede controlar la cantidad de actividades en curso (es decir, WIP) en todo el sistema. Ahora mismo, por ejemplo, estamos iterando con un WIP por persona de 5 tareas/temas/incidencias. Como somos 14, eso significa que nuestra capacidad máxima como equipo debería ser de 70. Esto es muy importante para nosotros porque ayuda a proporcionar estabilidad a uno de los esfuerzos más difíciles de la vida: la estimación. Según la Ley de Little (Little's law - Wikipedia), el número promedio a largo plazo de elementos en una cola es igual a su tasa promedio de llegada o throughput, multiplicado por el tiempo promedio de espera que cada uno de esos elementos permanece en el sistema. Por lo tanto, con un WIP limitado de 70 elementos, si recibimos 140 tickets por semana, en promedio se completarán en 0.5 semanas, y tendría que ser 0.33 semanas en promedio si recibimos 210. Esto asume, por supuesto, que el sistema está en un estado estable y que la cola de espera no crece indefinidamente, por lo que una calibración adecuada del WIP debe realizarse de manera iterativa. Todavía (y siempre) tendremos cantidades menores de tipos de trabajo que no podrán representarse en Discourse, como la gestión de nuestros mensajes de correo electrónico o nuestro pipeline de CRM, pero como la mayoría de nuestro trabajo pendiente ahora tiene una sola forma como los Temas de Discourse, implementar prácticas Kanban y ágiles, como limitar el WIP, será mucho más fácil. Por eso recomendaría que, si Discourse for Teams está destinado a ser una instancia separada del Foro de Discourse, sería una lástima no tener al menos una forma federada para mantener una vista centralizada y compuesta del WIP en ambos sistemas.
Espero que esta publicación ayude a mejorar Discourse como plataforma de comunicación y construcción de comunidades. De nuevo, muchas gracias por ello y ¡les deseo lo mejor!
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
