Hacía tiempo que no actualizaba los datos del currículum relativos al número de empresas en las que, o para las que, he trabajado, bien contratado directamente, o como consultor o auditor. Aunque alguna me habré dejado en la menoría, hasta hoy he trabajado para 56 empresas en 4 países. Podéis imaginar que el número da para escribir unos cuantos post de anécdotas, experiencias, amigos, buenos recuerdos, recuerdos no tan buenos, etc. Posts que, por limitaciones de tiempo, no sé si algún día escribiré. Pero no quería dejar pasar uno: una breve síntesis, basada en mi experiencia, de 8 puntos sobre la estructura del sector del desarrollo software español, sus actores y tipología de empresas.
1 – En España hay realmente muy buenos técnicos y muy buenos perfiles de desarrollo. Pero lo que apenas hay es «gestores técnicos», es decir, gente que habiendo estudiado una carrera técnica se dedique a la gestión: jefes de proyecto, auditores, CIOs, gerentes, responsables de calidad, consultoría estratégica, etc. Finalmente esos puestos los acaban ocupando perfiles no técnicos. Lo que comentábamos en el post de ser ingeniero informático y no acabar toda la vida programando.
2 – Son muy pocas las empresas de producto comparadas con las empresas de servicios (o de desarrollo “llave en mano”). Para las primeras, obtener el mejor desarrollo software es una necesidad. Para las de servicios, el trabajo en mejora de calidad, métodos o procesos software es más a corto plazo.
3 – Sobre todo en empresas de servicios, el cliente es quién realmente determina finalmente como trabaja la empresa de desarrollo. Sí el cliente pide calidad… se implanta la calidad (te recomiendo aquí el post de sin una certificación es difícil ganar a proyectos), sí sólo (o principalmente) piden precios bajos… se trabaja buscando el coste mínimo. Y la mayoría de los clientes seleccionan a sus proveedores principalmente, o únicamente, por precio.
4 – Hay muchas empresas que ven la mejora de la calidad como mejora de la productividad, pero también las hay que sólo pretenden obtener un diploma para ganar licitaciones y concursos. En esto, como comentábamos antes, las exigencias del cliente juegan un importante papel. Ah, y por más que lo repita no me cansaré: una mejora real de procesos software no es implantar una ISO 9000.
5 – Hay mucha diferencia cuando el equipo lo dirige un perfil comercial (o no técnico) que cuando lo dirige un perfil técnico o un ingeniero. En el segundo caso la calidad y la productividad suelen gozar de mejor forma. No digo que sea mejor lo uno que lo otro, eso depende de cada caso y negocio, pero he visto casos con directivos no técnicos, que además no se han rodeado por un buen equipo técnico, que han acabado en grandes fracasos en desarrollos y productos software.
6 – Al final la realidad dice que no hay verdades absolutas. Una cosas son las modas y otra la realidad. Puede estar de moda la técnica x de desarrollo, la metodología y, el desarrollo más ágil, menos, etc.; pero al final en el mundo real te encuentras desarrollos en cascada altamente productivos, aunque no esté de moda y aunque te encuentres muchos más no muy productivos. Y es que hay muchas tipologías de negocio, productos, etc. Por eso, ojo con las modas (o lo del post de diferencia lo esencial de lo accidental), balas de plata y los “talibanismos”.
7 – La mayoría de empresas de software crítico (quizás por razones obvias) y/o que provienen de un entorno industrial, y han incorporado el desarrollo software en los últimos años, en mi experiencia destacan muy especialmente por la calidad, rigurosidad y productividad de su desarrollo software. Aunque en España este tipo de empresas son pocas.
8 – Son sobre todo las pequeñas empresas, o los equipos pequeños en grandes empresas, los que, estadísticamente, aplican mejores prácticas de desarrollo software. Será porque se mueven de manera más ágil, porque ven más de cerca el retorno de inversión o por supervivencia. Concretamente en las pequeñas empresas ser productivos, o dar calidad de verdad, es clave para la competitivdad.
Conocer muchas empresas es como viajar a muchos países… abre la mente. Y te deja ver como hay cabida para muchas buenas prácticas de desarrollo software, que la mejora de la productividad y la calidad no es sencilla, requiere de esfuerzo y perfiles muy preparados, y que no hay una única mejor solución, o verdad absoluta, para todas las casuísticas o modelos de negocio.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
No puedo estar más de acuerdo con este post Javier. Me cuesta destacar un punto, aunque destacaría este:
5 – Hay mucha diferencia cuando el equipo lo dirige un perfil comercial (o no técnico) que cuando lo dirige un perfil técnico o un ingeniero
Muchas veces no se valora al ingeniero tanto como debería, y es quién debería tener las claves para asegurar la aplicación de las mejores prácticas. Aunque habrá de todo, claro
Javier, un gran post, como siempre.
Yo no he pasado por tantas empresas, pero sí por más de 20, y suscribo todas tus experiencias. De la 1 a la 8.
Quería comentar especialmente 2 de ellas:
3) El cliente es quién realmente determina finalmente como trabaja la empresa de desarrollo.
Muy cierto, es una de las principales dificultades a las que me encuentro. Muchas empresas (con motivo fundado) sufren al enfrentarse a clientes anárquicos o que directamente no aprecian la calidad.
6. Al final la realidad dice que no hay verdades absolutas.
Otra verdad. Ni el consultor, por mucha experiencia que tenga, tiene la verdad absoluta en propiedad, ni seguir a rajatabla ninguna metodología(sin pensar el motivo de las cosas)sirve.
Muy buen post, felicidades de nuevo.
Gracias Alex, y también por tus comentarios
Javier
Tampoco he pasado por tantas empresas y quiero comentar especialmente sobre el último punto. He tenido la experiencia de liderar grupos pequeños con excelentes resultados. Creo que es una mezcla exacta de los temas que mencionas: SUPERVIVENCIA y además es más fácil realizar seguimiento y determinar dentro del grupo de desarrollo y pruebas quien cumple y quien no cumple.
Pingback: Diagramas Gantt cómo arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito - Javier Garzás, sobre calidad software y otros temas relacionados
Buenas:
Un gran post. Me gustaría comentar sobre los puntos 2 y 3.
Sobre la cantidad de empresas de servicio, ahora mismo con el auge de la emprendeduría se está levantando poco a poco las pequeñas startups que se dedica a un producto concreto, bien ofreciendolos físiciamente o bien através de internet. Aunque reconozco viendo las experiencias de las empresas que realemente tienen algo de retorno, el camino es difícil pero no imposible.
Sobre la calidad del producto, recuerdo que había una figura que es un triangulo donde cada uno de los vértices están las palabras: calidad, precio, velocidad(rapidez), y el texto de abajo pone: Escoged 2. Sin embargo, hace tiempo y ahora más por el tema de crisis, el precio se ha convertido en un punto imprescindible. Pero el cliente siempre quiere todo, por lo que también lo quiere rápido de y calidad. La razón de siempre es que es algo que depende la supervivencia del proyecto. Esto lo digo por experiencia porque el proyecto actual en el que estoy lleva en momento crítico más de un año. Es como aquél jefe que cualquier cosa que te pide, es para ayer. No me extraña que acabamos muy quemados todos.