Manuel Zapata
Habían pasado unos 3 meses aproximadamente. No es por nada, pero el código me estaba quedando hermoso. La arquitectura tenía varios de esos patrones que había visto en mis clases de ingeniería de software.
¿Y las pruebas unitarias? ¡Claro que tenía unitarias! Por poco me saco un ojo, pero logré hacerlas funcionar.
Se podría decir que todo iba viento en popa. Tomé un curso de Google Adwords, y con eso esperaba, ingenuamente, resolver todas las necesidades de mercadeo digital de mi proyecto.
¡Llegó el día del lanzamiento!
Tristemente, la única visita que tuvo mi aplicación fue la de una bola gigante de heno que nunca se quiso ir.
Ese día el software no importó. Ese día daba igual que tuviera la mejor aplicación del mundo. Los problemas de mi negocio eran mucho más profundos que eso.
Esta historia comprime todos los errores que en una clase de “Introducción al emprendimiento” te dicen no cometer. Sin embargo, de eso no se trata este post.
Este post se trata de cómo los desarrolladores tomamos malas decisiones pensando que la tecnología que es el fin, cuando en realidad es un medio.
Este post intenta mostrarte que el software no lo es todo.
Comodidad vs necesidad
¿Saben de qué se trataba la aplicación?
Era una tienda virtual pensada para colombianos en el exterior que querían enviar regalos a sus seres queridos en el país.
De la frase anterior resaltan dos palabras: tienda virtual. Repito: ¡tienda virtual! ?
¿Saben de qué tipo de aplicaciones está lleno internet? Exacto. De tiendas virtuales y gestores de contenido.
A pesar de esto, decidí invertir 3 meses a aprender PHP 5 y Symfony, y a desarrollar desde cero un sistema que podía contratar, o bajar de internet y personalizar en unos días.
La verdad, me acuerdo y todavía me cuesta creerlo.
Pero he pensado muchas veces porque lo hice, y 10 años después por fin entendí la razón.
Lo hice porque era cómodo.
Como desarrollador que soy, era lo más cómodo que podía hacer. Soy bueno desarrollando, y se me da muy bien aprender nuevas tecnologías.
Además, representaba un reto técnico interesante. Me preguntaba cómo sería construir una aplicación web desde cero hasta que estuviera pública en internet. Antes de eso, solo había hecho aplicaciones internas para empresas.
Ja, ¡puro cuento! Eso último que acaban de leer es cuento.
¿Ahora sí la verdad?
La verdad es que tenía miedo de hacer el trabajo que se requería. En vez de eso, me dediqué a lo que era más fácil de hacer para mí.
El trabajo en que debía enfocarme era validar y probar mi idea. Es decir, tenía que hablar con mi mercado potencial. Tenía que ver si las personas estaban dispuestas a pagar por mi servicio. En fin, muchas cosas más allá de invertir varios meses en desarrollo.
Esto muestra como muchas veces huimos de las cosas que necesitamos hacer porque nos incomodan, y nos refugiamos en lo que siempre hemos hecho. Es cierto que se requiere práctica y destreza para hacernos muy buenos en algo. Sin embargo, algunas veces tenemos que dejar de lado eso que sabemos hacer, y dedicarnos las cosas que nos llevarán al siguiente nivel.
La tecnología no era el propósito de ese proyecto. Era solamente el mecanismo, el canal para hacer viable la idea de negocio. Sin embargo, cometí el error de enfocarme 100% en la tecnología y dejar de lado las actividades importantes para convertir el negocio en realidad.
Generar valor
Recuerda, no se trata de ti. Se trata de lo que necesita tu negocio, tu jefe, tu cliente o tu usuario para ser exitoso.
Esto debería siempre guiar tu proceso de tomar de decisiones y priorización.
Por ejemplo, imagina que quieres implementar una arquitectura muy compleja que garantiza el crecimiento futuro de usuarios de la aplicación.
Puede que eso sea lo que el sistema requiera en el largo plazo. Pero entonces deberías preguntarte: si me paso dos meses encerrado implementando esta arquitectura, ¿qué va a hacer la gente con esto? ¿Acaso el ejecutivo comercial va a poder hacer demos? ¿O mis usuarios van a poder dar retroalimentación del proceso? Se complica la cosa, ¿cierto?
Esto no significa que tengas que dejar la buena arquitectura que planeaste a un lado.
Pero sí significa que muchas veces tendrás que priorizar y enfocarte en lo que más puede generar valor en un tiempo dado. Así esto implique hacer de lado esa maravillosa idea técnica que querías implementar.
Lo nuevo no siempre es lo mejor
Hace varios años, cuando trabajaba en un banco, descubrí que uno de sus sistemas más importantes estaba hecho en COBOL. Para los que no lo conocen, es un lenguaje de programación con más de 50 años de antiguedad. Suena a prehistoria, ¿verdad?
Yo, recién graduado de una universidad, que venía de un mundo aplicaciones y servicios web, no lo podía entender. Me preguntaba ¿Cómo era posible? ¿Cómo pueden funcionar así?
Tiempo después entendí la razón, y fue más simple de lo que pensaba.
¡Porque funcionaba! La razón por la que aún tenían el sistema era porque funcionaba. El sistema llevaba funcionando de manera estable y confiable por muchos años. Así de sencillo.
Como desarrolladores queremos cambiar las cosas “porque si”. Porque salió una nueva versión de JavaScript. O porque salió la versión 8000 del framework Y. O sencillamente, porque un fulanito famoso dice que X plataforma es el futuro. Sólo porque sí.
Cambiar las cosas solo porque nuestros gustos técnicos cambiaron o porque queremos usar lo más cool, no son razones válidas. Al menos no para el negocio. Excepto que logres encontrar una justificación técnica muy importante.
Antes de cambiar lo que ya funciona, pregúntate dos cosas:
- ¿La plataforma o lenguaje existente está causando algún problema que impide el crecimiento de la aplicación o del negocio?
- ¿La nueva plataforma o lenguaje va a proporcionar alguna ventaja competitiva que no nos permita la actual?
Si la respuesta es no a ambas preguntas, quizá debas reevaluar tu idea y pensar en su viabilidad y necesidad.
El código solo te importa a ti
Suena feo y suena duro. Solo te importa a ti y a tu equipo de trabajo, como miembros del equipo de desarrollo.
Quizá a otras áreas del departamento de tecnología. Pero definitivamente no a tus usuarios ni a tus clientes.
¿A qué traigo este doloroso pellizco de realidad?
A que muchas veces nos ingeniamos complejas soluciones, cuando eso no era lo que nuestro usuario necesitaba. Como me pasó a mi, gasté meses construyendo soluciones que no eran necesarias, o que alguien en internet ya ofrecía. Por ejemplo, podrías emplear algunos meses construyendo un formulario web con requerimientos “especiales”, o podrías sencillamente adaptar el formulario y publicarlo en Google Forms.
Para nuestro usuario o cliente, eso realmente no importa. No importa en qué está escrita la solución que le estás dando, o si detrás de las escenas te conectas a un API de un tercero. Lo importante es resolver su problema haciendo el mejor uso de los recursos disponibles. De eso se trata al final del día.
Conclusiones
Personalmente, me tomó mucho tiempo asimilar eso de que la tecnología es un medio para ayudar empresas y personas. Ayudarlas a ser más exitosas, más productivas, más felices. Pero no es un fin en si mismo. La tecnología no lo es todo. Es difícil entenderlo porque fuimos educados con buenas prácticas, siempre apuntando a hacer las cosas de la mejor manera. Sin embargo, ese orgullo y amor que nos infundieron por lo que hacemos muchas veces nubla nuestro buen criterio, y se interpone en el camino para hacer las cosas que se necesitan y que realmente generan valor.
¿Y tú qué opinas? ¿Has vivido algo similar? ¿Has conocido alguien que haya tenido problemas por prestar únicamente atención a la tecnología? Más abajo se encuentra la caja de comentarios por si quieres compartir tu opinión.
Gracias por leerme.
Manuel Zapata
