Hola Habr!
Hoy queremos hablar sobre cómo nuestro equipo de productos aborda la preparación de requisitos funcionales para los desarrolladores al crear nuevos productos y características.
En la etapa de desarrollo, pueden surgir muchas sorpresas, especialmente si la tarea no se describe claramente. Los diferentes miembros del equipo pueden comprender el desarrollo y el funcionamiento de la misma característica de diferentes maneras, por lo que los gerentes de producto son responsables de crear un producto desde el desarrollo del concepto hasta la versión final. Y una parte importante de este proceso es la preparación de requisitos funcionales.
La cuestión de describir tareas para desarrolladores que ya hemos mencionado en el artículo
Cómo los gerentes aprenden a establecer tareas para desarrolladores , pero en ella hablamos más sobre cuestiones administrativas, y hoy hablaremos más sobre cuestiones técnicas. Este es un componente extremadamente importante de cualquier negocio cuyas ventas se realizan a través de Internet. Cada empresa que se está desarrollando activamente en el entorno de Internet, de hecho, se convierte en un negocio de software. Pero a pesar de esto, las competencias en el campo de la gestión de requisitos tienden a crecer muy lentamente.
Como resultado, a menudo vemos la misma imagen: las tareas de diferentes departamentos caen constantemente en el departamento de desarrollo, los requisitos en estas tareas se describen vagamente y, tan pronto como se pone en acción, vuelve inmediatamente para su revisión (porque el director no describió completamente lo que quería, y el desarrollador hizo lo que creía conveniente). El resultado es obvio: plazos impredecibles para tareas que pueden llevar meses, un equipo desmotivado, tensiones dentro del equipo, clientes insatisfechos, rezagados con respecto a los competidores, etc.
Con este artículo queremos dar una receta simple que sentará las bases para resolver tales problemas. Se puede recomendar de forma segura para el estudio (además, para la acción) a todos aquellos que establecen tareas.
Diferentes compañías tienen diferentes enfoques para escribir requisitos funcionales, pero en
Retail Rocket nos decidimos por esta opción y hasta ahora no nos arrepentimos.
Requisitos funcionales: qué es y por qué son necesarios
Primero, veamos cuáles son los requisitos funcionales.
Requisitos funcionales: esta es la declaración del problema para el desarrollador. Todo lo que no se indica en los requisitos se realiza a discreción del desarrollador, que a menudo difiere de la presentación del gerente de producto sobre el resultado esperado. Por lo tanto, los requisitos deben contener respuestas a todas las preguntas posibles sobre la tarea.
Los requisitos funcionales generalmente consisten en:
- Historia de usuario: muestra lo que espera del equipo de desarrollo
- Casos de uso: muestra escenarios de uso
- Wireframes: una herramienta de visualización para su idea
Hoy nos centraremos en la historia del usuario y los casos de uso.
Historia del usuario
La historia del usuario describe lo que el usuario desempeña en un determinado rol para lograr el resultado y lo que el desarrollador debe hacer para dar vida a esta tarea.
Por lo general, se usa una plantilla:
Como a / an <Nombre de rol>, quiero <Propósito, Acción>, para que <Resultado esperado>, haga <Lo que el desarrollador debe hacer>Hay varios ejemplos de la aplicación de esta metodología. Por ejemplo, así es como
funciona en Trello:
En Retail Rocket, creamos Historias de usuarios en Google Docs usando tablas. Esto ayuda a simplificar el proceso de comunicación entre los diferentes equipos, ya que todos pueden dejar comentarios y dar su opinión.
Por ejemplo, así es como se ve la tarea de seguimiento de NPS para una tienda en línea:
Gracias a dicha visualización de la interacción, la tarea del usuario pasa de manera fluida y lógica a la tarea de los desarrolladores. Luego llega el turno de los casos de uso.
Casos de uso
Los casos de uso describen el comportamiento del usuario paso a paso al interactuar con un producto desarrollado.
La tarea del usuario es lo que el usuario hace para lograr objetivos a corto plazo.
Si el usuario resuelve el problema en la página desarrollada de varias maneras, entonces cada solución debe tener su propio caso de uso escrito. Por ejemplo, si el acceso a la funcionalidad afectada se encuentra en varias páginas, debe escribir un caso de uso separado para cada forma en que el usuario cambie a la funcional.
Veamos un ejemplo de nuestra función lanzada recientemente:
Galería de imágenes y fuentes para envíos masivos.
El objetivo del usuario es almacenar imágenes en nuestra plataforma y usarlas para crear campañas de correo electrónico.
Tareas de usuario:
- Sube imágenes
- Incrustar imágenes en una plantilla de carta
- Eliminar imágenes
Para cada tarea, debe escribir su propio caso de uso: una descripción de cómo interactúa el usuario con la interfaz.
Ejemplos de casos de uso:Carga de imagen:
- Email Marketer inicia sesión en su cuenta personal de cohete minorista
- Email Marketer abre la sección de la galería
- El vendedor por correo electrónico carga imágenes arrastrando y soltando o haciendo clic en el botón "Seleccionar archivos"
- Se suben las imágenes.
- El usuario ve una notificación de carga exitosa de imágenes
Eliminar imágenes:
- El usuario hace clic en la imagen
- Imagen destaca
- La selección se puede eliminar haciendo clic en el área fuera de la imagen seleccionada.
- El usuario hace clic en el icono de tres puntos.
- Aparece un menú contextual.
- El usuario selecciona el enlace "Eliminar archivo" en él. Si se seleccionaron varias imágenes, todas se eliminarán.
- Imagen eliminada
Todos los escenarios de uso se pintan de la misma manera, lo que le da al desarrollo una comprensión clara de cómo se ve la interacción del usuario con el producto o las características, y qué se debe hacer para esto.
¿Por qué los requisitos funcionales son tan importantes?
Con este formato de requisitos funcionales, proporciona al equipo de desarrollo instrucciones claras. Además, puede mostrar cómo se ve la interfaz desde el lado del cliente y cómo resuelve sus tareas. Este enfoque ayuda a presentar su idea y evitar malentendidos en el equipo.
Por lo general, la formulación del problema a los desarrolladores genera muchas preguntas, cuyas respuestas dependen de la complejidad y el momento de la implementación. Para aclarar los detalles, tienen que dedicar tiempo a la comunicación en lugar de su trabajo directo, creando funciones interesantes y mejorando el producto. E incluso en el proceso de comunicación, no siempre se aclaran todas las sutilezas si el director de tareas solo responde las preguntas que surgen, pero el usuario no sigue el mismo camino.
Tome nuestro ejemplo de galería. Si al gerente de producto se le ocurrió la tarea de crear una galería, en un punto sobre la eliminación de archivos, los desarrolladores tendrían que aclarar:
- ¿Necesito eliminar el archivo?
- ¿Será una eliminación manual o los archivos más antiguos se eliminarán automáticamente cuando se descarguen nuevos, si se supera el límite de almacenamiento?
- ¿Es la eliminación de la lista de archivos o necesita abrir el archivo?
- ¿El archivo se elimina permanentemente o hay una cesta para los archivos donde se almacenan durante algún tiempo? Si necesita una cesta, ¿cuántos archivos hay almacenados en ella?
- ¿debería haber eliminación de archivos por lotes o solo se puede eliminar uno?
- el archivo se elimina con un ícono separado (¿cómo se ve este ícono?) o mediante un elemento del menú (¿cómo se llamará? ¿Dónde se encuentra en la lista de acciones?)
- etc.
Y después de todo, este es solo uno de los puntos de la tarea, y ya hay muchas preguntas. Y descubrirlos requiere tiempo y esfuerzo de ambos lados.
Los requisitos funcionales ayudan al gerente de producto a pensar y formular claramente todos los escenarios de interacción del usuario desde las interfaces dentro de la tarea.
Cuanto más precisa sea la tarea y más detalles tengan los desarrolladores antes de comenzar a trabajar, más eficiente será el trabajo. No se pierde tiempo en una comunicación larga y a veces sin sentido. En este caso, todas las partes se benefician: los desarrolladores obtienen una comprensión clara de qué y cómo hacer, y el proveedor de tareas realiza el trabajo exactamente en la forma en que lo imaginó.
¿Y cómo aborda la formulación de tareas para desarrolladores?
Director de producto Gulfiya Kurmangaleeva