Cómo Sacar el Máximo Provecho a una Demostración de Software

 

Lee la transcripción:

Estamos probando transcribir nuestros podcasts usando un programa de software. Por favor, disculpa cualquier error ya que el bot no es 100% preciso todo el tiempo.

Galen Low: Una vez más, la demostración de software de otro proveedor está resultando desastrosa. Tu director de tecnología y tu líder de DevOps parecen estar jugando al bingo de palabras de moda con cada término de marketing que menciona el presentador. Los ojos de tu director general se están desenfocando a medida que los temas se vuelven demasiado técnicos. Y aunque la persona que presenta realmente parece conocer el producto, nadie aborda el elefante en la sala: el hecho de que en realidad es el primo de tu CEO.

¿No hay una forma de que esto sea un mejor uso del tiempo de todos?

Si las demostraciones decepcionantes han sido un obstáculo para tomar una decisión informada sobre un nuevo software para tu organización, sigue escuchando.

Vamos a desgranar algunas de las estrategias más eficaces para que la fase de demo en tu proceso de selección de software sea mucho más relevante según las necesidades específicas de tu organización.

¡Hola a todos y todas! ¡Gracias por sintonizarnos! Mi nombre es Galen Low y formo parte de The Digital Project Manager. Somos una comunidad de profesionales digitales con la misión de ayudarnos mutuamente a adquirir habilidades, ganar confianza y conectar, para así elevar el valor de la gestión de proyectos en un mundo digital. Si quieres saber más sobre esto, visita thedigitalprojectmanager.com.

Hoy vamos a hablar sobre el proceso de seleccionar un nuevo software para tus equipos de proyectos, y específicamente sobre cómo ir más allá del típico discurso de ventas de una demo y asegurarte de que la herramienta no solo sea la mejor, sino la adecuada para la forma en la que trabajan tus equipos. Me acompaña hoy Olivia Montgomery, Analista Principal Asociada en Capterra y ex líder de IT PMO que ahora asesora a pequeñas y medianas empresas sobre selección de software.

¡Hola, Olivia!

Olivia Montgomery: ¡Hola, Galen! Gracias por invitarme.

Galen Low: Es genial tenerte de vuelta en el programa. ¿Cómo te ha ido en Austin?

Olivia Montgomery: Bastante emocionante. Está ocurriendo South by Southwest y vuelve a hacerse presencial por primera vez desde 2020. Así que la ciudad está vibrante, llena de eventos, charlas y de todo. Está siendo una semana muy emocionante.

Galen Low: Estamos de vuelta, estamos de vuelta. South by Southwest, estoy súper entusiasmado. Está en todas mis redes sociales. Nunca he ido a Austin, pero parece una comunidad musical y creativa tan viva. Hay tantas cosas pasando: conferencias, maneras de reunir a la gente y disfrutar.

Así que parece que ya no tengo excusas. Este podría ser el año.

Olivia Montgomery: Y está genial. Realmente destacan los temas tecnológicos. He podido asistir a charlas de líderes de la cadena de suministro, el CEO de Amtrak, John Deere está aquí impulsando su enfoque tecnológico. Hay experiencias de VR que se centran en contar historias de nuevas formas, desde temas serios a entretenidos, y cómo podemos interactuar distinto con los contenidos y entre nosotros.

Galen Low: ¿Cuál ha sido tu favorito?

Olivia Montgomery: Aparte de toda la innovación tecnológica, pude ver el nuevo Batimóvil en persona. Eso fue lo mejor para mí. Como cinéfila, no veo trailers, así que no he visto ninguno, ni siquiera la nueva película de Batman. Pero vi el Batimóvil por primera vez en persona y fue increíble.

Galen Low: Creo que eso es incluso mejor que cualquier trailer.

Olivia Montgomery: ¡Sí, creo que sí! Me hice una idea y ahora tengo muchas ganas de ver la película.

Galen Low: Eso es lo que más espero ahora que todo está volviendo a abrirse: volver a sorprenderse con cosas inesperadas.

Genial. Vamos al tema.

Hablemos de la parte más tensa y llena de dudas dentro del proceso de selección de software: la demo. Así que déjame primero ambientarlo.

Supongamos que te han encargado encontrar una herramienta para tu organización, y eres el único tomando la decisión o lideras el comité de selección. Has invertido incontables horas buscando casos de uso, recopilando requisitos del equipo, fijando presupuestos con la dirección y haciendo mucha investigación online. Por fin tienes una lista corta de herramientas que parecen encajar y ahora quieres verlas en acción.

¿Por qué tanta presión y dudas? Principalmente porque esto es la culminación literal de todos tus esfuerzos. Estás gestionando a todos los interesados, intentando comunicar los requisitos a los proveedores, tienes que absorber mucha información y reaccionar al instante. Todo ocurre en el entorno más estresante de todos: una reunión.

Por eso, quería que empezáramos con los argumentos de los escépticos. ¿Debería un equipo molestarse en hacer una demo? ¿No es solo un discurso de ventas?

Olivia Montgomery: Haz demos, por favor. Lo entiendo. Yo he pasado por muchas demos muy enfocadas al discurso comercial. Y justo ahí fue cuando empecé a pensar cómo mejorarlas. Creo que el proceso de demo es valioso y requiere mucha preparación y trabajo, especialmente del project manager, que puede convertirlo en una de las partes más importantes del proceso de selección.

Sí, hagan demos, pero no es tan sencillo como seguir el guion del proveedor. Ahí es donde a veces la gente se equivoca. Tú tienes que dirigir y definir lo que quieres ver en la demo.

Galen Low: Totalmente. Además, estas herramientas suelen ser muy amplias, ¿no? Normalmente buscamos una herramienta capaz de hacer muchas cosas para distintas personas. ¿Es siquiera posible cubrir tanto terreno en una demo más allá de un vistazo superficial a las funciones básicas? ¿Qué estrategias debería considerar una organización para asegurarse de recibir las respuestas necesarias?

Olivia Montgomery: Sí. Muy buenas preguntas.

Primero, no, no puedes cubrir todo en una demo. Para eso sirve la investigación previa. Si haces un proceso de RFP, o cuando pruebas tus dos o tres opciones finales, pídeles que te manden la información en un documento. La demo realmente no es el lugar para repasar todas las funcionalidades que necesitas.

Debes concentrarte en cómo se ve la interfaz de usuario y en los principales flujos de uso que el equipo necesita realizar. ¿Qué procesos de negocio necesita soportar esta herramienta? Y, sinceramente, ¿los usuarios se sienten cómodos con su apariencia y uso? Muchas veces es su primer contacto con la herramienta y la interfaz.

Así que el look & feel es clave aquí. Las funcionalidades concretas deberían quedar escritas antes de firmar el contrato.

Galen Low: Eso es fundamental. Y gracias por aclararlo porque antes planteé la demo como la culminación del proceso, pero realmente la demo ayuda a llenar lagunas.

Es parte de la investigación. Hay cosas que solo puedes evaluar en acción: la interfaz, ciertos casos de uso... No es que ya has hecho toda la investigación y toca ver cada función en dos horas. Eso difícilmente sale bien.

Más bien, sabemos lo que hay, tenemos información extra y ahora agendamos una demo para profundizar en lo importante.

Olivia Montgomery: Exacto. De hecho, recomiendo hacer dos demostraciones.

Una dirigida al negocio y otra técnica. Juntarlas sería una reunión muy larga y complicada, y la mitad de los participantes no estaría interesada en la parte técnica, y viceversa. Por respeto al tiempo de todos, mejor separarlas.

Y también necesitas gente diferente en cada reunión. Así se convierte en otro paso de evaluación y a la vez un mecanismo para seguir recogiendo requisitos del proveedor. No importa si es una herramienta de gestión de proyectos, contabilidad, ERP o lo que sea, yo sigo siempre la misma estructura para las demos.

La primera es de cara al negocio. Que esté el propietario del proceso. También tu usuario clave: normalmente un supervisor, líder o quien más usará el sistema. Así aseguras enfoque estratégico y operativo. El propietario de negocio puede decidir si la herramienta impulsa el crecimiento, y el usuario clave validará que sus funciones diarias pueden hacerse.

Algunos PM dicen que es difícil que el usuario clave participe, porque quizás es demasiado pronto o utilizan mil excusas. Pero ese usuario clave probablemente acabe siendo tu experto durante la implementación y tu fuente principal de requisitos. Son los que lo usarán, deben estar contentos con la experiencia; recuerda que la demo es para evaluar el aspecto y uso. Así que asegúrate de involucrar a ambos.

Otra forma de organizar eso es recopilar casos de uso del equipo, y al menos uno o dos del usuario clave, y enviárselos al proveedor varios días antes. Así pueden preparar la demo para recorrer esos casos concretos. Por ejemplo: como contador, necesito ejecutar el cierre mensual en menos de 24 horas; deberías ver eso en la herramienta.

El caso de uso no especifica funciones exactas, lo que permite que el proveedor muestre innovaciones que tal vez no conozcas. No conviene encasillarlos, pero debes dejar claro lo que necesitas ver.

El usuario clave debe comprobar su función esencial. El propietario de negocio suele querer ver el dashboard ejecutivo: cómo es la herramienta al entrar como gerente, cómo consultar informes, etc. Pide que carguen datos ficticios y preparen un entorno de prueba. Así evaluarás también los informes.

Galen Low: Me encanta ese enfoque de separar los grupos. Puede parecer contracorriente, pero tiene sentido: hay dos conversaciones distintas.

Así se aprovecha mejor el tiempo. A veces nos oponemos a involucrar al usuario clave porque parece pronto, pero su participación ayuda en la selección y validación de profundidad.

Y así, ese usuario clave se convierte en campeón del proceso. Si no participa, es quien más fuerte podría criticar la decisión.

Genial lo del entorno de prueba. En procesos que he vivido, es como: haces la demo, y después tienes chance de probar por tu cuenta. ¿Se puede hacer una demo interactiva en la que los usuarios prueben el sistema en directo?

Olivia Montgomery: Estoy segura de que los usuarios clave lo apreciarían. Porque quieres elegir una herramienta útil tanto para los procesos actuales como futuros. A veces la demo muestra solo la visión futura.

La creencia es: con la herramienta nueva, los procesos se transformarán por arte de magia, pero la realidad no es esa. El usuario clave sabrá si desde el primer día podrá hacer su trabajo y si la herramienta soporta bien el uso presente y el futuro.

Quizá probar el entorno antes ayuda a validar que puede cumplir con su trabajo actual con la herramienta. No sé si los equipos técnicos lo apreciarían igual; depende del contexto. Pero insisto: sé transparente, habla con tus interesados y proveedores para aclarar necesidades e ideas. Así puedes cortar con el discurso comercial asegurando que tú controlas la demo, pero tampoco cierres la puerta a innovaciones del proveedor.

Galen Low: Totalmente. Hablemos más sobre preparar esas demos. ¿Tienes ejemplos de casos de uso que deban solicitarse, o sobre cómo recoger los requisitos de usuario sin coartar la innovación?

Olivia Montgomery: Sí, claro. Si tienes un analista de negocio IT es ideal, pero no es común. Incluso así, tu usuario clave puede necesitar ayuda para plantear sus historias de usuario.

Yo a veces envío una encuesta a los líderes de los equipos usuarios formando una especie de Mad Libs para guiar la redacción. Tu historia de usuario es: como [rol], necesito [tarea] para [motivo]. Eso les ayuda a describir rápidamente lo que necesitan. Luego mandas eso tal cual al proveedor para que lo muestre en la demo.

Así que me gusta ese enfoque tipo Mad Libs.

Galen Low: ¡Me encanta! Soy fan tanto del Mad Libs como de las historias de usuario. Eso deja margen de acción al proveedor y asegura que el equipo pueda ver, de verdad, cómo la solución cubre la necesidad. Muy bueno.

Olivia Montgomery: Ver y sentir la herramienta es fundamental en la demo orientada al negocio. Pero la segunda demo, la técnica, puede incluir historias sobre frecuencia de tareas: ¿podemos programarlas? ¿Cuánto tarda en ejecutarse un proceso? ¿Se adapta a las necesidades del negocio? El líder técnico y el proveedor deben estar en esa demo.

Tu administrador de sistemas debe saber cómo funciona la herramienta, dónde se almacenan los datos, quién los aloja, etc. Hay muchos detalles técnicos que si dejas para el final pueden traerte sorpresas desagradables.

Pregunten sobre integraciones, si tienen clientes con esa integración, si es nativa o hay que desarrollarla. Así sabrás si es viable o requieres recursos extra. Puede parecer una conversación larga, pero si preparas bien, los equipos técnicos saben lo que preguntar y te ahorras muchos dolores de cabeza.

Galen Low: Es fundamental, porque hay mucho por cubrir y si no priorizas y enfocas podrías acabar con una conversación inabarcable. ¿Cómo seleccionar y priorizar los casos de uso y dudas a tratar con el proveedor?

Olivia Montgomery: Gran pregunta. Hay que apoyarse en los líderes de equipo, en los usuarios clave. Hay que hablar con ellos antes de la demo y preguntar: ¿Cuáles son tus principales dudas?

Haz una conversación previa con los participantes para que indiquen los dos o tres puntos que necesitan ver sí o sí. Así, durante la demo puedes controlar el ritmo y asegurarte de cubrir lo importante. Así todos saben qué esperar y no se sienten interrumpidos ni desestimados si frenas alguna pregunta.

Galen Low: Muy importante: como project manager tienes áreas bajo tu control y debes encargarte de la estructura y preparación. Pero hay decisiones que van con los patrocinadores y líderes, y debemos confiar en ellos para priorizar. Es fundamental implicar a todos y darles voz en el proceso.

Olivia Montgomery: Exacto. Y durante la demo hay que recordar que solo cubriremos tres o cuatro historias de usuario clave ya acordadas con el proveedor, y que todo lo demás puede quedar documentado en tu RFP o similar. Después de la demo pide al proveedor un desglose de costos, por ejemplo, por funcionalidades personalizadas, o quién desarrolla qué. Lo mismo aplica a las integraciones. Así evitas ahondar demasiado en detalles durante la demo y mantienes el enfoque.

Galen Low: Genial. Quiero retomar el tema de separar los grupos, hacer dos demos, y luego unir al comité para tomar la decisión conjunta. ¿Recomiendas hacer una hoja de puntuación (scorecard) para comparar objetivamente los productos finalistas?

¿O crees que eso ya no sirve por la complejidad de las soluciones actuales?

Olivia Montgomery: Me alegra que lo menciones. Soy muy fan del scorecard de proveedores. Creo que sigue siendo útil. Siempre que puedas reducir emociones (un peligro en demos muy comerciales), ganas objetividad. Así recuerdas el problema que tienes que resolver y puedes comparar cómo lo soluciona cada proveedor.

Aunque un propietario de negocio adore una herramienta, si la hoja muestra que no cumple los requisitos, tienes un rastro documental. Y como project manager, recomiendo guardar esos registros siempre; nunca sabes cuándo se va a auditar el proyecto o hay que justificar la elección. O si hay que reemplazar el software en el futuro y quieres recordar por qué no se eligió otro. Así tomas decisiones informadas. Puede ser una sola hoja para todos o una por stakeholder y luego consolidarlas, según el tamaño y complejidad del sistema.

Mi propia experiencia: en una empresa cambiamos de CTO después de adoptar un ERP nuevo, y la nueva CTO preguntó por qué elegimos ese proveedor. Gracias al scorecard pudimos demostrar que fue una decisión informada y razonada, ayudando además a que la nueva líder entendiera el negocio y la decisión previa. También, en empresas que cotizan en bolsa es esencial tener ese rastro documental para cumplir auditorías.

Galen Low: Lo que destaco de esto es que el scorecard no debe ser genérico. En vez de decir "Interfaz UI del 1 al 10", es mejor especificar: ¿en qué queremos mejorar? Haz las preguntas alineadas a tus objetivos, p. ej., ¿cómo de bien se integra con el ecosistema de software para automatizar procesos?

Olivia Montgomery: Prefiero puntuar de 1 a 5 y definir qué significa cada número, por ejemplo: cumple expectativas, no cumple, las supera o no lo tiene (sería un cero). Así obligas a posicionarse y el cálculo es más sencillo si ponderas cada criterio.

Galen Low: Me gusta ese enfoque. Además, ¿el scorecard debería ser único para todos o adaptarse por perfil (negocio vs. IT)?

Olivia Montgomery: Recomiendo un template único con requisitos de negocio y técnicos claros, y definir quién responde qué sección. Así hay transparencia y puedes detectar fácilmente divergencias, por ejemplo si negocio entendió que la integración es nativa y IT que es personalizada: surgen preguntas y debates cruciales antes de contratar. El mismo scorecard para todos da visibilidad y facilita discutir los riesgos y aclarar percepciones.

Galen Low: Eso a menudo se pasa por alto. El verdadero valor del scorecard no es sumar cifras y que el ganador salga de la hoja: es la conversación que genera, los desacuerdos que hay que trabajar y aclarar juntos.

Olivia Montgomery: Exactamente. Es una base para dialogar, evitando conflictos o posturas demasiado emocionales.

Galen Low: Si hablamos del proceso de recogida y consolidación de los scorecards, ¿cómo organizarías la reunión posterior a las demos y cómo presentas ese análisis final?

Olivia Montgomery: Gran pregunta. Cada caso es diferente, según los stakeholders, la madurez de los procesos, el presupuesto y los plazos. Como PM, tienes que preparar el terreno: identifica quién decidirá, si hay comité, quiénes son los líderes clave, etc. Planifica antes de ver proveedores. Así puedes organizar sesiones con los decisores y presentarles los resultados claros para facilitar el consenso y evidenciar el análisis.

Galen Low: ¿Es así, no? ¿Preparar todo, tener un plan, facilitar los inputs, luego mostrar el análisis y reunir a la gente adecuada para la decisión final, siempre dejando trazabilidad documental?

Olivia Montgomery: Sí. Y si cuesta lograr participación con el scorecard individual, pueden rellenarlo juntos tras la demo en una reunión dedicada de unos 45 minutos. Así todos se involucran y la herramienta cumple su objetivo de promover discusión y acuerdo. Es un proceso más colaborativo y muchos líderes lo prefieren así.

Galen Low: No son un concurso ni jueces olímpicos; es un debate y se puede afrontar en grupo. Muy de acuerdo.

Al final, algunos dicen que nunca conseguirás que todos estén satisfechos con la elección. ¿Cómo gestionas las expectativas para que no haya descontentos?

Olivia Montgomery: Por esto me gusta el scorecard, sobre todo si ponderas criterios. Recuerda siempre el motivo por el que necesitas la herramienta, no te centres en el nombre del proyecto o del software. Pregunta en cada fase: ¿resuelve el problema de negocio? El scorecard ayuda a mantener ese enfoque objetivo y no dejarse llevar sólo por lo llamativo o moderno, sino por lo esencial: funcionalidad, integración, etc. Así puedes explicar cualquier decisión aunque algunos prefieran otra herramienta por cuestiones subjetivas.

Galen Low: Me quedo con que el scorecard = transparencia. No la da por sí sola, pero esa es su utilidad: comunicar el proceso y la decisión, justificarla, dar claridad y rigor a todos los implicados.

Y al final, se trata de compartir la decisión, explicar el porqué, dar las gracias a quienes participaron, y mostrar los resultados. No todos estarán entusiasmados, pero al menos hay justificación y se ha involucrado a los adecuados para que el desacuerdo sea por una preferencia sincera y no por falta de rigor.

Olivia Montgomery: Exacto. No todos tienen que estar felices, pero sí respetar la decisión. Y eso solo se logra con debates honestos y transparentes basados en hechos.

Galen Low: Olivia, gracias, como siempre es un placer tenerte. Lo más revelador para mí fue lo de dividir la demo en dos: tiene mucho sentido y ahorra tiempo, pero no se pierde la visión global gracias a scorecards y diálogo colectivo después. Un consejo excelente.

Olivia Montgomery: ¡Sí! El usuario clave no necesita oír charlas sobre la frecuencia de procesos automáticos ni el API, y viceversa. Es un modo de respetar el tiempo de todos y no dejar los asuntos importantes para el final de la implementación.

Galen Low: Última pregunta, de cierre...

Olivia Montgomery: ¿Una más?

Galen Low: Imaginemos que eres PM y ves que el proceso de selección de software no tiene rigor, o que está viciado por conflictos de interés. ¿Qué puedes hacer para evitar esa parcialidad?

Olivia Montgomery: Necesitas una relación de respeto con quien sostiene esa postura. Verifica si realmente decide. A veces tienes que acudir al verdadero responsable y pedirle ayuda. Si realmente toma la decisión, escúchalo y proponle hacer juntos el scorecard. Expón que quieres asegurar que no se escapen aspectos importantes. Haz las preguntas críticas (¿qué sabemos de integraciones? etc.) con método socrático; a veces así la propia persona reconoce carencias o riesgos y reconsidera. Lo importante es ser conforme y transparente, dejar claro que la solución debe funcionar para el negocio y IT, tanto en el estado actual como futuro. Hazlo en equipo.

Galen Low: Genial, me ha encantado.

Olivia, ha sido un repaso profundo al proceso de selección de software, especialmente el enfoque en las demos y la toma de decisión posterior.

Espero que para quienes nos escuchan haya sido útil y ojalá vuelvas pronto al programa porque hay mucho más para explorar y más preguntas para ti.

Olivia Montgomery: Mil gracias por invitarme. Espero haber ayudado y que cambien la perspectiva sobre el proceso de selección y las demos, quizá que dejen de temerlas o dejen de ser arrasados en las decisiones. Siempre es un placer hablar contigo, Galen, gracias por todo.

¡Gracias!

Galen Low: ¿Y tú qué opinas? ¿Vale la pena una demo de software para tu equipo o es más bien puro espectáculo sin profundidad ni valor práctico? Déjanos tus historias y opiniones en los comentarios.

Y si quieres fortalecer tus habilidades como líder de proyectos estratégicos, únete a nuestra comunidad. Visita thedigitalprojectmanager.com/membership para acceder a una red de apoyo compartiendo conocimiento, resolviendo desafíos complejos y dando forma al futuro de nuestra disciplina juntos.

Desde plantillas robustas y capacitaciones mensuales que te ahorran tiempo y energía, hasta el apoyo entre pares a través del foro de discusión, eventos y mastermind groups, ser parte de nuestra comunidad significa contar con más de mil personas de tu lado mientras navegas tu carrera en la gestión de proyectos digitales.

Y si te ha gustado lo que escuchaste hoy, suscríbete y mantente en contacto en thedigitalprojectmanager.com.

Hasta la próxima. Gracias por escucharnos.