Colaboración Universidad Pública y Estado: un potencial círculo virtuoso

El estado invierte en la universidad pública. Por su parte la universidad educa a los ciudadanos, hace investigación y genera conocimiento que ayuda a mejorar la sociedad. Esta mejora se traduce (indirectamente) en una mejora del estado y así se cierra un circulo virtuoso.

En el área de informática/computación/sistemas creo que se da una situación en la que este circulo virtuoso no resulta tan virtuoso, o al menos no todo lo virtuoso que podría resultar.

Más allá de mi trabajo en la universidad, llevo casi 20 años trabajando en la industria del software, he sido empleado de distintas empresas privadas y en los últimos años he trabajado de manera independiente. Nunca fui empleado de un organismo estatal (más allá de mi trabajo en la universidad) pero como empleado de una empresa privada he trabajado en proyectos de consultoría y capacitación para organismos estatales. Proyectos que perfectamente podría haber realizado una universidad. Al mismo tiempo tengo muchos colegas en situaciones análogas. Esto me ha disparado una pregunta recurrente: ¿porque está una empresa privada haciendo este proyecto y no una universidad pública?

Es aquí donde veo que el círculo virtuoso Estado-Universidad no es todo lo virtuoso que podría ser. Si los organismos estatales contrataran a universidades públicas, estas podrían tener más presupuesto, una cuestión siempre escasa en las universidades Argentinas. Al tener más presupuesto podrían hacer más investigación, o mejorar diversos aspectos de su operatoria y en un última instancia aportar más valor a la sociedad.

Intentando dar respuesta a la pregunta planteada comparto aquí algunas posibles respuestas que se cruzaron por mi cabeza:

  • La universidad no tiene el conocimiento para dar servicios a terceros. No lo creo. Si efectivamente fuera así, entonces tendríamos un problema muy grave. Pero sinceramente no lo creo. Muchos docentes universitarios del área de informática trabajan en la industria y enseñan en la universidad justamente lo que ponen en práctica en la industria (es mi propio caso y el de todo mi equipo docente).
  • La función de la universidad no es dar servicios a terceros. Falso, la universidad (al menos en Argentina) tiene 3 funciones: docencia, investigación y extensión. El prestar servicios a terceros es una actividad de transferencia que puede enmarcarse perfectamente dentro de actividades de investigación y/o extensión.
  • Las personas de la universidad que podrían brindar servicios a terceros prefieren hacerlo en forma privada que por medio de la universidad. Este sí puede ser un tema. Las diferencias salariales en el área de informática entre la universidad y lo que paga el sector privado pueden ser muy relevantes. Sin embargo, según he estado averiguando, hay alternativas que podrían habilitar que los docentes que trabajen en brindar servicios a terceros puedan recibir una remuneración equiparable a lo que podrían ganar desde el sector privado.

Ojo, con esto no estoy diciendo que la universidad tenga que convertirse en una software factory o en un proveedor de servicios de manpower vendiendo “programador por kilo”. Sino que los tipos de trabajos en los que imagino a la universidad, son trabajos de capacitación, consultoría o proyectos de desarrollo con un alto componente investigación/innovación.

Me consta que en algunos casos de algunas universidades y algunos organismos, esta colaboración fluye exitosamente, pero no es el caso común.

Creo que revertir esta situación requiere de un acuerdo de las 3 partes: las universidades, los organismo estatales y los docentes/profesionales.

Estoy bastante convencido de esta idea del círculo virtuoso de colaboración Estado-Universidad y es por ello que ya estoy gestionando para participar de un proyecto de colaboración entre la universidad y un organismo estatal durante el año próximo. Continuará…

El riesgo de los Frontend Developers

En una época los developers se identificaban con lenguajes: java developer, c-sharp developer, python developer, etc y algunos aún se identifican así.

Pero da la impresión que las nuevas generaciones ya no se identifican con lenguajes (¡bien!) sino con las capas de la aplicación (¡oops!): frontend developer, backend developer, etc.

Este último enfoque me resulta riesgoso, porque desde el punto de vista del usuario las aplicaciones tienen funcionalidades que requieren tanto de front como de back. Me parece bien que un developer se especialice en una capa siempre y cuando tenga también la capacidad de trabajar también en otras. En una palabra yo esperaría que un developer pueda hacer una funcionalidad de punta a punta y esto es justamente lo que no estoy viendo en muchos casos. Me ha tocado trabajar en equipos donde los developers solo tenían instalados en sus máquinas el runtime/ambiente para correr su capa. Este tipo de escenarios suele generar las siguientes situaciones:

  • Un developer no puede estimar el esfuerzo de construir una funcionalidad completa porque solo conoce de una capa. Esto trae complicaciones de gestión y visibilidad hacía el usuario.
  • Desbalance y tiempos muertos: el equipo se compromete a desarrollar un conjunto de funcionalidades que requieren distinto esfuerzo en cada capa haciendo que en un determinado momento los devs de una capa esten muy ajustados mientras que los de la otra estén sin trabajo y terminen trabajando en cosas de menor prioridad.

Estas situaciones no tienen que ver particularmente con los frontend-devs sino con esta separación en capas, pero que a mi parecer  se manifiesta más fuertemente en los frontend-devs.

Mi recomendación es armar los equipos con fullstack-devs y en términos más generales con gente de perfil-T, o sea, especialistas en una cuestión (palito vertical de la T) pero con conocimiento general en el resto de las cuestiones (palito horizontal de T).

Pero en un postura de abogado del diablo alguien podría decir  que el problema no es del chancho sino de quien le da de comer. O sea, la culpa no es de los “capa-developers” sino de las organizaciones que los buscan y arman equipos con ellos.

Continuará…

(nobleza obliga: algunas de estas ideas las terminé de redondear con mi colega Matias Gorostegui, gracias Goros)