Seguro que lo que te voy a contar te suena: empiezas un proyecto que parece estar bien definido y con el paso de los días acabas trabajando en un Frankenstein que cada vez tiene más cambios y más características nuevas.
Y va incrementando el coste para ti, claro.
El “truco” para evitar estas situaciones es definir un buen Product Design Specifications (PDS), o lo que viene a ser una toma de requisitos en condiciones o un brief.
¿Brief? ¿Toma de requisitos?
Antes de empezar siquiera a pensar cómo resolverás el problema por el que te contratarán, es de vital importancia que redactes una buena toma de requisitos.
La toma de requisitos es algo que heredamos del mundo del software y que poco a poco empieza a abrirse camino en el diseño de producto digital. Se trata, en resumen, de un documento que describe qué diseñarás, por qué y cómo.
Su objetivo es articular de manera clara y sin ambigüedades el propósito del producto, sus características, funcionalidad y comportamiento.
Este documento tiene distintos beneficios para nosotros:
- Nos permite definir un presupuesto cerrado
- Definir un timing adecuado a las necesidades del proyecto, ya que nos permite estructurar el trabajo por semanas y tener más claro en qué se trabaja y qué hay por delante.
- Redactar al detalle qué hay que hacer y cómo, evitando así que el cliente añada cambios
- Es nuestro “seguro de vida”: al estar aprobado por el cliente al inicio, cualquier cambio en él -añadir otra característica, por ejemplo-, se presupuestará por separado.
No es un documento banal. Como se suele decir, “si la toma de requisitos se realiza bien, puede que el resultado no sea un producto exitoso, pero es cierto también que si no se realiza en absoluto, es imposible que el resultado sea un buen producto”.
Contenido de una toma de requisitos
Vaya por delante que no pretende ser una lista exhaustiva, sino un documento que se pueda tomar como base e ir añadiendo puntos a medida que crezca la complejidad del proyecto.
¿Qué objetivo se persigue?
Lo primero que hay que definir es el objetivo de lo que diseñemos. ¿Se trata del rediseño de una página? ¿Por qué se rediseña? ¿Vamos a añadir una nueva funcionalidad? ¿Por qué?
Recuerda que debe ser medible para que posteriormente sepamos si lo hemos alcanzado o no.
Como se suele decir, si no sabemos dónde vamos, ¿cómo sabremos si hemos llegado?
¿Para quién?
Está muy bien diseñar o rediseñar un producto, pero… ¿qué hay del usuario? Es importante tener claro qué le supone ese cambio al usuario, por qué y… si realmente es lo que necesita.
¿Cómo podemos saberlo? Bien, aquí es necesario coger datos actuales del producto, entrevistar a algunos usuarios o hacer encuestas. De este modo sabremos un poco por dónde van los tiros y hacia dónde enfocar todo el trabajo.
En este punto también hay que tener en cuenta al propio cliente y sus motivaciones para querer ese cambio. Es importante saber qué valor le da y cómo de importante es para el negocio. Y, obviamente, nunca debemos olvidarnos de la marca.
¿Qué características tendrá?
Aquí hay que listar y describir qué características tendrá el diseño (o rediseño) del producto. Hay que explicar cada detalle para facilitar el diseño, pero también la programación.
Aquí es importante que cada característica quede enlazada al objetivo. Es decir, que se vea que afectan a su consecución. De este modo podemos blindarnos con posibles cambios futuros y argumentar por qué no se debe quitar esa característica en concreto.
De estas características acabará saliendo las tareas a realizar, que posteriormente habrá que priorizar (must-have, high-wanted y nice-to-have) e ir añadiendo en un proceso de Scrum o Kanban para irlas sacando poco a poco.
Aunque se hable de características, este también es el momento para añadir otras tareas, como realizar los wireframes, prototipos, diseño final…
¿Hay riesgos potenciales?
Es importante tener una previsión de qué podría ir mal en el proyecto y definir cómo se solucionará. Por ejemplo, que el cliente no envíe la información a tiempo y por lo tanto se retrase el calendario, que el servidor que se usará no admita ese lenguaje en concreto, etc.
¿Qué métricas se usarán?
Como te comentaba en el primer punto, el objetivo debe tener asociada alguna métrica que permita ver si se cumple o no con el objetivo marcado. Si necesitas una guía, léete este artículo en el que te explico cómo medir UI y UX con Google Analytics.
¿Para cuándo?
Una vez estén claras las características y su priorización, es posible hacer una estimación más o menos realista del tiempo que supondrá realizarlo todo. Si se le presenta al cliente un timing realizado con estos datos, será más reacio a “recortar tiempo”, ya que verá que si recorta, perderá características que necesita para alcanzar el objetivo (de ahí lo que te decía en el segundo punto, que cada característica debe tener bien enlazado el objetivo).
Toma de requisitos en el “mundo real”
Estoy convencida de que ahora estás pensando: “vale sí, muy bien Cris… ¿pero cómo aplico esto en mi día a día?”.
Si eres autónomo es relativamente fácil añadir este tipo de documento en tu flujo de trabajo. Lo normal es hacerlo mano a mano con el cliente -de manera presencial o colaborativa con Google Docs, por ejemplo-, evitando el típico briefque se pasa por e-mail que solo dice “necesito una web”.
Si trabajas en una empresa que ya tiene los procesos muy asentados, soy consciente de que de entrada será complicado. Una manera de empezar a implementarlo sería haciéndolo tú por tu lado, para que te sirva a ti de base y una vez lo tengas bien definido y tenga los puntos necesarios -cada proyecto y cada empresa son un mundo-, escalarlo a puestos de mánager para que lo valoren. Si ven un ejemplo “en vivo y en directo” probablemente sea más sencillo que lo implementen.
Conclusiones
Una correcta toma de requisitos te permitirá ir más sobre seguro, ya que así tendrás un documento guía que te servirá para que el cliente sepa cómo está su proyecto y cómo se está desarrollando.
Para ti es un blindaje que te servirá para defender tu trabajo y poder tener cerrado al máximo posible el proyecto para que no aparezcan “setas” que alarguen el tiempo y el coste.
Si te ha gustado este artículo de https://lapizgrafico.com/ únete a nuestro canal de Telegram para recibir más artículos como este o síguenos en Twitter, o unete a nuestro canal de app para windows.
