Jul 01

Ser o no ser héroes

 

Imagínate que caes en un equipo de desarrollo con gente competente, que saben lo que hacen y lo hacen bien. Tienes además la suerte de que el jefe de proyecto para el que trabajas también es un buen jefe de proyecto. Sabe lo que quiere, se lo cuenta al equipo con claridad y trata de resolver todos los problemas que se presenten. ¿Qué pasa en esta situación?. Lo normal. El proyecto va bien, sin problemas graves, llega a tiempo a sus fechas de entrega con unas incidencias razonables y sin fallos graves.

Suponte ahora lo contrario. Un proyecto en el que el jefe de proyecto no tiene claro lo que quiere, no te especifica nada, no te dice como lo quiere, pero sí te dice cuando ya los has hecho que así no lo quería. Además, el grupo de desarrolladores es más bien de la media para abajo, el poco código que sale está lleno de errores y si funciona, es de casualidad. ¿Qué pasa en esta situación? Pues lo normal, que el proyecto va mal, que no llega en fechas, que cuando se pasan las pruebas con cliente todo es un "efecto demo" gigante.

Entre los dos proyectos hay además una consecuencia interesante. En el primer caso, los jefes del jefe de proyecto apenas saben que existe ese proyecto. Es un proyecto que no da pegas, que no gasta más dinero de la cuenta, que no se retrasa y que no recibe quejas del cliente, así que la cosa "no sube" hacia arriba, así que para ellos no es más que una cifra bonita en alguna tabla de Excel.

En el segundo caso, empiezan a dispararse las alarmas, los jefes del jefe empiezan a recibir los problemas de dinero, fechas y quejas del cliente. Empiezan a saber que ese proyecto existe y empiezan a hacerle un seguimiento exhaustivo día a día. Se empieza a hacer presión y los desarrolladores y jefe de proyecto empiezan a echar horas como locos y se olvidan de que tienen casa.

En el primer proyecto, el buen jefe de proyecto y los buenos desarrolladores han hecho estupendamente su trabajo, pero no se les ha notado ni los jefes los van a valorar en lo que merecen. En resumen, "no son héroes".

En el segundo proyecto, si después de echar muchos fines de semana y horas a tope se consigue que el proyecto pase como se pueda, con un listado interminable de incidencias y cosas pendientes, con el cliente descontento, pero pasa, entonces los que han participado en él son la leche, han hecho un esfuerzo sobrehumano y han conseguido sacar adelante un proyecto que era un caos. Gracias a esto, los jefes de proyecto ya conocen las caras de los desarrolladores y del jefe de proyecto. Por supuesto, se han creído todas las excusas que el jefe de proyecto y los desarrolladores les han dado para justificar que el proyecto va mal. En resumen, "Sí son héroes".

Desgraciadamente, es la realidad. Se valora más al desarrollador que echa horas y horas resolviendo problemas en un proyecto caótico, que al desarrollador que no resuelve problemas a horas intempestivas de la noche, símplemente porque no ha generado esos problemas.

Entradas relacionadas:

12 Responses to “Ser o no ser héroes”

  1. schan Says:

    Totalmente de acuerdo contigo. Lo único malo de la indiferencia es el hecho que también afecta al salario.

  2. Black Hole Says:

    Lo que cuentas es algo que he vivido ya unas cuantas veces y tienes toda la razón, siempre se repite y siempre con el mismo resultado: los que lo hacen mal son los que tienen la publicidad y el mérito, el resto… ¿quienes son?

  3. Gps1mx Says:

    Un buen amigo me enseñó un día que no solo hay que saber poner el huevo, hay que saber cacarearlo (hay que saber vanagloriarse) 😀

  4. atreyu Says:

    mmm no estoy del todo de acuerdo, al final los jefes de los jefes, no quieren “sufrir” los inconvenientes de un mal desarrollo tras otro. Tal vez en los primeros si que surta ese efecto pero al final si proyecto tras proyecto deben aguantar las quejas de los clientes y sobre todo se dan cuenta que tras entregar el proyecto los problemas de mantenimiento y correcion son todavia peores que los de desarrollo empezaran a mosquearse y a valorar los proyectos silenciosos que no les dan dolores de cabeza.

    Y si no se dan cuenta de eso al negocio pocos dias le quedan.

  5. Jorge Says:

    Totalmente de acuerdo con atreyu. Aunque bueno como todavia no trabajo en una empresa grande con proyectos relativamente grandes e importantes pues se podria decir que no tengo la experiencia para opinar, pero en cuanto a experiencia en desarrollo en grupo en las universidades no vamos a decir que buscamos a los mas ineptos para hacer algun proyecto, se busca a los mas capaces, y los ineptos van quedandose solos y caen por su propio peso.

  6. Chuidiang Says:

    Hombre, me refiero a empresas grandes, en las que los que deciden los sueldos no son los mismos que eligen a las personas para los proyectos, porque ni siquiera conocen a las personas. Sólo les ven las caras cuando un proyecto va mal y ven el enorme esfuerzo (merecedor de recompensa) que están realizando.

  7. R Says:

    Creo que te equivocas.
    Una vez me toco un proyecto parecido, con la salvedad de que 2 o 3 si sabiamos y tuvimos que ‘hacerla de heroes’, con muchas horas pero bien aprovechadas corrigiendo los errores de otros. El proyecto claro, se salio de costos y todo, pero el cliente quedo super satisfecho, por que lo entregamos bien a tiempo y creo que nos vio trabajar. Es decir el proyecto salio bien, aunque a la empresa le costo, pero para el cliente fue transparente, con la salvedad de que algunos tuvimos que esforzarnos mucho para eso.
    Claro que los jefes, aunque te reganen y todo por hacer horas extra, saben quien sabe y quien no, quien trabaja y quien no, quien lo hace bien y quien no.
    Desde entonces he estado en proyectos mejores, y fiel a mi politica nunca hago horas extra.
    Por motivo de ese proyecto y otras cosas tuve algunos roces con mi jefe, pero auque fui el mas reganado, o sorpresa cuando se trato de aumentos de sueldo me aumentaron mas que a los demas que estuvieron en el mismo proyecto.
    Eso demuestra que aunque te reganen hay jefes que si se fijan quien trabaja bien. Si no que harian? Tienen que cuidarte, no son tan estupidos.
    Ahora ya casi nunca hago horas extra, pero entrego todo bien a tiempo,y sigo siendo al que mas le aumentan.
    Las cosas caen por su propio peso.

  8. Ser o no ser heroes « Programación, tecnología, humor, curiosidades… Says:

    […] o no ser heroes 5 07 2009 “Ser o no ser heroes”. Así se titula el post que me encontré en el blog Diario de programación, el cual me parece muy bueno y que refleja la […]

  9. La cruda realidad… La cuestión de ser o no ser Héroes | Spargo.Net Says:

    […] el diario de programacion, encontre este articulo la verdad estoy totalmente de acuerdo y aunque es triste es la cruda […]

  10. JoTGi Says:

    Una reflexión que realmente no me la había planteado nunca desde este punto de vista. La realidad es dura, y sí que es verdad que muchos sobresalen cuando realmente no valen tanto, pero realmente no sé si es por ése tipo de proyectos.

    Lo que planteas puede ser verdad en algún tipo de empresas, si pasa una vez, dos, o tres, pero personalmente creo que, si fuera empresario con trabajadores y equipos a mi cargo, vería el trabajo que hacen unos y otros, los que provocan problemas y los que no, quién necesita hacer horas extras y quién no las necesita.

    Un proyecto puede ser difícil, se puede complicar, se puede salir del presupuesto inicial, incluso de la temporización acordada con el cliente. Pero si todos los proyectos de un mismo equipo son así, personalmente creo que más bien debe ser que el proyecto no está bien planificado, presupuestado y temporizado. ¿Quizá sea problema del equipo que está planificando el proyecto, no?

  11. Ser o no ser heroes: Programadores en el trabajo | Noticias de tecnologia, programacion y mas Says:

    […] o no ser heroes”. Así se titula el post que me encontré en el blog Diario de programación, el cual me parece muy bueno y que refleja la […]

  12. Valorando a un desarrollador | Blog personal de Bryan García Says:

    […] (Visto en Diario de Programación) […]

Leave a Reply