La finalización de un vínculo puede quizás organizarse en dos grandes grupos: salida por decisión (planeada y organizada) o salida traumática (no nos queremos volver a ver, al menos por ahora).
Con el correr del tiempo, y luego de haber pasado por tantos proyectos, uno trata de mejorar esa experiencia, tanto para el cliente como para el equipo (o incluso por absoluto egoísmo, para uno mismo).
¿Cuáles son, entonces, los temas que deberíamos intentar resolver ante la disolución de un vínculo cliente-proveedor? (más allá de cómo se origine esa disolución).
Como de costumbre, basaré mi ejemplo en un proyecto Magento, pero se puede aplicar a cualquier proyecto de software, más allá de algún paso específico.
Normalmente recibimos, de parte del cliente, acceso al código (repositorios), base de datos de desarrollo, puede que también tengamos de forma total o parcial acceso a entornos superiores hasta llegar a Producción (con usuarios de backend y de frontend), podemos también tener acceso a los servidores (dependerá de la infraestructura), credenciales de API, credenciales de servicios vinculados al proyecto; y ni hablar de información del negocio que, sí se hicieron bien las cosas, ha de estar protegida por un contrato de confidencialidad.
Entonces, si tenemos todos estos elementos, ¿por dónde empezamos?.
- Lo primero que hago es frenar y bloquear todos los accesos a todo el equipo de nuestro lado, para que ya no puedan ingresar a los sistemas (sin importar su grado de permisos).
- Bloquear acceso a servidores si existiera.
- Lo siguiente es retirar las credenciales de cualquier servicio relacionado.
En ambos casos, el bloqueo puede (y hasta debería) involucrar el borrado de los usuarios y rotación de claves si no se identificó a cada usuario de forma individual.
Con esto ya nadie del equipo puede (o podría) tocar ningún entorno. Ahora viene otro paso que es igual de relevante y está fuertemente vinculado a lo legal (por más que suene obvio, es importante tener contratos de confidencialidad, bien claros y delineados1), la eliminación de cada copia de código, datos y documentos que el proveedor pueda tener.
En mi caso, esto implica la solicitud interna explícita y la confirmación de cada integrante del equipo, también de forma explícita, por escrito, de que se ha eliminado toda información relacionada.
De esta forma buscamos garantizar que nadie quede con la posibilidad de hacer uso o abuso de credenciales o datos o código. Y si lo hiciera, dado que hubo una confirmación escrita según el contrato, se pueden tomar medidas legales por incumplimiento.
Si hasta acá logramos que todo el equipo se haya desprendido de toda copia y acceso del proyecto, lo siguiente es reportarlo al cliente.
Aquí lo que intento hacer es reportar todos los pasos ya resueltos, mencionar pasos faltantes explicando por qué no se han realizado aún, y un detalle de los próximos pasos (incluyendo plazos, bloqueos y responsables).
Hay un detalle adicional a considerar. En los contratos solemos estipular plazos de cierre o salida, lo cual significa que al momento de la notificación, el reloj corre. Y como el reloj corre, hay que intentar hacer las cosas en los plazos definidos para evitar descalces.
¿Y para el cliente o el proyecto, cuál es la responsabilidad? (O al menos, qué es lo que nos gustaría que pase).
Sin dudas, mantener la cadencia en la comunicación y en las acciones es la responsabilidad mayor. Aquí hay situaciones o pasos que sólo el cliente puede realizar (y hasta son su responsabilidad). Cualquier falla aquí estropea el proceso y podría generar un problema mayor al dejar acciones pendientes luego de la fecha final de prestación del servicio.
Un efecto no deseado de no respetar esto último es que alguna de las acciones que nosotros como proveedores debemos ejecutar se destraben una vez vencido ese plazo. Aquí ya no hay responsabilidad legal para nosotros, por lo que su realización quedará librado a la buena voluntad.
Habitualmente, más allá de la herramienta de gestión que usemos para los proyectos y/o soporte, solemos dejar la puerta abierta a que incluso cuando se finalice el servicio, el cliente pueda seguir usando el portal de soporte para hacer preguntas relacionadas o pedir cosas nuevas de forma aislada. Aquí el uso posterior al cierre es tan variado que no tengo un patrón identificado (posiblemente por el tamaño del muestreo).
El objetivo último es lograr finalizar el servicio sin afectar al negocio, en particular en los casos en donde la operación funciona las 24 horas del día.
Deberíamos apuntar a que ambas partes puedan ser capaces de seguir adelante de la mejor forma posible, entendiendo que todo cambio siempre produce alteraciones. Por eso tener un procedimiento documentado de offboarding puede ayudarnos a reducir el trauma.
No hace falta aclarar que ésta no es una guía perfecta ni definitiva, sino un recordatorio de pasos mínimos a considerar para la tranquilidad de todos.
Existen aspectos adicionales que quizás dependen del rubro, tecnología o tamaño del proyecto.
Por ejemplo:
- Plazos de cancelación de factura final (nada tan agotador como tener que recordar facturas vencidas).
- Gestión de licencias si corresponde.
- Documentación de desarrollos ya entregados o de procesos específicos.
- NPS al cierre del proyecto.
Como cada caso se convierte en aprendizaje, internamente todo va a parar al PlayBook para intentar hacerlo mejor la próxima vez.
¿Te ha tocado atravesar un proceso de salida de ésta manera?
- Sorprende la cantidad de empresas, clientes y proveedores que no definen cuestiones por contrato. Luego vienen los problemas, las quejas y las acciones emocionales que nada tienen que ver con la realidad. Por eso, un contrato con los procesos y reglas para cada caso, ayudan a que las cosas fluyan mejor para todos. ↩︎