Hacer software

Ayer discutimos sobre cómo se debe hacer software. Nosotros, creemos que las empresas grandes, como Telefónica, BBVA, Santander, ... se equivocan en la estrategia, al crear grandes monstruos para el desarrollo de software. Otros piensan, que gracias a esos monstruos, hacer software, para todas las áreas en las que se trabaja es más barato. Para que juzguéis vosotros mismos, pondremos dos ejemplos:

• El primero, el desarrollo, que podríamos llamar, tradicional:

En el desarrollo tradicional, los proyectos los llevan equipos, que suelen tener el conocimiento de la aplicación y lo gestionan desde el inicio del proyecto, hasta su fin. Este fin, no es cuando acaba el proyecto, si no, cuando el proyecto deja de utilizarse, esto es, el equipo (al menos parte de él), se encarga de su mantenimiento.

En este caso, los equipos suelen ser grandes al principio, cuando se parte de cero, para quedarse en mucha menos gente en el mantenimiento.

• El segundo, el desarrollo que, a grandes rasgos, hacen las grandes empresas:

En este tipo de desarrollo, no existe especialización por proyecto, todos, hacen de todo, por lo que hay equipos que analizan, equipos que prueban, equipos que desarrollan, ... Con este modelo, aunque lo normal es que los equipos suelan tratar el mismo tipo de proyectos, llevan varios proyectos, por lo que la especialización no es tanta. Además, como el conocimiento, se va pasando de unas áreas a otras, algo se pierde en el camino.

En este caso, en lugar de tener grandes equipos, tienes equipos más pequeños, pero muchos más y están durante toda la vida del proyecto invariables. Bien es cierto, que llevan varios proyectos, por lo que, probablemente, el coste sea parecido al del otro modelo.

En nuestra opinión, perder esa especialización por proyecto, es la que hace que los equipos no sean eficaces y por lo tanto, desarrollos que con el primer modelo, podrían hacerse en meses, con el segundo puede doblarse el tiempo, por lo que lo que ahorras por un sitio lo pierdes por el otro. Y en cuanto al tratamiento de incidencias, la velocidad con que se detectan y resuelven el primer modelos, es mucho mejor, que con el segundo.

Ahora toca a cada uno, ver cuál de los modelos le parece mejor e intentar aplicarlo. Para terminar, quizá el segundo modelo, en teoría puede ser mejor, el problema es que al llevarlo a la práctica, muchas veces, fallamos y por lo tanto, pierde su efectividad.