No hay que olvidar la fase del desahogo

Según mi punto de vista, el proceso consta de las siguientes fases, también de forma iterativa: Pensar, hacer, ver qué falla y desahogo. Como podéis ver, no es tan distinto del que me enseñaron en la escuela, pero hay algunos matices importantes a resaltar.

Está clarísimo que cada vez que creamos algo va a haber problemas, esto supongo que no lo discutiría nadie, ¿verdad? Entonces, podemos cambiar directamente el eufemismo “evaluar” por “ver qué falla”, ¿para qué engañarnos? Luego, según la teoría, después de ver qué está fallando, tenemos que pasar inmediatamente a pensar en la solución a los problemas, aplicar la solución encontrada, etc.

Tenemos que tener muy clara una cosa, antes que nada somos personas y negar que ante los fallos sentimos frustración, e incluso rabia, sería engañarnos a nosotros mismos. Por lo tanto, para humanizar más el proceso de resolución de problemas, aquí incluyo una nueva fase llamada “desahogo”. En esta fase suele ser cuando el pobre hardware recibe golpes al grito de... ¡¡¿Por qué <introducir los tacos favoritos aquí> no funciona esta <más tacos aquí>?!! Cuando muy probablemente la causa del problema esté en el software. O dicho de otra forma, en esta fase los problemas de software se los suele cargar el hardware (aquí podéis extrapolar...).

Una vez nos hemos desahogado y nos hemos calmado (ir a paseo es una buena opción), entonces sí es momento de pensar en nuevas soluciones a los fallos detectados, para luego implementarlos y ver de nuevo qué falla, etc.

El problema de la fase de desahogo es el contexto. No es lo mismo estar solo, que estar haciendo pruebas con el resto de tu equipo, que haciendo pruebas con el cliente... Así pues, el nivel de desahogo que podamos conseguir será directamente proporcional al nivel de confort que nos ofrezca el contexto o entorno en ese momento.

Cómo minimizar el ruido durante el desahogo

Para intentar minimizar el ruido (literalmente hablando) provocado por los fallos del desarrollo, está muy bien aplicar la conocidísima técnica del “Divide y vencerás”. Que consiste en algo tan sencillo como dividir los problemas en tareas más pequeñas y sencillas. Luego, juntamos las distintas soluciones y, si todo cuadra bien, ya tendremos el pie en el cuello del problema original a resolver.

Los ingenieros hablamos y pensamos en base a problemas y soluciones, incluso en la vida cotidiana. Como solemos ser personas tan metódicas y nos gusta aplicar una, otra y otra vez las soluciones que hemos encontrado a problemas recurrentes, entonces intentamos extraer patrones y los aplicamos durante los procesos de resolución de problemas. La experiencia aporta nuevos patrones e incluso variantes sobre los que ya hemos aprendido. Esto, en teoría, hace que se reduzca el esfuerzo durante las fases de “pensar y hacer”, al mismo tiempo que reduce los tiempos de las fases de “ver qué falla y desahogo”.

Más información: Eureka Startups.

Fuente: Eureka Startups.