Portada
mis comunidades
otras secciones
#16:
#13 En realidad se planifica como sigue (lo se porque yo, jefe de proyecto primero y comercial despues, y todos los mi antiguo gremio, es asi como lo hacemos):
1. El comercial tarifica a la baja para ganar el proyecto (en caso contrario no gana comision y probablemente sera despedido a los pocos meses). Desde luego no se consulta para nada a los tecnicos, no fueran a chafar la guitarra con su "conservadurismo".
2. El cliente firma por principio la oferta mas baja (si firmara una mas alta, sus enemigos en la empresa, normalmente sus subordinados mas proximos, lo usarian para echarle por malgastador y manirroto y ocupar su lugar y hacer exactamente lo mismo).
3. Como despues no hay tiempo suficiente, se presiona al programador, sobre todo en las semanas finales dle proyecto, cuando la espada de Damocles ya cuelga ostensiblemente encima de algunas cabezas, para que curre los sabados, los domingos, haga horas extras ... y todo sin cobrar, que si cobra el beneficio del proyecto se va al carajo.
Evidentemente toda la basura acaba cayendo encima del programador y del jefe de proyecto, que ademas son los que menos cobran. Pero asi es la vida.
#14 Eso de confundir la produccion con las horas de permanencia en el puesto se va a acabar cuando se generalice el trabajo en casa, algo que sucedera a medida que el precio del combustible o los atascos de trafico sin solucion y sin fin (o lo uno o lo otro seguro que pasa) hagan inviable el desplazamiento diario. Como en este caso el concepto de horas atado a la mesa de trabajo pierde sentido, no habra otro parametro para controlar al currante que la produccion pura y dura, y que el currante le eche las horas que quiera.
1. El comercial tarifica a la baja para ganar el proyecto (en caso contrario no gana comision y probablemente sera despedido a los pocos meses). Desde luego no se consulta para nada a los tecnicos, no fueran a chafar la guitarra con su "conservadurismo".
2. El cliente firma por principio la oferta mas baja (si firmara una mas alta, sus enemigos en la empresa, normalmente sus subordinados mas proximos, lo usarian para echarle por malgastador y manirroto y ocupar su lugar y hacer exactamente lo mismo).
3. Como despues no hay tiempo suficiente, se presiona al programador, sobre todo en las semanas finales dle proyecto, cuando la espada de Damocles ya cuelga ostensiblemente encima de algunas cabezas, para que curre los sabados, los domingos, haga horas extras ... y todo sin cobrar, que si cobra el beneficio del proyecto se va al carajo.
Evidentemente toda la basura acaba cayendo encima del programador y del jefe de proyecto, que ademas son los que menos cobran. Pero asi es la vida.
#14 Eso de confundir la produccion con las horas de permanencia en el puesto se va a acabar cuando se generalice el trabajo en casa, algo que sucedera a medida que el precio del combustible o los atascos de trafico sin solucion y sin fin (o lo uno o lo otro seguro que pasa) hagan inviable el desplazamiento diario. Como en este caso el concepto de horas atado a la mesa de trabajo pierde sentido, no habra otro parametro para controlar al currante que la produccion pura y dura, y que el currante le eche las horas que quiera.
#5:
Como dice el artículo, el modo más fiable de evaluar la productividad de un programador:
"La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida".
Ahí es donde se ve la diferencia entre el que sabe lo que hace y el mediocre. Luego te encuentras con proyectos en los que tienen problemas sin resolver desde hace meses, llega un tipo y en dos días lo corrige tranquilamente. Se nota muchísimo en el sector de la informática cuándo alguien es bueno de verdad, el problema es que normalmente es un trabajo que pasa desapercibido... no se ve... sólo lo valoran quienes están al pie del cañón.
"La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida".
Ahí es donde se ve la diferencia entre el que sabe lo que hace y el mediocre. Luego te encuentras con proyectos en los que tienen problemas sin resolver desde hace meses, llega un tipo y en dos días lo corrige tranquilamente. Se nota muchísimo en el sector de la informática cuándo alguien es bueno de verdad, el problema es que normalmente es un trabajo que pasa desapercibido... no se ve... sólo lo valoran quienes están al pie del cañón.
#7:
En España no se valora lo que produce uno, sino si llegas antes de las 9:00 y haces mas de 8 horas en el curro (aún que no hagas nada).
Comentarios
En España no se valora lo que produce uno, sino si llegas antes de las 9:00 y haces mas de 8 horas en el curro (aún que no hagas nada).
Como dice el artículo, el modo más fiable de evaluar la productividad de un programador:
"La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida".
Ahí es donde se ve la diferencia entre el que sabe lo que hace y el mediocre. Luego te encuentras con proyectos en los que tienen problemas sin resolver desde hace meses, llega un tipo y en dos días lo corrige tranquilamente. Se nota muchísimo en el sector de la informática cuándo alguien es bueno de verdad, el problema es que normalmente es un trabajo que pasa desapercibido... no se ve... sólo lo valoran quienes están al pie del cañón.
Por el precio de uno no. Ese es el maldito error que cometen algunas empresas: pensar que por 800€ vas a tener al programador[x28], y por lo tanto ofrecer salarios ridículos...
#13 En realidad se planifica como sigue (lo se porque yo, jefe de proyecto primero y comercial despues, y todos los mi antiguo gremio, es asi como lo hacemos):
1. El comercial tarifica a la baja para ganar el proyecto (en caso contrario no gana comision y probablemente sera despedido a los pocos meses). Desde luego no se consulta para nada a los tecnicos, no fueran a chafar la guitarra con su "conservadurismo".
2. El cliente firma por principio la oferta mas baja (si firmara una mas alta, sus enemigos en la empresa, normalmente sus subordinados mas proximos, lo usarian para echarle por malgastador y manirroto y ocupar su lugar y hacer exactamente lo mismo).
3. Como despues no hay tiempo suficiente, se presiona al programador, sobre todo en las semanas finales dle proyecto, cuando la espada de Damocles ya cuelga ostensiblemente encima de algunas cabezas, para que curre los sabados, los domingos, haga horas extras ... y todo sin cobrar, que si cobra el beneficio del proyecto se va al carajo.
Evidentemente toda la basura acaba cayendo encima del programador y del jefe de proyecto, que ademas son los que menos cobran. Pero asi es la vida.
#14 Eso de confundir la produccion con las horas de permanencia en el puesto se va a acabar cuando se generalice el trabajo en casa, algo que sucedera a medida que el precio del combustible o los atascos de trafico sin solucion y sin fin (o lo uno o lo otro seguro que pasa) hagan inviable el desplazamiento diario. Como en este caso el concepto de horas atado a la mesa de trabajo pierde sentido, no habra otro parametro para controlar al currante que la produccion pura y dura, y que el currante le eche las horas que quiera.
Me ha funcionado el enlace tras 4 intentos, así que casi mejor lo pego:
Entre 10 y 28 desarrolladores por el precio de uno
Hace tiempo ya, oí hablar sobre el libro The Mytical Man-Month, de Frederick P. Brooks, donde se asegura que los mejores programadores rinden hasta 10 veces más que los que se encuentran en el lado opuesto, los peores. Otras fuentes, como "Facts and Fallacies of Software Engineering" llegan a indicar que la diferencia puede ser incluso de 28 a 1.
Sin duda, la productividad en el desarrollo es algo más que tirar muchas líneas de código por día; ya lo comenta Charles Connell en su artículo It's not about lines of code, donde explica por qué la productividad no puede ser medida en esos términos, de hecho, ¿muchas líneas de código implican un trabajo bien hecho? ¿y si se trata de un nido de bugs?
Así, a lo largo de su artículo, Charles va definiendo y añadiendo características que debería presentar el código creado hasta llegar a una posible unidad de medida de la productividad, líneas de código limpio, simple, correcto y bien documentado por día, para finalmente llegar a la conclusión de que tampoco es del todo apropiado: ¿qué ocurre si un buen desarrollador es capaz de crear una función en 100 líneas de código perfecto y salir de la oficina a la hora habitual, mientras que otros realizan el mismo buen trabajo en 2000 líneas de código trabajando hasta altas horas de la madrugada? ¿quién es más productivo?
La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida. La ingeniería del software trata precisamente de eso, de aportar soluciones a los usuarios que usarán el sistema desarrollado, todo lo demás sobra. Sin embargo, como él mismo indica, es realmente difícil medir estas capacidades utilizando indicadores habituales como número de líneas de código, bugs provocados o tiempo de trabajo en la oficina.
Partiendo de esto, en "10 Developers For The Price Of One", Phil Haack, cuyo apellido seguro que lo predestinó a dedicarse a la informática, escribe sobre este tema centrando la medida de la productividad de los desarrolladores en torno al concepto TCO (Total Cost of Ownership), o Coste Total de Propiedad (CTO), e introduce algunas características propias de los buenos desarrolladores que hace que este factor sea óptimo.
La primera de ellas es la asunción de un proyecto como propio, la autosuficiencia en la resolución de problemas, tomar el control, resolver y asumir el avance del mismo como un objetivo personal. De esta forma se libera a los responsables de estar tan pendientes de estos aspectos y se recurre a ellos sólo cuando surgen problemas de entidad y con objeto de plantear una solución. Un desarrollador que escribe código rápido no es productivo, pues requiere de tiempo de los demás, y sobre todo, de aquellos que por sus responsabilidades disponen de menos tiempo.
La segunda hace referencia a la escritura de código con pocos errores. Un mal programador que escriba código muy rápidamente es un generador de bugs a una velocidad proporcional, lo que provocaría un mayor gasto de tiempo del equipo de testeo y control de calidad, así como del propio equipo de desarrollo en la corrección de los errores. Como comenta Phil, de nada vale ir rápido hacia la dirección equivocada.
En la tercera, se introduce el concepto de la creación de código mantenible. Y no sólo pensando en el mantenimiento futuro del software, sino durante el propio desarrollo inicial. Me ha gustado mucho su visión sobre esto, textualmente, Tan pronto como una línea de código sale de la pantalla y volvemos a ella, estamos en modo mantenimiento de la misma". Un código bien escrito, comprensible y limpio puede ahorrar mucho tiempo en el presente y futuro.
En cuarto lugar, comenta que los buenos desarrolladores hacen más con menos código, son capaces de identificar cuándo deben y cuándo no deben escribir software y utilizar componentes o elementos existentes. El reinvento de la rueda, no es beneficioso para nadie, y los buenos programadores suelen y deben esquivarlo.
Teniendo todos estos aspectos en cuenta, Phil retoma el concepto TCO indicando que todos estos factores son importantes a la hora de evaluar la productividad de un desarrollador en tanto en cuanto que influyen en el coste total de tener a un programador en la empresa, y no sólo fijándose en el coste directo que representa su nómina. Por ello asegura que intenta contratar, aunque no siempre lo consigue, al mejor desarrollador que encuentra en cada momento puesto que si es capaz de hacer más con menos código, escribir de forma inteligible, fácilmente mantenible y con menos errores, incrementará la productividad de sus compañeros, directivos y colegas. Por el contrario, un mal desarrollador puede disminuir la productividad de su entorno por los motivos anteriormente expuestos. Por este motivo puede justificarse la relación de 28 a 1 en la productividad entre unos y otros.
Estoy absolutamente de acuerdo con estas apreciaciones, un desarrollador no puede ser evaluado únicamente teniendo en cuenta aspectos cuantitativos como la cantidad de líneas de código que es capaz de generar: si lo que buscas es velocidad a la hora de teclear, contrata a un mecanógrafo, leche. Y aunque para cerrar un proyecto hace falta escribir líneas, tanto o más importante es la calidad con que esto se haga o tener capacidad para decidir cuándo hay que reutilizar en vez de escribir.
Quizás, por poner alguna pega, echo en falta un par de factores que a mi entender son fundamentales para aumentar la productividad en el desarrollo, y están relacionadas con la visión global introducida en el artículo citado anteriomente.
En primer lugar, la capacidad de comunicación bidireccional, es decir, ser tanto capaz de entender los mensajes de los usuarios, de analistas, comerciales o cualquier otro grupo de interés, como transmitir claramente mensajes, problemas o cuestiones siempre adaptándose a su interlocutor. Esta es, en mi opinión, una habilidad difícil de encontrar y que puede repercutir de forma muy negativa en la productividad global de un equipo de trabajo. ¿Quién no ha tenido que desechar código por culpa de un malentendido?
En segundo lugar, es fundamental la facilidad de integración en equipos de trabajo. Los desarrolladores trabajando en islas son difíciles de ver, la complejidad del software actual hace que en casi cualquier proyecto tengan que intervenir varias personas colaborando de forma muy estrecha. Además, en una máquina perfecta de producción de software la información y conocimientos fluyen con facilidad, lo cual influye en la productividad de cada uno de los componentes de la misma.
Curiosamente, ninguna de estas dos habilidades son técnicas... Sin duda esto de la productividad es un tema tan interesante como complejo, ¿eh?
#1 Sí carga el link, y sí. Buen artículo, por cierto.
#2 Se aprenden desde la infancia, son imprescindibles, con la práctica como mucho se mejoran, y la universidad "debería" fomentarlas, sí.
#7 Te olvidas de las empresas que permiten ir a trabajar los sábados "si quieres". Eso es el no va mas del currante, no hacer nada durante la semana y pasarse el sábado también en la oficina.
Y para los que creen hacerlo para que salga el trabajo ahí van unas reflexiones.
El trabajo debe estar planificado, es decir, alguien decide lo que se tiene que hacer, cuanto tiempo hace falta y cuantas personas son necesarias para cumplir los plazos.
Por lo tanto si es necesario trabajar fuera del horario laboral o los fines de semana es porque:
- Los plazos propuestos no son realistas, quien ha planificado no lo sabe hacer.
- No existe el personal necesario para cumplir los plazos, quien ha planificado no sabe gestionar recursos.
- Quien ha planificado ha contado con el hecho que la gente hará horas extras o trabajará los sábados a la hora de hacer la planificación. Esto tiene un nombre.
- La persona que tiene que hacer el trabajo no ha dado un rendimiento adecuado. Aquí cada uno ya sabe si le es aplicable. Hay gente que va los sábados porque se siente culpable en este sentido.
- Ha habido un imprevisto realmente imprevisible que ha retrasado los plazos. Este caso se puede dar pero no mas de 2-3 veces al año. Si realmente es justificable incluso el cliente puede entenderlo y se puede hacer la entrega mas tarde.
Y si quien planifica no tiene ni idea es también responsabilidad de su jefe el tenerlo en nómina.
Así que cada uno acoquine con sus responsabilidades.
Esto es el dia a dia en esta profesión, en España claro.
Se confunde productividad con número de horas que se le echa. Y cuando les resuelves problemas que les estaban llevando semanas o meses, y tu lo arreglas en cuestión de horas o pocos dias, notas perfectamente como le quitan hierro al asunto. Esos problemas "gravísimos" hasta entonces y "dificilísimos" pasan a ser "tonterías" a sus ojos cuando tu se las resuelves de manera profesional.
Luego se echan la mano a la cabeza cuando les pides una subida de sueldo y te dicen que ya cobras por encima de la media, quizás un 20 o un 25%.
#7 Completamente de acuerdo contigo.
En la empresa donde yo trabajo es muy habitual incorporar a alguien de prácticas (para tener mano de obra barata, vamos) y tras varios años incorporando a gente con módulos de FP, han terminado por incorporar a gente únicamente que esté realizando la ingeniería técnica de informática.
La única ventaja que tienen los procedentes de FP es que son muy conformistas porque al trabajar con personas más cualificadas son conscientes de que más que pedir un aumento de sueldo, deben agradecer que no estén en la calle. Ojo, hablo de los estudiantes de FP becarios (y no becarios) que han pasado por mi actual empresa, no sé como estará el nivel en otro sitio.
#1: a mi me ha tardado pero ha acabado entrando.
Me parece un artículo muy interesante; curiosamente el autor menciona al final que dos de las habilidades que un buen programador debería poseer (capacidad de comunicación bidireccional y de trabajo en equipo) no son específicamente técnicas. Entonces, ¿éstas dónde se aprenden? ¿Son imprescindibles, se adquieren con la práctica, debería la Universidad preocuparse de fomentarlas?
El problema de la productividad generando software es unicamente de los pequeños. Las grandes empresas detectan los buenos y malos programadores muy rapidamente. En las grandes empresas se diseña el trabajo de programacion a 3 o 6 meses vista y se subdivide en trabajos de 2 o 3 dias. Hecho esto, conforme los programadores o los equipos van terminando los trabajos, se les van asignando nuevas tareas de la lista.
El resultado es muy sencillo. Al cabo de varios meses, hay programadores que han sacado adelante mas trabajos que otros. Se contabiliza todo el trabajo tecnico en hojas de excel, se realizan encuestas a todos los miembros del equipo para que evaluen a sus compañeros y se ajustan los sueldos de acuerdo a esos dos parametros. No hay forma de escapar.
De todas formas, no creo mucho en el valor del programador como trabajador aislado. Un programador sin soporte de un equipo no es gran cosa.
De todas formas, hay muchos programadores que trabajan solo 3.5 dias a la semana porque el Lunes aparecen con resaca y los Viernes por la tarde no paran de mandar SMS para preparar la borrachera. Lamentablemente conozco a unos cuantos de este perfil... De 10 a 28 programadores al precio de uno? Probablemente es una apreciacion benevolente y entusiasta, no?
#7, y eso pasa en casi todos los curros, no sólo en el de programador. Triste pero cierto.
#8 Sí, pero también deberías haber puesto una de esas ofertas de trabajo para frikis:
Oferta de trabajo: "Si tus amigos te llaman friki, probablemente quieras trabajar aquí"
Oferta de trabajo: "Si tus amigos te llaman f...
infojobs.net[Img] Infojobs ha muerto
[Img] Infojobs ha muerto
ihaveanidea.wordpress.comVa a ser que en vez de contratar a gente de letras como programadores van a necesita contratarlos para RRHH o para directivos
Relacionada:
Oferta de empleo de programador para psicólogos, pedagogos, historiadores... etc. ¡LAMENTABLE!
Oferta de empleo de programador para psicólogos, p...
sevilla.oferta.infojobs.net#16 A menos que la situación en la empresa sea muy crítica (no me meto en temas personales que son muy chungos) el problema que comentas se arregla rápido. Se trata de que cada uno haga su trabajo, el proyecto salga mal, tarde y/o caro y luego cuando se pidan explicaciones (suponiendo que haya jefes con los que se pueda hablar) se dejan las cosas claras. El proyecto no ha salido porque la oferta era incorrecta.
Que la persona que ha hecho la oferta de explicaciones. Si tu, como jefe de proyecto, sabes que has hecho bien tu trabajo y el programador sabe que ha hecho bien el suyo raro será que seais vosotros los que os la carguéis.
El problema si aceptas la situación que comentas es que sienta precedente y si el proyecto anterior que era parecido salio en 15 días el de ahora tiene que salir en 10 días porque es lo mismo y ya tenemos la experiencia previa. No hay que jugar a ese juego.
Y no te hablo de teoría, eso lo estoy aplicando en la empresa donde trabajo desde hace tiempo (dentro de mis limitaciones) y la reacción de los jefes de proyecto y de sus jefes no es tan mala como se podría esperar. Son gente que son capaces de entender los problemas y aprender.
Yo ahora me convertiré en una especie de jefe de proyecto pero para proyectos internos, sin clientes finales. Se que es distinto pero sin duda aplicaré estos conceptos que te comento.
#15 Supongo que así trabajarán en otros países, pero no en España...
#16 Dios te oiga con lo de que el trabajo se va a generalizar.
Yo apuesto, y deseo por lo mismo, pero no creo que el combustible y los atascos vayan a tener mucho que ver en que se tome esa decisión. Recuerda que esas cosas, tiempo y dinero de transporte, lo pagamos los pringados de los trabajadores. Tenemos "tarifa plana" al respecto. Así que eso, mientras a los jefes/empresarios no les duela, no les motivará.
Las nuevas generaciones adquieren los conocimientos que les iteresan a modo de los artistas del renacimiento. Que haya pocos con el titulo de ingeniería informática no quiere decir de ninguna manera que haya poca gente que no sepa programar, esta es una de esas tareas que se aprende por hobbie, no por nota.
#16 lo has clavao. Yo como programador estoy hasta las piiii de comerciales que no preguntan antes de presentar la oferta, con lo que los plazos tienden a ser desproporcionadamente cortos y encima, ganado el proyecto, la responsabilidad de acabar a tiempo es del currela de abajo (aquello de "no es culpa mía que no sepas hacer bien tu trabajo"), y así salen los proyectos luego, claro.
Pero lo que más me revienta es que tampoco le puedo echar la culpa al comercial, porque si va uno honrado, hace un estudio y ve que se tardará un año de trabajo por ejemplo, no se va a comer una rosca porque perderá el concurso ante el comercial sin escrúpulos que suelta aquello de "nuestro equipo es muy cualificado y esto te lo hacen en 6 meses". Que el mundo siga funcionando así es muy triste
#19 para mí lo difícil es encontrar un sitio en el que puedas hablar con los jefes. Por los sitios por los que he pasado lo normal es que los comerciales sean "amiguetes" de las altas instancias y el problema cuando algo no sale siempre acaba en el último mono. Dicho lo cual, ahora estoy en una empresa pequeña en la que se puede hablar con el jefe y es otro mundo.
#21 Ese comportamiento depende mucho del jefe, porque yo estuve en una pequeña que el gerente, jefe y comercial era la misma persona y no veas como tiraba de la cuerda.
#19, esa es la filosofía BOFH-Zen aplicada a desarrolladores
El bofh-zen
El bofh-zen
mundowdg.blogspot.comEste hecho lo conocen de sobras las consultoras, que contratan a los peores porque cobran por horas y les interesa que el software esté lleno de bugs y se dependa de ellos.
Con un criterio mínimo se podría evitar este hecho, pero el problema de fondo es que en España el 90% de los contratos se firman en los "putis" con cuatro copas de más.
Me contaba un amigo que trabajaba para una consultora del Banco Santader que llegaron a facturar 2500 Euros por tres días de trabajo. En esos 5 días lo único que hicieron fue un par de sentencias SQL... y estaban mal. Sobran los comentarios.
#22
Efectivamente, hablo de empresas importantes, de las que cotizan en Bolsa.
En España supongo que las grandes tambien lo hacen.
Bah, programar, programar, ¿a quién le interesa programar?
Estáis perdiendo el tiempo chavales, será posible, con la de ladrillos que quedan por poner...