Los cambios son inevitables. Siempre llega un momento en que tienes la necesidad de cambiar o evolucionar, ya sea por decisión propia, o porque te veas forzado a ello.
Esto proceso simplemente ocurre, ya sea en lo personal como en lo laboral, en los proyectos que llevas a cabo, en tus relaciones, y un largo etcétera. Los proyectos de sitios web no son menos, sufren multitud de cambios en forma de nuevos proyectos o simples evolutivos. Al fin y al cabo, el tiempo pasa igual para todo y todos.
Por lo general, un proyecto web está sujeto a una constante evolución por multitud de factores, como por ejemplo:
- Evoluciones funcionales.
- Respuesta a una necesidad de negocio o mercado.
- Tecnología siempre cambiante.
- Una competencia activa.
- Por quedarse sencillamente obsoleta.
- …
Muy bien, está claro que los cambios suelen ser necesarios. Pero ¿qué determina su necesidad real? ¿Se llevan a cabo correctamente? ¿Cuál es el impacto? ¿Cómo evitarlo?
Es imposible responder a todo con un simple post… Me centraré en algunos conceptos que me parece importante comentar, todo basado en experiencia personal que seguro que comparto con la mayoría de vosotros (o no).
ROI
Cuando se prepara un proyecto de cierta envergadura, la relevancia del mismo viene determinada por el ROI o retorno de la inversión.
Por situaciones de necesidad puedes llegar a saltarte este filtro, pero por lo general no debería plantearse un proyecto que no vaya a proporcionar un beneficio a la empresa. Para eso se suele dedicar tiempo a evaluar, analizar, y estudiar el mercado. Sino, ¿para que perder el tiempo?
Ojo, el beneficio no tiene que ser obligatoriamente una consecuencia de una proyecto comercial o de marketing de cara al publico. Desarrollar aplicaciones internas también ofrece un beneficio real.
Pensaréis que es imposible llevar a cabo proyectos que no ofrezcan algún beneficio. ¡Nada es imposible! He podido ver e incluso participar de proyectos que no han ofrecido beneficios por ser ideas no meditadas o estudiadas, inservibles por un mal análisis o planteamiento, que no han sido de ninguna utilidad o que no eran necesarios.
Time to market
Todos hemos sufrido el TTM, el supervillano Time To Market, y su menos temible amigo Deadline. El TTM suele (o debe) tener una potente razón detrás: Aprovechar el momento oportuno del mercado, avanzarse a la posible competencia, o responder lo antes posible, una época determinada del año, cualquier cambio mandatory por necesidad,…
Con esto no digo que un deadline sea nocivo, todo lo contrario. Es necesario marcar hitos para poder llevar a cabo una planificación y avanzar en los proyectos.
Pero existe una delgada linea por la que un proyecto muy centrado en reducir tiempos, tiende a convertirse en un problema o fracaso en un corto o medio plazo. Porque lo primero que se suele ver afectado al reducir tiempos es la calidad del proyecto, ya sea en forma de falta de escalabilidad, bajo rendimiento, un producto erróneo, limitado, y con poco margen de evolución, o una avalancha de bugs detrás.
No podemos sacrificar un proyecto antes siquiera de ponerlo en marcha, porque es una perdida de tiempo y dinero.
Un par de consideraciones si las fechas aprietan:
– Plantéate fasear el proyecto: Por lo general, puedes sacar adelante un proyecto sin todas las funcionalidades. Normalmente esto ocurre en muchos proyectos, pero no es lo mismo planificarlo así de antemano que verte forzado a ello al llegar al deadline. En este segundo caso, la calidad probablemente ya se habrá visto comprometida. En la medida de lo posible, trata de fasear el proyecto, y si terminas antes de lo previsto, puedes plantearte añadir alguna cosa más.
– Recuerda paralelizar su sustituto: Si vas a hacer una “ñapa” o algo cutre, o realmente limitado y temporal, debes pensar en iniciar en paralelo el proceso para un nuevo proyecto que deberá sustituirá a éste. El problema es que habitualmente la opción cutre se queda en producción un largo tiempo, con todas sus consecuencias, menos para los verdaderos responsables. Ambos proyectos deben ir de la mano, no debería existir planificación de uno sin la otra.
– No olvides la deuda técnica o ella acabará contigo: Sobran las palabras ;)
Responder al impacto
Los cambios en la web suelen tener consecuencias, a la larga supuestamente mejores, y en algunos casos peores, pero a priori siempre parten de un impacto sobre el usuario que es negativo para la empresa. Los cambios suelen dificultar de inicio el normal desarrollo de los usuarios habituales.
Para minimizar ese impacto, es importante tener en cuenta ciertas acciones:
Comunicación: Si vas a llevar a cabo un cambio, no dejes lugar a la sorpresa, comunícalo a tiempo. Siempre puedes convertir el cambio en una acción de marketing. Y no puedes comunicar exclusivamente a través de e-mail, notifícale en la web. No todos los visitantes son usuarios registrados.
Pruebas: Antes de llevar un cambio agresivo, pruébalo. Puedes llevar a cabo un test A/B o Multi para determinar el impacto que puede tener, y así evitar males mayores.
Usabilidad (UX): A estas alturas no debería ser necesario hablar de la importancia de cuidar la usabilidad a la hora de diseñar cualquier cambios en la web.
Volver atrás (Rollback): Un cambio puede necesitar de tiempo para funcionar, pero si algo no funciona, asúmelo y vuelve atrás. Tratar de solucionar las cosas sobre la marcha solo puede empeorar la situación. Mejor volver a una entorno estable, determinar las causas del fracaso, y actuar en consecuencia.
Todos hemos vivido o planteado proyectos, mejoras, y cambios. Te animo a que compartas tu experiencia! ;)
