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?
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.
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:
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:
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.
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.
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.
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.
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.