h1

Cómo hacer Pruebas de Concepto (POC): un enfoque formal

04/29/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

El verdadero viaje del descubrimiento no consiste en buscar nuevos paisajes, sino en tener nuevos ojos.

Marcel Proust (1871 – 1922). Novelista, ensayista y crítico francés.

Supongamos que nuestro equipo ha estado trabajando durante varias semanas / iteraciones / sprints y todo se ve bastante bien. Sin embargo, el cliente nos pide desarrollar un tipo de requerimiento que nunca hemos hecho anteriormente o del que no estamos seguros cómo implementarlo. ¿Qué hacer cuando el equipo debe enfrentarse a una cuestión técnica o funcional desconocida?

Con frecuencia, los proyectos TI se desenvuelven en un ambiente caótico, para el que es necesario resolver una serie de requerimientos funcionales a través de soluciones tecnológicas que conllevan un cierto riesgo durante su implementación. Para minimizar este riesgo, es necesario llevar a cabo lo que comúnmente conocemos como prueba de concepto (Proof of Concept – POC) o spike – este último, surgido del desarrollo de software ágil. Esta actividad consiste en la construcción de una maqueta o demo con la finalidad de evaluar la factibilidad de un requerimiento funcional vagamente especificado, el desarrollo de un componente de software, la adquisición de un producto, o una combinación de todos ellos. En resumen, cada vez que encontremos requerimientos que posean demasiada complejidad técnica o un fuerte grado de incertidumbre, es necesaria una POC para determinar su factibilidad e impacto. Sin embargo, es necesario recordar que todo requerimiento posee un cierto grado de incertidumbre y riesgo, por lo que las pruebas de concepto deben ser una excepción, no la regla: para los riesgos e incertidumbres “menores”, el equipo debe descubrir la solución mediante el debate, la colaboración, la experimentación y la negociación. Una POC o spike por el contrario, debe reservarse para problemas importantes y complicados de responder. Por ello:

• La prueba debe evaluarse de acuerdo a objetivos claramente definidos entre todos los stakeholders, incluyendo mínimamente, qué medir (funcionalidad de negocio, funcionalidad TI, funcionalidad de sistemas), cómo medirlo (costo, facilidad de uso, escalabilidad) y cómo se realizará la evaluación (a través de un scorecard, escenarios de uso).

• Asimismo, debe tener un tiempo definido (timebox), para hacer el suficiente trabajo como para obtener el valor requerido.

• Finalmente, la prueba debe ser parte integral de la estrategia de implementación del proyecto, habiendo sido debidamente planeada y documentada, incluyendo el tiempo y esfuerzo necesarios para su análisis, diseño e implementación.

Pic: Wright Brothers' Prototype Designs


Cuando Wilbur y Orville Wright perfeccionaron su aeroplano, decidieron probar sus teorías antes de sujetarse a sí mismos sobre el ala de una máquina voladora. Usando modelos a escala en túneles de viento, hicieron pruebas sobre la factibilidad del vuelo tripulado.

Iniciando en 1900, éste fue su primer prototipo, que básicamente era un papalote o cometa. Con él, probaron la idea de deformar la parte superior del ala para controlar el balanceo de la aeronave. Entonces construyeron un planeador en 1901. Este avión volaba como una cometa, pero también podía desempeñarse como un planeador pilotado. Los hermanos Wright ganaron experiencia de vuelo con este avión, descubriendo a la vez varios problemas que tuvieron que superar más tarde, como mayor resistencia al aire y la tendencia a voltearse en pleno vuelo. Después vino el aeroplano de 1902, que fue el primer avión en el mundo que podía ser controlado sobre sus tres ejes (transversal, horizontal y longitudinal). Finalmente, en 1903 construyeron su Wright Flyer: una aeronave pilotada que podía despegar y volar por sus propios medios.

Así, sucesivas pruebas de concepto cumplieron su propósito, dando a los hermanos Wright los datos necesarios para validar que sus objetivos e ideas tenían suficiente mérito como para continuar. Se demostró que la teoría podría funcionar en conjunto con otros factores integrales, como la experiencia necesaria para controlar un avión, materiales de construcción y requerimientos climatológicos.

(Fuente: NASA)

Mejores Prácticas

Una prueba de concepto no debe ejecutarse de manera aislada del resto de la organización TI; ésta debe contar con el apoyo de las áreas relacionadas a su implementación, tales como los usuarios de negocio, proveedores, infraestructura y soporte técnico. Esto porque cualquier retraso durante la ejecución puede volverse crítico. Adicionalmente, es buena idea seguir las siguientes mejores prácticas:

• Limitar el alcance. La solución debe evaluarse contra escenarios representativos; no todos los escenarios de uso. En caso de estar evaluando la adopción de un producto, debemos indicar al cliente de que ésta correrá en las plataformas estándar y usadas por clientes existentes. Asimismo, es muy importante no añadir alcance adicional a la POC, a menos que éste sea obligatorio para el éxito de ésta, y haya sido acordado por todos los stakeholders, incluyéndonos a nosotros.

• Planear con anticipación. A menudo, esta será la primera vez que varias organizaciones, incluyendo terceros, estarán trabajando juntos. Es indispensable asegurar que todos puedan comprometerse a los plazos definidos por la POC. También es importante alinear las reuniones de avance antes de tiempo. Los usuarios usualmente tienen sus actividades del día a día, y los cierres trimestrales o anuales pueden comprometer su disponibilidad para revisión o apoyo.

• Ejecutar la prueba de manera aislada al resto del ambiente productivo. A menos que la integración sea crítica, la conectividad con otros sistemas debe ser simulada. Esto porque casi siempre, obtener los permisos necesarios para integrar la maqueta a otros sistemas informáticos se convierte en todo un reto.

• Mantener a los stakeholders informados con regularidad sobre el progreso de la prueba. Cuando llega el momento de selección y/o evaluación, todos los interesados deben estar alineados a los resultados. Esta alineación es crítica para obtener la aprobación por parte de la dirección TI. El concepto clave aquí es “sin sorpresas”.

• Reuniones diarias de seguimiento. La prueba se llevará a cabo en un lapso de 2 a 8 semanas, por lo que un retraso de uno o dos días puede poner la fecha de entrega en riesgo. Una llamada o reunión de carácter informal al final de cada día asegurará que los retrasos, riesgos y problemas sean abordados y resueltos de forma rápida, minimizando el impacto sobre el resultado final.

Fases de implementación

Una POC consiste generalmente de seis fases que pueden variar en tiempo y esfuerzo de acuerdo a la complejidad, alcance y objetivos de la solución:

Fase
Descripción
Pre-Planificación
Prerrequisitos de la prueba.
Kick-off / Formación
Instalación de software, planificación detallada de la prueba de concepto y diseño de alto nivel de la solución.
Implementación
Diseño e implementación de la solución, en conjunto con retroalimentación del usuario y capacitación en los productos comerciales.
Pruebas / Capacitación a usuario
Verificación de que los escenarios de evaluación y todos los componentes están integrados correctamente. Creación de datos para la evaluación. Los usuarios son capacitados en la solución.
Evaluación
Los usuarios y la organización TI llevan a cabo la evaluación y retroalimentación de la POC.
Conclusión
Crear una presentación de resultados, incluyendo una recomendación.
Fases de ejecución de una prueba de concepto.

La fase de pre-planificación asegura que la prueba esté configurada de forma correcta, y que las dependencias hayan sido identificadas adecuadamente para que no haya retrasos durante su ejecución. Si ésta es la primera vez que se realiza un ejercicio de esta clase, es recomendable iniciar la fase de pre-planificación con al menos un mes de anticipación al kick-off. Si ya se han realizado dos o tres pruebas de concepto, la pre-planificación puede comenzar dos semanas antes del kick-off formal.

Por otro lado, el kick-off es una combinación de inicio formal de la prueba de concepto, así como el período durante el que ésta será planeada a detalle, mientras los compromisos por parte del equipo y proveedores son acordados, para llevar a cabo los escenarios de ejecución: instalación y configuración del o los productos, revisión de requerimientos, planeación y governance, diseño detallado, revisión funcional y arquitectónica, modelo de datos y posiblemente, hitos dentro de la construcción de la POC.

La implementación incluye no sólo la codificación o configuración de la solución, sino también reuniones de seguimiento. Los stakeholders deben ser informados acerca de entregables en tiempo y forma, y qué problemas y riesgos tienen que ser abordados. Esta es también una oportunidad para dar la primera respuesta oficial al o los proveedores acerca de sus fortalezas y debilidades percibidas, dándoles la posibilidad de ajustar su desempeño. Estas reuniones también ayudarán a reducir las desconexiones y posibles fallas de comunicación dentro del equipo.

La fase de pruebas se enfoca en las pruebas funcionales básicas de la solución, que frecuentemente incluyen la capacitación de los usuarios que estarán participando en la prueba de concepto. Es importante establecer las sesiones de capacitación y evaluación antes del inicio de la ejecución, para asegurar la disponibilidad de los stakeholders.

La fase de evaluación es aquella en la que los usuarios y el departamento IT recorren la solución y aplican los criterios para su selección. Se asume que, tanto la funcionalidad de la solución así como los escenarios implementados, serán utilizados para determinar el resultado final de la solución propuesta (aceptación y adopción, o rechazo y búsqueda de nuevas opciones).

Finalmente, la conclusión incluye los entregables de la POC (requerimientos, escenarios, scorecard, evaluación), así como las recomendaciones planteadas, que pueden incluir requerimientos presupuestarios, plan de capacitación, aprovisionamiento de personal y definición y/o cambio en requerimientos para los que se implementó esta prueba. En la siguiente liga se encuentra un ejemplo de dichos entregables.

Recomendaciones adicionales

Nótese que una prueba de concepto puede también formar parte del set de herramientas del desarrollo ágil, pero bajo el entendido que su duración será de un sólo sprint o iteración (2 a 4 semanas). Cuando la solución no pueda implementarse dentro de este periodo de tiempo, primero es necesario desmenuzar el requerimiento (comúnmente denominado como “historia épica”), para posteriormente desarrollar una o varias pruebas de concepto dentro de los límites de tiempo establecidos por el sprint.

También, es importante recordar que una prueba de concepto no nos dice si lo que vamos a hacer es la mejor opción; ésta solamente nos dice si la manera en que abordamos el problema es factible: las POCs tienden a ser muy específicas y concretas; dejando fuera muchas áreas críticas que pueden requerir validación también. Por ejemplo, si estamos evaluando una herramienta de reporteo, una prueba de concepto puede estar enfocada en la generación de algún tipo particular de informe, pero su implementación puede ignorar otra funcionalidad, como la integración de la herramienta con otras aplicaciones, o qué tan personalizables son los reportes generados.

Finalmente, es necesario tomar en cuenta que el diseño de una buena prueba de concepto requeriría una comprensión completa del dominio, ya que es importante identificar por adelantado las diferentes áreas de riesgo, para que éstas sean validadas; en la mayoría de las situaciones esto es imposible, por lo que es muy probable que después de la adopción de alguna solución, el equipo (o peor aún, el cliente) descubra deficiencias en la solución adoptada. Por ello, es necesario sensibilizar al cliente sobre las limitaciones de una prueba de esta naturaleza.

Conclusiones

En el sentido más general, una POC es un prototipo que representa las capacidades o posibilidades técnicas y funcionales de un producto final. Es un modelo a escala que intenta probar que una teoría se puede transformar en una realidad, pero ni nosotros ni el cliente deberíamos esperar a tener la funcionalidad completa. Si bien una prueba de concepto puede ser útil y a veces indispensable, ésta rara vez debe ser vista como la única manera de seleccionar el producto final propuesto: ésta tiene limitaciones y sólo puede proporcionar información que debe ser considerada en combinación con otros factores; así, el propósito principal de la prueba de concepto consiste en proveer certidumbre al respecto de los aspectos básicos de rendimiento y características de un entregable.

One comment

  1. Muy completo, contiene informaciones de mucha ayuda.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: