La razón por la cual este artículo está acá es porque una gran mayoría de los proyectos de software nunca se concluye correctamente. Ya sea por demoras, gastos extra o requerimientos cambiantes, los proyectos de software son muy suceptibles al fracaso, tanto por culpa de los programadores, clientes, o ambos. Por ello vamos a hablar sobre pautas básicas para evitar esta clase de problemas.

“Haciéndolo Realidad” es la traducción del título del libro “Getting Real” publicado por 37signals. El libro describe una excelente metodología para “desarrollar aplicaciones web de manera inteligente, rápida y fácil” y es tan interesante que nos parece que ningún diseñador web debería dejar de leerlo.

Por un lado, los invitamos a leerlo aquí, cuando tengan algo de tiempo libre, pero a continuación vamos a destacar algunos de los ensayos que nos parecieron más interesantes.

Básicamente la filosofía de Getting Real se basa en el desarrollo de software tan sencillo como sea posible. Software elegante e inteligente que haga justo lo que las personas necesitan y nada más. Compartimos la idea de que la mayoría del software es muy complejo. Demasiadas funcionalidades, demasiados botones, demasiada confusión. Las interfases son inentendibles e inusables. Entonces, ¿por qué no concentrarnos en hacer un producto básico excelente en lugar de uno súpercompleto y mediocre?

Si bien existen otras metodologías de desarrollo de software que ya hablan de “construir menos”, como eXtremme Programming, no lo proponen desde la conveniencia del usuario, sino del proyecto y del desarrollador.

Las siguientes son algunas de las propuestas de Getting Real que más destacamos:

Construir menos

Contraimente al pensamiento tradicional, GR propone construir menos que la competencia: menos funcionalidades, menos opciones/preferencias, menos gente y estructura corporativa, menos reuniones y abstracciones y menos promesas. Creemos en esto ya que al construir menos tenemos una puerta abierta para focalizarnos en la escencia del producto que deseamos construir. Y queremos destacar que captar esa escencia no es nada fácil; los programadores tradicionalmente tienden a analizar demasiado y a preveer situaciones futuras que sólo serán necesarias en el 1% de los casos.

Fijar tiempo y presupuesto, Flexibilizar el alcance

Todo proyecto de software comparte estas tres variables: tiempo, presupuesto y alcance. Y la recomendación es que, si tenemos problemas, no invirtamos más tiempo o dinero en él; simplemente reduzcamos el alcance de nuestra aplicación. Lanzar en tiempo y en presupuesto, con alguna funcionalidad menor que lo originalmente planeado siempre es mejor que lanzar un producto mediocre y lleno de bugs tan solo por el hecho de necesitar cumplir con tiempos y presupuestos ridículos.

Que no sea una carga

Este punto nos pareció importantísimo. Nuestra pasión, o la falta de ella, se traslucirá a través de nuestra aplicación. Mientras menos sea una carga, mejor será el producto final.

“Si la aplicación no nos exita, algo anda mal. Si solo trabajamos por el dinero, se notará”.

Menos masa

En cinemática (una rama de la física) aprendemos que cuanto mayor es la masa de un cuerpo en movimiento, mayor energía necesitamos para detenerlo o cambiar su dirección. Esto también es cierto en el mundo del desarrollo de software.

Los cambios son todo un tema para la ingeniería del software y son una de las tareas que más disgusta a los integrantes de un proyecto. Y es cierto, a nadie le gusta cambiar lo que hizo, sobre todo si invirtió un tiempo y esfuerzo considerables en realizar la tarea original.

Para que esto no se convierta en un problema, los cambios simples y baratos. Si un cambio no resulta simple y barato significa que no estamos llevando el proyecto por el camino correcto, y tal caso sería bueno revisar qué estamos haciendo mal. Si no podemos hacer cambios de esta forma, perderemos terreno ante un competidor que sí puede.

La masa aumenta con:

• Contratos de largo plazo
• Staff numeroso
• Decisiones permanentes
• Reuniones acerca de otras reuniones
• Un proceso denso
• Inventario (físico o mental)
• Estar limitado un hardware, software, o tecnología concretos
• Formatos de datos propietarios
• El pasado rigiendo el futuro
• Planes de acción a largo plazo
• Políticos de oficina

La masa la reducen…

• Forma de pensar “Just-in-time”
• Miembros del equipo multitarea
• Aceptar las limitaciones, no tratar de aumentarlas
• Menos software, menos código
• Menos funcionalidades
• Tamaño de equipo pequeño
• Simplicidad
• Interfaces simplificados
• Productos de código libre
• Formatos de datos abiertos
• Una cultura accesible que haga fácil admitir errores

Las ventajas de tener menos masa son importantísimas: nos permite cambiar de dirección rápidamente, focalizarnos en en las buenas ideas y descartar las malas. En fin, nos permite estar siempre un paso adelante de nuestros competidores.

Reducir el costo del cambio

Como venimos diciendo, la posibilidad de implementar cambios rápidamente nos permite diferenciarnos de nuestros competidores y estar un paso delante de ellos. Por esto es importante reducir todos los obstáculos que puedan impedir cambiar rápidamente. Rápido y barato es un arma secreta que las grandes empresas, con docenas de empleados jamás van a poder tener.

Ignorar los detalles tempranos

Los detalles son importantísimos, pero cuando estamos en la etapa inicial de un proyecto, lo importante es concentrarse en lo escencial, disponer los elementos que van en la página y hacerlo andar.

Si empezamos por preocuparnos por qué colores, qué fuente y qué tamaño tendrán los títulos de nuestras páginas, empezaremos a “desgastarnos”. Los detalles llevan tiempo y no son los escencial del proyecto.

Sin embargo, sí queremos decir que consideramos los detalles importantísimos para la calidad final de un proyecto. Un producto en donde todo funciona perfectamente, pero en el cual no se tuvieron en cuenta los detalles, es un fracaso. Si no es un problema, no te hagas problema

Es interesante esta filosofía. Muchos dirían que es poco profesional no adelantarse a los problemas. Pero es cierto que si tenemos “poca masa” que manejar, solucionar los problemas cuando aparezcan será fácil y barato.

Y creo que eso es lo que debemos tener en cuenta. Si bien no se habla de esto en Getting Real, es bueno tener una idea de los riesgos y problemas que podemos encontrar en el camino y construir de forma tal que, llegada la necesidad, podamos implementar la solución correcta rápidamente. Pero ciertamente no es válido construir un castillo cuando solo necesitamos un departamento de tres ambientes.

Simplemente, “¡NO IMPORTA!”

Cuando debemos indicar la fecha y hora de creación de un mensaje en un foro, ¿es importante indicar toda la información, por ejemplo, “11-10-07 14:54”? Simplemente, toda esa información no importa, y sería más útil para los usuarios indicar, en su lugar, “ayer” o “hace 3 días” o bien “hace 2 horas”, por más que no sea tan preciso como el caso original. Solo preocupémonos por la información que es realmente importante. Empezar con el “No”

Getting Real afirma, y con razón, que cada vez que decimos “sí” a una nueva funcionalidad estamos “adoptando a un niño”. Y tenemos que llevar a ese niño por toda una cadena de eventos hasta su madurez (análisis, diseño, implementación, pruebas, etc.).

Una de las cosas más importantes que aprendimos es que nunca debemos “regalar” funcionalidades no solicitadas en nuestros productos. Si un cliente no pidió la posibilidad de editar la lista de países que aparecen en los menúes desplegables, por más que nos parezca súper simple hacerlo, no lo hagamos. Una vez que le dimos esa funcionalidad al cliente, tendremos que mantenerla.

Cada funcionalidad debería poder probar por sí misma que es valiosa. Por ello, seamos selectivos, pongamos filtros, si una funcionalidad es realmente importante, podrá atravesarlos.

¿Podemos sostenerlo?

Este ensayo me encanta, personalmente porque lo he comprobado y aplicado en muchísimos aspectos de mi vida también. Sólo hagamos aquello que podemos sostener. Esto implica descartar muchísimas cosas, pero al hacerlo concientemente, y sabiendo por qué, no nos sentiremos mal. Por el contrario, sabremos que estamos haciendo lo correcto.

Muchas veces en nuestra vida empezamos algo con muchísimo entusiasmo y luego lo abandonamos. Puede ser cualquier cosa: clases de música, el gimnasio, llevar una lista de los gastos diarios, etc. Mi consejo es no empezar ninguna de estas actividades si no estamos seguros que vamos a poder continuarlas. Abandonar algo que se inició con entusiasmo es mucho más deprimente que nunca haberlo empezado, porque no ibamos a poder mantenerlo.

Entregas rápidas y frecuentes

En las metodologías de desarrollo iterativo, como RUP o XP, se conoce con el nombre de iteraciones a las partes en que se divide un proyecto de software para tener porciones más pequeñas y fáciles de manejar. Las iteraciones son una excelente herramienta, y es importantísimo que las iteraciones sean cortas y que entreguen un subproducto que haga algo importante y que funcione tan bien como un producto final.

Las iteraciones nos permiten concentrarnos en una funcionalidad (o en un conjunto de ellas) por vez. Por ejemplo, si tenemos que hacer un sistema de facturación muy grande, la primera iteración sería la creación de un módulo de clientes. De esta forma sólo deberíamos construir un subproducto muchísimo más reducido el cual podríamos entregar al cliente en no más de dos semanas para validar la dirección del proyecto.

De la idea a la implementación

En este ensayo Getting Real aconseja seguir el flujo ideas-bosquejos-interfaces-programación. Y ciertamente, funciona. Dibujar bosquejos en papel a partir del análisis de las ideas, luego diseñar las interfaces pensando en las necesidades de las personas y recién después pasar a implementar la programación, lo que incluye también el desarrollo de la base de datos.

La mayoría de los programadores suele empezar diseñando e implementando la base de datos o el modelo de dominio, dejando la interfaz para el final. Creemos que esto está mal ya que se le suele restar importancia a la parte más importante del programa: la interfaz. Tengamos en cuenta que nuestro producto no va a ser utilizado por expertos en bases de datos o software. Va a ser utilizado por vendedores, contadores, ingenieros industriales, arquitectos, en fin, personas. Y el punto de entrada de estas personas con nuestra aplicación será la interfaz. La interfaz es el “cuello de botella” de nuestra aplicación.

De nada sirve haber optimizado una consulta para que en lugar de traer los resultados en 3 segundos lo haga en 1 segundo. Si el usuario tarda más de 2 segundos en entender o acordarse cómo había que hacer para obtener la información que necesitaba, no servirá de nada. Y si los usuarios no se sienten exitados utilizando nuestro producto, podemos considerarnos fracasados.

Evitar las preferencias/opciones

Tan simple como eso. Limitar las preferencias en un producto al máximo lo harán más simple de utilizar.

Tiempo a solas

Getting Real resalta que es muy importante darnos cuenta cuál es el momento del día en que podemos ser más productivos. Muchas veces, durante el día sufrimos interrupciones (el teléfono, alguien que toca el tiembre, nuestra familia, etc.). Ciertamente, para ser más productivos necesitamos de un período de tiempo continuo sin interrupciones. Puede ser después de cenar, a la mañana muy temprano, después de medianoche, etc. Lo importante es encontrar un período de al menos cuatro horas en donde podamos programar sin interrupciones. Y personalmente confieso que da mayores resultados trabajar cuatro horas así que siete u ocho en una oficina rodeado de distracciones.

Buscar y celebrar pequeñas victorias

Sobre este ensayo puedo decir que, personalmente, suelo “premiarme” con un café o una salida cada vez que obtengo una pequeña victoria, como ser una nueva funcionalidad implementada, una mejora a una funcionalidad ya existente, una simplificación en el programa, etc.

La interfaz en primer lugar

Ya hablamos de esto antes, pero Getting Real dedica un ensayo especial sobre su forma de diseñar las interfaces en primer lugar. Nosotros también trabajamos del mismo modo ya que la interfaz es lo que el usuario verá en primer lugar y, si la dejamos para el final, ciertamente se notará en la calidad del producto terminado.

Diseño desde el epicentro

El objetivo de esto es centrarnos en la escencia de la interfaz. Sabemos que toda página web, por ejemplo, tiene un encabezado, barra de navegación, pie de página, etc. Obviamente, también deberemos definir los colores, las tipografías, la disposición del los elementos, etc.

Pero empecemos por el epicentro. Si estamos diseñando una página para registro de nuevos usuarios, hagamos sólo eso: un formulario para registrar nuevos usuarios. Y esto no implica modificar la fuente ni los colores predeterminados del navegador ni la necesidad de meter toda la página dentro de una tabla (créanme, lo he visto).

Solución para los tres estados

Algo que muy pocos saben o tienen en cuenta es que la mayoría de las aplicaciones, sobre todo hablando de aplicaciones con bases de datos, tienen tres estados:

• Vacío: Este es el estado inicial de toda aplicación. Cuando los usuarios utilicen nuestro programa o sitio web por primera vez, lo verán vacío, sin datos, sin información. Y este estado es tan importante que es el que les dará la primera impresión a los usuarios. Por ello, debemos pensar cuidadosamente qué se mostrará cuando el programa se inicie por primera vez o cuando alguna pantalla no tenga datos.

  Por lo general se suele dejar una tabla vacía o colocar un mensaje de “0 productos”, pero esto no es muy estimulante para los nuevos usuarios. Muchas aplicaciones web, por ejemplo, han elegido resolver este estado inteligentemente mostrando una imagen, con una marca de agua que dice “EJEMPLO”, de cómo se vería esa página si tuviera datos.

  Otra alternativa sería no intentar mostrar una pantalla de listado de “cero productos” sino que, directamente, mostrar el formulario para agregar el primero a la lista.

• Regular: Este es el estado para el que solemos diseñar generalmente. Es el estado en el cual se encuentra una pantalla cuando ya se ha empezado a trabajar en ella y ya tiene información.
• Error: Finalmente, es importantísimo diseñar para cuando las cosas anden mal. ¿Qué tipo de errores vamos a informar? ¿Dónde vamos a mostrar los mensajes de error? ¿De qué forma? ¿Qué pasará con el resto de la página si hay un error? ¿Y los datos que cargó el usuario en el formulario?

Ciertamente todavía hay mucho más Getting Real para leer, pero quisimos solo destacar lo escencial para lo que nos compete. No dejen de leer este excelente trabajo.