Buscar
Social
IntelliJ IDEA

Contenido de otras web
« OSUM, la red social universitaria de Sun Microsystems, cierra el 1 de diciembre | Main | Entrevista a Howard Lewis Ship sobre Tapestry en DevRates »
martes
nov202012

Trabajar muchas horas disminuye la productividad

El viernes pasado asistí al evento de Big Data Spain, a la organización del cual javaHispano ha aportado un granito de arena. Después del evento tuve el placer de asistir a una cena con los ponentes. Uno de ellos, dueño de su propia empresa de desarrollo de software, me comentó durante la cena que unos pocos años atrás había tenido que reorganizar la empresa porque no estaban cumpliendo objetivos. Ahora había conseguido resolver este problema, y una de las claves para conseguirlo fue obligar a que la gente trabajase menos horas.

Según él, lo realmente importante es la calidad de esas horas, y no la cantidad. Hay que trabajar de modo inteligente, y no mucho. Y si trabajamos mucho, vamos a terminar haciendo las cosas mal, como por ejemplo, introduciendo un montón de bugs en el código (uno de los problemas que ellos tenían).

Esta idea que él me transmitió es la misma que se presenta en este artículo de Johanna Rothman: Management Myth #10: I Can Measure the Work by the Time People Spend at Work. Ella incluso nos propone una estrategia para convencer a nuestro jefe si no cree que esto sea cierto: probar en un experimento.

El experimento consiste en trabajar un par de semanas 40 horas, sin permitir a nadie hacer más horas. Y después trabajar dos semanas un mayor número de horas (50, 60, lo que quieras). Y cuantificar los resultados, medidos por ejemplo en el número de "story-points" implementados.

El experimento que Johanna Rothman propone es, cuanto menos, interesante. Aunque no fácil de llevar a cabo. Desde luego, parece tener sentido que en un trabajo creativo es necesario tener un cerebro fresco para poder hacer un buen trabajo, y el número de horas dedicadas no tiene por qué ser proporcionar a lo que se produzca. En un trabajo no creativo probablemente si hay más correlación entre el número de horas dedicadas y el resultado.

Por ejemplo, si nuestro trabajo es poner ladrillos en una pared, probablemente cuantas más horas dediquemos más ladrillos pondremos. Pero si nuestro trabajo es hacer una obra de arte, no necesariamente cuantas más horas metamos mejor va a ser la obra de arte. Programar es, por norma general, un trabajo creativo más parecido a concebir obras de arte que a poner ladrillos en una pared.

¿Estais de acuerdo en que en el mundo de la programación trabajar más horas no significa producir más? ¿Alguno va a intentar hacer el experimento de Johanna ?

Aprovechemos la ocasión para hacer una pequeña encuesta sobre este tema:

http://www.jrothman.com/blog/mpd/2012/11/working-long-rethink-why.html

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (27)

En muchas ocasiones queremos "adelantar" trabajo, quedándonos más Horas en la ofina o delante del PC pensando que así seremos más productivos, cuando en realidad, todos sabemos que nuestro cerebro se satura y que llega un momento en el que hacer la tarea más sencilla conlleva mucho tiempo. Así que lo más eficiente es decir "hasta mañana a las 8".

noviembre 20, 2012 | Unregistered CommenterJ Carlos

Hay un pequeño error en la encuesta, la 4ª opción debería ser 40-45

noviembre 20, 2012 | Unregistered CommenterDavid

¿Donde esta el rango de 40 a 46? ;)

noviembre 20, 2012 | Unregistered Commenterjosejuan.montiel

Corregido, ya tenemos el rango de 41-45

noviembre 20, 2012 | Registered CommenterAbraham

Sólo una apreciación, de forma PUNTUAL echar alguna hora más si puede servir para hacer más trabajo. Por ejemplo antes de un determinado deadline o quizás arreglando algún bug de esos misteriosos. El problema es que esto que puede servir puntualmente no es sostenible, te puedes cargar el equipo por culpa del sobre-esfuerzo y poner en riesgo un proyecto de meses o incluso años sólo por querer "arañar" una funcionalidad más, y esto no parece muy inteligente.

Se necesita tranquilidad y mente despejada para hacer un trabajo de la complejidad del nuestro. De todos modos, esto no es precisamente nada nuevo, por ejemplo eXtreme programing incluye como una de sus 12 prácticas fundamentales lo que llaman "sustainable pace" es apañol, ritmo sostenible.

Dicho esto, los clientes siempre van a querer todo bueno, bonito y barato, nuestro trabajo tambien consiste en explicar al cliente que se necesita X tiempo o en buscar alternativas (normalmente priorizando como dios manda y eliminando funcionalidades no tan importantes para una siguiente versión) junto con el cliente para que el pueda cumplir sus metas y nosotros podamos hacer nuestro trabajo de un modo racional sin meternos en locuras. Hay veces que lo consigo y veces que me arrastran a la locura, pero poco a poco voy consiguiendolo más a menudo :P

noviembre 20, 2012 | Registered Commenteralfredocasado

creo que las personas que trabajan más de 40 horas "voluntariamente" no van a tener tiempo de rellenar esta encuesta ;o)

Manolo! coñe, qué haces otra vez mirando el facebook!! a currar de una p*** vez HOMBRE YA, que son sólo las 21.30...

noviembre 20, 2012 | Unregistered CommenterPerry Mason

Exijo a Abraham que diga quien era el susodicho dueño, quien sabe... xD

Las personas son como los coches (toma ya), tienen su punto óptimo, un "buen coche" usado normalmente en su punto óptimo, consume poco y dura muchos años, pero si se le fuerza a circular continuamente a velocidades significativamente por encima de su punto óptimo pues aparte de consumir un montón (consumo/kilómetro recorrido) su vida útil será mucho menor.

Si valoramos por puro interés económico qué modo de funcionamiento ha sido más rentable en cuanto a consumo de combustible dado un número de kilómetros recorridos y duración en años, el resultado es claro.

En pocas palabras, la cuerda cuando se tensa mucho por muy buena que sea... se rompe.

Pues esto tiene mucho que ver con el mundo de desarrollo software, la dichosa comparación con el obrero que pone ladrillos (con todo el respeto) sigue estando en la mente de muchos, yo desde hace tiempo uso una analogía diferente, yo considero más al PROGRAMADOR (así con letras grandes) más como una mezcla de CIRUJANO y ARTISTA (así con letras grandes).

Cirujano porque el desarrollo software puede ser COMPLICADO DE LA OSTIA (perdón por la frase muy made in Spain), sobre todo hacerlo bien. Lo curioso es que un cirujano, profesión normalmente bastante hipervalorada (y no le quito razón sobre todo porque actúa sobre personas), hace lo mismo una y otra vez, las cirugías son básicamente siempre las mismas (vale no idénticas) y la posibilidad de "reutilización" de una cirugía para la siguiente pues no da mucho de sí, por eso la analogía con el cirujano no es del todo completa y por eso el programador tiene algo de artista, porque el desarrollo software es creativo por obligación, no hay dos problemas exactamente iguales (en cirugía sí hay operaciones prácticamente iguales), pues si lo fueran haríamos "copy & paste" o crearíamos un super-conjunto.

Pues de igual manera que un cirujano puede hacer verdaderas carnicerías por el exceso de horas o por amateurismo (o por las dos cosas), lo mismo pasa en el desarrollo software, un cirujano puede hacer perder vidas, un programador puede hacer perder mucho dinero.

No conozco que exista una tendencia de cirujanos que a los tres años de ejercer la cirugía se pasen a vender seguros. En el mundo del desarrollo software eso ocurre todos los días...

Dejo aquí el tema que tengo hoy un problema de mil demonios de concurrencia de hilos y de inyección asíncrona de código JavaScript desde Java a un WebKit que tiene que esperar a que se cargue la página con el fin de resolver la posición visual de un nodo DOM cualquiera en donde a veces WebKit me dice que "ahora no puedo dártela" inexplicablemente si el nodo cae en la primera parte del documento... ¿Tenéis algún amigo cirujano que a lo mejor me pueda echar una mano...? XD

noviembre 21, 2012 | Registered Commenterjmarranz

@jmarranz como entenderás, no estaría bien decir públicamente los detalles de una conversación privada ;)

Me ha hecho gracia que tu hagas una analogía con la conducción de coches :P

Ánimo con el problema de concurrencia

noviembre 21, 2012 | Registered CommenterAbraham

José María, seguro que unos cuantos cirujanos te han puesto una vela negra :P los artistas no, porque no saben que existimos

Yo no soy mucho de comparar curros porque todos tienen sus méritos. Intenté levantar un muro de 1x1m de ladrillos, resultado penoso y eso que soy un manitas :)

Respecto el tema de la entrada, desde mi punto de vista no hay dudas, el cociente produción/numeroHoras es una parábola invertida que hasta cierno numero de horas aumenta y de un punto en adelante decrece. Y para liarlo más ese máximo es variable. Pero nuestros horaríos suelen ser fijos con tendencia a crecer y nuestro trabajo incomprendido.

noviembre 21, 2012 | Registered Commenterrobertiano

Las comparaciones habría que hacerlas con cuidado, por que luego pasa lo que pasa. Lo que queda claro es que Mr. Maligno no es cirujano ni conoce mucho la profesión ;).

noviembre 21, 2012 | Unregistered CommenterKomorr

robertiano se necesitan al menos "dos velas negras" para que sean efectivas :)

Komorr joer que fama me ha creado David Bonilla con lo de Mr. Maligno (que él lo dice con aprecio que lo se), quien me conoce más de cerca sabe que "mi maldad" apenas pasa del mundo de las ideas :)

Sin llegar a absurdos y en plan constructivo ¿en qué crees que conceptualmente la cirugía, como disciplina que requiere unos conocimientos y unas habilidades, no es extrapolable al desarrollo software (más allá de tratar con humanos)?

noviembre 21, 2012 | Registered Commenterjmarranz

Por cierto, @jmarranz, por si te interesa, el ponente en cuestión no era "nacional" ;) Seguramente en España hay poca gente que para resolver problemas en la empresa se le ocurra obligar a sus empleados a trabajar menos.

noviembre 21, 2012 | Registered CommenterAbraham

Esto de trabajar por objetivos en una actividad que tiene tanto de artesanal como de intelectual, y sin que la gente haga un quiebre... bueno, tiene su pega.

Lo peor de todo es que resulta difícil saber de antemano cuando y de que forma la gente va a quebrarse. Se de alguien que terminó en una habitación acolchada repitiendo el nombre del jefe.

Es allí donde las metodologías y una buena planeación deberían venir al rescate (tanto en sistemas como en el resto de las ramas de la ingeniería).

En cuanto a la comparativa con los cirujanos, yo disiento.
En especial pensando en aquellos de nosotros que tenemos algo que ver con automatización e integración industrial. No solo interactuamos con el "mundo real", sino que un error (ya sea de diseño o de implementación), "potencialmente" puede provocar accidentes fatales.

noviembre 21, 2012 | Registered Commenterefrigerio

Me mola este portal

noviembre 21, 2012 | Registered Commenterjcarmonaloeches

A mi tampoco me gustan las analogías con otras profesiones, la analogía con la construcción nos ha llevado por muy mal camino, ni una más.

Sobre la responsabilidad y tal, el mundo en el que vivimos esta cada día que pasa más regido por normas y logica escrita en código fuente que por ninguna otra cosa. Si nos conceden una hipoteca, si nos aplican descuento en un supermercado, si nos dan nuestro billete de avion, si nos dan cita para una operación, si... y podría seguir indefinidamente.

La reflexión es si queremos que las reglas que rigen nuestro mundo las escriban 4 recien licenciados que trabajan 14 horas diarias + algún fin de semana por mil y pico euros al mes, esto es lo que me preocupa...

noviembre 21, 2012 | Registered Commenteralfredocasado

El post refleja una realidad sufrida y conocida por todos. Incluyendos muchos jefes de proyecto y responsables de IT que las fuerzan.
Si la empresa desarrolla sus propios productos puede tomar este tipo de medidas, ya que no tiene a un cliente esperando una entrega. Pero las empresas que desarrollan a medida a menudo piden horas extras para poder venderle el sobreesfuerzo al cliente y gestionar retrasos, malas estimaciones, problemas de calidad, etc... En este caso no se busca un incremento de la productividad si no una acción comercial y eso es mas complicado de resolver.

noviembre 22, 2012 | Unregistered CommenterLuis

Alfredo la verdad es que mi interés no está en "jugar a los médicos" o jugar a hacer estúpidos y ociosos ejercicios intelectuales (en España se llaman "p.... mentales"), no tengo tiempo para eso :)

"En pocas palabras, la cuerda cuando se tensa mucho por muy buena que sea... se rompe."

"No conozco que exista una tendencia de cirujanos que a los tres años de ejercer la cirugía se pasen a vender seguros. En el mundo del desarrollo software eso ocurre todos los días..."

En el fondo estamos hablando de lo mismo...

noviembre 22, 2012 | Registered Commenterjmarranz

Esto me recuerda que cuanto más adelanté en mi tesis doctoral (simulaciones numéricas que había que programar) fue al principio cuando no cobraba un duro y me negaba a estar más tarde de las 3.
Luego en el postdoc me quedaba a veces hasta las 11 de la noche sin conseguir encontrar el bug, cosa que conseguía hacer a la mañana siguiente en 5 minutos.

noviembre 22, 2012 | Unregistered Commenterfísico

Solo quiero aportar mi granito de arena como administrador de sistemas: este experimento ya está más que probado y se llama "horario de verano". En mi ex-empresa demostramos como en 7 horas al día en verano hacíamos no el mismo, sino más trabajo que con el horario de invierno (8:30 horas + 1:30 horas obligatorias de comida). El secreto era que se trabajaba del tirón, como en otros países (solo he probado el Reino Unido, pero era igual). Cierto es que durante el horario de trabajo había más estrés, pero también había más relajación una vez que salías por la puerta porque tenías más horas para disfrutar del resto del día.

No justifico jamás el tiempo extraordinario en un proyecto de desarrollo: indica mala planificación. En soporte suele haber trabajo a turnos y raramente puedo justificar ese tiempo extraordinario dado que siempre hay alguien que cubra el problema; quizá en caso de una incidencia grave que afecte a la producción, pero solo si se remunera y si no depende de una mala planificación previa por parte de algún nivel superior (las cuales se suelen advertir y por desgracia también se suelen ignorar por parte de los responsables).

noviembre 22, 2012 | Unregistered CommenterRoberto

Atención, que entra el abogado del diablo.

No exageremos, que dáis un punto de vista exagerado:

1) Trabajar 40 horas a lo máximo es lo que hay que hacer, salvo cuando el jefe la lía o hay que cubrirle y si te da la gana, le cubres y luego buscas un hueco y se lo recuerdas. Eso pasa en todos lados. No seáis dramáticos. Si que puedo ver competenecia ilegal en empresas consultoras exageradas, de las que no daré nombres. Al igual que pienso que los chinos compiten con los fruteros y no tienen competencia, o los americanos, sin horarios, nos dan una paliza en competencia y no podemos hacer nada.... en fin, pero el hecho de que busquemos la comodidad, sinceramente, creo que puede generar que nos acomodemos y eso es algo malo, desde mi punto de vista. La vida es guerra continua.

2) Con respecto al tema del salario, creo que nuestra profesión está en inferioridad de condiciones con respecto a otros sectores y nos han tomado el pelo, en eso estoy de acuerdo. Unidos les podemos plantar cara, es lo de siempre. En informática no existe unión, de momento, y estamos condicionados a terceros.

3) Tenemos convenios que regulan la profesión, al igual que otras. Siempre se puede hacer uso de esos convenios para defenderse uno.

4) Nuestra profesión, por suerte, no está tan inflada como otras profesiones, véase banca, medicina, o el caso de Iberia. ¿La ventaja? Si te echan de un sitio te mueves a otro. Es una profesión nueva, acaba de crecer. Ya se corromperá o ya entrarán vicios más adelante, como el tema del salario que comentáis, que lo único que va a generar es ruina para la profesión, a costa del enriquecimiento personal, que vuestros ojos parece que no ven el bien común y si el individual.

5) En Madrid existe un colegio informático (llamado www.ali.es), del que ya iremos hablando en este portal, pues tiene iniciativas interesantes. ¿Alguien pueda dar opinión sobre el colegio?

6) El entrenamiento es bueno, en cualquier caso. Un sobreesfuerzo de 12 horas siempre tiene un trabajo mental hecho, aunque ese día no arregles, te sirve para aprender en días posteriores.

Creo que aquí hay mucho comodón... la verdad. Y no me gusta ese camino. Que queréis que os diga. Nos limita la libertad y la posibilidad de participar, de manera libre, en una profesión que es nueva y nos da de comer.

Por otro lado, en España creo que manda: política, banca e Iglesia. La informática no manda, está condicionada a lo que quieran los otros sectores. Es decir, no tenemos criterio propio, somos currantes para otros. Yo me veo más como un obrero currante para empresario que otra cosa.

Mi profesión y mis estudios no se respetan, se respeta que saque el trabajo adelante. En mi caso, en vez de ser Ingeniero, podría haber sacado un módulo y me hubiera bastado.

Es más: bastantes jefes que he conocido, muchos, no tienen carrera. Eso sí que mola. Ahora bien, pienso que todo en esta vida tiene recompensa y castigo, tarde o temprano. Y todo tiene su época y su recompensa. Si buscáis la comodidad a corto plazo será a costa de otras felicides que ahora no podéis ver (y que a mí me pasa como a vosotros, no os creáis)

Es un punto de vista más, un saludo

noviembre 22, 2012 | Registered Commenterjcarmonaloeches

Tienes mucha razon en tu articulo, antes trabajaba en Spain y podria facil echar a veces mas de 9 o 10 horas al dia, lo importante era terminar el trabajo fuese como fuese, eso hacia que surgieran a la larga problemas o bugs que no se habian tenido en cuenta. Ahora he cambiado de trabajo y actualmente lo hago en UK en el que las horas de trabajo son 7.5 al dia y le dan mas importancia a la calidad realizando TDD, Scrum y pair programming.

noviembre 22, 2012 | Unregistered CommenterJC

Jose maria: estoy de acuerdo en todo lo que has dicho, simplemente que por (malas) experiencias previas prefiero argumentar sin usar analogías con otras profesiones, sólo eso, sabes que en el resto estamos muy de acuerdo.

Jaime: no se de donde te sacas lo de "comodones", no se trata de currar menos, se trata de currar mejor. Se trata de evaluar a la gente no por el número de horas que tiene el culo en un asiento sino por lo que es capaz de producir. La cuestión es que sin un ritmo sostenible es muy difícil producir buen software y el costo de los errores en software es elevadisimo. Por eso menos es más y por eso es tan dificil de entender para quien no comprende la verdadera naturaleza del desarrollo de software (algo habitual entre los jerifaltes de muchas empresas cercanas)

Me sorprende esta frase:

"Mi profesión y mis estudios no se respetan, se respeta que saque el trabajo adelante."

Por supuesto amigo!, el como hayas obtenido tus conocimientos no tiene absolutamente ninguna relevancia, lo único que importa es que sabes hacer, estaría bueno!. Y más en el mundo actual donde cualquiera puede aprender por su cuenta si tienes ganas y el talento necesario. Tener una carrera no debería otorgarte ningún privilegio sobre nadie, tus privilegios te los tendrás que ganar demostrando tus conocimientos. (y como siempre que digo esto aclaro, soy ingeniero informatico, he dado muchos años clases en la universidad, yo elegi ese camino, pero hay otros igual de validos).

noviembre 22, 2012 | Registered Commenteralfredocasado

En Europa se realizan jornadas laborales de 6 horas con mesa de ping pong para los descansos. Aquí echamos 14 horas cueste lo que cueste y rindan lo que rindan...

noviembre 22, 2012 | Unregistered CommenterRedvolucionarios

Comparto la crítica de que en España no se valora la calidad del software, ni la calidad de pruebas, y eso es un problema para la profesión. Y el mayor mal de todos, desde mi punto de vista, el amiguismo

noviembre 23, 2012 | Registered Commenterjcarmonaloeches

Jaime,
Estoy seguro que ya lo sabes, pero lo que describes, no es un problema exclusivo de España, ni siquiera es exclusivo de los países de habla castellana.

:)

noviembre 23, 2012 | Registered Commenterefrigerio

@jmarranza (a.k.a. Mr. Maligno) Lo digo por lo de "profesión hipervalorada", como si fuera excesivo, lo de "hace lo mismo una y otra vez,", "las cirugías son básicamente siempre las mismas" etc. y lo de que, al fin y al cabo, es lo mismo lo que uno "pierde dinero" y el otro "pierde vidas". Casi nada.

Teniendo en cuenta además que para ser cirujano has de estudiar "algún añito" más que para ser informático, ojo que no es solo estudiar medicina eh?, y que no puedes ejercer legalmente sin titulación...

Pues que no le veo la similitud, la verdad.

Y volviendo al tema general, yo lo siento pero cuando leo eso de "no queremos echar horas por que somos unos comodones" me descojono. Y eso de que en Europa las jornadas son de 6 horas con mesas de ping pong y en estados unidos todos cobran una pasa y les tratan de VIP... hay que ver lo que flipa la gente. Que no, gente, que un artículo en Internet de algo que pasa en un sitio no quiere decir que TODO sea así fuera. Que no es que estemos cojonudamente aquí, pero dejad de soñar con que la lechera vive al otro lado de la frontera. Nadie regalada nada.

noviembre 23, 2012 | Unregistered CommenterKomorr

Joder komor, que tio mas sensato, despues de las pajas mentales que nos hemos hecho es lo mas sensato que he oido. En serio tio. Eduardo gracias por el feedback, aqui el amiguismo se ha introducido en todas partes, cuando lo que de verdad funciona, que ya lo dijo Jesus, es servir a todos y recibir plos de manera continua. Eso si ue es digno, no el amiguismo. Ni los premios, ni la vanidad. El sacrificio y no el comodismo que proponen algunos y que les llevara por caminos materialistas y muchos peores que los de la pobreza. No os flipeis

noviembre 23, 2012 | Registered Commenterjcarmonaloeches

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>