Riesgo de cambio

Parte de lo que pretendo en este blog es compartir algunas lecciones que aprendemos día a día en ASPgems.

Hace poco envié el mail que copio a continuación a un cliente que estaba valorando la posibilidad de hacer un proyecto cambiando de entorno tecnológico. En mi opinión lo relevante del mail no es la discusión sobre si la tecnología A o B es mejor, sino cuales son los factores mentales y los frenos que afrontan muchas compañías a cambiar y avanzar.

Hay veces que en desarrollo de software vemos los cambios como un riesgo, y el mail pretendía ser una invitación a ver los cambios de plataforma como una oportunidad para aprender.

El coste de cambio es siempre enorme, y la aversión al riesgo una carácterística tremendamente humana.

Querido cliente:

Llevo unos días dándole vueltas al proyecto que os presentamos, y a como trasmitirte las ventajas que os puede aportar.

En primer lugar, quiero volver a insistir en que entiendo perfectamente la situación en la que estáis.

La plataforma que gestionáis es muy compleja, y sobre todo tiene muchos años de vida (como decimos nosotros: “el mundo se pudo hacer en 7 días porque no había base instalada”). Mantener la aplicación en funcionamiento en un entorno tan cambiante seguro que no es fácil, y mas cuando muchas veces las decisiones hay que tomarlas rápido y no siempre con todos los recursos que serían necesarios.

Entiendo además que la perspectiva de cambiar de plataforma tecnológica introduce mucha incertidumbre, especialmente en lo que se refiere a dependencia de un proveedor, frente a trabajar con tu propio equipo.

Te mando este correo para ofrecerte la posibilidad de ver las cosas de otra manera, para ver este proyecto no como un proyecto que complicará vuestra actual infraestructura haciendo vuestro trabajo mas difícil, sino como una oportunidad para la innovación y la mejora que acabará redundando en un mejor servicio al resto de la empresa, y reforzará una de las ventajas competitivas de tu empresa: su diferencial tecnológico.

Es complicado resumir en pocas líneas todas las ventajas que Ruby on Rails puede ofrecer en un entorno con necesidades de cambio constantes y con presión en plazos y costes. Puedo decirte que las ventajas que estamos experimentando desde hace ya casi 4 años son:

• Velocidad de desarrollo
• Estabilidad de la plataforma
• Escalabilidad
• Disminución del número de errores y necesidades de soporte

Si decidierais ir adelante con el proyecto, podríamos abordar juntos, y poco a poco, algunos de los retos a los que tenéis que hacer frente porque:

• La productividad de Ruby on Rails os permite atender mejor las necesidades de las áreas de negocio sin necesidad de nuevos recursos.
• Adoptar un entorno como Ruby On Rails os permite utilizar la experiencia y pasión de muchos desarrolladores, de mucho software disponible como software libre, y servicios.
• El que Ruby On Rails disponga de tres entornos integrados pero diferenciados (desarrollo, pruebas y producción) hace la gestión de los desarrollos, las pruebas de regresión y las puestas en producción mas estables.
• La estabilidad y escalabilidad de la plataforma reducen drásticamente el tiempo dedicado a incidencias.
• Sabes bien que los informáticos somos gente con pasión por la innovación y seguro que un cambio de plataforma es una oportunidad para tu equipo de aprender algo nuevo. Es verdad que cambiar de entorno es un desafío, pero cuentas con nuestro soporte para hacer ese camino lo mas fácil posible. Nosotros estamos teniendo tiempos de aprendizaje básico de la plataforma de menos de 2 semanas.
• Independencia de proveedores y empleados, las aplicaciones Ruby On Rails tienen todas la misma arquitectura y por tanto cuando un desarrollador llega a un proyecto ya sabe donde está todo y su tiempo de adaptación a un proyecto es muy pequeño. Nosotros lo experimentamos continuamente en la reorganziación de los equipos de trabajo, y en las escasas ocasiones donde ha habido que hacer alguna intervención, cualquier miembro de nuestro equipo es capaz de resolver la incidencia. Dejame compartir contigo que en estos cuatro años no hemos tenido ningún bug que nos haya costado mas de 4 horas resolver.

Si te parece oportuno, podemos quedar un día para discutir este tema con nuestro director técnico y el vuestro,  y explicaros con mas tranquilidad nuestro punto de vista.

El mail no debería ser tan bueno, al final no ganamos el proyecto.