Supongamos que ves un anuncio de una empresa que busca programadores para incorporar a un proyecto que está a punto de empezar. Por lo que te cuentan, en la empresa se trabaja bien, el proyecto puede ser interesante y (¡emoción!) hasta el salario parece bueno. Te empieza a gustar la idea de trabajar allí y decides intentarlo. ¿Qué es lo peor que podrías poner en tu curriculum antes de enviarlo?

Nombre: Fulanito
Apellido: Picateclas
Programador
Y no, no tiene nada que ver con el nombre ni el apellido (bastante ridículos) y esta entrada no trata sobre cómo cambiarlos para tener mejores oportunidades en la vida (aunque, sin duda, eso también ayuda). En realidad, esto va sobre programadores.

Si alguien me preguntara qué he sido durante el tiempo que llevo trabajando le diría que muchas cosas y le hablaría de roles que he ido teniendo, entre los que nunca estaría programador. Sí, exacto, yo nunca he sido programador. Y tú tampoco (¿cómo? ¿tú sí lo has sido? no, no lo has sido, calla y sigue leyendo). ¿Por qué?

Vamos a empezar con algo fácil de entender. Una empresa puede hacer muchas cosas (normalmente el grado de estupidez de lo que hace crece de forma pareja al tamaño de la empresa) pero, fundamentalmente, todas quieren aumentar los ingresos y reducir costes. Y una consecuencia lógica de esto es que las empresas normalmente recompensan a sus trabajadores en función de cómo son capaces de hacer alguna de estas dos cosas. Sí, las empresas recompensan a los empleados que hacen que sus ingresos aumenten o que consiguen reducir costes. ¿Crees que no? ¿Te parece mal? Monta tu propia empresa y lo entenderás.

Ahora viene la parte que hace que esto tenga algo que ver con tu carrera profesional. La persona que va a leer tu currículum y decide si contratarte o no también está buscando aumentar beneficios o reducir los costes. Después de  lo que hemos visto arriba debería ser algo bastante evidente,  ¿por qué se nos olvida tantas veces? Y a la persona que te paga no le interesan las arquitecturas limpias, utilizar lenguajes de programación de moda, frameworks chulos, el software craftsmanship ni resolver problemas complejos que constituyen un reto para tu mente de ingeniero. Aumentar los ingresos. Reducir los costes. Ése es su interés y lo demás son sólo medios para conseguirlo. Así que no te sorprenda que te a ti te vea como una pieza de la que espera que, encajada dentro de su equipo, haga que algún coste se reduzca o que los ingresos aumenten.

Y tradicionalmente los ingenieros son en sí mismos centros de costes, y bastante caros, por cierto. Y cuando tú mismo eres un centro de costes muy caro para una empresa te estás poniendo una diana para que todas esas mentes maquiavélicas que tienen un MBA o creen que saben dirigir una empresa empiecen a pensar cómo quitarte de en medio. Así es como aparecen ideas tan interesantes como el outsourcing. (Por cierto, nunca he escuchado que ninguna empresa haya externalizado su departamento de ventas. ¿Empiezas a ver la diferencia?)

Si te pones la etiqueta "programador" lo que estás diciendo sobre ti es "soy un peón muy caro que pica teclas". Y creo que esa no es la mejor idea sobre ti y tu trabajo que quieres que alguien se quede, ¿verdad?. Al menos, no lo es si quieres ser valorado (o sea, ganar más dinero). En vez de eso, intenta describir cómo has ayudado a las empresas en las que has estado anteriormente a reducir costes o aumentar los ingreso. Y si no has tenido oportunidad de hacerlo aún, busca una descripción que sugiera que eres capaz de hacerlo en el nuevo puesto que ocupes. 

Analista es mejor descripción que programador (y, piénsalo, seguro que has estado haciendo un montón de análisis hasta ahora aunque nadie te haya llamado así). Desarrollador es mejor que programador (si encima has desarrollado la solución que ha hecho ganar un montón de dinero a esa empresa en la que trabajaste, dilo). Arquitecto es mejor que programador. Creo que lo único peor que programador es progamador Java (además de ser un coste, tienes un ámbito de trabajo limitado).

A lo mejor ha sido algo que no has tenido en cuenta. ¿Te ha ido bastante bien hasta ahora sin prestarle atención? Sencillamente has tenido suerte de que alguien te haya estado viendo como un activo en lugar de como un coste (aunque si ignorabas esto, seguramente tú no hayas puesto mucho de tu parte y podrías haber ganado mucho más dinero si lo hubieras hecho).

Creo que inconscientemente casi todos saben esto. Al fin y al cabo, muchos queríamos promocionar rápidamente a categorías como analista dentro de las consultoras porque, de alguna forma, pensábamos que era mejor. ¿Mejor trabajo? ¿Más prestigio? ¿Quién sabe? Definitivamente, más dinero, sí. Pero ahora ya no debería preocuparte tanto siempre que sepas explicar lo realmente importante.

Grábalo en tu mente: reducir costes y aumentar ingresos. Eso es lo que le interesa a quien te paga así que es mejor que también te interese a ti. Y que seas capaz de reflejar ese interés.



Os presento una situación bastante corriente: hemos conseguido un contrato para el mantenimiento de una aplicación web Java, con almacenamiento en una base de datos Oracle, donde se hace un amplio uso de procedimientos almacenados, y un carga fuerte de JavaScript en la capa de presentación. Se trata de un proyecto largo (más de un año) para un equipo pequeño (digamos que el presupuesto no es muy amplio). Hacemos algunos cálculos, pensamos en los escenarios más probables que nos vamos a encontrar y llegamos a la conclusión de que vamos a dimensionar el equipo con tres presonas.

Tenemos ahora que pensar en quiénes formarán parte del equipo. ¿Sabéis una cosa? Lo más probable es que la inmensa mayoría de los responsables de proyecto o, al menos, los que suelen completar sus proyectos con éxito, decidirán tener en su equipo a:

* Un desarrollador Java
* Un experto en bases de datos Oracle
* Un programador web con amplios conocimientos de JavaScript

Parece una decisión bastante lógica, ¿no? Pues bien, no es más que la inversión de una regla bastante antigua aunque, a veces, desconocida en el desarrollo de software: la ley de Conway.

Cualquier organización que afronte el proceso de diseñar un sistema de información diseñará uno que copie las estructuras de comunicación de la organización.

O, dicho de otra forma:

La arquitectura de un sistema refleja la estructura del equipo que la diseñó.

Junta a un desarrollador Java con un programador JavaScript y un experto Oracle y tendrás una aplicación en tres capas, posiblemente con procedimientos almacenados en la base de datos y una interfaz rica en el navegador. ¿No quieres procedimientos almacenados? Quita al experto en Oracle del equipo. Organiza un equipo de tres desarrolladores para construir un compilador y tendrás un compilador en tres fases. Estos diseños serán utilizados incluso aunque no sean los más apropiados para el sistema que queremos construir.

Las decisiones sobre la arquitectura del sistema se empiezan a tomar incluso antes de que nadie haya dibujado el primer diagrama ni escrito la primera línea de código: las tomamos cuando decidimos el equipo que queremos para nuestro proyecto.

Se toman cuando menos información tenemos sobre el sistema (justo al principio del proyecto) y las toman las personas que menos conocimientos tienen para hacerlo (los jefes de proyecto).

¿Cómo podemos evitar esto?


En primer lugar, intenta empezar el proyecto con el equipo más pequeño posible. Ten en cuenta que cada persona que añadas al equipo del proyecto supone una carga más en la arquitectura del sistema. Y demasiada arquitectura puede ser incluso más perjudicial para el resutado que tener muy poca arquitectura. Formando un equipo pequeño al principio, estarás tomando las mínimas decisiones sobre la arquitectura final del proyecto.

En segundo lugar, busca los perfiles más generalistas a la hora de formar el equipo en vez de meter a personas con una única (o un reducido número de) habilidades. En este caso, es mejor ese desarrollador Java al que no le importa trabajar en la base de datos y que puede defenderse a la hora de hacer interfaces web que un gurú de Oracle o un ninja del JavaScript. Puede que, con el tiempo, llegues a necesitas esos perfiles, pero te aseguro que es mejor retrasar su incorporación hasta que la arquitectura esté completamente clara.

Como podéis ver, todos los proyectos tienen, al menos, un arquitecto. Uno que decide sobre el diseño del sistema de una forma muy peculiar: sin diagramas ni documentos de arquitectura sino asignando personas al equipo que se va a encargar de construirlo.

Mi recomendación para cualquier jefe de proyecto es que evite en la medida de lo posible convertirse en ese arquitecto. Por el bien de su proyecto.

Bibliografía