Sin embargo, a día de hoy, el desarrollo de software tiene más de artesanal que de industrial. Incluso existen diversas opiniones que consideran que así debe ser:
- ¿Alguien ha visto un programador? (Enrique Dans)
- No alcanzo a ver, disculpe mi miopía, aquello que constituye un valor diferenciable en la especialización (Daven)
Supongo que en este tema, como en tantos otros, cada persona ve lo que quiere ver. No son pocos los profesionales que les gusta considerar que la informática es una actividad tan creativa como cualquier otra faceta artística. Por supuesto, el sector es tan amplio que da cabida a todos estos enfoques. En ese sentido, para una página web seguramente sea más apropiado un pequeño equipo sin roles diferenciados siguiendo metodologías ágiles, mientras que para un sistema complicado de la Administración que tenga múltiples interfaces con otros sistemas sea más necesario dedicar gran parte del tiempo inicial al análisis y diseño.
El problema radica en que, frecuentemente, los componentes de los equipos de trabajo no comparten un mismo enfoque, con lo que no se consigue ni favorecer la creatividad ni la productividad. ¿No os parece que cuando una empresa propone su visión, además de dejar claros sus objetivos (calidad, innovación, orientación al cliente, precio competitivo, etc.), también debería indicar sus líneas maestras para conseguirlos, es decir, su enfoque?
De nuevo, surge aquí el concepto de compromiso (la palabra más "ingeniera" que conozco): Creatividad vs. Planificación. Por mi parte, tengo mi postura bastante clara:
- Cumplimiento de metodologías de trabajo: No más "síndrome de la hoja en blanco" ni documentación innecesaria (aquí también hay un compromiso).
- Persecución de la estandarización de componentes básicos ("tornillos"): Nunca más volver a programar un reloj para una página web.
- Especialización + Multidisclipinaridad (otro compromiso). Mi enfoque: saber mucho de lo tuyo, un poco del resto y a quién preguntar sobre lo que no sabes. Por supuesto, requiere formación continua y orientación a la colaboración.
- Distinción de las tareas por su nivel de dificultad y por las habilidades requeridas: No más roles programador-analista-gerente-secretario.
- Desarrollo de marcas y certificados que inspiren confianza a aquellos consumidores con menor conocimiento sobre las TIC.
La principal ventaja de seguir este enfoque es que favorece el reparto de trabajo y, con ello, la posibilidad de subcontratración y de joint-ventures. Esto facilitaría la creación de pequeñas empresas centradas en nichos del mercado con lo que se fortalecería el tejido empresarial del sector y dejaríamos de depender tanto de la grandes empresas para proyectos de tamaño considerable.
¿Cuál es tu enfoque? ¿Conoces una empresa que comparta tu mismo enfoque? ¿Encontraremos los tornillos?
4 comentarios:
Muy interesante Rubén-san!
Aunque yo no entro mucho en el debate denominativo sí que estoy de acuerdo en bastantes puntos.
Sobre todo el de "artesanía", hay tantas disciplinas con tantos "problemas" y tantas formas de arreglarlos que lo mejor es separar lo "artesano" de lo "industrial" (me van a faltar comillas...).
Para cercar mi verborrea profana voy a coger los puntos de tu postura y customizarlos, ak ak:
* Cumplimiento de metodologías de trabajo: Sí, pero sin pasarse. Quiicir, es básico guiarse por conceptos de ing. del software (como pueden ser los malditos Rieles!), pero dependiendo del proyecto y aunque sea una parte muy importante, la documentación (que es un básico de las metodologías) puede ser contraproducente, vamos, que si te obligan a llenar 20 apartados con un reloj de una página web (;)) vas a repetir tantas veces lo mismo pero con diferentes palabras que el que tenga que encargarse del mantenimiento va a perder tanto o más tiempo que el que lo ha escrito
* Persecución de la estandarización de componentes básicos ("tornillos"): De acuerdisísimo, el modulaje es el futuro!
* Especialización + Multidisclipinaridad (otro compromiso). Esto me suena aun muy buen argumento para defender una carrera universitaria (en anteriores capítulos :P). De acuerdo
* Distinción de las tareas por su nivel de dificultad y por las habilidades requeridas: No más roles programador-analista-gerente-secretario.
Y lo comento sobre tu opinión. Ni de coña nos vamos a librar de eso, no de momento, y menos en empresas consultoras más o menos asentadas (una pena...)
* Desarrollo de marcas y certificados que inspiren confianza a aquellos consumidores con menor conocimiento sobre las TIC.
Difícil proposición...pero es la peor de las soluciones a excepción del resto (como diría chuchi). Cuanta gente ha estudiado para un examen que certifique su conocimiento de una tecnología en vez de estudiar esa tecnología? Menos es nada...
a clase!
¡Hola, Beñat!
Me alegro mucho de que compartamos puntos. A ver si así sacamos mejor nota...
Los exámenes de cerificación de los profesionales algo aportan porque permiten a los de RR.HH. basarse en algo más determinista que el ojo de buen cubero. Más importante me parece que las empresas obtengan certificaciones porque así están obligadas a definir metodologías.
Pero, la idea que más me atrae es el establecimiento de marcas reconocibles por la gente externa al sector.
Seguimos en ello. Un abrazoooo,
Rubén
Error mío!
A nivel empresarial sí que me parece una buena idea basarse en certificados (eso sí, emitidos por instituciones oficiales), y que se cree el concepto de "marca". Vamos a ver tu siguiente post :)
A ver un par de comentarios sobre esto...
* No estoy totalmente de acuerdo con que sea un arte y no una industria. En algunos casos, puede que tengas razón, pero en general, hoy en día los programadores son peones del código y trabajan con código "a granel".
* Totalmente de acuerdo en lo de la modularidad. Hay que partir los grandes problemas en pequeños módulos y asignarlos a los que hagan eso mejor, además de no reinventar la rueda, ...
* ... el problema es que lo que es obvio a nivel de dirección, no lo es tanto a nivel de "obrero" o "artista", según lo veas. La gente, como en muchas otras industrias, no acepta tan fácilmente las cosas que vienen de fuera, "lo no inventado aquí". Consideran que ellos lo hacen mejor y lo seguirán haciendo, y que lo que viene de fuera... "a saber".
* Además, los que saben de esto de programar, y mucho (te puedo presentar a alguno por estos lares), dicen que el buen código es muuuuy distinto del malo. Que hay mucha diferencia, así que este sentimiento de "lo que no hago yo, no está bien" es muy grande.
* Creo que ese es el punto que hay que perseguir más. Estandarizar los módulos para que puedan ser evaluados de forma objetiva, y que un trozo de código, pueda ser como un "tornillo".
Publicar un comentario en la entrada