Hace 3 años | Por arcadiobuen a genbeta.com
Publicado hace 3 años por arcadiobuen a genbeta.com

Hace poco menos de año y medio, Renfe anunció que renovaría su página web, que dentro de las grandes webs de servicios en Españas, era de las más criticadas desde hace muchos años. La compañía informó de que el presupuesto del proyecto sería de unos 700.000 euros, algo que a los expertos les pareció poco considerando la tarea que había que acometer.

Comentarios

D

Una asquerosidad lol sin poder elegir asiento con billetes carísismos.

i

#7 Claaro. Y probablemente también harás la migración de datos a nuevas tablas en un plisplas. Y además incluso leerás el pliego de condiciones para saber porqué Renfe paga 600.000€. A lo mejor tienes que darle tu alma a cambio y no solo la web.

Por cierto, crear una Web modo Home es una chorrada...montar una infra con disponibilidad, balanceadores de carga, base de datos sincronizadas/replicas de lectura, tokenización, microservicios, eso ya es otra historia...
Un desarrollo en el que esté involucrado 2 analistas, 2 desarrolladores front, 2 desarrolladores back, 2 analistas de base de datos/migración, 2 sysadmin, 1 diseñador gráfico/maquetador...son 11 salarios anuales.Que se te van de 300.000€-350.000€ fácilmente (coste de empresa, salarios brutos mas seguros sociales) al año. Son 18 meses pues hablamos de 450.000€-525.000€ en equipo humano. Y el equipo que he descrito no es precisamente “grande”.
Si le sumas los costes de operación/infraestructura (no, el desarrollo no consiste en “Renfe aquí tienes tu web cuélgala en un XAMPP” sino que lleva el soporte 24/7 de mínimo infraestructura/sistemas) mensual de ese bicho...otros 30.000€ no se los quita nadie.
Y si ademas ha contratado una bolsa de horas para cambios tras entrar en producción...etc...
Asi que no.
600.000€ no me parecen una barbaridad.

squanchy

#13 No te flipes, que estamos hablando de una web para consultar horarios y comprar billetes de tren. El resto de contenido es completamente estático. Esto no es un CRM con una docena de módulos interconectados.

ccguy

#15 Digo yo que algún backend habrá ya, seguramente prehistórico y que no se puede cambiar.

i

#15 ¿En qué me he flipado?
He puesto un equipo mínimo para cualquier proyecto.
¿Web para consultar horarios y comprar billetes de tren? ¿Solo eso?
Bien. Veamos:
Horarios: Significa algoritmos de busqueda combinatoria, tu pones que quieres ir de Palencia a Málaga, y el sistema debe darte las combinatorias. Espero que sepas por dónde empezar con ese algoritmo tan “sencillo”.
Comprar billetes: Supone integración con pasarelas de pago. “Supersencillo”. Sobre todo para aquellos que han tocado únicamente un Wordpress que traen Plugins para Stripe que solo tienes que meter tus Secretos. No. Integración de verdad con pasarelas de pago de bancos y merchants para eliminar intermediarios como Stripe y Paypal.
Después, perdóname si me equivoco, en la
Web de la Renfe se cuelgan noticias, ofertas y demás.
Eso significa el desarrollo de un panel de administrador (que en sí mismo es una segunda web aparte) y ya entramos en un CMS propio. Más complejo, menos complejo, pero un CMS.
Sigamos para bingo.
Tiene registro de usuarios. Registro de usuarios: otro follón. Páginas protegidas, seguridad en tokenizaciones, almacenamiento de info de usuario, gestion de contraseñas, recuperar, etc...
Aun así, la complejidad de la web de la Renfe tiene que ver con:
1 - Migración de datos de las tablas antiguas a las nuevas. Dependiendo de como de mal esten montadas las antiguas mas jodido será el curro de llevárselo a las nuevas. Nadie sabe como están las antiguas, asi que el riesgo de encontrarse una mierda hay que pagarlo.
2 - Disponibilidad y balance de carga. La web debe tener una arquitectura con alta escalabilidad horizontal para que se adapte a las horas picos de peticiones. Esto significa tener balanceadores de carga, lanzamiento de nuevas maquinas de manera automatizada según demanda, cacheo de peticiones, crecimiento de base de datos en horizontal con replicas de lectura....
Me encanta cuando la gente dice “si solo es una web...”. Ya veras cuando te toque cambiar el mando del garaje y te soplen 50€...”si solo es un mando de plasticucho”.

D

#20 En mi opinion, puedes poner otro comentario explicandolo que ocupe el doble, y seguire pensando que todo lo que has dicho ni es nada del otro jueves, ni es nada excesivamente complejo o un follon (aun habiendo que hacerlo). En cualquier caso , elucubras igual que el que te diga lo contrario.

-Horarios, dejando a un lado que ya lo tienen hecho en principio, no me parece tan complejo. Por no decir que estara bastante inventado ya.
-Comprar, no he mirado que sistema utilizan y puede que hace años fuese un infierno, hoy tecnicamente esta trillado. Que sea un coñazo, si , que supone un hito, no.
-Un cms y un panel de administracion, dejando a un lado opciones de las que partir, aun de cero, nada complejo. El dia a dia de cualquier sistema, evidentemente hay que desarrollarlo, pero sin mas.
-Gestion de usuarios, tokens , profiles, paginas protegidas , otro follon? estarás de broma. Aparte de ser el dia a dia de cualquier proyecto, que complicación tiene montarte hoy en dia un identityserver o similar en una tarde y tener todo eso que dices? por no decirte alternativas online que no tienes ni que montar. Es que no se me ocurre que follon es ni pensandolo.

-Migracion de datos, con un poco de mala suerte puede ser pesado,tedioso y un coñazo, seguro (y he hecho unas cuantas de los origenes mas diversos), pero te aseguro que poco mas (contando que se haya hecho). Por otra parte me gustaria saber de cuantas tablas hablamos
-Disponibilidad y balance de carga, en serio que los balanceadores de carga , la dockerizacion y el levantar servidores en aws/azure tiene tanta magia hoy en dia?

A mi tambien me hace gracia la gente que dice "si solo es una web", pero tampoco hay que buscarle cinco pies al gato.

D

#20 Por curiosidad he mirado y no tengo ni idea pq no suelo ir en tren, pero me da a mi que esto hace la combinatoria que yo te diga.

El trayecto consultado no se encuentra disponible para la venta en estos momentos o bien no existe conexión directa, por favor inténtelo más adelante y disculpe las molestias.

ccguy

#13 Mucho "analista" veo yo ahí.

i

#16
He metido 4 analistas.
Por un lado tenemos 2 analistas: 1 para front, otro para backend. Dos mundos totalmente separados. ¿Que pueden ser analistas y programadores? Por supuesto. Pero el análisis de la web de la Renfe no es tan "trivial" como parece. Tienes sesión de usuario, CMS para gestión de usuarios/billetes/ofertas/blog?, integración con pasarelas de pago, definición de nuevas APIs...
Por otro lado 2 analistas de BBDD: Estoy seguro que las tablas en las que se monta la antigua web de la Renfe tienen un follón de padre y señor mío despues de pasar por varias manos. Ese follón que hace que las consultas sean lentas, pesadas e infumables. Los dos a full entendiendo las antiguas tablas para poder llevarse los datos a las nuevas. Diseñar una arquitectura de base de datos. Etc...Si no metes dos analistas en BBDD la Renfe seguirá siendo una porquería. De un buen diseño de la base de datos se optimizan las consultas y se obtienen tiempos decentes en las mismas.

Me parece muy gracioso (sarcasmo ON) que se diga que la web de la Renfe es una "simple web de consulta de horarios". Por esa regla de tres, Amazon es una "simple web de consulta de productos". O Blablacar una "simple web de consulta de trayectos". Un pequeño ecommerce tiene del orden de 20-30 tablas. No creo que sean menos las de la Renfe, que no deja de ser un ecommerce de billetes.

Cantro

#24 Te ha faltado meter un arquitecto, pero es más o menos como operamos nosotros. La gente no tiene ni la más remota idea de lo que puede llegar a costar una web de las grandes, y eso recortando gastos como cabrones.

ccguy

#24 Qué horror lo de analistas y programadores. Es lenguaje de consultora del siglo pasado.

Yo espero y doy por hecho que los datos de la web de renfe, o cualquiera seria, no están a cargo del equipo que gestione esa web. Desde luego precios, disponibilidad, horarios, etc, todo eso que no se usa sólo para dar servicio al usuario de internet sino que es información de la que depende el propio funcionamiento del servicio, no pinta nada a cargo de un equipo web.

M

#13 Si han contratado eso no es una barbaridad, pero dudo mucho que hayan contratado eso, como es habitual en Everis, Indra y compañia lo que tendrán serán muchos becarios sin puñetera idea de lo que hacen.


Eso sí, tendrán un jefe de proyecto que cobrará 200.000€ al año o más sin saber encender un PC, pero que será un crack vendiendo humo y exigiendo horas extras gratis.

Si han contratado eso que dices, después de pagar salarios a los curritos no queda un euro para pagar directivos ni tener beneficios. Cosa harto improbable, que a los directivos no los van a despedir y gratis tampoco van a atrabajar. Sería más lógico empezar deduciendo lo que van a cobrar los de arriba y lo que se van a repartir en beneficios y ver cuanto queda para salarios de los que hacen el trabajo (que es como lo hacen ellos).

i

#18 Me da igual que hagas números con 2 desarrolladores senior de Frontend que saben lo que hacen a 30.000€ al año, o que metas 4 desarrolladores junior de Frontend que hacen y rehacen y deshacen y hacen por 15.000€ al año. El coste es el mismo: 60.000€.
El jefe de proyecto nunca gana 200.000€ porque ni un CTO lo gana. Eso sí, si un jefe de proyecto tiene que estar constantemente encima de los 4 juniors para que no metan la gamba, y encima en un año se le largan dos, y tiene que formar a otros dos...lo menos que puedes es tener contento a ese jefe de proyecto porque yo "ni por todo el oro del mundo" me gustaría estar en su pellejo. Prefiero ser jefe de proyectos de un equipo de 2 senior que cuesten en total 60.000€ que ser un jefe de proyecto de un equipo de 4 becarios que cuesten un total de 60.000€ que están constantemente rotando.

"Contratando eso que digo", sale unos 500.000€ de gasto. Hasta 600.000€ hay un buen pico. El truco de Everis es explotar al máximo a su gente para que en vez de necesitar 18 meses de desarrollo se queden en 14 meses. Esos 4 meses que se ahorran es beneficio. Pero ojo, que si se encuentran con problemas, Renfe empezará a meter penalizaciones por retraso de entrega. Y también hay que contar con ello.

Cantro

#7 Yo trabajo en webs como la de Renfe y cosas mayores. Bueno, pues sólo en licencias de software, sin empezar a meter mano en hosting (que AWS y Azure no son baratitos) y antes de hacer nosotros nada, ya puede ir la factura por los seis ceros tranquilamente.

Tenéis una idea pero que muy equivocada de las cantidades en las que se mueven los sitios grandes.

Duke00

Titular erróneo para ganar clicks, no perdáis el tiempo haciendo pruebas, aún no terminaron de renovarla ya que serán varias fases:

"la compañía ha informado de que lo que estamos viendo es el inicio de "un proceso de transformación de la web que irá evolucionando en los próximos meses, hasta finalizar el proyecto total de trasformación de la página""

El_Cucaracho

Yo he comprado billetes de renfe en la web y ningún problema ¿Cuáles son los fallos habituales?

squanchy

#5 Intenta hacerlo cuando hay promociones, o cuando salen a la venta los billetes de navidad.

El_Cucaracho

#8 ¿Es un problema con las macros o los procesos automáticos?

squanchy

#9 Mayormente, de rendimiento. A partir de cierto volumen de consultas/transacciones, la web se cuelga, las consultas de trenes tardan horrores en aparecer, etc., haciendo imposible algo tan simple como consultar los trenes de ida, los de vuelta, seleccionar dos y comprarlos.

i

#10 Curioso...supongo que dependerá de la optimización de las consultas, no tener cacheadas peticiones, y no contar con réplicas de lectura de Base de Datos...

squanchy

#14 Es complicado aventurar qué podía ir mal sin poder depurar para analizarlo. La carga de información que debe soportar el sistema tampoco es tremenda: los billetes de los próximos 3 meses (más adelante no deja reservar), y los itinerarios de esos trenes. El resto puede estar en una base de datos secundaria (el histórico).

Piensa que hay sistemas como los bancarios o los de telecomunicaciones que soportan miles de registros nuevos cada día: cada ingreso/reintegro, cada llamada/sms/conexión a internet, etc. A su lado, la web de renfe es un paseo.

i

#19
La carga de información que debe soportar el sistema tampoco es tremenda: los billetes de los próximos 3 meses (más adelante no deja reservar), y los itinerarios de esos trenes.
Esta frase indica que no sabes como funciona por dentro una base de datos. No se "cargan informaciones". Ni se cargan "billetes". Tienes, si es una base de datos relacional, una serie de horarios guardados en diversas tablas que se consultan para obtener los horarios posibles para tu trayecto. No se cargan por meses. De todas formas, el problema de una base de datos no es ni mucho menos la información estática guardada en ellas. Es la cantidad de peticiones/consultas que hacen Hit contra la base de datos por segundo.

Piensa que hay sistemas como los bancarios o los de telecomunicaciones que soportan miles de registros nuevos cada día: cada ingreso/reintegro, cada llamada/sms/conexión a internet, etc. A su lado, la web de renfe es un paseo.
El precio de un sistema bancario es prohibitivo, por eso, entre otras cosas, los bancos tienen su propio equipo de programadores. El Santander tiene en plantilla mas de 100 desarrolladores para mantener su sistema. Ya puedes ir haciendo números de cuanto sale un sistema bancario, y verás que 600.000€ es un paseo.

squanchy

#21 lol Qué a pecho te lo tomas. Estoy empezando a sospechar que perteneces a ese equipo de desarrollo.

i

#22 Nop. Simplemente no me gustan los cuñados de barra de bar que hablan sin pensar como te he ido demostrando.
¿Por qué soy directo con comentarios de cuñados con respecto a tema de programación? Porque comentarios como los tuyos ayudan a que se siga pensando que hacer una web es un plisplás y que por tanto 600.000 es una puta pasada. Espero que con comentarios como los míos, argumentados, sirvan para contrarrestar los tuyos. ¿Y por qué me importa? Porque tenemos en España, no es mi caso, a compañeros informáticos penando por 15.000€. Y están penando por 15.000€ porque se sigue pensando y se sigue (malamente) diciendo (como tú haces) que una Web es "barata" de desarrollar.
En USA, por ponerte un ejemplo, un desarrollador junior (dependiendo del estado) puede ganar unos 100.000$ anuales. ¿Por qué en España un junior pilla 15.000€ y en USA 100.000$? Porque en España se subestima el coste de una web y la Renfe no pagaría 1.5M por el desarrollo de su web. Que es mas o menos el coste de lo que le costaría en Alemania, UK o Francia, o USA.
Tus comentarios hacen daño a compañeros y amigos. Y de ahí mi intento de contrarrestar tu desinformación.
Mi vida por fortuna está en otros niveles, ganando esos 200.000 al año y pudiendo dedicar mi tiempo libre a comentar en Menéame. Mientras otros, a estas horas, están currando en Everis hasta las 20:00 de la tarde...o más si tienen que entregar un proyecto.
Saludos IT.

M

#25 Luego te encuentras con webs que han costado unos 14 millones de euros y que los que han programado el frontend no saben para lo que sirve el doctype, que no contiene la etiqueta , que no saben que meter 1000-2000 líneas de CSS y otras 1000-2000 líneas de javascript incrustado en el código no es buena idea, entre otras cosas porque penaliza el tiempo de carga (así la página tardaba ~2 minutos en terminar de cargar)

En concreto recuerdo esa, porque me pilló estudiando una asignatura optativa de sobre programación web (PHP+HTML+CSS+Javascript), la web del congreso de 2007, la critican, por ejemplo, aquí (en temas sobre todo de usabilidad):
https://www.torresburriel.com/weblog/2007/06/17/la-web-del-congreso-espanol-hace-aguas/
y aquí analizan el código HTML:
https://www.anieto2k.com/2007/06/14/la-nueva-pagina-web-oficial-del-congreso/

Si tienes ganas de ver de lo que son capaces unos programadores frontend de un proyecto de 14 millones de euros puedes ver el código HTML original de entonces aquí, flipante:
https://www.anieto2k.com/wp-content/uploads/2007/06/congreso.txt

13 años después han arreglado muchos fallos (no se sabe si con sobre costes o no), pero en lo que a diseño se refiere ya estaba obsoleto entonces y no ha cambiado, así que imagínate ahora: http://www.congreso.es/portal/page/portal/Congreso/Congreso
(La url, como ves, debió idearla un Hingeniero con master en Harward por lo menos, ¿lo haría así por el SEO, porque repetir palabras les da "fuerza"?)

¿En serio asegurarías que los que programaron eso eran algo más que aficionados al Dreamweaver? De hecho, si supones que eran aficionados al Dreamweaver pero sin ni puta idea de lo que es el código HTML se explican gran parte de los errores, como repetir el Doctype (porque Dreamweaver lo pone si creas una página y construyes tu página juntando varios fragmentos varias páginas), el borrar el doctype y el html en la página (les dijeron, "hay que borrad el html, body, header de las 'páginas internas', pero el de la 'externa' no vayas a borrar el header y el body que la liamos", y no borró el header ni el body, pero borró el doctype y el html), el meter el CSS y el javascript directamente incrustado en el código (con algunos editores visuales es, o era, más fácil hacerlo así que de la manera correcta), que haya código CSS repetido que aparece de forma consecutiva (¿este trozo de CSS lo había metido?, venga, lo meto otra vez que no sé donde mierda se pone), y puedes seguir así un buen rato.

Que sí, que programarla bien costará una pasta, pero es que rara vez se hace ni remotamente bien, y no es el caso de esta ni de muchas otras webs de coste millonario.

D

Y los sobres que han caído con el supercontrato? lol Cuanto chorizo y cuan pocas balas !!

D

#30 Correcto. Pero no se podia saber , las webs multiidioma son un campo experimental todavia

D

Yo vi esta funcion, q maneja la opcion de elegir valenciano en el header (que si no recuerdo mal se comprueba si esta desplegado buscando la clase con un setinterval de 1000) y ya me hice a la idea de como/quien lo ha hecho y no hizo falta mirar mas para ver que poco son 700k.

Si le hubiesen metido 800k podrian haber hecho mas QA y alguien se habria dado cuenta de que la Ñ de Coruña sale un cagarro con otra codificacion.

Y sospecho que si te echas un rato mirando, es la punta del iceberg


function valen()    
   var liACopiar = lis[i].cloneNode(true);
   
   nuevoLi = liACopiar;
   i = lis.length;
  ">

 }
 var hrefOriginal = nuevoLi.firstElementChild.getAttribute('href');

 if(hrefOriginal.indexOf('/es/es') >= 0)

zetch

#28 Que no falten las funciones patrias en español.

pozoliu

Voy a rescatar los comentarios que hice en su día -> renfe-lanzara-junio-nueva-web-vendera-billetes-ano-antelacion/c02#c-2

Hace 4 años | Por --491272-- a eleconomista.es


En fin demasiado previsible era pero bueno... por lo menos no me llevo chasco

D

Primera prueba, las estaciones las carga rápidamente. Quiere decir que por lo menos han creado algún tipo de caché nueva. El multiidioma sigue siendo la rision. Si pones la web en inglés y tratas de comprar un billete, más te vale saber algo de español, porque vas a encontrar partes importantes que no están traducidas. De la parte de comprar billete casi nada está traducido.

Simulando comprar un billete, si, las opciones son las mismas. El backend no parece haber cambiado. Si algún día llegó al punto de comprar un billete ya veré que más han cambiado.

D

#2 https://ssl.renfe.com/comprabilletes/js/estacionesEstaticas.js?v=11

La cache de la que me hablas es un array en js, no carga al irte al dropdown sino con la pagina. Las carga rapido pq ya las tiene danzando por ahi.

D

#29 Buff, vaya chapuza.

Bueno, eso al menos explica que al cambiar el idioma no cambie el nombre de las estaciones, como Madrid (Todas). No querían enviar una lista distinta por cada cliente

D

Por 600.000 euros pintamos los coches de correos con la bandera de colorcitos de los homosexuales para hacer campaña.