Incentivos perversos

La lectura de los libros “El economista camuflado” y “Las trampas del deseo”, así como el descubrimiento de la categoría "incentivos perversos" hace algún tiempo, me ha llevado a reflexionar sobre el trabajo que desempeño actualmente y la diferencia entre lo que se solicita, y lo que se incentiva (lo que la empresa está orientada a realizar realmente).

Digamos que actualmente un recién llegado podría suponer que debe hacer su trabajo lo mejor y más rápidamente posible y que con esa orientación en mente, todos seríamos más felices y quizá se le recompensase de alguna manera en función de los buenos resultados. Sin embargo la realidad es bien distinta. Intentaré exponer por qué.

Para empezar hay demasiados niveles de intermediación (jefes, subjefes, responsables de departamento y subcontratas de subcontratas) lo que, como todos sabemos (y comprobamos al menos en el equipo), redunda en una productividad mucho menor de la posible, pero visto desde mi nueva perspectiva se podría empezar a pensar que existen todos esos niveles por razones diferentes. Por ejemplo, el trabajo que deberían realizar 2 personas a lo sumo (un Analista y un Programador, o incluso un solo Desarrollador) y que podrían llevar a cabo en un mes, acaba siendo realizado por un gerente de cuentas, un comercial, un responsable de área, un jefe de proyecto, un analista y un analista programador a lo largo de 5 meses Este evidente aumento de personas (el doble) y tiempo (cinco veces más) no puede explicarse de ninguna manera como una actividad orientada a la productividad y satisfacción del cliente, sin embargo puede explicarse si pensamos que la empresa está orientada a justificar el sueldo de una parte de los actores del proceso sin aumentar en lo posible el trabajo realizado por estos (“Money for nothing” como decía la canción de los Dire Straits). Dicho de otra manera, un 50% del dinero que paga el cliente, se utiliza en pagar directa (sueldo) o indirectamente (coches de empresa, alquiler de oficinas/despachos) a unas personas que no proporcionan ningún bien o servicio al cliente, ni directa, ni indirectamente. Entiendo que el precio mínimo de un trabajo debe incluir ciertos gastos administrativos como el del departamento o persona que se encargue de tramitar contratos y facturas, pero debería suponer un aumento mínimo del precio dado el tamaño de la empresa.

Por otro lado tenemos el tema de la documentación técnica que se realiza. Esta no se parece (por laxa) ni de broma a la que me enseñaron a hacer en la carrera, y desde luego no se parece a la de ninguna metodología que conozca. Además la documentación técnica no está orientada al cliente (que no tiene conocimientos de informática), sin embargo es el quien la valida y por ello se insiste siempre y únicamente en cambiar la documentación para que sea bonita, fácil de entender por el cliente (olvida términos técnicos exactos, A.K.A.: formal) y esté abierta a interpretaciones (para poder dar menos y escudarnos en el documento). Esto es, la documentación técnica se convierte no en una herramienta de desarrollo, sino en un elemento de justificación de cara al cliente.

Por último tenemos una manera de desarrollar orientada, no a la funcionalidad o a las necesidades reales del cliente. Tampoco intentamos darle algo rápido con lo que ayudarle a encontrar el camino (Extreme Programming, Scrum, prototipos…) todo ello buenas prácticas que funcionan, y desarrolladas para problemas similares). Lo que se intenta es tener pantallas con los colores correctos, el tipo de letra adecuada y que funcionen de una determinada manera (que normalmente implica olvidarse de la usabilidad), evitar el sentido común (propongo renombrarlo como “sentido raro”) e ignorar conscientemente (a veces sistemáticamente) las necesidades reales y evidentes del cliente y los usuarios.

En definitiva, un trabajo que debería hacerse sobre Power Point (diseños de navegación y distribución del interfaz de usuario) se hace directamente programando (y olvídate de usar soluciones estándar implementadas en el framework de desarrollo, tendrás que picarlo todo desde cero). ¿Por qué realizar un trabajo de diseño en la fase de programación y no en la de diseño? La respuesta es fácil: la fase de diseño ya se ha justificado de cara al cliente, volver a ella obligaría a volver a justificar la misma, así que es preferible darla por cerrada y continuar con la siguiente fase, y su justificación de cara al cliente, inventando a cada paso nuevas fases con sus respectivas justificaciones, en una huida hacia delante. Es de nuevo un trabajo que se ahorran tanto los niveles superiores (el project manager no tiene que reestimar casi nada, el analista no tiene que retocar los documentos) como quien tiene que realizar la justificación (que además obtiene un chivo expiatorio para retrasos, ajeno a uno mismo) consiguiendo así que la búsqueda de responsables por los retrasos recaiga sobre el siguiente eslabón del desarrollo del producto, o sea, del desarrollador, para abajo.

Quizá estoy siendo demasiado negativo, escéptico o malpensado, pero como decía al principio, esta perspectiva cuadra bastante bien después de leer ciertas cosas. En cualquier caso no lo considero un problema de personal, sino organizacional y por ello pienso que cualquier posible solución debería venir de un cambio general y fundamental en la organización.