Debatir sobre las responsabilidades de gestión de las partes interesadas
Si bien cada proyecto es diferente, como consultor funcional es común interactuar con las partes interesadas. Por lo general, esto se hace con la colaboración de otros miembros del equipo, como el administrador de proyectos y el arquitecto de soluciones. Esta comunicación con los interesados se lleva a cabo en reuniones, correos electrónicos, talleres y documentación. El liderazgo del equipo debe permitir que cada miembro del equipo sepa qué tipo de comunicación con las partes interesadas se espera para el rol del proyecto.
Realizar talleres
Los talleres pueden comenzar antes de que comience el trabajo real del proyecto. La recopilación de requisitos, la confirmación de requisitos y la recopilación de más requisitos se pueden realizar con un taller de cliente.
Colabore con el equipo de creadores para garantizar la comprensión y la ejecución de los requisitos. Identifique y recopile información de sus campeones y consulte su opinión sobre qué ámbitos del sistema se deben presentar de forma destacada a los usuarios finales para garantizar su entusiasmo. Anime a la dirección a ofrecer incentivos a los usuarios para la adopción del sistema, como una competición, el seguimiento de objetivos comerciales, etc. Encuentre formas mensurables de realizar un seguimiento del compromiso y la adopción del usuario tanto para demostrar el sistema como para identificar áreas potenciales de mejora en una fase posterior.
Los talleres también son el lugar donde preparamos a los interesados para que se hagan cargo del sistema que hemos construido para ellos. A veces, esta transferencia de conocimiento fluye del constructor al mantenedor; otras se produce al incorporar a nuevos usuarios. No todos los proyectos tendrán un recurso dedicado para planificar estos talleres. Como puente entre la tecnología y los negocios, el consultor funcional está muy bien preparado para asumir este rol.
A menudo, el consultor funcional ayudará a impartir formación a los usuarios finales. De nuevo, esto se basa en su posición única para comprender tanto la tecnología como el negocio para ayudar a cerrar esa brecha que lo separa de los usuarios.
Crear y entregar la revisión de una solución
La revisión de una solución es una oportunidad para demostrar a las partes interesadas el progreso hacia un objetivo. Dependiendo de la metodología de entrega exacta, es probable que tenga revisiones incrementales del progreso. La revisión de una solución también podría incluir la demostración de una prueba de concepto al equipo para obtener su opinión y su apoyo.
Es probable que el arquitecto de la solución sea quien tome la iniciativa a este respecto, pero los detalles más particulares de la revisión de una solución suelen recaer en el consultor funcional. Al planificar la revisión de una solución, busque formas no solo de obtener su aprobación, sino también de obtener comentarios auténticos. Este es el momento de planificar correcciones menores en el proceso si una función no ha salido como estaba planeado, o tal vez si no funciona tan bien como funcionaba durante su diseño. No se sienta mal si se identifican correcciones en el proceso durante este ciclo de revisiones, para eso están. Lo que más importa es lo que hacemos con los comentarios.
Crear demostraciones y pruebas de concepto (POC)
Cuando empiece a imaginar la solución, podría ser un buen momento para compartir una demostración para validar los requisitos con las partes interesadas, pero también para generar confianza en la plataforma. Cuando un cliente confía en la plataforma, está más dispuesto a aceptar las soluciones propuestas con entusiasmo. Si está utilizando un enfoque iterativo para la solución, es posible que acabe creando distintas pruebas de concepto pequeñas a lo largo del camino. Microsoft Power Platform facilita la creación de una prueba de concepto.
Las demostraciones pueden adoptar diferentes formas, dependiendo de la solución que se proponga. Los siguientes enfoques son algunos de los más comunes:
- Lista para usar: una demostración lista para usar simplemente muestra una o varias aplicaciones sin ninguna personalización. Esta demostración a menudo se realiza con recursos de preventa y no involucra al arquitecto de soluciones. La demostración también es una forma efectiva de poner al día a los clientes con las características principales del producto. Lo negativo de este enfoque es que no ayuda al cliente a visualizar su solución en la aplicación. Puede mitigar parte de la negatividad de este enfoque incluyendo datos de muestra asociados a su negocio.
- Demo precompilada: muchos partners se especializan en sectores verticales o áreas de solución concretas e invierten en el desarrollo de demostraciones precompiladas que contienen su propia propiedad intelectual y que adapta la solución base lista para usar con el valor agregado diseñado. Este enfoque ayuda al cliente a ver su área problemática concreta, porque a menudo usa el lenguaje vertical en la aplicación. Suele ocurrir que también oculta cosas que no son apropiadas para el área de la solución, que podrían distraer al cliente.
- Prototipo: este enfoque toma el estado listo para usar y, teniendo en cuenta las necesidades del cliente, realiza una adaptación mínima de la aplicación para reflejar sus requisitos. La ventaja principal de todo esto es contar una historia durante la demostración a la que el cliente pueda remitirse cuando intente resolver sus propios objetivos.
- Prueba de concepto: se deben crear pruebas de concepto para demostrar que un concepto funciona. Normalmente, afecta a un componente o una actividad muy específicos de la solución propuesta. A diferencia de un prototipo, que generalmente va directo a la finalización, las pruebas de concepto pueden probar múltiples enfoques para alcanzar el objetivo deseado.
Es bastante común usar indistintamente los enfoques de prototipo y prueba de concepto y, desde la perspectiva del cliente, la diferencia generalmente no importa. El objetivo debe centrarse en contar una historia y dar vida a la solución propuesta, lo que ayudará al cliente a ver el problema resuelto por esta. También debe intentar reducir el riesgo eliminando las incógnitas.
Conservar o desechar
Cuando se compila un prototipo o una prueba de concepto, es necesario ser consciente de que las ganancias rápidas pueden no ir asociadas a una práctica recomendada para soluciones listas para producción. Esto no significa que las prácticas recomendadas sean difíciles de seguir, pero para una presentación rápida de una idea, es probable que le convenga más esbozar una idea rápida que planificar una solución a mayor escala. Esto debe ser algo que decida con antelación, ya que si desea transferir los recursos, deberá asegurarse de que estos cumplan los estándares y no sigan atajos que no se puedan remediar fácilmente.
Gestionar las expectativas
Debido al hecho de que es fácil preparar rápidamente una demostración para mostrar una propuesta de solución, es importante gestionar las expectativas. No es raro que se presente una demostración y el cliente diga: "muy bien, ¿cuándo podemos publicarlo?". La mejor manera de administrar este escenario es ser honesto y decir que, si bien lo que está mostrando puede parecer completo, no tiene todos los ajustes necesarios de seguridad y automatización, entre otros, para su puesta en marcha. El punto importante es tener la conversación y no presuponer que el cliente sabrá que una demostración es solo una demostración.