Llevo tiempo pensando que quizás retribuir a un programador por horas es tirar el dinero. Esto no quiere decir que sea algo bueno o malo. Hay programadores de todo tipo. Los hay que cada hora pagada está invertida provechosamente para la empresa y también lo contrario. Pero, ¿realmente es buena idea pagar por esa hora? ¿No hay otra forma mejor?
Ejemplo de procrastinación: El Pintor
Pongamos como ejemplo que haya pintores que cobren por horas en lugar de por metros pintados o por trabajo completo a realizar. Si un pintor tiene que pintar una pared de 20 metros cuadrados, para la cual sabe que puede tardar unas 2 horas, puede que trabaje una hora, pare para tomar algo, prepare de forma calmada y lenta su equipo, y trabaje después la segunda hora, habiendo echado, finalmente unas 4 ó 5 horas, quizás incluso las 8 horas que son el día laboral normal de cualquier persona.
El pintor cobrará entonces por 8 horas, en lugar de 2 horas que ha sido su trabajo real. Es más, si el trabajo fuese de 200 metros cuadrados, sabiendo que son 20 horas, quizás en ese momento, por procrastinación, los primeros días no hace gran cosa, y cuando va viendo que quien lo contrató comienza a estar con la mosca detrás de la oreja, entonces trabaja bien las últimas 10 horas que le queden, habiendo hecho un trabajo de tres días (todos tenemos derecho a nuestros descansos) en cinco días.
Por ello, estos profesionales, por costumbre (que no de mala fe), acostumbrarán a posponer el trabajo en el tiempo (procrastinar) para llegar al punto de parecer, durante un tiempo al menos, malos profesionales, acelerando en el último punto, para que se vea que saben trabajar, y acabando el trabajo justo a tiempo para que no se les eche del trabajo.
En el mundo del software
Hay muchas veces que, la estimación de un proyecto de software se hace por tiempo. En función del tiempo tardado, se paga a los programadores, y se estima el precio del proyecto. No obstante, esto tiene bastante puntos negativos para los desarrolladores, e incluso para los clientes:
- La competencia: competir por el desarrollo de software es decir que tardas menos (y por lo tanto cobras menos). Pero si el tiempo se recorta y no los requisitos, o pagas menos a los trabajadores (programadores) o les presionas para que hagan más en menos tiempo.
- Procrastinación: si se firma un proyecto de un año, se fija el alcance los requisitos, y se comienza a trabajar. Pasará, y eso se quiera o no es así, que los primeros meses la curva de implicación y desarrollo es muy baja, mientras que el último mes es incluso insana, echando más de ocho horas diarias. La presión no se tiene hasta que la fecha está próxima a cumplirse, y como a los desarrolladores/programadores se les paga por el tiempo que están ahí desarrollando la solución, no les motiva el terminar antes.
- Recursos Humanos: aún usando metodologías ágiles, si la presión es variante en el tiempo y la motivación de hay que entregar se sucede con bastante frecuencia, sin que haya un premio por ello, y sin embargo habiendo broncas o castigos en caso de no llegar, eso hace que la gente se desmotive, comience a trabajar cada vez peor y termine viendo más las páginas de trabajo que el desarrollo en sí.
- Retorno de Inversión: equivocarse en una fecha tras otra, puede ser un punto de pérdida de dinero si se tiene que invertir horas de personas en algo que se supone que debería de estar acabado. Supone no saber exactamente el precio de un desarrollo hasta que no se ha terminado completamente.
¿Otro modelo es posible?
Pudiera ser posible, sí. Pensemos en el modelo del pintor, ¿cómo le pagaríamos? Supongo que lo óptimo sería por pintura gastada y por metros pintados, así como por manos de pintura dadas. Es decir, materiales y mano de obra calculando el trabajo realizado, y no las horas invertidas. Esto hace que el trabajador sea el más interesado en ser óptimo en su trabajo, ya que, tanto si tarda una hora, como si tarda tres, cobrará lo mismo.
En el mundo del desarrollo de software, ¿es posible hacer esto? Muchos dirán inmediatamente que no, que es complejo e incluso imposible determinar cuánto tiempo se demora en desarrollar un cierto sistema. La pregunta es clara:
Si es posible determinar el tiempo que se va a tardar en un desarrollo, ¿por qué no se puede determinar el precio de ese mismo desarrollo?
Esto es lo que vienen haciendo desde hace mucho tiempo otras doctrinas, como la abogacía, los registradores, los notarios o los arquitectos. Todos los profesionales colegiados en realidad. En el primer caso, por ejemplo, el Colegio de Abogados de cada provincia establece un precio por trabajo específico a realizar. En nuestro caso, el desarrollo de software, por ejemplo, podríamos determinar conceptos como:
- Desarrollo de una página web: HTML + CSS + JavaScript; precio mínimo: XXX euros
- Desarrollo de una página dinámica web (lenguaje de etiquetas: JSP, ASP o PHP); precio mínimo: XXX euros
- Desarrollo de un sistema de gestión de usuarios; precio mínimo: XXX euros
- etc.
Si se desglosa el desarrollo que se pide, hasta el nivel de análisis (e incluso diseño) más básico, toda petición se pueden englosar en uno de estos conceptos, quedando algunos otros como as en la manga, como la creación de conceptos de investigación, o incluso de riesgo, por tratarse de algo que se sale de la línea base en la que desarrolla la empresa en concreto.
Estableciendo precios
Al igual que se debe de realizar un modelo de negocio cuando se levanta una empresa, se deberían de plantear los precios por concepto de lo que la empresa realiza. Está claro que hay conceptos que seguirán quedándose en horas, como la hora de atención al cliente, o la hora de soporte, o la hora de formación.
No obstante, se pueden determinar ciertos desarrollos en los que la empresa se desenvuelve sin problemas, si es web, por ejemplo todo lo que se suele desarrollar de web y cosas que no se han hecho pero se saben hacer, así como si fuese de sistemas, todos los posibles montajes que se pueden realizar en base a tipologías de servidores que se quisieran montar, sistemas de seguridad, de redes, etc.
Buscando motivación en lugar de procrastinación
Si se tiene una empresa en la que los desarrollos son para la propia empresa, tipos como se han puesto de moda SaaS (Software as a Service), es decir, vender software como servicio y no como producto, entonces se podría hacer una evaluación de los tipos de desarrollos que se acometen, fijar un esquema de conceptos internos, y pagar a los desarrolladores por trabajo realizado. Tal y como se paga a los equipos comerciales.
En este caso, las empresas pagarían el mínimo fijo a los trabajadores, y una comisión, por trabajo realizado ese mes. Si se han realizado muchas labores imputables por conceptos acordados, el trabajador percibirá la cuantía según su hoja de servicio. Sin embargo, si ha realizado poco trabajo o ninguno, solo percibirá el mínimo.
Competencia interna e intereses contrapuestos
Desgraciadamente, no todo es bueno en este modelo. El hecho de ganar más dinero si se hace más, hace que también se busque la forma de hacer menos y seguir ganando más (naturaleza humana), por lo que nos podemos encontrar que haya gente que intente atribuirse el trabajo de otros, o incluso soliciten ayuda del compañero para que le acabe el trabajo.
Esto hace que el trabajador se mueva siempre en beneficio propio, y no en el de la empresa, ya que gana dinero si hace, no si ayuda. Esto puede forzar a que el trabajador genere más trabajo del que requiera la empresa en cierto punto (necesidad de ganar más) o incluso que haga más hora para conseguir más beneficio.
Todo es controlable y todo se puede mejorar. Estos puntos son salvables, ya que se pueden incluir conceptos de soporte entre trabajadores. Si el jefe estima que un trabajador está ayudando a sus compañeros, puede darle un incentivo por compañerismo, que esté reflejado en la tabla de conceptos, con lo que se potencia el trabajo en equipo.
Así mismo, se puede incentivar el que se trabaje a unas horas concretas, asistencia a reuniones o incluso tener un contra-incentivo si se permanece en la oficina pasada una hora concreta, para controlar que un trabajador no llegue a un punto insano de saturación por obsesión de intentar conseguir cada vez más.
Conclusión
Considero que, al igual que el incentivo es una buena forma de educar a un niño, es una buena forma de mantener la motivación de una persona en el trabajo, haciendo que la propia persona, con su experiencia y su creatividad, en las horas que determine dedicar al trabajo, consiga el mayor partido, ganando lo que quiera ganar, y con limitaciones para que la obsesión o avaricia se pueda presentar.
Los partes horarios son un ente arcaico que vienen bien en casos de trabajos concretos, que no se pueden medir por un trabajo realizado, sino más bien por un servicio prestado o por una atención dada. Pero este no es el caso del desarrollo de software.
