Requerimientos…
…de la boca de un experto: Fernando Palacios.
Hoy en día cuando hablamos de desarrollo de software en automático me vienen a la mente 3 conceptos: agilidad, dispositivos móviles y startups. Leemos, vivimos y soñamos con diversos frameworks de agilidad, y obvio; todos quieren ser ágiles, ser emprendedores, innovar y desarrollar soluciones disruptivas que cumplan cabalmente con todo lo que nuestros clientes piden. Pero para cumplir con esas metas hay algo que tristemente dejamos de lado, o por lo menos no le damos la importancia y respeto que se merece: LOS REQUERIMIENTOS.
La gestión de requerimientos es más que un proceso, es un arte complejo de saber escuchar, ser escuchado, de saber cuándo recomendar, cuándo ofrecer una hoja de papel para maquetar o dibujar lo que la inspiración mande. Es saber cuándo ofrecer un buen café para entender lo que nuestros clientes quieren; es una mezcla de pasión con conocimientos técnicos, un poco de psicólogo y un mucho de consultor. Son esas horas no valoradas que determinan el éxito del proyecto, solución, MVP, prototipo, APP o como quieran llamarlo.
Desde hace algún tiempo (y muchas canas) vengo trabajando y apoyando a bancos, gobierno federal, fintechs, valeras y startups en LATAM para la gestión de requerimientos y les puedo decir que las preguntas no cambian mucho. Incluso las respuestas son similares, no importa si las escribimos en HU y mockups o en casos de uso de RUP y UML (para los nostálgicos como yo).
Los requerimientos no solo son funcionales o los que vemos a primera vista; o los que nos piden por que se ven bien en la plataforma, o aquellos que vimos en algún sitio web. Estos son solo una pequeña parte del universo de todos los requerimientos que debemos considerar. Es gracioso ver a enormes y pequeñas empresas que les dedican solo un par de horas para analizarlos a conciencia y escribirlos en una HU que no tiene más de 5 hojas incluyendo el índice.
Mis queridos colegas y amigos, los requerimientos nos deben servir para que el producto tenga el IMPACTO y el VALOR que el negocio nos pide y es en este momento cuando me surge una gran duda:
¿Estamos siendo ágiles…? ¿O veloces?
Es necesario entender como una simple plática con nuestros clientes ayuda a equipos tan diversos, como infraestructura, seguridad, Data o hasta legal y finanzas.
¿Pero cómo hacemos para saber que estamos detallando todos los requerimientos? ¿Que no se nos escape nada?
Les diré algo que llevo divulgando desde hace más de 10 años: NO, pero absolutamente NO OBVIES NADA, no des por entendido que tú eres el experto, incluso, a veces, pero solo a veces; el mismo negocio no conoce su negocio, y por supuesto … La pregunta más tonta es la que no se hace.
Vemos un caso simple y muy real en donde quiero mostrarles un poco de lo que estos años y canas me han enseñado, y que sirve para clarificar lo que quiero expresarles. Obviamente, siempre respetando los frameworks y/o marcos de referencia.
“AZTECA WEB es una empresa con tiendas físicas y pocas ventas on-line y requiere cambiar su pasarela de pagos y volcarse de lleno al e-commerce.”
Como sabrán, siempre habrá esos “visionarios” internos que quieren impactar con sus propuestas, pero sin un análisis de las repercusiones de las mismas. Para este ejemplo listaré una serie de objetivos a alto nivel que los directivos mencionaron. Aclaro que esta simulación es una recopilación de experiencias reales que combinan personas con diferentes profesiones, puestos, experiencias, países y, por supuesto, visiones de lo que quieren alcanzar.
Van los requerimientos:
- Queremos un sistema sencillo, fácil de usar y amigable
- Queremos una nueva plataforma de pagos
- Queremos que en nuestras tiendas físicas exista un sistema de auto cobro por medio de Tablets
- Queremos reportes
- Queremos gestionar la entrega de nuestros productos que se compren en línea
Iniciemos con algo que todos sabemos; El cliente siempre pide lo que quiere, más no lo que necesita y justo es ahí donde nosotros como analistas de requerimientos los ayudamos. Antes de iniciar te recomendaría esto:
- Pregunta por el stack tecnológico ¿Qué BD, la infraestructura es híbrida, física, nube? ¿En qué está desarrollada la mayor parte de las aplicaciones?
- Date una vuelta por el LinkedIn de la empresa, Facebook y más redes sociales… te sorprendería saber lo que encontrarás.
- Conocer a sus clientes/usuarios finales quien usa la plataforma
- Platica no solo con el stakeholder o patrocinador, conoce las experiencias de todos lo que participan en la cadena de valor.
- NO OBVIES NADA
- Pregunta TODO
Ahora si: vamos paso a paso; ojo que no quiero profundizar ya que podríamos llenarnos de detalle y hoy no se trata de eso. Desglosemos y analicemos los requerimientos de “AZTECA WEB”.
- Queremos un sistema sencillo, fácil de usar y amigable
Cualquier requerimiento debe estar construido con estas máximas: SER CLARO, SER CORRECTO y MEDIBLE (hay otras más). Esto nos ayuda a quitar la ambigüedad que el requerimiento sea trazable y UNICO. En este caso yo diría:
“Señor usuario, lo que mediremos será la cantidad de abrazos y numero de buenos días que de la app 😊.” (broma y sarcasmo)
Fácil de usar …uff… Mi master de UX y guía espiritual; un argentino y mezcalero de corazón estará a punto de infarto con esta petición.
Descartaría por completo este requerimiento y me inclinaría más por el hecho de que la actual plataforma no es atractiva, la experiencia de usuario no es buena, el diseño es anticuado o no es responsive
Acá mis colegas UX /UI deben ser considerados y escuchados; A/B Testing, encuestas de satisfacción y conocer la cadena de valor y el Journey de lo que es nuestro producto, reduce esas brechas.
Un gran jefe me dijo una vez, el UX /UI es como un chiste, si se tiene que explicar no sirve. (gracias JA y CM)
- Queremos una nueva plataforma de pagos
Lo primero que preguntaría, es ¿Por qué la quieren cambiar? ¿Su actual modelo no funciona? ¿Necesitan mejorar las tarifas? ¿Quieren dar más opciones de pago a sus clientes? ¿Buscan posicionamiento con proveedores reconocidos?
¿Qué está fallando con su actual plataforma? Esto nos dirá mucho, acá no se trata de cambiar sino de ver que no está funcionando, que sí, y cuáles son los objetivos de negocio y estrategia para alinear a la nueva solución. Antes de pensar en Demos, POC y en reuniones de ventas con proveedores y soluciones, pensemos que estamos buscando y hacia dónde va el negocio.
Ese es la meta real de la gestión de requerimientos, tener sesiones con los stakeholders e identificar otros puntos que nos permitan la toma decisiones:
- ¿La empresa opera en México o existen planes de expansión?
- Esto para saber si buscamos solución global o local
- Cada mercado es diferente en cuanto a cuotas, tarifas, IVA, facturación, ETC
- ¿Cuánto buscan crecer sus ventas con este modelo de e-commerce?
- Como es la tasa de conversión de usuarios
- Proyecciones de ventas
- Cómo lo van a potencializar: ¿campañas? SEO, SEM
- Ya contactamos con el equipo de Marketing
- ¿Conoces a tus clientes, quieren usar pagos vía internet? Confían en esto (Idiosincrasia LATAM)
- Nuestro mercado es consumidor online
- Pagaría en línea, ya sea por poder adquisitivo, uso de Tarjetas o confianza a esos canales
- Pensaríamos en transferencias, SPEI, Pago contra entrega, Pagos en sucursal
- ¿Cuál es el ticket promedio?
- El uso de estos servicios impacta en el precio de venta
- ¿Nuestros clientes requieren pagos diferidos?
- Meses por intereses, promociones
Todas estas preguntas ayudarán al equipo de arquitectura e infraestructura para comenzar a dimensionar volumen de todos los nuevos clientes, ancho de banda, al equipo de data para el almacenamiento incluso al equipo legal y de compliance para ver el tiempo de resguardo de los datos, si no vemos esto tendremos a “n” clientes queriendo consultar meses de datos, imaginen el número de peticiones y el tiempo de respuesta
¿Hasta dónde debo llegar?
Si se dan cuenta vamos aumentando el detalle y el nivel de profundidad de los requerimientos, y seguro se preguntarán ¿hasta dónde debo llegar? Esta respuesta es compleja pero también menos complicada de lo que imaginan. Lo sabrán cuando lleguen hasta donde sus equipos y todos en el squad entiendan lo que necesitan, en una tarjeta con HU, en un documento detallado o un diagrama simple.
Les comparto algo que me ha ayudado demasiado, y aunque me encantaría, esto lleva en el mercado más de 20 años, “Rational Process” y UML nos los decían.
Pregúntate que deberá contener tu sistema o solución, la clave es usar esa palabra: DEBERÁ. Esa frase sencilla puede tornarse compleja para aquellos que no saben lo que quieren. Si les hacen esa pregunta a sus clientes…. “¿Qué debe tener el sistema?” les ayudará, ya que pondrá a nuestros clientes a pensar en qué quieren realmente y es ahí cuando el analista se vuelve consultor.
- La Nueva plataforma de pago deberá permitirme ofrecer pagos con al menos 5 bancos nacionales
- La Nueva plataforma de pago deberá permitirme hacer pagos con tarjetas internacionales
- La Nueva plataforma de pago deberá permitirme hacer pagos en mensualidad
- La Nueva plataforma de pago deberá permitir generar una orden de pago para hacer el mismo en bancos o tiendas de autoservicio
- La Nueva plataforma de pago deberá contar con reconocimientos VISA, MC y de AMEX
- La Nueva plataforma de pago deberá contar con certificación PCI-DSS
- La Nueva plataforma de pago deberá mostrar las últimas 20 transacciones del usuario
- La Nueva plataforma de pago deberá desarrollar una arquitectura que me permita incorporar países al esquema de pagos conforme el plan de expansión
- Queremos que en nuestras tiendas exista un sistema de auto cobro por medio de Tablets
El ejemplo más claro de la combinación del hardware y software para la gestión de requerimientos, si bien el requerimiento es simple, se torna complejo con estas preguntas.
¿La Tablet la proporciona Azteca WEB? ¿Tienen en stock? ¿Tiene un lector de tarjetas físicas (TPV) para el cobro? ¿Las tabletas son Android? ¿Qué resolución tiene? ¿Imprimirán recibo? ¿Consideran algún mobiliario para evitar el robo o daño de las mismas? ¿Tenemos un plan cuando no hay red o Tablet disponible?
Este requerimiento lleva temas de redes, seguridad, biométricos y costos escondidos que nadie vio y van saliendo. Con estas preguntas el tomador de decisiones ya se hubiera cuestionado si es momento de este requerimiento o si debe replantear la estrategia.
Pudiéramos ofrecer los mismo con un dispositivo móvil y un lector de tarjetas bluetooth 😊
- Queremos reportes
Las dos palabras más temidas por muchos, ¿el equipo de DB es el equipo de Reportes? BI VS Big Data, antes de llegar a estos temas complejos y apasionantes, preguntaría ¿Qué NECESITAS ver en los reportes? ¿Cuántos reportes tienes? ¿Me los compartes? ¿Qué no están viendo? ¿Tenemos toda la información? ¿Necesitas descargar el reporte en una Hoja de Cálculo, PDF, CSV? La información mostrada cuánto tiempo tiene ¿un mes, un trimestre, un año?
Tenemos alguna solución para mostrar los datos, he de decirles que el éxito de este requerimiento no es que tan rápido puedas mostrar los reportes, o si se descargan en excel o no. El éxito radica en saber si cuentas con toda la información necesaria, sabes dónde está cada dato. Para ello el equipo de data nos ayudará a tener un gobierno de datos, normado y estandarizado. HOY LA INFORMACIÓN es PODER más que nunca.
Los requerimientos no son solo funcionales, para mis los requerimientos que más trabajo nos dan son aquellos que no vemos, que no consideramos y es más, no los documentamos: LOS REQUERIMIENTOS NO FUNCIONALES, aquellos que puede ser el éxito de un proyecto.
Los requerimientos NO funcionales (URPS) o atributos de calidad son los menos explotados pero los más recurrentes en los equipos de QA:
- En WEB que pasa si le doy clic al botón atrás en mi navegador
- Ortografía
- No son los colores institucionales
- El diseño es responsive
- Rango de fechas
- Tiempo de sesión activa
- Enmascarar datos de tarjetas
- Tiempos de descarga de PDF
- Tiempo de Respuesta de una consulta
En conclusión
Sin duda hablar de estos requerimientos me llevaría otro artículo completo y si hablamos de QA otro más, pero no quiero aburrirlos con tanta palabra y lectura aburrida. Me gustaría concluir diciendo que la gestión de requerimientos muchas veces no es valorada, pero sin duda existimos locos que aún disfrutamos de platicar y ayudar a nuestros clientes a que estén contentos y que vean a los equipos de TI como sus aliados, no como un área más.
Gestionar requerimientos es como un traductor entre los que hablen en Dinero, Objetivos y KPI y los que hablan en bytes y datos. Si bien ya hay muchos que hablan estos dos idiomas, tener alguien que esté de los dos lados no solo fomenta la comunicación, la empatía, sino que nos ayuda a fomentar equipos ágiles, pero sobre todo que confíen y se respeten por el bien del negocio y de ellos mismos.
Hasta la próxima 😊
Product Manager en 99minutos
Si quieres participar en “De la boca de los expertos” no dudes en contactarme en micaela@soy-startup.com. ¿Quieres aprender más sobre startups de alto impacto que están cambiando nuestra región? Escucha nuestro podcast DESAFIANTES en Spotify, síguenos en YouTube, Instagram y LinkedIn como Soy Startup Latam.
