La vida de un proyecto web entre el kickoff y su primera alerta de seguridad
Por Jaime De La Cruz
Todos hemos estado en esa reunión: el cliente llega con una referencia abierta en el celular, quiere algo parecido, más moderno, que se vea bien en el teléfono y que se sienta “dinámico”. Todos asienten, alguien anota “look & feel” en la minuta y el proyecto arranca.
Y ahí, en el minuto uno, se toma la decisión más cara del proyecto sin que nadie la note: tratar un problema de negocio como si fuera un problema de diseño.
Tomemos un caso reciente: el sitio de una organización sin fines de lucro, seis secciones, cuatro meses de proyecto, nada extraordinario en papel. Lo cuento justamente por eso: es un proyecto normal, y en los proyectos normales es donde el patrón se ve con más claridad.
Acto 1: lo que se pidió y lo que se necesitaba
Sube el telón: El requerimiento inicial decía, casi textual, que el sitio debía parecerse al de la organización global y funcionar bien en móviles. Ese era el pedido.
Pero en las notas de ese mismo levantamiento estaba el proyecto real: recibir donaciones con pago seguro y prevención de fraude, una sola persona del equipo encargada de publicar todo el contenido, un sitio en español y en inglés, y alguien que respondiera cuando algo fallara durante el primer año.
Nada de eso es diseño; es operación. Es dinero entrando, una persona sin perfil técnico publicando sola y una organización que no puede darse el lujo de quedarse sin sitio. Cierra el telón.
La lección para quienes trabajamos en proyectos digitales es esta: muchas veces el requerimiento inicial describe lo que el cliente puede ver, pero no necesariamente todo lo que el negocio necesita. El trabajo del kickoff no es solo tomar nota del pedido; es descubrir la operación que existe detrás.
Acto 2: el 4% que todos miran
Sube el telón: El plan del proyecto tuvo 117 tareas: 5 fueron de diseño visual, 17 de desarrollo, 15 de rondas de ajustes con el cliente y 71 de preparación y ejecución del lanzamiento.
Lean ese número otra vez. El diseño, la parte que se discute en todas las reuniones, fue el 4% de las tareas. Más de la mitad se fue en preparar el día en que el sitio sale en vivo, para que nada se rompa.
Y en medio apareció el clásico: el dominio con el que la organización se había presentado durante años no estaba bajo su control. Hubo que comprar uno nuevo a menos de dos semanas del lanzamiento.
Esto pasa más de lo que el sector admite: a veces el dominio lo registró un proveedor anterior, a veces un ex-empleado o a veces el sobrino que sabía de computadoras. Nadie lo documentó porque nadie pensó que importara, hasta que importa, y ese día no hay diseño que lo resuelva. Cierra telón
La arquitectura de un proyecto no son solo servidores y código; es saber quién es dueño de qué (dominio, hosting, accesos, cuentas de pago). En gestión de proyectos tecnológicos, esto forma parte de la gestión de configuración: saber qué activos existen, quién los controla y qué depende de ellos. Si esa pregunta no se hace al principio, alguien la va a tener que contestar al final, con prisa y sin opciones.
Acto 3: el día diecisiete
Sube el Telón: El sitio salió en vivo en la fecha prevista. Así terminan la mayoría de los proyectos en nuestra industria: con la foto del lanzamiento.
Diecisiete días después, un sábado a la 1:42 de la madrugada, el monitoreo detectó un plugin vulnerable en el sitio.
No hubo llamada del cliente. No hubo queja. Nadie del lado de la organización lo habría visto, porque nadie tenía por qué estar mirando. Esa es la parte incómoda: las vulnerabilidades no avisan, no respetan horario de oficina y no les importa que el sitio sea nuevo. Cierra Telón
Un sitio web no se termina el día del lanzamiento. Ese día empieza a envejecer. Cada plugin, cada integración, cada dependencia tiene su propio calendario de actualizaciones, y ninguno está sincronizado con el tuyo.
No es solo una precaución operativa. OWASP (Open Worldwide Application Security Project) incluye los componentes vulnerables, desactualizados o sin mantenimiento dentro de los riesgos asociados a la cadena de suministro de software y recomienda monitorear continuamente las vulnerabilidades de las dependencias utilizadas en una aplicación.
Si el proyecto se presupuestó para lanzar y no para vivir, alguien va a encontrar esa vulnerabilidad. La única pregunta es si será tu equipo de soporte o alguien con peores intenciones.
Lo que queda cuando se apagan las luces
Tres actos, tres decisiones. En el kickoff, entender qué negocio hay detrás del pedido. En la construcción, saber quién es dueño de cada pieza. Después del lanzamiento, tener a alguien mirando cuando nadie más mira.
Ninguna de esas decisiones aparece en un mockup. Ninguna sale en la presentación de avance. Y las tres definen si ese sitio va a funcionar dentro de tres años o si vamos a estar otra vez en la misma reunión, con otra referencia abierta en el celular.
Muchos proyectos digitales no fallan por feos. Fallan por todo lo que nadie preguntó mientras se discutía si el azul era el correcto.
No es diseño. Es negocio.
Jaime De La Cruz
CEO y socio de BlueTide, Profesional en Gestión de Proyectos y Arquitecto de Negocios