Hazlo

El otro día vi la charla de Ricardo Baeza y en un momento él da algunos consejos que le han servido en su carrera, como por ejemplo, “no hagan planes, no se proyecten …. si yo hubiera imaginado que iba hacer en mi vida no estaría aquí en este momento… porque cuando uno se proyecta lo hace en algo más pequeño, porque cree que así lo va a lograr. Porque uno no se atreve a ponerse una meta muy grande, porque ¿qué pasa si no llego a esa meta, me voy a frustrar? No”.

También aconseja a ser flexibles, a reinventarse. Aceptar que los errores muchas veces no lo son, simplemente es falta de información, o decisiones que se toman con la información que se cuenta en ese momento.

Pero el consejo que Ricardo Baeza considera más importante es: “no piensen en lo que tienen que hacer, ¡háganlo!”. ¿Cuánto tiempo hemos perdido en pensar lo que tenemos que hacer, en cómo hacerlo, cuando todo ese tiempo lo podríamos haber aprovechado en hacer lo que debíamos?.

Hazlo

Cuando uno desarrolla software el “hazlo” corresponde a entregar el producto, o servicio, en la fecha comprometida. En inglés dicen Ship It, ¡entrega la maldita aplicación!

En palabras de Jeff Attwood: “Version 1 Sucks, But Ship It Anyway” (“La versión 1 apesta, pero entrégala de todas maneras”).

Todo proyecto está plagado de dificultades:

• La planificación era muy agresiva y demasiado corta. ¡Necesitamos más tiempo!
• Encontramos problemas técnicos no previstos que nos forzaron a hacer compromisos con los que no estamos conformes.
• Teníamos un diseño erróneo, y necesitamos cambiarlo en medio del desarrollo.
• Nuestro equipo experimento fricciones internas entre sus miembros que no anticipamos.
• Los mejores programadores abandonan el equipo porque encontraron una mejor oferta económica
• Los clientes no respondían a nuestras solicitudes de información a tiempo.
• La gente de infraestructura y de desarrollo no se comunicaban adecuadamente.
• El tiempo de respuesta de los proveedores no era el que ofrecieron inicialmente.
• Usamos una tecnología que fue descontinuada en la mitad del proyecto.

Los problemas son miles. Los registros en correo electrónico dejan una traza de cientos de mensajes diarios, y varios gigabytes de discusiones, aclaraciones, documentos, pantallas, informes, cientos de revisiones a la carta gantt, una larga lista de bugs y correcciones.

“Al final del ciclo de desarrollo finalizas con un software que es una pálida sombra del brillante, glorioso monumento a la ingeniería de software que visualizaste al empezar.”

Y la tentación de tirar la toalla, como dice Attwood, es grande, y pedir más tiempo para poder completar lo que falta es el mayor error que se podría cometer, ¡porque los verdaderos desarrolladores entregan!

Hay muchos errores de los que todavía no sabes nada, pero ¿cómo vas a enfrentarlos si aún no entregas el software? No es el mejor producto, puede que consideres que es el peor servicio que has entregado, pero a veces peor es mejor.

Un software, un servicio que se usa, que es entregado, que ha sido liberado a sus usuarios es mejor que aquel que sufre la enésima reprogramación para entregar un “producto de calidad”.

Todo esto a propósito de un hito que cumplimos con mi equipo, precisamente hoy. Porque se trata de un servicio que entró en operaciones en la fecha comprometida, lo entregamos, lo hicimos. Aún faltan cosas, tenemos nuestra lista de bugs y pendientes, seguiremos trabajando por meses, pero lo esencial está allí.

We shiped it! Los usuarios ya lo están usando, el servicio está en el aire. Entregamos, ¡lo hicimos!, un sistema funcionando, lo logramos y se siente bien 😄