Hechar horas
Leyendo un post de hace unos días en Cyberf ,aqui, me recuerda una "batalla" que he tenido siempre con mis jefes, clientes, empleados, etc. el tema de facturar, cobrar, vender "horas".
Ahora que estoy en el bando de "los jefes" entiendo porque se hace, hay varios motivos:
Comodidad, me explico, controlar horas es fácil, entras a las 09:00 y sales a las 14:00, son cinco horas.
Igualdad, cinco horas son cinco horas para todo el mundo, medimos a todos con la misma medida.
Cultura, la gente está acostumbrada a trabajar dentro de un horario, de hecho obligan a las empresas a tener el calendario laboral donde se especifica el horario de trabajo.
Ojo, no digo que esté de acuerdo con esto, sino que ahora lo comprendo. Controlar el trabajo mediante horas y horarios es más cómodo y sencillo para todos, controlar el trabajo por objetivos implica que el jefe debe entender lo que hacen los empleados, deben existir indicadores claros del trabajo realizado y tanto la empresa como los trabajadores deben aceptar el retribuir/cobrar de forma variable, a tanto trabajo realizado tanto dinero, y eso es complicado.
Al implementar un sistema de retribución por objetivos hay que ir con mucho cuidado de retribuir a quien haya que hacerlo y no que unos se tapen con la manta de otros. Los objetivos deben ser claros, medibles y que no entren valoraciones personales, sólo trabajo realizado, teniendo en cuenta los factores de cantidad y calidad. Los objetivos deben entenderlos, comprenderlos y aceptarlos, tanto los que realizan el trabajo como quienes lo controlan.
En el desarrollo de software no me gustan los objetivos que se basan en la cantidad de líneas, lo encuentro absurdo, es como pagar al albañil por ladrillos colocados, cuando lo que debe hacer son metros de muro, suena parecido, pero no es lo mismo. Si un programador es más eficaz reutilizando código y con menos líneas resuelve un problema, ¿debe cobrar menos, según la cantidad de líneas? Al revés, porque al haber escrito poco seguramente habrá introducido menos errores en el código.
Mucho mejor veo un combinado de número de errores introducidos (cuantos menos mejor), dificultad de la tarea (establecer un sistema de puntuación/pesos/ponderación) y cumplir con las fechas. Es importante el establecer unos objetivos de grupo y unos personales, de forma que se recompense tanto los resultados globales como los particulares.
Claro que para medir todo eso, no se puede hacer de forma manual, hay que tener unas herramientas que lo controlen de forma automática y, a ser posible, integradas dentro del entorno de desarrollo.
Nosotros de momento continuamos buscando la mejor forma de hacerlo.
Ahora que estoy en el bando de "los jefes" entiendo porque se hace, hay varios motivos:
Comodidad, me explico, controlar horas es fácil, entras a las 09:00 y sales a las 14:00, son cinco horas.
Igualdad, cinco horas son cinco horas para todo el mundo, medimos a todos con la misma medida.
Cultura, la gente está acostumbrada a trabajar dentro de un horario, de hecho obligan a las empresas a tener el calendario laboral donde se especifica el horario de trabajo.
Ojo, no digo que esté de acuerdo con esto, sino que ahora lo comprendo. Controlar el trabajo mediante horas y horarios es más cómodo y sencillo para todos, controlar el trabajo por objetivos implica que el jefe debe entender lo que hacen los empleados, deben existir indicadores claros del trabajo realizado y tanto la empresa como los trabajadores deben aceptar el retribuir/cobrar de forma variable, a tanto trabajo realizado tanto dinero, y eso es complicado.
Al implementar un sistema de retribución por objetivos hay que ir con mucho cuidado de retribuir a quien haya que hacerlo y no que unos se tapen con la manta de otros. Los objetivos deben ser claros, medibles y que no entren valoraciones personales, sólo trabajo realizado, teniendo en cuenta los factores de cantidad y calidad. Los objetivos deben entenderlos, comprenderlos y aceptarlos, tanto los que realizan el trabajo como quienes lo controlan.
En el desarrollo de software no me gustan los objetivos que se basan en la cantidad de líneas, lo encuentro absurdo, es como pagar al albañil por ladrillos colocados, cuando lo que debe hacer son metros de muro, suena parecido, pero no es lo mismo. Si un programador es más eficaz reutilizando código y con menos líneas resuelve un problema, ¿debe cobrar menos, según la cantidad de líneas? Al revés, porque al haber escrito poco seguramente habrá introducido menos errores en el código.
Mucho mejor veo un combinado de número de errores introducidos (cuantos menos mejor), dificultad de la tarea (establecer un sistema de puntuación/pesos/ponderación) y cumplir con las fechas. Es importante el establecer unos objetivos de grupo y unos personales, de forma que se recompense tanto los resultados globales como los particulares.
Claro que para medir todo eso, no se puede hacer de forma manual, hay que tener unas herramientas que lo controlen de forma automática y, a ser posible, integradas dentro del entorno de desarrollo.
Nosotros de momento continuamos buscando la mejor forma de hacerlo.
3 comentarios
Fernando -
Anónimo -
Lucas Rodríguez -
Supongo que es más fácil hablar sobre ello que implantarlo.
¿álguien tiene alguna experiencia real sobre este tema? Me gustaría conocer las opiniones de aquellos que han intentado llevar a la práctica algo similar.
Lucas Rodríguez Cervera