Soft Skills recomendados para ingenieros de software.

El siguiente documento está dirigido a profesionales que se encuentren colaborando directamente o no en la industria de software y aquellas personas que requieran conocer las habilidades que son recomendadas en cualquier proceso de desarrollo de innovación.

Este artículo tiene como objetivo definir algunas de las habilidades blandas “Soft-Skills” más sobresalientas en función con la experiencia que hemos tenido en el proceso de implementación de proyectos de software en diversos sectores. Estas habilidades vienen a potencializar las habilidades técnicas, que es donde comúnmente nos centramos.

Introducción.

Durante la carrera profesional podemos adquirir habilidades técnicas singulares como la creación de bases de datos, algoritmos, lenguajes de programación, etc. Estas habilidades, si bien son importantes no lo son todo en la industria de software.

Durante nuestros 11 años de experiencia en desarrollar proyectos de software, hemos observado un número de cualidades relacionadas a la actitud, que, si bien van acompañadas de aptitudes cognitivas, sabemos que, al practicar dichas actitudes, o lo que denominamos “soft-skills”, terminan desarrollando la aptitud más temprano que tarde. Estas cualidades hacen que los desarrolladores que las aplican ávidamente destaquen notablemente de los que no. Dado lo anterior, presentamos tres “soft-skills” fundamentales que debe de desarrollar un ingeniero de software; si bien no son limitativas a otras más, son las que por su practicidad destacamos más.

I. Comprender el problema, táctica sobre técnica.

Aprender el lenguaje no es lo más importante, lo realmente importante es entender el problema que vamos a resolver. El lenguaje debe ser una herramienta para resolver problemas, no el fin. Si queremos saber de lenguaje, lo que deberíamos estudiar sería compiladores o en su defecto, sistemas operativos, y hasta eso, tengo mis dudas al respecto. 

Entonces, ¿Cómo podemos llegar a desarrollar una comprensión del problema para poder resolverlo con el lenguaje de programación que tenemos en nuestras manos? Aunque es cierto que debemos de conocer las bases de cómo utilizar la herramienta (lenguaje de programación), ¿cómo podemos sacar el mejor resultado? Definitivamente no es hacer calculadoras con cada lenguaje de programación que aprendamos.

La manera más rápida que recomiendo es observando otros problemas, más aún, observando cómo otros “resolvedores” ejecutan la solución con el lenguaje que se pretende utilizar. Si observo muchos problemas resueltos, es posible que llegue a encontrar patrones de soluciones. En el peor de los casos, pudiesen influir esas ideas en construir una nueva, con un análisis deductivo.

Leyendo código de diversos proyectos (ahora podemos apelar a la gratitud del “open source”) es la mejor manera de saber cómo se resuelven problemas, además, ir poco a poco construyendo lo que diría el “criterio de lógica”. Esto lo puedo ejemplificar muy fácil, si le preguntamos a un militar especialista en técnicas de guerras, ¿Cómo aprendió a diseñar sus mejores proyectos de guerra?, no nos va a responder en función de sus conocimientos técnicos sobre artillería, nos va a responder que tuvo que haber analizado un número muy grande de expedientes de guerra y, tal vez, hasta documentales.

En resumen, toda esta información adquirida viene siendo un conjunto de escenarios de problemas con un inicio y un desenlace. Con lo anterior quiero decir que aprender a programar, es más una cuestión de táctica que de técnica.

¿Cómo entonces llegamos a dominar la táctica, para aplicarlo en la técnica?

De acuerdo con el SWEBOOK[1] (Guía sobre cuerpo de conocimiento de la Ingeniería de Software), para abordar un problema que resolveremos con software, debemos de preguntarnos lo siguiente:

-        ¿Cómo nos imaginamos (nos damos cuenta) qué decirles a las computadoras?

-        ¿Cómo convertimos el problema en algoritmos?

-        ¿Cómo convertimos esos algoritmos en instrucciones de máquina (código máquina desde un lenguaje de programación)?

El soft-skill en el que nos centraremos tiene que ver con la solución de la primera pregunta. En nuestra experiencia, hemos notado que para poder “darnos cuenta” qué decirles a las computadoras, es necesario tener un bagaje cultural de “lo que otros han hecho” adicional a “lo que hemos hecho”. Es por ello, que analizando cómo han sido resueltos otros problemas, junto con la práctica, podemos llegar a un nivel de “abstracción” requerido y “evocar” imaginaciones efectivas.

Por ello, recomendamos analizar tanto código como nos sea posible y poner en práctica un sin número de problemas con sus soluciones, para poder llegar a un nivel más abstracto de sus componentes. Esto permite alcanzar un nivel superior de entendimiento y una mejora de la técnica, por lo tanto, tendremos un mejor espectro para convertir el problema en algoritmos y, a su vez, bajarlo al lenguaje de programación predilecto.

Para lo anterior, hay una actividad cognitiva: “abstracción”[2], que se mejora así misma en una dinámica de aprendizaje. Esta actividad cognitiva parte de lo caótico hasta la comprensión de patrones utilizados para resolver otros problemas. Mientras más se practique esta dinámica en un proceso de experimentación, análisis y evaluación, se podrá crear incluso conocimiento. 

II. Dar respuesta oportuna al cambio, saber adaptarse.

Partiendo del punto anterior, la táctica es importante, pero no lo es todo. Después de tener práctica de cómo resolver problemas (leer código y experimentar con él), llegaremos a un punto donde el problema que se nos presente no tenga ningún precedente en nuestro histórico experimental. Este es el momento de hacer una pausa y revisar el contexto, para poder determinar qué ruta tomar ante una problemática incierta. Este tipo de problemas serán a los que mayormente nos estemos enfrentando. Cuando tratamos de resolver un problema incierto, es importante utilizar los conocimientos adquiridos y mutarlos hacia un escenario nuevo que pueda traer mejores resultados, en otras palabras, “mejoramos algo”. Este proceso es más sencillo si tenemos la orientación adecuada de a qué punto queremos llegar y en qué momento accionar.

La dificultad aquí es en saber ¿cuándo adaptarse? y ¿por qué adaptarse? La adaptación se origina en dos sentidos, por una reacción a un evento externo que nos obliga a realizar esta “modificación” o por una anticipación a un evento futuro probable. Es decir, esta adaptación es forzada o promovida. Aun conociendo el ¿por qué?, es muy probable que haya una resistencia infinita por iniciar esa “modificación” que traerá un cambio positivo, es decir, quedarnos estáticos.

El quedarse estático o no adaptarse es lo que hay que evitar. En la mayoría de los casos, no se produce el cambio porque no se visualiza un beneficio mayor al que se tiene actualmente; la utilidad “pareciera” ser menor, más no quiere decir que sea real. Sin embargo, si se encontrara ese beneficio próximo, se obtendría la motivación suficiente para realizar ese “cambio” sin sentir “tanto dolor”.

Aquí la cuestión es ¿cómo poder encontrar asertivamente ese “beneficio” con una “orientación” correcta y pueda ser “accionado”? Este momento debe corresponder a un periodo de tiempo adecuado (ni tan apresurado ni tan largo), el cual permite hacer buen uso de los recursos sin comprometer la continuidad del proyecto. Esto nos lleva a la siguiente pregunta:  ¿Cómo desarrollar ese sentido de orientación para saber adaptarse en el tiempo adecuado? 

Antes vamos a comprender lo que abarca una adaptación en un contexto de ingeniería de software.  La adaptación sucede porque decidimos realizar cambios de un estado “A” a un estado “B”. Normalmente, estas decisiones implican un doble esfuerzo de trabajo, o en el mejor de los casos, solo requiere tomar una acción prevenida. Algunos de los casos que se utilizan de ingeniería de software son:

-        Cambios de lenguaje de programación de un lenguaje “A” hacía uno “B”.

-        Reconstrucción de las funciones de un framework “A” a uno “B”.

-        Utilización de una librería diferente.

-        Realización de “Refactoring” a nivel de “algoritmo” de algún módulo.

-        Migraciones de tecnologías de resguardo de información (BD, Storage, etc).

-        Implementación de una interfaz de comunicación distinta.

-        Implementación de un modelo de HMI nuevo.

Entonces, la respuesta es conocer el momento preciso de tiempo, es decir, el “cuándo” adaptarnos. El cambio no vendrá a avisarnos, el cambio vendrá, estemos en el o no. 

Para poder resolver lo anterior, debemos de contar con una observación continua de los hechos, en otras palabras, necesitamos una “estratégia del estar alerta”. Esta estrategía nos permitirá estar en una “avanzada” de cambio y poder adaptarnos en el momento adecuado, es este el “soft-skill” del que estamos hablando.

En 1986, el coronel de Guerra John Boyd desarrolló un trabajo de donde emerge la idea del “OODA Loop”. Su trabajo “Patrones de Conflicto[3]”, tiene los siguientes objetivos:

-        Encontrar la manifestación de la naturaleza: moral, mental y física de un conflicto.

-        Discernir los patrones de las operaciones exitosas.

-        Generalizar la táctica y la estrategia.

-        Encontrar las bases de la estrategia.

John Boyd nos menciona que para ganar (en un conflicto), debemos operar a un ritmo más rápido que nuestros adversarios, o mejor aún, entrar en el ciclo de tiempo de (OODA) observación-orientación-decisión-acción del adversario.

Como ingeniero, debemos tener por sentado que frente a nosotros (nuestro adversario), se suscitan diversos conflictos conocidos o por conocer, pero siempre teniendo en cuenta que la “no mejora continua” es nuestro enemigo por vencer. Podemos aplicar esta estrategia (OODA Loop) a partir de una continua observación de nuestros procesos o técnicas, o hacia una orientación con el propósito de elevar el nivel del producto o servicio. Entonces, aplicando el OODA nos beneficia porque tomaremos las mejores decisiones para que sean llevadas hacia la acción. Entre más rápido realicemos esto, el futuro no nos podrá alcanzar.

III. Subir el nivel de usuario.

Este punto más que ser un soft-skill es un “estado de pensamiento”, y mejor aún, un estado que debe de ser considerado como: “pensamiento continuo”, es decir, siempre debe estar inmerso en la cultura del ingeniero. Esta debe ser la orientación máxima por perseguir del ingeniero, en cualquier proyecto que participe. <conectar con nivel de usuario>.

Primero tenemos que definir ¿Qué es un nivel de usuario? En algún punto todos somos usuarios de tecnología, a continuación, mostramos algunos niveles de usuarios identificados con respecto al uso de una computadora:

1. Manejo de ofimática.

2. Ensamblaje de computadora y reparación.

3. Desarrollo de algún aplicativo (software).

4. Construcción de hardware. 

5. Dar instrucciones al procesador directamente (gurus).

Entonces, cada usuario de una computadora pertenece a un “nivel” de conocimiento de lo que se usa. El máximo nivel de una herramienta será aquel, en donde el usuario posea el conocimiento de poder desarrollar todos sus componentes en todas las escalas.

La pregunta que todo ingeniero de software debe hacerse es : 

¿En qué nivel me encuentro?

Y la segunda:

¿Qué estoy haciendo para subir de nivel?

Esta brújula siempre será la correcta y permitirá mejorar el nivel de usuario de manera vertical o de manera horizontal, por ejemplo:

Horizontalmente: Conocer otras librerías para utilizarla en gráficos

Verticalmente: Construir mi propia librería.

Lo anterior, podrá variar de acuerdo con las necesidades, gustos, contexto de trabajo y demás; sin embargo, lo que no debemos permitirnos es el quedarnos estáticos. 

Si tenemos años desarrollando software, pero no hemos elevado el “nivel de usuario”, quiere decir que algo nos hace falta por hacer y, no hemos puesto en práctica las dos preguntas anteriores.

En realidad, no importa que tan rápido podamos movernos de un nivel de usuario a otro, lo importante es que esta sea una cultura “kaizen” personal, que además, siempre sea este el motor de nuestra motivación.

CONCLUSIONES.

Si bien nuestra tarea como ingeniero de software o ingeniero de innovación es: poder entender y abstraer la realidad a un punto que permita, computacionalmente hablando, procesar dicha información. Para poder realizar esta tarea será necesario entender que las “soft-skills” son la “raíz” de cómo originar una técnica pensada, sistemática y profesional. 

Es por ello, que a través de las “soft-skills”, se nos habilitarán, con mayor facilidad, el desarrollar la técnica desde una perspectiva más táctica, afinar la táctica a través de una estrategia de adaptación y tener siempre la visión de auto-critica para mejorarnos y tener mejores respuestas a los retos diarios.