Pages Menu
Categories Menu

Posted by on Ene 22, 2014 in General | 6 comments

Probable futuro del desarrollo software y consejos para orientar tu profesión

Son realmente muchos los correos que recibo con preguntas relacionadas con orientación profesional. Mayoritariamente, las preguntas giran entorno a cuáles son, en mi opinión, dentro del desarrollo software, la gestión de proyectos tecnológicos y similares, las líneas más prometedoras para orientar, o re-orientar, tu carrera profesional.

He de confesar, responder me supone mucha responsabilidad. Todo futuro es incierto y aconsejar sobre emprender un camino profesional requiere de respuestas que midan los riesgos de equivocarme.

No obstante, y tomarlo simplemente como mi opinión personal, basada exclusivamente en mi experiencia, de lo que yo personalmente me encuentro cada día, visitando u sitio y otro, voy a sintetizar tres caminos por donde yo tiraría (estoy tirando).

1. Toda actividad profesional relacionada con alinear (de verdad) Desarrollo y Explotación

La estructura tradicional de una empresa que necesita la tecnología para funcionar (hoy en día, prácticamente todas) es tener dos áreas separadas, con jefes separados, con profesionales separados, con modelos de procesos separados: una desarrollo software y la otra explotación (operaciones, CPD, operaciones o como cada uno lo llame).

Esa es visión del pasado, aunque sea el presente mayoritario en la mayoría de empresas.

El reto ahora y en los próximos años es romper el muro entre desarrollo y explotación. ¿Por qué? Muy simple, tema económico, para ser competitivo, para sobrevivir.

El ritmo de los negocios de hoy requiere mucha mayor velocidad poniendo nueva funcionalidad en producción al software, es decir, al negocio (te dejo aquel post de  hoy lo más determinante es la velocidad de desarrollo. ¿Eres rápido? Tu empresa lo tiene todo), en mucho menos tiempo. Si tu empresa no lo hace, otra lo hará, pondrá servicios antes en el mercado, y aprenderá antes qué quieren los clientes.

Esto es un reto para los próximos años, de los mayores, al que todo el mundo anda dándole vueltas, pocos saben cómo hacerlo y no todos podrán hacerlo, pero marcará (está marcando) diferencias en competitividad entre empresas.

Dicho esto, dedicaciones profesionales relacionadas con lo anterior son previsiblemente…

– Profesionales del Continuous Delivery (te dejo el post aquel de ¿Tardaríais mucho en pasar a producción un cambio en sólo una línea de código? Aprende entrega continua), que se dice muy rápido, pero dentro hay mucho, pero mucho, empezando por la integración continua, las pruebas exploratorias (y mucho testing aplicado a este problema), etc.

– Lo que algunos llaman DevOps (development + operations, es decir, desarrollo + operaciones), otros menos lo llaman Lean IT, que organizativamente pasa por orientar y ayudar a romper las “yo soy de CMMI y tu de ITIL”, “tu no pasas a producción hasta que mi comité lo diga, y si lo dice será los lunes por la noche de 1:00 am a 4:00 am”, “estamos esperando el OK del departamento de pruebas”.

Se necesitarán profesionales que sepan orientar para crear equipos multi-funcionales (en vez de islas separadas), equipos que ellos solos , como una mini empres autónoma, tomen un requisito y lo dejen ellos solitos en producción. Lo otro es demasiado lento, poco reactivo, no desaparecerá, pero debe convivir con otra manera de ver las cosas.

Todos los anteriores no los puedo ver separados, son dedicaciones complementarias.

2. Saber llevar la agilidad más allá de desarrollo software

La agilidad nació en el mundo del desarrollo software. La ingeniería del software nació intentando imitar métodos heredados de disciplinas que trabajan con productos físicos, crean coches, casas, cadenas de montaje, etc. (esto ya lo he contado un montón de veces, te dejo este post).

Y a nosotros esta manera de trabajar no siempre nos funcionó.

Apareció entonces la agilidad como alternativa, y esta vez somos los informáticos los que en vez de copiar métodos de trabajo… los estamos exportando, nos los están copiando a nosotros.

Los primeros fueron los que querían hacer nuevos negocios rápido, los que querían validar startups rápido sin tirar tiempo y dinero, que no podían estar un año haciendo un plan de negocio sobre cómo se venderá un producto dentro de cinco, sin ni siquiera tener el producto… y nació el Lean Startup (te dejo un post sobre el Lean Stertup).

Después de lo anterior la agilidad está introduciendo en cualquier actividad cuyo producto sea intelectual, campo hay.

3. Todo lo que deriva de la externalización: Gestión de proyectos global, equipos formados por personas en cualquier parte del mundo, etc.

Toda empresa mediana o grande anda dándole vueltas a lo externalizar el desarrollo (te lo digo porque no hay día que alguna empresa grande no me hable de ello).

Pero haciéndolo bien, no cometiendo aquellos errores del pasado (y el presente) que nos llevaron al nearshore, y a mi en, una época profesional anterior, a estar viajando por el mundo, porque en aquellos tiempos el desarrollo se mandaba a India, por poner un ejemplo, con gestión de proyectos software mínima o nula, y el supuesto ahorro de costes se perdía en viajes España – India para solucionar problemas de software.

Todo el mundo anda dándole vueltas a esto, descentralizar el desarrollo, que parte del desarrollo lo puedan hacer en otros países y que no se pierda el control.

Y las razones de esto son, siento decirlo, no me gusta, me duele, pero es así, bajar los costes. Un programador en Rumanía es más barato que en España y a las empresas se le van los ojos. Durante un tiempo, como no sabían muy bien externalizar a Rumanía o India, intentaron ser más competitivas contratando programadores en pequeñas ciudades españolas… pero en Rumanía siguen siendo más competitivos (de esto ya te hablé en vamos a competir por un puesto de trabajo con profesionales de todo el mundo)

Dicho sea de paso, y en relación al tema que nos trata, yo me andaría con ojo de estar en una actividad de programación fácilmente externalizable a otro país, aquellas que aporten poco valor, ahora o en unos años.

Así que, dedicaciones profesionales relacionadas con lo anterior son previsiblemente…

–   Calidad software. Para que el anterior modelo funcione la empresa que externaliza debe tener control absoluto en que el producto software que le está desarrollando mucha gente fuera conserva una calidad mínima. Aquí entra testing, caja blanca, saber inteligentemente qué métricas mirar, calidad del producto software, revisar el diseño. Te dejo algunos post relacionados: Sólo necesitas dos métricas para hacerte una idea de la calidad del producto software (y del dinero que puedes estar tirando), otro la verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más.

–  Integración continua, pasar de ver el desarrollo como “proyectos” a verlo como un producto al que continuamente otros, desde muchos lugares, a cualquier hora, añaden funcionalidad. Aquí hay temas relacionados con los que comentaba en el punto 1.

– Saber organizar equipos distribuidos físicamente, y no sólo como hasta ahora, que tradicionalmente quien daba el paso de externalizar fuera era contratando una única empresa en Ucrania, por poner un ejemplo. Yo aquí me refiero a integrar muchos profesionales (no necesariamente empresas) extranjeros (freelance, contractors, etc.) de mucho valor y de manera autónoma.

Todo esto va a ser una necesidad por temas de competitividad. Y muy pocos están preparados, organizativamente, culturalmente, contractualmente y técnicamente para ello. Pero el primero que lo logre (en España me refiero, fuera ya lo hacen muchos) marcará grandes diferencias con sus competidores.

Así que, vete preparando y ayúdales si esto se dispara en cinco años.

Consideraciones finales

La letra pequeña de lo anterior, más allá de que me pueda equivocar, son mis humildes pensamientos, es que los anteriores requieren de mucho estudio, además os he dejado solo un resumen, dentro de cada uno hay mucho campo.

Es necesario que comiences a tener experiencia en ellos empezando ya, que ya puede ser tarde, y ya es después de terminar de leer este post (y esta es su última línea).

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

6 Comments

  1. Buenos consejos sí señor.

    La advertencia final es importante.. los tres caminos son empinados, ahora que seguro te diferenciarán como profesional. Por ejemplo llevo ya un tiempo aconsejando a técnicos profundizar en Continuous Delivery, ya empieza a aparecer en ofertas de empleo y en una sala llena de desarrolladores pocos levantarían la mano para explicar qué hay detrás del término. Éste (como otros de los caminos que sugieres) pueden distanciarte del tristemente conocido montón de “AP java” o “AP .Net”.

    Saludos,
    R Hens

    • Ciertamente Roberto, aún estamos con problemas en la integración continua, por lo que nos queda para el delivery…

  2. Gracias Javier por compartir tus pensamientos.
    Concuerdo contigo en las tres áreas que señalas, sin embargo me extrañó no ver explícitamente algo relacionado con escalar la agilidad hacia el resto de la organización y me pregunto si lo consideras implícito en el punto 2 o si ya definitivamente no insistimos en ese punto …
    Saludos
    Pablo Lischinsky

    • Pablo,

      Efectivamente, la escalabilidad de la agilidad, llevarla a empresas grandes, etc., podría haberlo incluído explicitamente. Quizás lo veo algo más ya de presente que de futuro, pero si que podría complementar el punto 2.

      Saludos

  3. Un tema que me gustaría que trataras relacionado sobre la calidad del software es 1) refactorizar a menudo implica deshacer lo que otro ha hecho, y esto puede crear mal ambiente 2) añadir calidad a un producto no puede ser una tarea individual, sino que implica cambiar la forma de trabajar de todo el equipo. Y si el jefe no quiere hacer estos cambios, que haces? dejas tu puesto de trabajo?

    Agradecería mucho tu opinión al respecto..

    • Yo también necesito saber la opinión de Javier sobre el punto 1).
      Soy un desarrollador jóven recién salido de la Carrera (llevo un año en el sector IT) pero creo que tengo bastante autoformación en calidad del software, patrones y diseño y en mi trabajo he intentado refactorizar mucho código que algún compañero ha hecho, incluso justo después de haber sido entregado, pero a veces no me he atrevido por el hecho de tener miedo a que haya mal rollo y puedan pensar: ¿pero quién es este para enseñarme a mí?.
      Cuando la gente no quiere saber que lo ha hecho mal (porque puede estar mal aunque funcione) no se como actuar y tratar eso.

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com Valora en Bitacoras.com: Son realmente muchos los correos que recibo con preguntas relacionadas con orientación profesional. Mayoritariamente,…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This