Tips para escribir visión, necesidades, tareas (Scrum)

Ingrid Astiz Creatividad e innovación, Desarrollo de equipos, Herramientas, Productividad 1 Comment

Para habilitar el trabajo de un equipo, es necesario invertir tiempo en lograr una comunicación clara.

IR AL ÍNDICE SCRUM

Visión del proyecto

¿Para qué escribirla?

  • Una visión  clara, honesta y directa, permite contar con un rumbo y un destino, con una herramienta para confirmar si se está avanzando en la dirección correcta, comparar la visión con la situación actual y diseñar las acciones para llegar a destino.
  • Además facilita la sinergia del equipo, ayudando a que todos miren a un mismo lado.
  • Cuando la visión está concretada, sabemos que el proyecto está terminado.

¿Cómo escribirla?

  • Se puede construir de forma colaborativa, por quienes reciben el producto/servicio y por quienes lo construyen/prestan la solución. Cuando se hace de forma grupal el equipo tiende a comprometerse más y a conectar más fuerte con lo que se está buscando. Es importante que los que que piden o reciben el producto/servicio sean profundamente escuchados.
  • Es recomendable que sea breve, para que sea fácil de recordar y visualizar.
  • Puede incluir una descripción sobre cómo seremos cuando lleguemos ahí, cómo nos queremos sentir, cómo queremos estar. Esto lo aclaro porque he visto que muchas veces se define un objetivo exterior y las personas lo logran pero al llegar ahí están agotadas, con algún problema de salud, con algún vínculo roto… por eso, ayuda a tomar conciencia también de aspectos emocionales y personales, si queremos llegar con salud y con relaciones de confianza fortalecidas, será clave tenerlo presente a lo largo de todo el proyecto. Por eso puede estar complementada con los valores y los principios para tomar en cuenta en la acción cotidiana, aportando claridad a la pregunta “¿cómo queremos avanzar?”.
  • La idea es que la visión sea más que una buena idea, puede ser: un destino específico, una imagen de futuro deseado, un sueño que se quiere hacer realidad, un desafío que se desea resolver, una solución que se busca materializar.
  • Se sugiere esté descrita en tiempo presente (en la mente está siendo ahora).
  • Es importante que esté siempre visible para el equipo, se mantenga viva y actualizada, para que sea incorporada y tomada en cuenta en las decisiones cotidianas.
  • La visión va más allá de las metas: estas son objetivos de corto tiempo, que son medibles y nos acercan a la visión que suele ser mediano o largo plazo. Según las culturas y las personas cambia lo que cada uno entiende por “corto”, “mediano” y “largo” plazo. Para mí, “plazo corto” es menos de un año, “mediano” de un año a 3, “largo” de 4 años o más.

Necesidades (Historias de usuario en un Backlog)

  • Luego de aclarar la visión, es necesario comprender lo que se necesita para concretar la visión y que estén disponibles para ser consultados por todo el equipo. Dado que vivimos en un mundo de cambio constante y de tiempos acotados no es necesario detallar todas las necesidades, sino aquellas que serán las que orienten el trabajo en el corto y mediano plazo.
  • Las necesidades pueden estar expresadas en pedidos para satisfacerlas. Lo que se sugiere es que el pedido no se limite a decir “qué tareas hacer” sino que también se comunique para qué se quiere que esas tareas estén hechas, que se aclare qué necesidades se busca satisfacer, qué problemas se desean resolver, qué oportunidades de mejora se desean implementar. Al brindar más información aumenta las probabilidades de que el equipo esté más conectado con el trabajo por realizar, y que surjan formas diferentes y más creativas de resolver el pedido.
  • Las necesidades tienen que tener un valor de negocio. No es necesario hacer un cálculo de ROI por cada necesidad pero sí tener criterios claros para poder priorizarlas, por ejemplo:
    • El grado de Impacto (puede usarse Alto/Medio/Bajo), que puede ser estimado en relación a si va a ayudar a vender más, a vender mejor, a reducir costos, a prevenir o mitigar riesgos, a mejorar la calidad técnica.
    • El esfuerzo interno en resolverlo (puede usarse una estimación en horas, o más general Alto/Medio/Bajo), el esfuerzo en tiempo de las personas de la organización o el esfuerzo por salir de sus tareas habituales o, si fuera el caso, por un costo de oportunidad.
    • El costo externo por resolverlo (en presupuesto económico), si hace falta contratar un proveedor que lo resuelva.
  • Si el listado de necesidades está visible para todos los interesados en el producto, ellos podrán ver con facilidad cuáles son las ideas en curso y las prioridades. Podrás así dar sugerencias o planificar sus actividades vinculadas.
  • Las “historias de usuario” son un tipo de formato para escribir necesidades: Como [rol] quiero [tarea] para [motivo/necesidad]. Por ejemplo: “Como vendedor, quiero registrar los datos de mis clientes en una aplicación web para consultarlos de forma rápida desde adentro o afuera de la oficina”. Esto puede estar escrito como frase, o puede estar detallado en columnas, por ejemplo: “Quién” o “Área”; “Qué” o “Tarea”; “Para qué” o “Beneficios”.
  • La propuesta es contar con un listado de necesidades (backlog) donde las necesidades más prioritarias estén escritas de forma breve y clara (llamadas “historias de usuario”); las de menor prioridad pueden estar escritas de una forma amplia y poco precisa (llamadas “épicas”). A medida que se van resolviendo las necesidades, las “épicas” van dividiéndose, especificándose y pasando a ser “historias”.
  • Sobre las más prioritarias, antes de comprometerse a resolverlas, es indispensable que quede claro cómo se considerará satisfecha la necesidad. Por ejemplo, si es un producto, deberá detallarse cómo será usado y puesto a prueba, o si es un servicio, qué tipo y grado de satisfacción se espera en el cliente. Puede incluirse, cómo será la situación inicial, qué hará el cliente y cuál será el resultado esperado, por ejemplo: Habrá un botón “Eliminar” al lado del ítem y cuando el usuario haga click sobre el botón, el sistema preguntará “¿Está seguro que desea eliminar el ítem?” Si el usuario responde sí, el sistema lo borra y envía un mensaje de confirmación “El ítem ha sido eliminado”.

Tareas

  • Es necesario identificar las tareas que deben ser resueltas para resolver cada necesidad que se encaren en el corto plazo.
  • Si se usa Scrum, el corazón es la autogestión donde el equipo decide el “cómo” (el “qué” está en la necesidad o pedido que se está respondiendo), es decir, que agregar una o varias tareas específicas para organizar la acción.
  • Cada tarea debe tener por lo menos un responsable asignado. Si se usa Scrum cada integrante del equipo se autoasignan las tareas.
  • Es importante que queden visibles para todo el equipo (y para personas de otras áreas que puedan estar interesadas): las necesidades comprometidas, la división en tareas de la necesidad y el grado de avance.
  • Es importante que las tareas permanezcan vinculadas a las necesidades que le dieron origen para, una vez ejecutada la tarea, se puede revisar si la necesidad fue o no satisfecha.
  • Una vez que están identificadas las tareas es necesario revisar si se cuenta o no con lo necesario para resolverlas. Si hubiera algo que el equipo no pudiera hacer o decidiera no hacer, se convocará a los colaboradores correspondientes para distribuir el trabajo.
  • Es opcional agregar una “vía rápida”, un fragmento en horizontal donde las tareas entren y salgan a alta velocidad, puede estar reservado para emergencias, reclamos (en el caso del desarrollo de software “errores en producción”).
  • Para más información pueden ver el video que hice con Oxean: Mejorar la productividad con Kanban.

Impedimentos

  • Es importante comunicar apenas emerjan o se detecten obstáculos para realizar las tareas.
  • Al comunicarlos estamos abiertos a recibir ayuda y estamos dando alertas tempranas.

Deuda técnica (para desarrolladores de software)

  • La calidad está directamente vinculada con la confianza, y la confianza es la base de Scrum (es decir, la base del trabajo en equipo). Entonces la gestión de la calidad técnica es uno de los aspectos claves para tener presentes y cuidar a lo largo de todo el proyecto.
  • Se deja registro lo que ha sido resuelto con baja calidad de código, y que el no corregirlo genera errores en producción o mayores costos de mantenimiento (es decir, hay que estar seguro que vale la pena el tiempo que se invierta en corregirlo).
  • NO es “deuda funcional”, no es algo visible para el usuario. Lo aclaro porque hay algunos equipos que confunden esto y ponen como “deuda técnica” cuestiones que no lograron terminar a tiempo.
  • Es importante que se especifiquen las tareas de deuda técnica, y que se asigne un porcentaje de tiempo durante el sprint para resolverlas, o bien, que se agregue una historia aclarando el impacto en el negocio (por ejemplo, Mejorar la performance o Reducir el tiempo de desarrollo en tareas de mantenimiento).
  • El Guardián del producto (Product Owner) no necesita conocer el detalle, pero sí el impacto en el negocio y en los tiempos de desarrollo.
  • El Facilitador (Scrum Master) puede chequear que se esté utilizando correctamente la categoría “Deuda técnica”, y que no se estén acumulando demasiados temas en esta categoría.
  • Al momento de encontrar algo resuelto con mala calidad, si es algo rápido de resolver o algo cuyo impacto negativo es muy alto, se sugiere resolverlo en el momento.

IR AL ÍNDICE SCRUM

Comments 1

  1. Hola, Ingrid, soy Carmen López Lacarrere, amiga de tu mamá. Me pasó el link a tu blog, me parece una propuesta super “vital” y bien desarrollada. Creo que la clave de estos tiempos es relacionarse de manera adecuada con los demás, en cualquier ámbito, y esto es un camino de aprendizaje interesante. Te felicito y deseo toda la suerte!!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Captcha *