2236
www.variablenotfound.com/2007/07/entre-10-y-28-desarrolla... Se ha creado un cierto revuelo sobre si hay o no programadores en España y, en este caso, los posibles motivos, entre los que destaca el bajo salario que las empresas están dispuestas a invertir en tener a desarrolladores cualificados. En este post se detallan algunas de las características y habilidades que, de poseerlas, hacen que un profesional pueda llegar a producir, según algunas fuentes, hasta 28 veces más que otros.
menéame
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?
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 » ver todo el comentario
meneame.net/story/oferta-empleo-programador-para-psicologos-pedagogos-
Estáis perdiendo el tiempo chavales, será posible, con la de ladrillos que quedan por poner...
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.
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.
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?
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.
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.
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.
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
Efectivamente, hablo de empresas importantes, de las que cotizan en Bolsa.
En España supongo que las grandes tambien lo hacen.
meneame.net/story/el-bofh-zen