Royalmail.com

Advierto: entrada sólo para gente del género antihumano🙂 y aun así es pesadísima!

Esta noche se hizo “pública” la parte en la que estuve trabajando las últimas 5-6 semanas.

Se trata básicamente de un proceso de optimización del portal de royalmail.com, lo han dividido en 3 fases, son como 9-10 subproyectos, y esta primera ha sido la más “grande” de todas.

Diferencias de trabajar en IT´s España – RoyalMail eBusiness (puesto que es el único sitio en el que he trabajado), a nivel técnico no muchas, pero a nivel de organización, muy muy diferentes.

A nivel técnico nada nuevo que contar, trabajamos con ATG, que básicamente es un gestor de contenidos centrado en e-commerce (y por dentro es muy similar a Vignette, portlets, droplets, capas por aquí y por allá…) Bueno, el rollo de siempre.🙂

A nivel gestión del proyecto, impresionado me he quedado (gratamente). Lo primero, para arrancar es un balance del proyecto en sí. La documentación es digna de ver. Me gustaría poder ponerla porque el estudio no pasa simplemente por párrafos y más párrafos de lo que va a hacer la aplicación. Se aportan posibles soluciones en pseudo-codigo, e incluso se relacionan las clases que se van a tener que crear. En este punto, siento decir que es de gran ayuda para el desarrollador, el “gran olvidado” en las transacciones españolas.

Tiempo para el developing muy muy amplio (se agradece!). Y donde viene el infierno es en el proceso de signs-off.

Imagen 1.png

Asi que tenemos lo siguiente. Para comenzar, 15 (si, 15) entornos de desarrollo. El programador tiene cancha para toquetear todo del sistema (via ssh). Acceso a bbdd. Una vez completado el desarrollo (trabajando en paralelo con la gente de contenidos si es necesario), se realizan las peticiones de firma:

i. Sign-off de la gente de accesibilidad y usabilidad (DDA). Cualquier pequeño defecto en el gui, o la no-optimización de css´s, … nos para el proceso. Es decir, es un muro tan grande como el de la eficiencia del código o el diseño de la bbdd. Si no te firman (y no lo harán si no es PERFECTO), no pasas al punto ii

ii. Sign-off de los gurús de programación (DA). Revisión del código desarrollado, sean jsp´s, .java, .sql, … El algoritmo de generación de menús se revisó hasta 6 veces, llegando a una versión final implementada recursivamente.

iii. Sign-off de Support Transition. Una vez que el proyecto vea la luz, cualquier incidencia no forma parte del grupo de desarrollo (PTT – Portal Technical Team, donde estoy), sino que va a para a manos de la gente de CSC. Para ello, conferencia telefónica con CSC-India / Londres. 2h30′ explicando que se hizo, porque el código es así o porque se usan esas tablas en la bbdd. En definitiva, transmitir todo lo hecho. Si no lo ven claro, no hay firma, y se para el proceso, pudiendo pedir revisarse por los DA.

iv. Sign-off de testing. Applabs se encarga de realizar pruebas de regresión sobre todo lo que el proyecto haya modificado, o en el caso de ser demasiado general, scripts eternos de regresión total de las diferentes comunidades del portal. Los errores son comunicados a PTT, así como las trazas de eficiencia.

Con las 4 firmas, pasamos a los estados. El control de estas fases es obra de los gatekeepers (CSC)

i. Acceptance. Como desarrollador ya no se puede tocar nada de nada. Se comprueba que todo es correcto y das tu sign-off a los gkps. Se requiere, de nuevo, una firma del grupo de testing y de DDA.
ii. Staging. Pasa previo a productivo. De nuevo necesita de firma de testing. Se hace un volcado del entorno de productivo a todos los entornos (desarrollo, acceptance y staging), y se modifica toda la configuración con nuestros requerimientos.
iii. Productivo. Argh… al fin..😛

Por supuesto, todo esto supervisado además por el Jefe de Proyecto asignado, y los Team Headers.

Resumiendo, llevar algo al “directo” es tedioso, pesado y enfermizo. Pero asegura al 100% que si algo va a fallar, es algo realmente difícil de reproducir. Lo más curioso es que un DDA (acc./usabilidad) tiene el mismo peso que un gatekeeper (y en las dos vertientes, profesional y personalmente, de hecho los DDA´s están cobrando mucho mucho más dinero que muchos de nosotros).

Recuerdo que en el Principado se “intentaba” hacer algo parecido con una organización parecida, pero, 1o, la gente aquí tiene muy claro que es lo que tiene que hacer, y COMO lo tiene que hacer.

Y lo más importante, no existe nadie que pueda decidir saltarse una firma o pasar a otro entorno “porque me da la gana” o “porque tenemos que sacar esto pasado mañana”. La máxima parece ser “saquemos un producto de mucha ‘calidad'” en lugar de “saquemoslo rápido que no llegamos a las fechas”.

Bueno ya estuvo bien, prometo nunca más aburrir con el trabajo, pero había que hacerlo🙂

Currently playing in iTunes: Clowns by Goldfrapp

3 comentarios en “Royalmail.com

  1. Aqui un antihumano. Si hacemos eso este verano para RGSA, nos acaban nombrando funcionarios a titulo postumo a Jorge, a ti y a mi; porque las horas que ibamos a echar, acababamos inmolandonos por el hueco de la escalera fijo.

    Donde este hacerlo a lo “españó”, que da más juego, más vidilla… no sé más emoción al fin y al cabo. Eso sí, lo que dijiste de las galletas y el chocolate, eso lo implantaba ahora mismo jejeje.

  2. Otro antihumano. Acojonao me he kedao man, impresionante, que envidia!!!

    Sobre todo, cuando estos días estamos intentando sacar a producción el jodio chequebebe. No te voy a contar nada que no sepas, pero esto cada vez mete más miedo. Tamos escogiendo ya la celda en Villabona, jeje!!!😉

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s