La evolución de las empresas hacia la transformación digital se ha vuelto en los últimos años, muy vertiginosa. Cada vez son más las compañías que obligadas por la coyuntura o entendiendo el rumbo de las preferencias de sus consumidores, deben apresurarse a adoptar su operatoria dentro de canales online.

En la mayoría de los casos, las empresas que deseen ingresar al proceso de transformación digital, dependerán de la contratación de los servicios expertos que les brinda una implementadora o agencia especializada en eCommerce. Estas tendrán el objeto de llevar adelante la gestión, desarrollo, concreción, implementación, evolución y mantenimiento de su solución de eCommerce.

Esta relación entre el cliente y la consultora, como en toda relación, debe tener reglas de convivencias, responsabilidades, un plan y objetivo en común, entendimientos, disidencias y, claro, puntos de conflicto que inevitablemente sucederán. Estos últimos deben tender a minimizarse para asegurar la buena convivencia, la disminución del estrés y el éxito del proyecto. 

A continuación revisaremos algunos puntos a tener en cuenta a la hora de interactuar con una implementadora, solicitar requerimientos y solucionar problemas de entendimiento con el objetivo de llevar al proyecto en un camino exitoso:

Recomendaciones y buenas prácticas

Definir responsabilidades

• Al inicio del proyecto se debe generar una serie de encuentros donde conjuntamente se defina cuáles son las responsabilidades de cada participante tanto a nivel empresas (cliente, implementadora, integraciones, etc), como a nivel departamentos o áreas, y finalmente para cada rol individual con nombre y apellido. La responsabilidad incluye lo que cada parte debe hacer, lo que podría hacer y lo que no debe hacer, esto último a fin de que no se produzcan solapamientos de tareas o doble comandos. Hay que considerar que pese a que existe un organigrama estandarizado para la mayoría de los proyectos, cada organización será única y siempre debe adaptarse a la misma.

• En términos generales, el 30% de los problemas con los requerimientos se dan porque el cliente desconoce cómo diligenciar, qué pedir y qué no, cómo manejarse en cada etapa y la interacción en general con la implementadora. Por ejemplo, se podría generar el siguiente requerimiento: “se solicita armar un template para un email de campaña de descuento”. Esto por lo general no es responsabilidad de la plataforma de eCommerce sino de la solución de Email Marketing, que no suele ser gestionada por la implementadora (a menos que haga Full Commerce). En este caso, una implementadora que sepa visualizar la foto general del proyecto, sabrá guiar al cliente para seleccionar la plataforma de Email Marketing que mejor se adapte a sus necesidades, siendo la contratación y configuración de la misma, responsabilidad del cliente.

Una buena práctica es armar una tabla donde se indique la responsabilidad de cada equipo o área de la empresa, los canales de comunicación con la implementadora y la definición de responsabilidades. También incluir quiénes firman los VVBB (vistos buenos) de cada entregable a fin de avanzar a la siguiente fase.

Comunicar claramente

• A la hora de explicar oralmente, es recomendable parafrasear y confirmar el entendimiento tanto propio como el del interlocutor, con el objetivo de clarificar. Por ejemplo, cuando se solicita: “quiero construir un sitio escalable” o “quiero un diseño moderno”, ¿qué está significando en realidad?. Una opción para mejorar el entendimiento de un requerimiento visual es incorporando lista de palabras ampliadas, descripciones coloquiales, dar ejemplos, hacer mockups y wireframe.

• En cualquier reunión o intercambio de ideas, una buena práctica es generar notas o minutas de los puntos principales a modo de “bullets” o diagramas, a fin de consolidar, sentar como historial o evidencia de lo acordado y tener un doble check. Tener en cuenta que la minuta, no solo debe considerar lo relevado sino los próximos pasos y responsabilidades, como también, quienes participaron de la misma. Es recomendable manejar una plantilla o template estándar para este documento y que sea compartido.

• La implementadora puede presentarle un cuestionario inicial con preguntas básicas a complejas con el fin de ir dilucidando cada tópico o tema relevante de la toma de requerimientos. El cliente también puede generar un cuestionario a la consultora en caso de dudas específicas que necesite aclarar. Otra buena práctica, puede ser, tener acordado un template general para preguntas y respuestas y manejarlo colaborativamente. También existen herramientas como Jira, Assembla o Trello para este tipo de interacciones.

• No es malo equivocarse, pero si lo es equivocarse tarde. Si el error se reconoce tempranamente, se puede corregir con menos costo y se evitan problemas que podrían consumir mucho tiempo y recursos. Aceptar un error es natural en un proceso de aprendizaje y descubrimiento continuo.

• Las implementadoras trabajan con muchas verticales e industrias, suelen ser expertos en algunas de ellas ,como retail, electro, moda, etc; pero no en todas. Por eso es importante compartir el vocabulario específico de su área. Una buena estrategia es invitarlos a conocer el proceso de negocio, depósitos, locales, incluso el sector de fabricación, esto puede sugerir nuevas ideas de mejora y evolución que en papel no suelen ser visibles.

• Nuevamente se hace hincapié en que a veces el cliente no tiene claro lo que quiere o solo tiene una idea general. Por ejemplo “escalar” es una palabra muletilla en el mundo eCommerce, pero ¿qué significa?, ¿cómo se mide? Esto se aclara evitando términos ambiguos y ampliando las preguntas, por ejemplo: “¿cómo se quiere escalar?”, “¿cuántos SKUs?”, “¿cuantas órdenes?”,”¿con qué sistema integra?” etc.

Respetar los tiempos y metodologías de trabajo acordadas

Tener presente los tiempos de entrega de cada respuesta, documento e ítems solicitado por la implementadora. Estas fechas no serán unilaterales, ya que siempre se acordarán con el cliente, pero una vez comprometidas, a menos de situación de fuerza mayor, deben cumplirse para no atrasar el proyecto y se traduzcan en mayores costos.

A continuación se describe un ejemplo donde un equipo de UX le indica el plan para validar un diseño de pantalla:

• El equipo de UX presenta la mockup visual.
• El cliente tiene 48 horas para indicar correcciones, mejoras y aclaraciones.
• 24 horas después de recibida las correcciones el equipo de UX presenta una nueva mockup.
• El cliente una vez más debe aceptar o pedir últimos cambios.
• Si aún quedan correcciones se vuelve al paso 3, esto solo se puede repetir una vez más como máximo.
• El cliente aprueba el mockup. Si el cliente no da respuesta a las 48 horas se da automáticamente como aceptado la mockup.

Aquí vemos, como se indica a modo de regla, que la no respuesta dentro del tiempo indicado se toma como aceptación compulsiva.

Como plantear requerimientos

• Siempre se debe partir de una visión general a una particular. Es normal que a veces no se sepa lo que se quiere, se puede tener una idea aproximada. Hay que entender que el proceso es iterativo y uno puede ir mejorando la solución. Pero se debe tener en claro lo que se pretende del desarrollo y con un nivel de detalle aceptable.

• Hay muchas técnicas que pueden ayudar a entender cómo se quiere orientar la solución de eCommerce y por ende qué funcionalidades incluir. Se puede iniciar con un brainstorming, para luego ir depurando un mapa de funcionalidades indicando el para qué y el cómo afecta al negocio o si podré darle soporte operativo.

• Antes de plantear requerimientos al analista es importante entender internamente qué valor me va a proveer la necesidad que estoy delineando. Puede “quedar lindo”, pero ¿me ofrece algún tipo de ventaja en mi negocio?, ¿aumentan o facilitan las conversiones?, ¿genera más leads?”.

• Cada departamento, desde su conocimiento del área, debe plantear sus requerimientos, pero estos no deben ser estancos. Deben poder conectarse, dialogar y ser simbióticos entre los mismos. Evitando incluso situaciones donde existan requerimientos contradictorios entre sí.

• Es muy importante estudiar a la competencia para tomar ideas, tendencias y soluciones probadas, esto puede reducir tiempos, dar ejemplos sólidos e incluso adquirir los mismos componentes (plugins). Sin embargo, no es válido el pedir algo solo por el hecho que la competencia, líder de segmento o marca de renombre internacional lo tiene. Debe preguntarse: ¿Es esa funcionalidad para mi tipo, tamaño y ADN de mi negocio? ¿Me va a permitir mejorar las conversiones? ¿Podría incluso distraer al cliente? ¿Tengo estructura para soportarlo? ¿Realmente se usará dentro de mi segmento de clientes?. Siempre es útil buscar alternativas.

• A la hora de solicitar requerimientos hay que saber manejar la ansiedad y entender que cada punto necesita de un análisis comprensivo, se debe evaluar la capacidad, los tiempos, el costo si es que requiere presupuesto, las prioridades y las dependencias. Tener en cuenta que siempre se debe dejar un buffer de por lo menos un 5% en los tiempos pre estimados para acolchonar imprevistos.

Cambios en los requerimientos

Esta situación debe tenerse presente para saber atacarla y que sea provechosa, a continuación algunas recomendaciones:

• Seguramente luego de presenciar una demo o al ir entendiendo más sobre la plataforma y cómo ésta impacta en su negocio, descubrirá nuevas necesidades. Darse cuenta que la necesidad era otra, cambiar el rumbo de un proceso, ver que la competencia o un cambio de tecnología hacen que la necesidad ya no sea válida o requiera innovar, implica que tendrá una pronta conversación con la implementadora donde lleve a la mesa de discusión esta situación disruptiva. 

• Considere que los cambios pueden comunicarse en cualquier momento, pero nunca deben afectar al ciclo de desarrollo actual (ó Sprint) y lo que se tiene acordado como resultante. El cambio será analizado y evaluado para ingresarlo al listado de requerimientos pendientes (ó backlog) y que forme parte de las iteraciones próximas. Durante un Sprint, el equipo no debe ser interrumpido con cambios o pedidos adicionales. Los cambios en la planificación deben ser acordados antes de comenzar cada ciclo de trabajo. Esta práctica, permitirá al equipo realizar un compromiso real sobre la concreción de los objetivos planteados para dicho Sprint.

• Los cambios se deben informar formalmente por medio de un RFC (Request for change) donde se debe indicar la funcionalidad actual y cuál es la que cambia, el rational (motivo), la prioridad, si afecta otros requerimientos y donde se incluyen diagramas, esquemas, casos de uso o documentos complementarios que sean necesarios como soporte. Seguramente el analista y líder técnico sumarán preguntas y su entendimiento a la necesidad planteada, que se resumirá como un Caso de Uso en el backlog del proyecto.

• Aunque surjan ideas nuevas, siempre hay que pensar en el MVP (minimum valuable product), lo cual es lo mínimo indispensable que necesitamos para salir operativos a producción. Luego habrá tiempo para mejoras evolutivas.

• Hay que tener en radar que si el proyecto se extiende por muchos meses, las ideas que quizás eran buenas al principio de la iniciativa, puedan ser menos interesantes o incluso caducas al momento de la salida a producción. Esto se podrá deber a los avances tecnológicos, cambios de hábitos de consumo, sobresaturación de algún tipo de experiencia e incluso la innovación de la competencia.

• Tener en cuenta que un requerimiento se debe cerrar para luego poder abrir otro. Si algo cambia en una funcionalidad solicitada, la misma no se debería ampliar. Sino desde lo formal, se debe generar un nuevo requerimiento (con un nuevo ID) y extender esa funcionalidad. Si el requerimiento cumple con los criterios de aceptación se debe dar como válido, pese a que haya cambiado.

• Saber que los requerimientos deben estar consensuados entre distintas áreas o departamentos de la empresa impactados por dicha necesidad. Evitar situaciones en donde se pide una funcionalidad y luego desde otra área se solicita algo distinto. Por eso el rol de Product Owner es tan importante como centralizador y árbitro de cara de la empresa hacia la implementadora.

Catalogación

• Se debe trabajar codo a codo con la implementadora para entender cómo realizar la catalogación. Hay cuestiones básicas que deben ser contestadas lo antes posible en el proyecto, por ejemplo si se contará con productos simples, configurables o variaciones, combos, virtuales; o si se tendrá stock centralizado o aperturado.

• Es primordial armar el set de atributos o características que deberán mostrar cada producto según su familia de producto. Dado que, por ejemplo, son diferentes los detalles de la ficha de producto de una heladera o de un televisor. Además, dichas características no solo se verán en la ficha de producto, sino que se usarán para filtrado, ordenamiento, armado de reglas de carrito, etc. 

• Se debe definir la taxonomía del árbol de catalogación, entendiendo como se verá en la tienda, la cantidad de subniveles y que tan balanceado quedará. Definir un límite máximo de subniveles (generalmente 3) y de ítems por nivel.

• Al momento de catalogar recomendamos comenzar con un conjunto acotado de productos, por ejemplo 10 por categoría, para probar inicialmente y luego ir armando los batch o paquetes de catalogación completos.

Capacitaciones

• Es muy importante acordar capacitaciones previas a la salida de producción para formar a los distintos roles de la empresa en las funcionalidades básicas de la plataforma,  desde lo administrativo y la gestión del eCommerce. 

• Las capacitaciones deben estar divididas en cada temática, por ejemplo: catalogación, promociones, gestión de órdenes, gestión de clientes, CMS, etc. Previamente se debe tener el cronograma, a fin de poder invitar a los participantes que cumplirán distintos roles dentro de la gestión del eCommerce.

Pruebas y defectos

La etapa de “pruebas de aceptación de usuario” es crítica para el buen funcionamiento de un proyecto:

• Se debe planificar con la participación de todas las áreas de la empresa que tengan incumbencia en los procesos del eCommerce. Es mandatorio tener un plan de pruebas acordado con la implementadora.

• Lo principal es realizar un E2E (end to end) que es una prueba completa de todo el funnel de conversión en lo que respecta al “happy path” (situación o caso de usuario ideal) y luego validar las situaciones alternativas o de errores.

• También se deben probar las situaciones de borde, estrés de datos, operativos y concurrencias. Otro punto muy importante es probar, no solo el frontend del store, sino todas las integraciones y procesos que corren por detrás.

• A la hora de reportar defectos o bug se debería trabajar mínimamente en una planilla de seguimiento en común donde se indique prioridad, problema, fechas, responsable, etc. Idealmente utilizar una plataforma como Jira o Assembla para el reporting.

• El reporte de defectos tiene que ser lo más claro posible con el fin de poder reproducir el mismo escenario. Se debe indicar el paso a paso, captura de pantallas o videos de la ejecución, logs de error, set de datos con los que se probó, incluso a veces la configuración del browser, de la red u hora del día en la cual se produjo el inconveniente.

• Hay que entender qué es un error o bug y qué es un cambio de requerimiento. Esto suele ser un punto de conflicto porque a veces es difícil aceptar que lo que uno pidió no era lo correcto. Pero no hay que preocuparse, sino ocuparse. Como dijimos el cambio es bueno y constante. Nunca existirá un sistema terminado. Por otro lado, en situaciones así hay que confiar en el expertise, know how y buenas prácticas que propone la consultora.

Conclusión

El proceso de creación o evolución de un eCommerce es realmente apasionante, presenta muchos desafíos pero también oportunidades que, quizás inicialmente, no se vislumbraban.

El tener conciencia de cómo interactuar con la implementadora, quiénes participarán de la arquitectura y construcción de su tienda, es fundamental para lograr buenos cimientos y un crecimiento exitoso. Como cliente debemos tener la imagen de la implementadora como socia continua en su crecimiento, y no meramente como un proveedor de servicios tecnológicos temporario.

Muchas cosas se aprenderán sobre la práctica, y tal vez haya fuentes de conflicto y desentendimientos. Pero cuanto más tengas presente las buenas prácticas aquí brindadas, amenizadas con tu cultura de trabajo y la de la implementadora, siempre podrás encontrar terreno común para avanzar exitosamente y crecer.