Supongamos que queremos hacer el sitio web de tarjetas de cumpleaños en línea más simple del mundo. Los visitantes llegarán al sitio, ingresarán el nombre y la dirección de correo electrónico del destinatario previsto junto con un mensaje personal y presionarán el botón «crear», lo que hará que el destinatario reciba un enlace por correo electrónico. Cuando hagan clic en el enlace, serán llevados a una página donde verán:
Querido [su nombre], ¡Feliz cumpleaños! [mensaje personalizado]
Este texto se mostrará encima de una imagen de un elefante sosteniendo un globo. Lindo, ¿no? ¿Cómo redactaríamos nuestros requisitos de tal manera que pudiéramos pasarlos a un desarrollador? Bueno, para ser honesto, lo acabamos de hacer en el texto anterior, nos parece como una especificación bastante completa que es lo suficientemente clara como para que cualquiera que no estuviera tratando deliberadamente de malinterpretar supiera lo que buscábamos. ¡Bien! Así que se lo pasamos a un desarrollador, junto con la imagen del elefante para que lo use, y una maqueta que muestra qué colores y fuentes usar para el texto, y se ponen a trabajar.
Entonces viene el primer problema. No incluimos qué hacer con los mensajes largos. Cuando un usuario ingresa más de 50 palabras, el texto se derrama por la parte inferior de la imagen del elefante. ¡Se ve terrible! Pero no pasa nada. Esto nunca fue diseñado para mensajes largos. La intención era permitir que las personas escribieran notas cortas y personalizadas. Así que impongamos una regla que obligue a los usuarios a escribir más de 50 palabras. De acuerdo, dice el desarrollador, eso debería ser lo suficientemente fácil de implementar, y solo tomará una hora más o menos agregarlo.
Todo está bien, entonces. Excepto que, cuando se entrega la nueva versión y comenzamos a jugar con ella, descubrimos que solo te enteras cuando intentas presionar el botón de crear si has superado el límite de palabras. Pero, igualmente, es muy difícil estimar cuántas palabras has escrito, y es un dolor contar las palabras una y otra vez a medida que avanzas. Entonces, a menos que tenga un mensaje realmente corto, esta cosa es bastante molesta de usar. Lo que sería mejor sería que hubiera un pequeño contador que te dijera cuántas palabras has escrito a medida que avanzabas, y tal vez se pusiera rojo cuando tuvieras menos de 5 palabras para hacer. Ahora, seamos claros: nadie pretende que hubiera algo sobre un contador de palabras en los requisitos originales. Pero ahora que tiene una versión funcional de la aplicación frente a usted, ha quedado claro que la aplicación no es adecuada para su propósito sin el contador, simplemente no es una experiencia divertida de usar, por lo que no tiene sentido tener la aplicación a menos que tenga un contador. Le explicamos esto al desarrollador, y suspiran y dicen que pueden agregar un contador, pero llevará un tiempo. Verás, según la especificación original, construyeron todo usando un lenguaje del «lado del servidor», pero el contador de palabras requiere un procesamiento del «lado del cliente», por lo que deberán configurar algunas cosas que les permitan usar un lenguaje del lado del cliente. Pero se ponen manos a la obra, y trabajan un poco hasta tarde, y lo consiguen, y ahora tienes la versión 3 de la aplicación, con un contador brillante y todo está bien…
Excepto que, cuando intentamos usar la aplicación en el mundo real, el primer cumpleaños que aparece es nuestro amigo británico Mountford Cuthbert Beringer-Fortesque. Desafortunadamente, debido a la forma en que el texto está colocado en la página, su nombre aparece como «Mountford Cuthbert Beri» cuando mira su tarjeta electrónica. ¡Ajá! Este es un error, seguramente: la especificación dice claramente que la tarjeta debe mostrar el nombre del destinatario, no parte del nombre. Se lo señalamos al desarrollador y le pedimos que arregle su trabajo. El desarrollador, un poco fríamente, señala que en la maqueta que proporcionamos especificamos un tamaño de fuente y solo dejamos espacio para una línea de texto. Con ese tamaño, los nombres largos no caben en una sola línea. La especificación no decía qué hacer si el nombre no cabía en una línea. El desarrollador no puede torcer las leyes de la física para que se ajusten a lo que no es apto. Suspiramos. Nos parece bastante obvio, en retrospectiva, que si el texto no cabe en el cuadro, debe cambiarse de tamaño para que se haga más pequeño hasta que quepa. Le pedimos al desarrollador que lo haga por nosotros, momento en el que el desarrollador se queja de que si hubiera sabido que necesitaríamos ese tipo de cosas, lo habrían construido todo de manera diferente. Resulta que, si bien es trivialmente fácil para las páginas web cambiar el tamaño de las imágenes para que se ajusten al espacio disponible, es mucho más difícil hacerlo con texto. El desarrollador dice que pueden poner un «truco» en su lugar para que funcione con nuestra configuración actual, pero lo que realmente deberíamos hacer es mover todo el proceso de generación de tarjetas al lado del servidor. De lo contrario, este tipo de cosas seguirán ocurriendo. Le prometemos al desarrollador que realmente no habrá más cambios después de esto, así que sigamos adelante con el truco y dejémoslo. El desarrollador se queja un poco, pero se va a investigar cómo hackear el cambio de tamaño del texto para que se ajuste. Finalmente se les ocurren algunos trucos, y finalmente todo está terminado.
Exceptuando… Podría extender este escenario indefinidamente. Es, por supuesto, un ejemplo trivial y artificioso, basado en un requisito trivial y artificial, pero espero que sirva para ilustrar lo fácil que es pasar por alto algo al elaborar una especificación para el software, y lo rápido que se acumulan las ramificaciones. En el punto donde lo dejamos anteriormente, nuestra entrega de software estaba muy retrasada, nos habían dicho que se había construido de la «manera incorrecta» y que ya debería ser reconstruida, y habíamos logrado agriar un poco las relaciones con nuestro desarrollador. Nuestro proyecto no ha sido un gran éxito, la verdad. Aunque, quizás lo más deprimente, nuestro proyecto ha sido tan exitoso como el proyecto de software promedio.
Deja una respuesta