Cómo fue el proceso de traspaso de un cliente que cambió de agencia (desde el lado de quien recibe)

También tengo experiencia siendo la parte que entrega, así que añado dos puntos desde ahí.

1. El traspaso se hace en el peor momento de la relación y por eso suele hacerse mal. Si se incluye una cláusula de "procedimiento de traspaso" en el contrato, se reduce esa parte emocional: queda escrito desde el principio qué, a quién y en cuántos días se entrega.

2. También diré algo a la agencia que entrega: hacer un buen traspaso es la mejor publicidad. Dos clientes que entregamos correctamente volvieron dos años después por otro trabajo. Los que dan un portazo no vuelven.

En nuestro caso fue así: al asumir el proyecto hicimos una sola reunión de traspaso con la antigua agencia y funcionó muy bien.

Dos horas, grabadas, solo preguntas y respuestas. Nuestro equipo se preparó antes y escribió las preguntas. Lo que aprendimos en esas dos horas no lo habríamos aprendido solos en dos semanas.

El cliente había incluido esta reunión en el contrato, si no, no se habría hecho. Lo recomiendo.

Como agencia pequeña, añado esto: en el primer mes del proyecto que asumís, no cambiéis nada solo porque parezca "feo".

Ese es el primer reflejo de cualquier equipo que recibe, nosotros también lo hicimos. Luego aprendimos que debajo de esa solución fea suele haber una razón y limpiar sin conocer esa razón significa romper algo que funciona.

Antes de cambiar nada, responded a la pregunta "¿por qué se hizo así?". Aunque no haya respuesta, el hecho de haber buscado es lo que os protege, no lo que os frena.

Exacto, y encima no es tan conocido. Las decisiones apresuradas son las que hay que corregir seis meses después.

Corrijanme si me equivoco.

Hay un punto que me genera dudas. Si el alcance crece debe crecer el plazo o el presupuesto. No hay tercera opción.

Eso es todo, disculpa si me he extendido demasiado.

Hablaré desde el otro lado, yo estoy en el lado del proveedor. Si intentas cambiarlo todo a la vez nada termina de asentarse.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación. Ánimo.

Lo escribo para que no cometan el mismo error. Que todo el mundo haga algo no significa que sea lo correcto.

Yo no me apresuraría. Si la propiedad del código no está en el contrato, al irte no tienes poder de negociación.

Comprobado por experiencia.

La respuesta de arriba ha dado en el clavo. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Por supuesto, cambia si tu situación es diferente.

Separemos los conceptos, se están confundiendo. Las decisiones apresuradas son las que hay que corregir seis meses después.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación. Espero que le sea útil.

Entrando en detalle: Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Ánimo.

Gracias, me ha servido de mucha ayuda. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

También me gustaría saber si alguien lo hace de otra manera.

A nosotros también nos pasa. Si no lo pones por escrito desde el principio, luego surgen discusiones.

Por supuesto cambia si tu situación es diferente.

Estoy siguiendo esto. Lo importante no es la cifra sino en qué se basa esa cifra.

Gracias esa era la respuesta que buscaba. bueno el código sin documentación de instalación aunque lo tengas, no es tuyo.

Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza. Comprobado por experiencia.

Tienes razón, yo también pasé por lo mismo. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

En su momento, nosotros también nos atascamos ahí. El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas.

Si decidimos sin medir, siempre acabamos en el mismo punto. También me gustaría saber si alguien lo hace de otra manera.

Esto también tiene su parte de medición. Antes de decidir, mirad qué datos tenéis en la mano.

Comprobado por experiencia.