¿Es necesario escribir una tarea técnica? ¿Cuál es la mejor manera de hacerlo?

Answer 1

En la mayoría de los casos, SÍ.

Cada tarea que creo como Project Manager tiene 3 componentes. Historia del usuario, tarea y criterios de aceptación. Mi responsabilidad es la parte de la historia del usuario, donde escribo cosas en inglés simple, es decir, “el cliente quiere implementar este complemento en su sitio web” y ponerlo en Backlog.

Durante la revisión del trabajo atrasado / reunión de sprint discutí esto con mi jefe técnico y él escribe la parte de “Tarea” que es básicamente una explicación detallada de cómo se realizará esta tarea de la A a la Z (es importante porque el equipo de QA necesita prepararse plan de prueba basado en la revisión de esta explicación de la tarea). Además, si un nuevo desarrollador se une en medio de un proyecto, también sabrá exactamente qué se está haciendo aquí (por lo que no solo es por el bien de la tarea sino también para la revisión del proyecto más adelante si alguien nuevo Uniones). Y la última parte “Criterios de aceptación” es, por supuesto, el ciclo de vida de la tarea, es decir: Estimación requerida, asignada, estimación aprobada, En curso, Revisión TL, Revisión PM, etc. (diferentes etiquetas) dependiendo de cómo va la propiedad de la tarea .

Answer 2

Depende del tipo de tarea. Me inclinaría hacia un ‘Sí’ en estos casos:

1. Si el usuario no está familiarizado con el tema o no ha recibido capacitación que le permita ser autodirigido
   > Cuanto menos sepa su público objetivo, más necesita explicar.
2. Si la tarea es muy compleja con múltiples pasos y varias acciones para cada paso
   > Las tareas largas requieren pasos e hitos claramente numerados
3. Si la interfaz de usuario no se explica por sí misma y no es evidente de inmediato cuál debería ser el siguiente paso
   > Proporcione gráficos para ayudar a guiar al usuario sobre lo que esperaría ver en el sistema que está utilizando
4. Si la tarea tiene muchas advertencias entre los pasos, como advertencias y casos excepcionales a tener en cuenta
   > Marque estos claramente para que se enfaticen entre los pasos habituales
5. Relacionado con el ítem 4, si la tarea contiene alto riesgo o tiene un alto impacto
   > Las listas de verificación suelen ser útiles

Answer 3

Sí.

Aclare el propósito de la tarea. Esto es útil para las personas que no creen que la tarea valga la pena y para cualquiera que intente tomar una decisión en la que no haya pensado.

Conoce a tu público objetivo. Si esta tarea será realizada por alguien que se capacitará en la tarea, usted tiene un enfoque diferente que si está escribiendo para el público en general.

Usa imágenes para ilustrar puntos. Las capturas de pantalla son las mejores.

Aclare los requisitos previos de la tarea. Cualquier cosa que deba obtenerse que no sea nativa del entorno de la tarea debe discutirse.

Incluye cada paso. Asegúrese de que sepan con claridad qué buscar si la tarea es exitosa y qué buscar si la tarea salió mal y qué hacer a continuación en cualquier caso.

Déles una idea de cuánto tiempo lleva la tarea si es más que una tarea rápida.

Determine qué productos o artefactos serán producidos por la tarea. Cosas como informes o archivos de datos.

Determine dónde y cómo informan o registran su actividad si es posible.

Pruebe la tarea con alguien que no la conozca. Hacer ajustes.

En general: escriba la tarea como si no recordara cómo hacerlo y alguien le va a pedir que lo haga en seis meses.