Blog::Navigation
Bookmarks::Blogroll
Bookmarks::Articulos
Blog::Referers
Las visitas de hoy a la página: 46
Powered by Roller Weblogger.
Las visitas de hoy a la página: 46
domingo octubre 28, 2007 Como todo el mundo, a lo largo de mi vida profesional, me he encontrado (ocasionalmente o no tan ocasionalmente) con los típicos "trepas" que "en este mundo abundan". Siempre me ha llamado mucho la atención este "perfil profesional" (por llamarlo de alguna forma). Es realmente interesante cómo personas, con habilidades tanto técnicas como personales muy limitadas pueden ascender con tanta facilidad en sus trabajos.
Yo creo que la clave está en la personalidad. Son gente con ambición y que "viven profesionalmente por encima de sus posibilidades". Por ejemplo, si su trabajo es programar, van a dedicar más tiempo del que deberían a diseñar o a escribir documentos funcionales, o cualquier otra tarea en principio de más nivel del que les correspondería. Si tienes a un programador (trepa) con algo más de experiencia y le encargas "controlar" un grupo de juniors, enseguida se montará un diagrama Gantt para seguir el progreso de "su" equipo (cuando en realidad, coño, solo tenía que echarles una mano de cuando en cuando!!).
Lo mas curioso es cómo estos tipos (y tipas, para que nadie se ofenda) consiguen engañar a sus superiores. Muchas veces trepas iguales que ellos. Otras veces, profesionales a los que en principio, respetas. Todos a la larga caen engañados por los trepas. ¿Como lo hacen?
Yo tengo una teoría. Últimamente me ha tocado tener algo de responsabilidad sobre un grupo de desarrollo, en el que trabajamos en varios proyectos. Al final, como responsable ¿que es lo que valoras de la gente con la que trabajas?: El compromiso. Lo que mas valoras es que puedas encargar un trabajo a una persona y tengas las mejores garantias de que esa persona lo va a hacer tan bien (al menos) como tu lo harías: se va a preocupar porque todo salga bien tanto como te preocuparías tú, si no da tiempo se dará cuenta y actuará en consonancia (al menos, como lo harías tú), sabrá decidir cuando hay que echar mas horas y cuando no, y si toca pringar, pringará como pringarías tú. Si tiene que lidiar con una tecnología desconocida, sabrá ponerse al día por su cuenta, etc. En resumen, un buen profesional desde el punto de vista de un responsable, es alguien en quien puede confiar tanto como en él mismo.
Normalmente los trepas encajan en este perfil. Son gente con ganas y con ambición. Gente que se busca la vida, que se preocupa (o eso parece), etc.
La diferencia entre un trepa y un buen profesional es que éste último asume las responsabilidades y las lleva a cabo con SU trabajo. Un trepa asume las responsabilidades ante su superior y luego consigue que los demás hagan el trabajo sucio, poniéndose luego las medallas.
Como siempre termino con la pregunta...Seguro que todos conoceis a algun trepa (o varios) ¿se ajusta a este perfil?
¿Un programador no puede estar interesado en realizar análisis funcional? ¿Debe ser considerado un trepa por intentar orientar su trabajo hacia un área de la informática que le puede resultar más interesante?
Enviado por 62.14.249.65 en octubre 29, 2007 a las 07:40 AM GMT-01:00 #
Yo lo puedo resumir de otra manera.
Si un trabajor fuera un MVC, un trepa sería una Vista tipo Beryl, con un controlador implementando el patrón Brown Dispatcher y un modelo vacio.
No tiene nada que ver con hacer analisis funcional o docs, pues aunque estas tareas no visten para nosotros tanto como hacer un código /diseño de puta madre, son completamente necesarias y haciendolas bien tremendamente complejas.
Es más, una empresa con un analista funcional práctico, inteligente y buen gestor de requisitos puede conseguir más para el producto/desarrollo final que un tio capaz de escupir código optimizado...(una pausa para digerir lo que acabo de decir), ¿o acaso no es la planificación de tiempos y alcances el drama más gordo que tenemos en el día a día?
En el otro extremo esta la mayoria de informáticos que tiende a ser mucho modelo, un poco de controlador y la vista pa' la ONCE, olvidando que al final nuestras pajillas mentales deben transformarse en ventajas para el "imbecil" que va a usar nuestros programas.
PD. Por cierto, creo que el ti@ del comentario anterior no ha pillado bien el conce'to del post..
Enviado por ivo_es en octubre 29, 2007 a las 08:20 AM GMT-01:00 #
Hola Ángel,
Trepas en esto, como en todas partes, por supuesto que existen XD, aunque más que programadores trepa yo diría que son "no programadores en el rol del programador", que es un problema distinto (no entro a valorar si valen para hacer otra función).
Si me permites el consejo (si no puedes tirarlo), porque hay cierta parte de tu post que me deja un tanto "intranquilo" en la parte de "que lo hagan como lo harías tú". No digo que sea tu caso, pero me permito la reflexión. Sorry.
Aunque seguramente lo sepas, lo que tienes que tener claro al asumir cierta responsabilidad es que tu trabajo depende de ellos desde ahora, y que tu función es (debería ser) la de hacer que ellos puedan hacer su trabajo lo mejor posible. Es cierto que ellos tienen que hacer su trabajo lo mejor que puedan (y si no eres tú quién debe actuar), pero no es algo tan simple como "deben mirarse las cosas por su cuenta o pringar como lo harías tú". Nadie nace sabiendo, y tu función es la de facilitarles que aprendan, pero dentro de unos límites (basados en el convenio laboral si me lo permites, lo cual incluye darles las herramientas para que hagan su trabajo, lo que incluye el conocimiento). Hay que darles cancha tanto como para que aprendan como para que se equivoquen, porque quizás el que se equivoca eres tú.
Lo que más me ha gustado que me han dicho en toda mi carrera es que una persona que estaba a mi cargo, semanas después de irme de la empresa, me comentó que no sabía todo lo que hacía para hacer su trabajo más sencillo hasta que me fuí.
Enviado por Al en octubre 29, 2007 a las 10:54 AM GMT-01:00 #
Algunas apreciaciones: "...sabrá decidir cuando hay que echar mas horas y cuando no..", por norma nunca deberían de echarse horas, nun-ca. Y si el paciente no se muere, se puede seguir con ello al día siguiente. Por cierto, muy pocas veces el paciente se muere o lo que es lo mismo, pocas veces nos encontramos en una situación tan tan crítica que hay que pringar alargando nuestra jornada y echando horas. Otra cosa es que algunas personas en este país quizás no están preparadas o no estamos preparados para trabajar sólo durante nuestra jornada laboral.
Para mi una función importante de un jefe es que debe ser un filtro, que es lo que comentaba Al; necesitas que llegue hasta ti lo necesario para poder hacer tu trabajo, y eso implica que la información debe llegar libre de ruido.
Y sobre todo, debe de existir una muy buena comunicación.
Enviado por Jesús Navarrete en octubre 29, 2007 a las 01:41 PM GMT-01:00 #
Unas breves aclaraciones:
1.- Al primer anonimo: Un programador por supuesto que puede estar interesado en hacer otras cosas: análisis funcional, diseño técnico, fusiones y adquisiciones, lo que sea. Pero siempre y cuando eso no afecte a su rendimiento como programador. Si trabajas como programador (o como yesero, o como lo que quieras), tienes unas responsabilidades que cubrir y no es escusa el hecho de que "te guste hacer análisis funcional" para no hacerlas.
Y si "orientar su carrera" es dejar de hacer el trabajo que se supone que tiene que hacer (programar) entonces sí, es un trepa. mas que nada porque ese trabajo se lo comen luego con patatas los compañeros.
2.- Para Al:
- Admito la puntualización y la redondeo aún mas. Mas que trepas son "programadores no en el rol de programador y que, de motu propio, asumen un rol superior sin estar capacitados para ello, redireccionando su trabajo real a sus compañeros". En realidad use la palabra "trepa" por ser mas conocida, pero el que lea a Fuckowski los reconocerá mejor por "Monchitos".
- En realidad, cuando dije "como lo harías tú", me refería a que puedes confiar en que harán las cosas con el mismo interés y que llevarán una línea similar de actuación (vamos, lo que viene siendo: "alineados con la organización").
3.- Para Jesus. Me alegro de que donde tu trabajas no haya que echar horas extras nun-ca, no es mi caso. Pero bueno, a lo mejor hay que decidir que no se echan horas. O a lo mejor, hay que decidir que compensa mas hacerlo mejor y echar algunas horas mas, en lugar de hacer la aplicacion mas cutre y mas rápido... A ese tipo de decisiones es a lo que me refiero.
Enviado por retamar en octubre 29, 2007 a las 04:43 PM GMT-01:00 #
Yo no he afirmado que no se echen, he afirmado que cuando se planifica, no se tengan en cuenta (que no es la primera planificación que se hace bajo ese supuesto); que no se piense que tener un programador a cargo es tener a alguien que puede echarlas sistemáticamente; que no se piense que gracias a eso sale un mejor trabajo; que no se cuente el tiempo de formación como el tiempo de ocio de un trabajador.
En definitiva que cuando se estime un trabajo no sea gracias a que otros te trabajan gratis.
Digamos que hay algo que quizás no he sabido expresar, o no se me ha entendido. Si planificas tareas y estas se extienden tendrás que ver el porqué. Si planificaste mal, si no supiste medir lo que se tardaba en hacerla, si surgieron imprevistos, si desconocías la tecnología, si... es gran medida un problema que debes solucionar tú, la planificación es tuya y el error podría también ser tuyo. Buscar "al culpable" también es tu misión, y dar una solución a la situación. Y no culpar siempre al que programa.
Pero, ¿por qué todo se soluciona echando horas extras? Para mi es muy sencillo, porque no se paga por ellas ni un euro. Si las horas se facturasen, y se pagasen como extras, quizás a algún gerente de cuentas le resultasen excesivos los gastos del proyecto y le pusiese las pilas a alguien. Aunque aquí no necesitamos esto, no, porque por trabajar 40 horas te pagan lo mismo que por trabajar 50, 60, ... , haz tú las cuentas, que a mi me da la risa.
Y una cosa, si tienes a un trabajador haciendo su trabajo, cumpliendo con su jornada laboral, por más que trabaje echando horas no significa: uno que lo vaya a hacer mejor y dos que la aplicación vaya a ser menos cutre. Porque el ritmo agota física y mentalmente; y este trabajo requiere de ambas, sobre todo de una mente ágil y descansada para resolver.
Es tan bien conocido que en España somos los que más horas dedicamos a trabajar, sin embargo, somos los que menos rendimos y sinceramente cuántas de todas esas horas de las que unos alardean son trabajo; que conste que no estoy acusando a nadie, pero contar como regla con las horas extras que un trabajador podría hacer porque sí, no me parece hacer una buena labor ni como gestor ni como "planificador".
Pero bueno, quizás todo esto se empieza a salir del post. Conclusión, si diriges gente, si cae sobre ti la responsabilidad de que otros hagan su trabajo, preocupate de que lo hagan, dales solución a sus problemas (que no tienen porqué ser técnicos), haz que no pierdan el día al teléfono resolviendo incidencias de un usuario que no diferencia entre doble click y simple click (sobre todo sino es su trabajo), no metas a tus programadores en reuniones diarias de horas, concreta sus tareas y negocia con ellos vías técnicas de llevarlas a cabo, cuenta con ellos cuando midas las tareas (sobre todo si no tienes una idea exacta de cuánto puede llevar), y otra más.
Enviado por Jesús Navarrete en octubre 29, 2007 a las 09:43 PM GMT-01:00 #
Creo que os habeis desviado totalmente de lo que es un trepa.
Si os estais refiriendo a gente con ambición y ganas de dirigir (por muy repelentes que sean) no son trepas, serán "no programadores" o lo que sea, pero es otra categoría.
La ambición no es lo que define al trepa.
Atribuirse el mérito de los demás si lo es.
Ningunear el trabajo de los demás si lo es.
Instalarse como "único interlocutor válido" de los jefes si lo es.
Mentir sobre la viabilidad de los objetivos y luego culpar a los demás si lo es.
Lo otro, a lo sumo podrá ser un "scheissmeister" (Capataz de la mierda), pero no un trepa.
Enviado por chuache en octubre 29, 2007 a las 10:20 PM GMT-01:00 #
Jesus, tengo un post respecto a eso que comentas de las horas extra. Estoy un poco vago para buscar el enlace pero, en resumen, lo que decia es que al final, se echan horas extras porque en el plazo es "de donde" el comercial tiene para tirar a la hora de hacer "ofertas competitivas". De "calidad" no puede tirar, porque de todos es sabido que aquí el que no es "el puto amo en lo que sea" no es nada. De precio tampoco, que palman pasta (y lo que es peor, comision). Solo queda ofrecer un plazo menor y que los pringados echen horas hasta por los ojos.
Ya se que echando horas no se hace mejor. Pero se hace. Al menos, se puede "entregar algo" (normalmente una mierda que se viene abajo al día siguiente de instalarlo). Pero ahi, el comercial ya cobró el cheque y ese no es su problema.
Repecto a lo que comenta "chuache". Nadie está diciendo que la ambición sea mala. Es mas, en mi opinión es buenísima. Si en este post precisamente digo que los "trepas" y los "buenos profesionales" son, en ese punto iguales. De hecho, es tan dificil distinguirlos porque son muy parecidos. La unica diferencia es que los buenos profesionales aceptan la responsabilidad y la solucionan. Los trepas, en cambio, aceptan la responsabilidad y luego el trbajo lo endilgan a los compañeros.
Enviado por retamar en octubre 30, 2007 a las 08:14 PM GMT-01:00 #
Para Retamar:
La entrada del blog empieza bien, pero al final acabas en tópicos. Mencionas a pringaos echando horas, ¿como eres capaz de poner tantos calificativos?. Sobre echar horas, o no. Eso depende también de la planificación casi siempre bien ajustada para que el coste sea menor.
Como te ha dicho Al, evita que llegue ruido al equipo de desarrollo, y no supongas que lo harán igual que tu. Simplemente guialos para que tengan un estilo común.
Llevar a gente, es dificil, pero intenta evitar los errores más comunes. Aunque será inevitable cometer otros. Pero sobre todo respeta al equipo, y cuando tengas que evaluar, hazlo de forma objetiva. Recibir críticas suele ser muy constructivo para ti, estás no siempre vienen de un trepa.
Enviado por jesta en octubre 31, 2007 a las 07:46 AM GMT-01:00 #
Yo es que soy de ciencias de toda la vida y por eso no tengo una prosa tan clara como me gustaría.
- Nunca he hablado de pringados. Seguramente hay muchas empresas donde NUNCA hay que echar horas extras. Yo personalmente no conozco ninguna. Jamas he defendido que haya que echar horas extras para nada y no me parecen positivas pero, la realidad (al menos la que yo conozco), es que hay muchos proyectos que, por la causa que se quiera (mala planificación, un comercial avispado que se columpió mas de la cuenta, un incendio en un servidor, etc), hay que echar horas extra o no se terminan en plazo. Esta es la realidad que yo conozco. No digo que sea buena (es mas, es muy mala) pero es así. Entonces, teniendo esto en cuenta, lo que quería decir en mi post es que un buen profesional, sabe detectar estos casos (y ponia el caso de echar horas solamente como un ejemplo de una contingenia que puede surgir) y reaccionar consecuentemente. No se queda parado esperando instrucciones. Si para cubrir los plazos hay que echar horas, se da cuenta el solo y actúa en consecuencia.
- Respecto a la frase "como tu lo harias" (debí ponerla entrecomillada), evidentemente no creo que nadie espere que los programadores sean clones de sus superiores. No me refería a que el resultado fuese igual (que no puede ser, logicamente), sino que ese profesional ponga el mismo interés y sea capaz de reaccionar con la misma solvencia que tú mismo podrías poner. Gente que reciba un encargo y lo solucione satisfactoriamente, sin mas (siendo siempre conscientes de que cualquiera puede cometer un error, igual que "tu mismo" podrías cometer el "mismo error").
- No creo haber dicho que tenga que evaluar a nadie, pero bueno. Como todo el mundo, tengo mis criterios que, evidentemente, creo que son los mas objetivos.
- Sobre las criticas no creo haber dicho nunca nada. Pero ya que estamos: normalmente, un buen profesional tiene una opinión formada por su experiencia y su conocimiento y la defiende aunque tenga que llevar la contraria al Papa de Roma. Por eso, normalmente una critica suele venir siempre de buenos profesionales.
Los "monchitos" sin embargo (como no suelen tener mucho conocimiento) critican en base a sus intereses personales (trepar) y, estas criticas suelen ser lamidas de culo a sus jefes.
Otro motivo por el que los buenos profesionales suelen oponerse a las "sandeces" de sus jefes es que luego (como son gente comprometida) al final son quienes acaban pringando. Los treps (como no son gente comprometida y cuelgan el chollo al primer incauto que pase) no suelen tener ningun problema en comulgar con las ruedas de molino que les echen.
Enviado por retamar en octubre 31, 2007 a las 01:55 PM GMT-01:00 #