Define el problema que quieres solucionar

La semana pasada asistí a una conferencia en Madrid donde hablé con muchos estudiantes de doctorado.

La mayoría de doctorandos quieren saber cómo “hacer bien” su doctorado: lo que facilita tener conversaciones interesantes con ellos.

Conversaciones donde se habla de problemas concretos:

• ¿Qué herramienta es la mejor para solucionar este problema?
• ¿Qué libro/curso me recomiendas para aprender esto?
• ¿Qué lenguaje de programación utilizas en tu tesis?

Y conversaciones sobre cómo gestionar a nivel personal y emocional el trabajo del doctorado:

• ¿Alguna vez has estado atascado? ¿Cuánto tiempo lo estuviste?
• ¿Cómo mantienes la motivación y la creatividad?
• ¿Tienes claro qué es lo que tienes que hacer en tu doctorado?

No tener definido el problema que quieres solucionar

Una situación que sufren los doctorandos —y que yo también sigo sufriendo— es no tener definido qué es lo que tienes que hacer.

Lo habitual es que tu director de tesis defina de forma general el problema (o problemas) a resolver en tu tesis.

Pero esta definición no se traduce a un problema concreto y definido para el doctorando.

Es una situación frustrante.

¿Por qué?

Aunque no tengas definido completamente el problema, puedes trabajar en él. Incluso, con un poco de suerte, puedes encontrar una solución que, a priori, resuelva el problema.

Sin embargo, después de un tiempo, lo normal es que recibas un «golpe de realidad» que te haga descubrir que…

• tu solución no resuelve el problema completo
• tu solución es imposible de utilizar en la vida real
• o, simplemente, tu solución ya existía: has reinventado la rueda.

Define el problema que quieres solucionar

La solución a esta situación consiste en definir el problema que quieres resolver antes de trabajar en él.

Define cuáles son:

• Los objetivos. Cómo saber si una solución resuelve o no el problema.
• Las limitaciones. Cómo saber si una solución se puede utilizar en la vida real o no.
• Las soluciones preexistentes. Qué soluciones están disponibles en el mercado.

Una vez que definas tu problema, reducirás las posibilidades de recibir un «golpe de realidad» y, además, encontrar una solución te será más fácil: incluso puede que el problema pase a ser trivial.

Definir el problema es tu responsabilidad

¿Quién tiene la responsabilidad de definir los problemas: tu director de tesis o tú?

Es tu responsabilidad.

Es tu responsabilidad asegurarte de que estás trabajando en un problema definido porque serás tú quién sufra las consecuencias de no hacerlo.

Lo más normal (sobre todo al inicio del doctorado) es que no tengas los conocimientos técnicos para definir un problema. Pero eso no te libera de esta responsabilidad.

En este caso, pide ayuda a alguien que sí tenga esos conocimientos, pero asegúrate de supervisar ese proceso: que se definan los objetivos, las limitaciones y las soluciones preexistentes.

Una frase que me encanta decir a los doctorandos es: “Tu trabajo consiste en descubrir qué es lo que tienes que hacer”.

Conclusión: Aprende a recibir «golpes de realidad»

Una de las cosas que más diferencia a una persona inexperta de una experta es la capacidad de definir bien los problemas: saber qué es lo que quieres conseguir con tu trabajo.

Sin embargo, definir tus problemas no evita que, de vez en cuando, recibas un «golpe de realidad».

Sin ir más lejos, en la conferencia de la semana pasada, hice una presentación sobre los resultados de mi tesis.

La presentación fue bien —disfruté de la puesta en escena—, pero al acabar me hicieron una pregunta que fue un «golpe de realidad». En resumen, lo que me preguntaron era si estaba reinventando la rueda (pero peor) en mi trabajo.

Durante mi doctorado, dediqué mucho esfuerzo en definir el problema y asegurarme de no caer en reinventar la rueda. Pero, esta pregunta me pilló de improvisto y respondí mal. Es lo que hay, no siempre uno está preparado para todo.

Pero, este «golpe de realidad» me ha servido para dos cosas:

• La definición de mi propuesta.

  Esta situación me ha ayudado a definir aún más la propuesta de valor de mi herramienta y me ha servido para darme cuenta de que tengo que potenciar aún más la parte diferencial de mi herramienta: la colaboración.

• La importancia de comunicar.

  En la presentación dediqué poco tiempo a explicar las ventajas de tener una herramienta como la mía. Esto fue un error, porque para alguien que no tiene el contexto que tengo yo en mente, es normal que parezca que he reinventado la rueda. Para la próxima dedicaré más tiempo a comunicar los efectos de esta herramienta a nivel práctico.

Aprovechando la ventaja que da el tiempo, quiero dejar aquí por escrito la pregunta que me hicieron y la respuesta que me hubiese gustado dar. Así, si algún día me vuelve a pasar, tendré la respuesta más a mano.

(OneModel es la herramienta que he desarrollado yo y OpenModelica es la herramienta preexistente con la que compararon a OneModel.)

—OpenModelica es más eficiente que OneModel para definir modelos matemáticos debido a que utiliza programación orientada a objetos y relaciones acausales. ¿Por qué merece la pena usar OneModel en vez de OpenModelica? —me preguntaron al acabar mi presentación.

—No lo he mostrado en la presentación, pero, OneModel también permite programación orientada a objetos y modelado acausal —respondí en esta simulación virtual de conversación—. Es cierto, es que menos potente que OpenModelica, no te quiero convencer de lo contrario: yo pienso que OpenModelica es la herramienta más potente disponible en el mercado. De hecho, al principio de mi tesis yo utilizaba OpenModelica.

»¿Por qué pasé de usar OpenModelica a desarrollar OneModel? El problema ocurre cuando tienes que colaborar con otras personas, como puede ser tu jefe, que no saben, o no quieren, usar OpenModelica. En esa situación, estás vendido. Se acabó poder colaborar con ellos.

»Es cierto que puedes convertir código de OpenModelica a MATLAB (por ejemplo) y de esta forma podrías asegurar la colaboración. Pero, la diferencia entre OneModel y OpenModelica es que OneModel se ha desarrollado con este tipo de colaboración en mente. En OneModel defines la información del modelo utilizando un estándar, SBML, por lo que no estás atado a ningún lenguaje de programación en concreto.

»Utilizar este estándar asegura la colaboración entre personas y herramientas, es trivial programar un convertidor de SBML a MATLAB, a Python, a Julia, a OpenModelica, a C/C++, etc. Y no solo eso, también permite que emerja un ecosistema de herramientas compatibles entre sí a través del estándar.

»Por último, a mí me es indiferente qué herramienta de modelado usar en particular, en este sentido soy pragmático. Yo utilizo la herramienta que es más eficiente para cada situación: aunque eso signifique no usar ni OneModel ni OpenModelica.

»Yo lo que quiero es poder hacer modelos matemáticos sin que la herramienta que use entorpezca mi trabajo ni mi colaboración con terceros.

Y tú, ¿has recibido algún «golpe de realidad» en tu trabajo?

Referencias:

• El respositorio Github y la documentación de OneModel
• La web de OpenModelica