Riesgo de la tercerización in-house

Por: José Miguel Loor - nDeveloper

Primero que nada, vamos a entender a que nos referimos cuando hablamos de tercerización in-house. En este caso, estamos hablando de que un cliente A nos subcontrata para desarrollar un proyecto que, a su vez, otro cliente B ha encomendado por contrato al cliente A. Como añadido, el cliente B solicita al cliente A que sus recursos (en este caso, el personal de desarrollo e implementación) trabajen de manera presencial en las instalaciones del cliente B.

Una vez aclarado el panorama vamos a tratar algunos de los riesgos a los cuales nos exponemos al adoptar este método de trabajo:

• Canal de comunicación muy largo: las peticiones que sean necesarias realizar durante el transcurso del proyecto deben recorrer un camino muy largo; primero tenemos que justificarlas frente a nuestro cliente directo (cliente A) que a su vez debe justificarlas al cliente final (cliente B). De esta manera, cualquier decisión demora más de lo debido y necesario, al tener que escalar de manera vertical de un estrato al otro.

• Identificación errónea del grupo de trabajo: ¿a quienes ve el cliente final? A los desarrolladores por supuesto. Pero los desarrolladores no están representado a la empresa a la que pertenecen en verdad (nDeveloper en este caso) sino a la empresa que los ha subcontratado para desarrollar el proyecto. Eso no se le comunica al cliente final, sino que este asume que el equipo de trabajo le pertenece a la empresa que ellos contrataron. En consecuencia, perdemos la oportunidad de crear imagen (en caso de que el proyecto sea exitoso) y asumimos los errores de nuestro cliente (en caso de que el proyecto sea un desastre).

• Errores y fallas heredados: ¿que pasa cuando nuestro cliente comete errores? Pues somos nosotros, el equipo de desarrollo quienes cargamos con las críticas y las “pedradas” causadas por cualquier fallo en las decisiones o planificaciones en las que haya incurrido nuestro cliente directo. Estas fallas, sobre todo si son fallas de base (diseño de los esquemas de datos, fallas en los levantamientos de procesos, etc), resultan tremendamente costosas puesto que socavan grandemente la imagen de todos los involucrados. Sin embargo, el equipo de desarrollo asume la etiqueta de “culpable” sin tener directa responsabilidad en el problema.

• Roles confundidos: Como equipo de desarrollo, somos responsables de una sola cosa. El código. La implementación de las definiciones de nuestro cliente inicial, y la puesta en marcha de estas definiciones, sujetas a las estructuras de datos que ellos hayan definido, son nuestra única meta. Sin embargo, al estar dentro de los predios del cliente final, el equipo de desarrollo tiende a verse involucrado dentro de tareas que no les corresponden: definición de estándares, elaboración de documentos, reuniones de evaluación, etc.

El principal riesgo que se corre en este caso, es precisamente lo afectada que se puede ver la imagen de la gente encargada del desarrollo. Si el proyecto va mal, el equipo de desarrollo va a ser la primera línea de contención de las fallas (la carne de cañón); si por el contrario el proyecto es un éxito, ¿quienes creen que se llevarán el crédito?

¿Cómo podemos evitar que este esquema de trabajo se vuelva en nuestra contra? Vamos a definir algunas alternativas:

• El cliente de mi cliente, NO ES MI cliente: Debemos tener una cosa siempre presente durante el desarrollo del proyecto. Nuestro cliente es quien nos contrata a nosotros, no quien contrata a nuestro cliente. Nuestra responsabilidad es responder los requerimientos de nuestro cliente directo; los requerimientos del cliente de nuestro cliente, escapan del ámbito de nuestras responsabilidades.

• Limitar el contacto con el cliente final: lo mejor sería no tener, NINGÚN contacto con el cliente final. Pero en este caso no estaríamos hablando del escenario descrito en primer lugar: que el cliente final requiere que el equipo de trabajo esté localizado en sus instalaciones. Lo que se debe hacer en estos casos, es abstenerse de cualquier tipo de reunión de planificación, revisión o avance del proyecto, en las que participe personal del cliente final. Esto va ligado con el punto anterior: nosotros tenemos que limitar nuestra relación con nuestro cliente directo.

• Definir exactamente los límites de nuestra participación: Como ya lo habíamos expresado antes, nuestra tarea es programar, nada más. Debemos entregar el código que implemente unos requerimientos y unos esquemas de datos que deben estar bien definidos desde el inicio del proyecto. Cualquier fallo sobre esos requerimientos, es responsabilidad de nuestro cliente, no nuestra, por lo tanto, NO DEBEMOS asumir ninguna responsabilidad sobre esos fallos, o sobre requerimientos agregados durante el proyecto.

Estas medidas no garantizan la ausencia de problemas y fricciones entre nuestro cliente y nosotros, pero por lo menos nos ayudan a limitar la responsabilidad de nuestro trabajo y a cuidar de algún modo, la imagen de nuestra empresa, al no asumir errores que no son nuestros.