Entre las muchas ideas que pudimos comentar en la reunión de Chile Ágil del pasado 26, salió un tema que resulta bastante habitual: Ingenieros que quieren dejar de hacer trabajo técnico. Dejar de programar para pasar a tareas comerciales, de consultoría o de gerencia.
El año pasado comentaba en Navegápolis que me encontré en una selección de personal (para programadores) con un candidato que, con poca malicia y demasiada sinceridad afirmaba que su objetivo era ascender en la compañía, para dejar de programar y pasar a comercial o consultoría. Según sus palabras: “a puestos con mayor proyección”.
Os invito a leer, no el post, sino los comentarios de los que se pueden extraer muchas más conclusiones e ideas para reflexionar.
Algunos fragmentos:
“Un médico de 50 años es una eminencia y un programador de 50 años es un fracasado”
“No podemos negar que el salario, además de la reputación es muy importante”
“Efectivamente, el negocio del software en España funciona así” … “Acá en Mexico la cosa no cambia” (y por lo que vimos en la reunión de la semana pasada, en Chile pasa lo mismo)
“No hagan líderes de proyecto a sus mejores programadores, porque pierden a su mejor programador y ganan un pésimo líder de proyecto”
“Ser (buen) programador es duro. Muy duro”
“El mérito se lo llevan los comerciales y gerentes, y dentro de las empresas solo se valora a quien tenga contacto con el cliente, ya que es el que paga”
“No entiendo como a un ingeniero informático o a un técnico informático no le parece apasionante el mundo de la Programación de ordenadores. Nunca lo entenderé”.
“Me encanta programar, me apasiona. Es mi vida. Pero sabéis qué me ha sucedido? Mis jefes y superiores me han tradado mal”
etc.
foto: wili_hybrid (cc by)
15 Comments
Join the conversation and post a comment.
Leave a Comment
Foro Oficial
Suscríbete al foro
Consultar este grupo ?
FailFast: Base de Conocimiento Colaborativa
- Material sobre gestión y dirección de proyectos ágiles 13/01/2012 Ängel perez
- Que responderías a esta frase de Cmmi: "la calidad del producto depende de la calidad del proceso" 12/01/2012 iván córdova
- ¿Qué es un patrón? ¿Por qué utilizar patrones de diseño? 30/12/2011 arquitectura dsn_xp
- Alguin sabe sobre alguna CRM Social que sea open Source 21/12/2011 ignacio loyola
Creo que lo primero que debiésemos preguntarnos es: ¿de que estamos hablando cuando decimos programador?
Lo digo porque acá en Chile, se le suele llamar programador formalmente a aquel que recibe requerimientos ya analizados, y diseños ya establecidos para que los implemente. Sin Embargo en la practica un programador en Chile, es muchas veces un ingeniero, que se dedica un poco a: analista, arquitecto e implementador (a veces también jefe de proyecto, PMO, QA, etc…).
Si nos fijamos en esto, es claro que una buena parte de estos seres tenga aspiraciones distintas de la labor de implementación que es la que formalmente se asocia a la programación, pero que informalmente implica mucho mas. Y eso es porque la propia formación del ingeniero en Chile implica un sin-numero de otras expertices que no tienen que ver con la más o menos hábil capacidad digitar código de mejor o peor calidad.
Seamos sinceros la única forma en que un ingeniero en computación en Chile puede adquirir la experiencia necesaria para lograr acceder a estos cargos relacionados con sus estudios es desempeñándose como programador (o al menos tomar este tipo de cargo aunque no sea lo que derechamente haga)
El problema esta, a mi juicio, en la poca sinceridad que hay en que no hay otra forma tampoco en que alguien puede lograr la experiencia para ocupar los otros cargos de interés y los pocos incentivos que hay para lograr la especialización en ser un monstruo de la programación.
Para ser programador en Chile a los 40 años y poder vivir dignamente de ello, debes ser muy bueno. Más de lo que debes serlo para ser vendedor u ocupar cualquier otro cargo. Y lo digo sin considerarme a mi mismo programador.
Hola Gerardo,
En el artículo me refiero a Programador con mayúsculas. Al programador ágil. No al progrmador para ciclos de cascada donde un “ingeniero” toma requisitos, otro hace el análisis, un “programador” codifica y unos “testers” prueban.
El Programador capaz de trabajar desde el diseño inicial de la arquitectura en una evolución continua de forma global, integrado en un equipo entre iguales, y completamente consciente y conocedor de los problemas y necesidades del cliente.
Esta analogía demuestra uno de los grandes motivos de la decepción de los programadores.
Ninguna profesión es tan ambigua
Estimado Sr. Arquitecto:
Por favor diseñe y construya una casa para mi. No estoy muy seguro de lo que necesito, así que tendrá que usar su imaginación. Mi casa debería tener entre dos y cuarenta y cinco dormitorios. Simplemente asegúrese de que todo esté pensado de forma que sea sencillo añadir o quitar dormitorios. Cuando
me traiga los modelos, tomaré la decisión sobre lo que quiero. Además, tráigame un resumen de los costes para cada configuración de manera que pueda elegir una de ellas de manera arbitraria.
Tenga en cuenta que la nueva casa debe costar bastante menos que la casa en la que estoy viviendo ahora. Pero asegúrese, de todas formas, de que corrige todas las deficiencias que existen en mi casa actual (el suelo de la cocina vibra cuando ando por el, y las paredes no tienen suficiente aislamiento).
Mientras diseña, tenga en cuenta que quiero mantener los costes de mantenimiento lo mas bajos posibles. Esto significará la incorporación de materiales mas costosos coste como el aluminio, la fibra de vidrio o el vinilo. (Si elige no considerar el aluminio, prepárese para explicar su decisión en todo detalle.)
Por favor asegúrese de que se utilicen las prácticas mas modernas de diseño y lo último de lo último en materiales a la hora de construir la casa, ya que deseo poder presumir de haber utilizado las mas actuales ideas y métodos. Tenga en cuenta, de todas formas, que la cocina debería diseñarse para acomodar, entre otras cosas, mi nevera Gibson del 52.
Para asegurarse de que esté construyendo la casa de manera correcta para toda la familia, contacte con cada uno de mis hijos e hijas, y también con mis nueros y nueras. Mi suegra tendrá también bastantes cosas que decir sobre como debería diseñarse la casa, ya que nos visita al menos una vez al
año. Asegúrese de que considera cada una de las opciones que le propongan cuidadosamente y asegúrese también de elegir la decisión acertada. Yo, de cualquier forma, siempre tendré la última palabra y podré rectificar cualquier elección que tome.
Por favor no me moleste con los pequeños detalles de momento. Su trabajo es desarrollar una idea general del diseño de la casa: captar la idea. Este momento, por ejemplo, no es el apropiado para elegir el color de la alfombra.
En cualquier caso, recuerde que a mi esposa le gusta el azul.
Además, no se preocupe aún de adquirir los materiales necesarios para construir la casa. Su prioridad es la de desarrollar planos detallados y especificaciones. De todas formas, una vez que yo apruebe esos planos, espero que la casa esté construida en 48 horas.
Aunque esté diseñando esta casa específicamente para mí, tenga en cuenta que antes o después tendré que venderla a otra persona. De manera que debería ser atrayente para una gran variedad de compradores potenciales. Por favor
asegúrese antes de que finalice los planos de que halla un consenso sobre las características de la casa entre la población de la zona. Le aconsejo que eche un vistazo a la casa que mi vecino se construyó el año pasado. Nos encanta. Tiene bastantes características que también queremos en nuestra nueva casa, especialmente la piscina de 75 pies. Aplicando la ingeniería de
manera cuidadosa, creo que no tendrá dificultades en añadirlo al diseño final sin que tenga ningún impacto en el coste.
Por favor prepare un conjunto completo de modelos. No es necesario por ahora que prepare el diseño real, dado que solo queremos los modelos para calcular los costes de la obra. Tenga en cuenta, de todas formas, que usted será el responsable de cualquier incremento en el precio debido a cambios posteriores en el diseño.
¡Debería estar emocionado por trabajar en un proyecto tan interesante como este! Poder utilizar las últimas técnicas y materiales y el que le den tanta libertad en sus diseños es algo que no ocurre muy a menudo. Contacte conmigo tan pronto como sea posible con una lista completa de sus ideas y sus planes.
*Postdata:* Mi esposa acaba de decirme que no está de acuerdo con algunas de las instrucciones que le doy en esta carta. Como arquitecto, es su responsabilidad el resolver estas diferencias entre mi esposa y yo. Yo ya lo he intentado en el pasado y fui incapaz de conseguirlo. Si no puede hacer frente a esta responsabilidad, tendré que contratar a otro arquitecto.
*PostPostdata:* Quizás lo que necesite ni tan si quiera sea una casa, sino una caravana. Por favor aconséjeme lo mas pronto posible si ese es el caso..
Yo creo que es importante que los roles dentro de un equipo estén bien definidos, para evitar por ejemplo que sea el programador quien tome las decisiones de arquitectura o diseño gráfico, haga el plan de pruebas, etc.
Pero aún así es importante que el equipo trabaje en conjunto. Esto no es ambiguo, es decir, si cada uno tiene algo importante que aportar desde su punto de vista que lo haga, pero la carga debe estar bien balanceada.
En chile la mala administración de los proyectos hace que el presupuesto no alcance para contratar expertos por area, así que se corta por lo sano y a se contrata solo un programador y listo, se espera que el haga todo… por eso los programadores se terminan aburriendo de hacer su pega.
eberrios, con tu relato se demuestra la importancia de roles transversales, no para aliviar la carga de los programadores o de cualquier otro, sino para ejecutar una actividad ingenieril digna.
Por favor, evitemos de caer en la precariedad de proponer la omnipotencia y superioridad de cualquier rol y mucho más evitemos el rebaje de otros roles que bien ejecutados, son tal vitales como la que uno pueda llevar.
Por lo que puedo observar, lo que realmente falla es el estilo de liderazgo organizacional y la falta de comprensión y aplicación de un verdadero proceso de ingeniería, independientemente del modelo que lo rija.
Sucede que en todas partes del mundo se ahorra en gente, se ahorra en procesos, procedimientos y mejores prácticas y los resultados finales no son los ideales.
El recorte es una característica que se reconoce en todos los casos de de fracaso, pero sucede así por que se recorta sin criterio y con total arbitrariedad y luego se estandariza el proceso dejándolo estático, en lugar de adaptarlo para cada proyecto.
Por otro lado, esta sensación de insatisfacción generalizada se presenta aún en personas que aman su profesión, independientemente del rol. Puede variar la perspectiva, pero todos tenemos a la corta o a la larga, la necesidad de reconocimiento general o de nuestros pares, un salario digno, horarios laborales tan flexibles como nuestra flexibilidad horaria, beneficios e incentivos por hacer cada día más productiva nuestra labor, posibilidades de crecimiento y proyección, respecto, trato justo, entre otras cosas.
Entonces si la percepción es la misma, tal vez la solución no sea mirar de reojo y con desmedro a nuestros colaboradores de otras fases, sino demostrar que el trabajo en equipo es mucho más que una ambición utópica y lo podemos hacer.
Hola Rodrigo,
No se si es conveniente tener equipos con roles muy definidos. ¿A qué roles te refieres, según cuales fueran, se podría tender a la separación de funciones y de ahí a la cascada (yo analizo, tu diseñas, el programa…) hay un paso.
Desde la visión ágil, resulta más aconsejable trabajar con un equipo que todo él es un único rol del sistema, como “equipo multifuncional”.
Un Saludo!
jejej conozco bastante gente que mira despectivamente a los programadores … como algo bajo … sinceramente a mi me gusta bastante programar … y aunque me dedico a llevar proyectos enteros solo, la opcion de dedicarme a “comercial” u otro es una de las cosas que me gustaría evitar
opino lo mismo que este comentario:
http://www.navegapolis.net/content/view/792/53/#pc_1398
por otra parte creo que tiene mayor proyeccion un programador freelance que un “comercial” trabajando para terceros
Para situaciones como las que se describen en
http://mundogeek.net/archivos/2004/10/21/si-los-arquitectos-tuvieran-que-trabajaran-como-los-programadores/
son precisamente para las que la aproximación ágil al desarrollo de software se ha creado.
Cuando la especificación no existe realmente en el cerebro de ningún ser vivo, o no coges el proyecto o lo coges y haces lo que buenamente puedas. Y hasta ahora, intentos como scrum han conseguido un éxito notable.
Dicho esto, por comentar algo sobre lo que puede asquearte en el trabajo, diría que existe una relación inversa entre el nivel de estudios de uno y el tiempo que es capaz de soportar trabajo repetitivo sin odiar implacablemente lo que está haciendo. Por eso, cuando un ingeniero técnico o un ingeniero llega a un puesto de programador y es víctima de un gestor de recursos humanos que no es capaz de extraer la mínima parte de su potencial, algunos tienen (muy comprensiblemente) la sensación de que todo cuanto han estudiado sólo sirve para picar java 50 horas a la semana durante el resto de su vida.
hola a todos
Habiéndose hecha la diferencia entre Programador y programador.
Tenemos lo siguiente, aun cuando en las organizaciones estamos tradicionalmente trabajando con Programadores, no se quiere admitir que se les paga y trata como programadores.
La vision de los mismos en las empresas es la misma que se les de da en las construcciones a los obreros (guardando las distancias) por lo mismo se les trata como tales. Se les grita, se les mira con desconfianza, se les exige sobretiempo aun cuando no sea su culpa los retrasos del proyecto.
Como a diferencia de los obreros estos toman decisiones debido a su rol de Programador, se les exige más, por lo mismo se vuelven responsables de decisiones para las cuales no poseen información adecuada pero que se espera tomen.
Tengo la suerte de trabajar en mi empresa con un Buen Programador, sin embargo gana mucho menos que otros programadores, solo porque no sabia que podía negociar su sueldo a ese nivel.
Por que ocurre esto? porque cuando en la universidad veia a compañeros evaluando proyectos valoraban el costo de los Programadores como si fuesen programadores, pero el rendimiento esta estimado con esfuerzo y roles de Programador.
En fin a lo que apunto es que, aun siendo Programador tu techo en Chile es ser programador, sin cambiar eso, sin modificar esa mentalidad ser programador en Chile a los 40, y tener una vida digna es muy difícil.
fe de ratas
el ultimo programador debió ser escrito con mayúsculas
en mexico tambien es muy dificil a los 35… ayer una estudiante de una de las universidades privadas mas costosas de la capital (mexico df), me pidio que le cotizara su proyecto final, es decir “su tarea”, yo me imagine que me hiba a pagar por hacer “su tarea”, pero al revisar de que se trataba, la señorita queria una aplicacion bastante completa para dibujar con pixels de 24 diferentes colores en un website y que tuviera la capacidad de guardar los dibujos y que otros usuarios tuvieran acceso a los dibujos de otros y poder editarlos cuantas veces se quisiera, imprimirlos, etc. en pocas palabras un editor de imagen bastante basico pero no por eso sencillo. me dio un plazo de una semana, decidi que 550 dolares americanos (7000 pesos mexicanos) estaban bien, tomando en cuenta la universidad privada en donde estudia -algo asi como 40,000 pesos de colegiatura mensual- y su grado socioeconomico, 7000 me parecieron lo justo y la verdad no demasiado, lo pense asi para que ella accediera, a fin de cuentas era “su tarea” la que habia que resolver…
no me sorprende que se le haya hecho demasiado dinero, los judios aqui en mexico tienen fama de tacaños, sin generalizar ni con la intencion de ofender a ninguno de los aqui presentes. el caso es que mi conclusion es la misma, el trabajo del programador esta subvalorado, siempre nos quieren pagar la mitad de la mitad y a eso restarle la mitad. amo programar, me hace muy feliz y me llena de satisfacciones, el problema es que existe un claro desface entre los conceptos “subdesarrollo” y “programacion” es decir: desarrollo = programacion, subdesarrollo = miseria. en mexico es un abyecto milagro que las dos palabras puedan existir una al lado de la otra. y por lo visto el subdesarrollo no es privativo de las clases bajas…
Rescatando la idea de Juan sobre la separación del trabajo, comparto contigo la idea de que al hacerlo así estás a cerca de la cascada,es decir, de querer controlar todo, pero también estás cerca del caos, ya que al tener un equipo multifuncional tienes muchas variables incontrolables(espectativas, ideas, metodos, herramientas, etc), pero justamente creo que de eso se trata la agilidad, de saber mantener el equilibrio entre caos y el control
Por ejemplo:
- caos para ser creativo, control para entregar a tiempo
- caos para aceptar la diversidad cultural, control para hacer converger de ideas en una solucion
Muy buenos comentarios, sigamos así
Saludos a todos!
I just want to tell you that your blog is very interesting, bookmarked
Hola queridos amigos, soy Pío, su blog está la verdad bien bueno y este artículo que han publicado me agrada mucho. Este asunto, debo confesarles, es muy controvertido puesto que hay tantas diversas opiniones como personas distintas existen en nuestro planeta. ¿Cual es el mejor estilo de gerencia? Yo no tengo idea. Sí se que me gustan los de Michael Useem y los de David Ulrich, pero no se decir cual es mejor entre todos. Me agradaría conocer la opinion de todos ustedes. Espero volver pronto.
Leí el artículo y refleja la realidad de muchos programadores, yo estudié análisis y programación y aquí en Chile se contrata un ingeniero ejecución para hacer labores de programador y a un ingeniero civil para hacer de analista, y el que tiene título de programador queda cesante. ¿ pero saben qué ? la mayoría de los ingenieros chilenos sean ejecución o civiles no saben programar. ¿ saben porqué ? porque desde que están estudiando se les mete en la cabeza que la programación es algo inferior y que ellos cómo futuros ingenieros debieran mandar a otro a hacer esa labor. ¿ resultado ? cuando salen a trabajar en las empresas les piden que hagan un sistema y se dan cuenta que no tienen la suficiente habilidad para programar, y mientras tanto el proyecto se atrasa. después de un tiempo contratan a un ‘ayudante’ (programador o analista) que es el que hace la pega. Señores el escenario antes descrito lo he vivido hasta el cansancio, y un sin número de veces he sido yo (el analista/programador), el que les ha salvado el trasero a los ingenieros, los cuales con toda sus supuestos conocimientos y habilidades no han sido capaces de escribir el programa, evitándoles quedar mal ante sus superiores. ¿ les cuento otro secreto ?
Los ingenieros son pésimos analistas/diseñadores de sistemas- ¿ porqué ? porque el diseño de sistemas no es una labor topdown o bottom up, sino que es una mezcla de ambas. Yo cuando voy a disñar un sistema, al mismo tiempo estoy mirando ‘hacia adelante’ y visualizando los obstaculos o metas que se que jamás podré alcanzar, así puedo ‘reacomodar’ las funcionalidades del sistema para que se ajusten a metas u objetivos alcanzables. en cambio los ingenieros cómo están desapegados de los detalles de ‘más bajo nivel’ no poseen esta habilidad para anticiparse a los obstaculos. Para ser un diseñador experto, primero deberías ser un programador experto (comenzar desde abajo). Esta filosofía es la que siguen los Japoneses y a ellos les ha funcionado perfectamente.