Antes de comenzar un proyecto, sea cual fuere, siempre pido a la persona que lo solicita que se siente conmigo a contarme qué quiere. Para mí, ahí empieza el trabajo principal de lo que después puede ser un rediseño, la creación de una web o simplemente la mejora de un servicio.

Los que han trabajado conmigo (siempre quise poder escribir esto, «los que han trabajado conmigo», es taaaan de gurú) saben que soy bastante cansina con el detalle de una buena toma de requisitos. Esa charla, esa entrevista o conversación, marcará sin duda el éxito del proyecto.

Cuántas tomas de requisitos comienzan con un «quiero cambiar esto de mi web» y terminan siendo algo totalmente distinto a la idea que el dueño del producto tenía. Mejoras de secciones que terminan en rediseño de web, intuiciones no fundamentadas que terminan siendo una realidad, problemas vistos en el servicio online que se solucionan con la mejora de procesos humanos… Todo parte de la que creo la más importante de las virtudes de nuestro gremio, de los expertos ux: saber escuchar.

Por ello, en su momento, intenté sintetizar esta pequeña guía que siempre me ayuda a conducir esa toma de requisitos. Y fan como soy de la metodología de las 5 W, en ella la baso.

---

Guía para una buena toma de requisitos

5W: what, why, who, where, when = HOW

WHAT – ¿Qué es lo que necesitan? ¿Cuál es el objetivo?

Hay que saber cuál es el objetivo del proyecto, no cuál es el proyecto en sí. Éste lo decidiremos en función de las necesidades.

Por ejemplo, no es lo mismo decir
«Quiero dejar de gestionar mis pagos por teléfono»
que
«Quiero que el cliente pueda meter su cuenta bancaria en la web para domiciliarle el pago»

La primera premisa puede llevarnos a externalizar el servicio por falta de tiempo, a revisar el proceso por temas legales o a la segunda opción, el pago online.

Pero es posible que lo que parece obvio, no siempre lo sea. Tal vez tu usuario no sea del que está dispuesto a pagar online o que tu producto se esté vendiendo más por teléfono que vía web. Tenlo en cuenta.

WHY – motivos. ¿Por qué necesitan este desarrollo?

No se trata de que intenten justificar el proyecto ante nosotros, se trata de que nos expliquen de dónde surge esa necesidad.

A menudo me he encontrado que intentan justificarme ciertos desarrollos como si tuvieran que excusarse ante algo que ahora se está haciendo mal o de manera ineficaz.

No se trata de juzgar, si no de saber los motivos que empujan al cambio.

WHO – ¿Qué usuario va a ser nuestro objetivo?

No es lo mismo saber para quién es el proyecto o desarrollo (el cliente) que saber quién va a usarlo.

En una empresa un nuevo desarrollo puede ser para el equipo de atención al cliente, por ejemplo, con el fin de ahorrarle tiempo de gestión. Pero tal vez el usuario final sea el cliente de tu producto en sí, ya que tal vez intentes que sea él quien haga una acción por si mismo en vez de gestionarlo a través de alguien de tu equipo telefónicamente.

Por ejemplo, que un usuario pueda incluir y modificar sus datos de facturación a través de un panel de usuario, reducirá el tiempo de gestión y llamadas telefónicas de las personas que se encargan del seguimiento de tu cliente desde la oficina.

Hemos de distinguir a menudo, pues, entre el usuario interno y el usuario externo.

WHERE & WHEN – ¿Cuándo y dónde se va a usar?

Analizar siempre los distintos casos de uso que se pueden dar nos ayudará a preveer escenarios y momentos muy útiles. Esto nos puede ahorrar caer en ciertos errores a los que solemos llegar a través de presuposiciones.

Ejemplo: Si vas a desarrollar un servicio relacionado con el transporte público, ten en cuenta que muchos de tus usuarios acudirán a él mientras están en trayecto. Eso decidirá que tu web sea visible en un móvil o tableta.

Además de estas 5 W, que marcarán el «HOW», trato siempre de responder a estas 5 preguntas:

1. ¿Qué querrás medir de este desarrollo?
   La medición del objetivo te dirá el éxito del cambio.
2. ¿Has tenido en cuenta a todos los agentes que intervienen en el cambio?
   Si hablamos de algo que estará online, ten en cuenta siempre, siempre, el SEO. Si se trata de un desarrollo técnico, habla con los desarrolladores. Si hablamos de e-commerce, no empieces sin hablar con el comercial. Ten siempre en cuenta a todos los agentes que intervienen. Como fuente de sabiduría y como «usuarios que sufrirán tus novedades».
3. ¿Realmente es necesario?
   A veces nos empeñamos en desarrollar funcionalidades porque «intuimos» que mejorará nuestro producto o servicio. Un test previo (test de usuarios, encuesta, entrevista o lo que corresponda) tal vez nos diga que esa intuición no era tan acertada.
4. ¿No hay nada que ya esté resolviendo/cubriendo esta necesidad?
   Ten cuidado, a menudo no se trata de innovar, si no de resolver o mejorar.
5. ¿Es posible que se amplíe, reduzca o elimine el proyecto? ¿que se hagan modificaciones en él?
   Si algo aprendí de las metodologías ágiles y del scrum, es que todo proyecto hay que hacerlo desde un punto de vista escalable. Si mañana hay que ampliar una sección, incluir nuevos productos o dar acceso a más usuarios, no me obligues a rehacer lo hecho. Intenta desde el principio que lo que haces tenga un modo fácil de crecer.

Y tú ¿qué cosas tienes en cuenta al comienzo de un nuevo proyecto?