archivo

Archivos diarios: marzo 9, 2013

¿Y qué se hace con esas horas que no se facturan? La respuesta a esta pregunta no es simple, de hecho no la voy a responder, solo dejo unas cuantas reflexiones:

– Llegado a un punto, en un proyecto llave en mano las horas que superen lo contratado no serán facturables (salvo pacto contrario) ya que el compromiso es desarrollar un producto con el precio y las condiciones fijadas. En este tipo de proyectos lo que interesa, por tanto, es cumplir la agenda con el objeto de no incurrir en pérdidas y para ello la medida más óptima es que el equipo y las personas que lo componen sean productivas por encima de que el 100% de sus horas sean facturables o no porque al final si no cumples, si no trabajas bien, todas las horas te costarán dinero.

– En general un trabajo que no esté bien hecho y que haya que volver a hacer y/o que erosione tu credibilidad con respecto al cliente es dinero perdido y/o que se dejará de ganar.

– Si una persona o un equipo tiene trabajo que potencialmente supera el 100% de su capacidad corre el riesgo de que en determinados momentos se sature y que la misma afecte a la productividad y a la calidad.

– Lo ideal es que la dedicación de personas a proyectos sea del 100%. El problema de la saturación es provocado generalmente al compartirse entre diferentes proyectos, incluso en aquellos casos donde se quiera tener cuidado de que la dedicación total no supere el 100% porque, ¿quién es capaz de delimitar con tanta precisión las fronteras?, ¿alguien ha tenido en cuenta el esfuerzo real que supone cada cambio de contexto?, ¿quién tiene la suficiente capacidad para olvidarse de los problemas que tiene en otros proyectos en los que esté trabajando?, ¿qué pasa cuando los diferentes proyectos en los que se trabaja están en “crisis”?.

– No todos los perfiles funcionan igual al compartirse entre proyectos distintos. Cuanto mayor sea el nivel de detalle con el que trabaje en el proyecto menos productiva será esa división.

– La productividad de una persona o de un equipo no se debe medir por el número de horas que facturen sino por la efectividad de las horas facturadas, si se es efectivo seguro que será rentable.

Cuando tenemos que pagar, casi siempre nos parecerá demasiado caro lo que nos ofrecen. Por otro lado, el proveedor tratará de no pillarse los dedos y realizará estimaciones con el objeto de minimizar riesgos.

La situación no es sencilla de resolver, de hecho, casi nunca nadie estará satisfecho, teniendo en cuenta de que el proveedor casi siempre termina equivocándose en sus estimaciones y de forma desfavorable para él (otra cuestión es analizar si el motivo del error ha sido el exceso de optimismo, la baja productividad o una información insuficiente y/o inexacta).

Un primer antídoto lo tenemos en el cumplimiento de las expectativas del cliente, ya que éste se quedará con el valor real que le proporciona el producto, por encima de lo que se ha gastado (siempre, como es lógico, dentro de unos márgenes razonables).

Otro antídoto lo tenemos en la confianza, sin confianza, da igual lo que te apliques estimando que la otra parte terminará pensando que te estás cubriendo las espaldas. La confianza en estos casos se obtiene a través de la transparencia y de la capacidad de asumir errores, porque para el proveedor todo se simplifica, todo es muy sencillo, si es el cliente el que siempre termina pagando sus fallos. Lo mismo pasa al revés, cuando el cliente trata de repercutir en el proveedor su indefinición, sus errores en las especificaciones, su falta de colaboración, etc…

Soy partidario del reparto de riesgos, por eso ni creo en la facturación por horas ejecutadas, ni tampoco en la llave en mano, ambos sistemas son injustos.

Soy partidario de definir objetivos globales, crear una visión inicial del producto que se quiere obtener y a partir de ahí, realizar estimaciones basadas en iteraciones de corta duración (se reduce el margen de error) en las que cliente y proveedor, repartan riesgos, y en las que (muy importante) sea el equipo de desarrollo el que estime (ese espacio debe respetarlo el cliente o en su extensión, el área usuaria o el responsable funcional).