¿Puede un escritor de contenido de sitio web, soporte y comercializador ser parte de un equipo de scrum?

Finalmente estamos considerando utilizar scrum para uno de nuestros productos, y estamos tratando de averiguar qué hacer con todas las personas del equipo. Contamos con las siguientes personas:

  • Desarrolladores
  • Probadores
  • Atención al cliente
  • Redactores de contenido (redactores de sitios web no técnicos)
  • Diseñador
  • Comercializador de Adwords
  • Gerente de producto

Sabemos que tendremos desarrolladores, evaluadores y un diseñador en el equipo de scrum. Sabemos que el gerente de producto asumirá el rol de propietario del producto y sabemos que alguien del equipo será un experto en scrum.

Sin embargo, ¿dónde se ubican en el equipo el soporte, los escritores de contenido y los especialistas en marketing? Estas son todas las personas que se dedican a este producto y actualmente forman parte del equipo en su configuración pre-scrum.

¿Pueden estas personas ser parte del equipo Scrum? ¿Por qué o por qué no?

Respuestas (2)

Como con todas las cosas ágiles, "depende".

Un equipo Scrum tiene dos objetivos a menudo en conflicto.

  1. Una porción vertical de la organización que puede lanzar de forma independiente software funcional y probado. Esto a menudo requiere un amplio conjunto de habilidades.
  2. Equipo multifuncional "sin roles". Los miembros del equipo Scrum también se comprometen a ser capaces de hacer algo más que "su trabajo". Cualquiera puede tomar una historia, cualquiera puede probar, etc.

Entonces, con esa dicotomía existente, primero importa cuál es la prioridad de su organización en lo anterior.

Desde mi experiencia, esto es lo que yo haría:

Atención al cliente: si es una empresa lo suficientemente grande como para que la atención al cliente interactúe con un desarrollo como este, probablemente sea lo suficientemente grande como para tener un equipo de propietarios de productos (POT). Cuando el Equipo Scrum posee la entrega del trabajo pendiente priorizado, el POT posee la creación del trabajo pendiente. El Equipo Scrum envía el producto, el POT envía una acumulación. Poner la atención al cliente en el equipo de propietarios de productos les da una voz en el diseño desde el principio. Habiendo estado en este rol antes, pude ayudar a evitar los problemas de los clientes brindando experiencia de campo. Escribí sobre esto hace un tiempo en mi blog y tengo una charla completa sobre la creación de backlogs bien formados y equipos de propietarios de productos.

Escritores de contenido: supongo que esto es diferente de los escritores de documentación. Si el producto no puede enviarse sin el trabajo del Redactor de contenido, entonces debe estar en el Equipo Scrum, incluso si no puede hacer ningún otro trabajo (codificación, prueba). Esto se debe a que "Terminado" los requiere. La alternativa es hacerlos parte del equipo Extend Scrum. Este es el concepto de contribuyentes que no se requieren en cada Sprint. Es posible que solo se necesite una persona de la base de datos cada pocos sprints, por lo que se sientan en el equipo extendido y, a menudo, son un recurso para más de un equipo. Si no se necesita Content Writer en cada sprint, intente esto.

Comercializadores : equipo de propietarios de productos. Mismo concepto que Atención al Cliente.

Interesante. De hecho, estábamos pensando que una persona de apoyo sería un buen PO. En nuestra configuración previa a Scrum actual, ya trabajan en estrecha colaboración con el gerente de producto para analizar y priorizar las funciones en función de las interacciones de soporte con los usuarios. Parece que estás sugiriendo que sigamos haciendo lo que ya les funciona bien.
Los escritores de contenido no son únicamente escritores de documentación. Pueden actualizar los documentos de helpcout en la base de conocimiento pública del usuario, pero también escriben contenido para el sitio web, lo que a menudo requiere la comprensión de las funciones que el equipo Scrum creó recientemente. Estábamos pensando que un Departamento de Defensa también podría tener la copia en el sitio web, pero también podemos ver cómo podría ser una unidad separada adjunta al marketing. Si DoD involucra documentos de ayuda, entonces creo que eso es un argumento más sólido para incluirlos en el equipo de scrum real.
Si su gerente de producto no puede encontrar el tiempo para ser el propietario del producto, entonces una persona de atención al cliente con conocimientos técnicos sería una excelente orden de compra. Ya están acostumbrados a ser la voz del cliente. Según lo que estás describiendo para los redactores de contenido, también los incluiría en el equipo. Podría intentar darles un entrenamiento cruzado en la prueba para ayudarlos a ser más colaborativos.

Yo diría que probablemente no deberías poner a todas estas personas en el mismo equipo. Aunque sería un experimento interesante.

Voy a tener que imaginar un poco la configuración de su producto y equipo, pero por lo general he encontrado que obtiene:

Desarrolladores : desea que implementen funciones para su producto

Esta es la columna vertebral de su equipo de scrum porque ha introducido scrum para evitar que hagan lo que creen que es bueno hoy o para reducir un proceso de cascada demasiado largo.

Probadores : desea que estos tipos sean su prueba de aceptación de las características

Puedes poner probadores en un equipo de scrum y mucha gente lo hace. Pero me parece que los aleja del rol de 'aceptación de características' y los lleva a un rol de automatización de pruebas. Esto ejerce presión sobre el PO para escribir especificaciones detalladas en lugar de confiar en la prueba para detectar problemas y plantearlos como errores.

Diseñadores : quieres que estos chicos te vendan sus diseños geniales.

Puede poner a estos muchachos en el equipo, 'Diseñar página X' es una tarea muy fácil de scrum

Product Manager : quiere que este tipo piense en cómo mejorar el producto

Deberías ponerlos en el equipo como propietario del producto.

Soporte : desea que estos chicos mantengan contentos a los clientes

No pondría a estos muchachos en el equipo de scrum. No creo que pueda decirles a los clientes que esperen a que su solicitud de ayuda entre en la lista de espera y se priorice, y si lo hiciera, necesitaría un equipo para hacerlo bien.

Redactores de contenido : desea actualizar el contenido de su sitio web

No los pondría en el equipo de scrum. una de las características de su producto debe ser la 'interfaz de administración de contenido' una vez que esté completa, los escritores de contenido deberían poder usarla para hacer sus cosas independientemente del scrum.

Sería genial si los marcos de desarrollo web incluyeran formas de separar fácilmente el contenido del código real, pero no he encontrado nada como esto. Implementar una función de este tipo, por lo que sé de nuestra cultura corporativa, no sería percibido como valioso ya que están muy centrados en el usuario.
?? la gestión de contenido es una característica bastante básica, WordPress, sitecore, sharepoint
Cierto... pero usamos Java y Google App Engine y no usamos nada que funcione bien con esas cosas y viceversa... Estas también son aplicaciones, no blogs ni sitios web de marketing.
¿Puede un escritor de contenido de sitio web, soporte y comercializador ser parte de un equipo de scrum?
RespuestasAquíPolítica de privacidad1y, 0v