No hace mucho que escuche por primera vez esta palabra. Me la dijo Jose Carlos Cortizo que fue mi profesor, es mi jefe y desde 5º de carrera le considero mi mentor en lo profesional.
La escuela del pragmatismo determina que "sólo es verdadero aquello que funciona" muy bonito y filosófico pero los programadores no entendemos esta jerga. Otra definición más cercana a lo que quiero llegar es "El pragmatismo consiste en reducir lo verdadero a lo útil". Y de las dos extraemos que "lo importante es aquello que funciona y es útil" y añado " y no sale caro".
Jose Carlos se refiere al pragmatismo como a ser realista, desarrollar lo que necesitas dedicando el mínimo tiempo y por tanto coste posible. Los ingenieros tendemos a querer hacerlo todo demasiado bien, hazlo, ya tendrás tiempo y dinero para mejorarlo si gusta a tus clientes. Prueba lo que quieres probar aprende a pivotar (cambiar partes de tu desarrollo o RoadMap) para gustar a tus clientes, hasta que les gustes.
Haciendo un remix con los conceptos de Lean Startup y el Pragmatismo de @Josek_net he extraído estos puntos:
Antes de empezar a desarrollar:
- ¿Tu producto soluciona algún problema?
- ¿Tus clientes han reconocido este problema?
- Si existiera una solución a tu problema ¿Tus clientes la comprarían?
- ¿Comprarían tu solución?
A la hora de programar:
- Haz lo necesario para probar tu producto. MVP: Mínimo Producto Viable.
- Pruébalo con los que serán tus usuarios. Pide betatesters.
- Monitoriza, analiza y pregunta.
- Desarrolla lo que quieren tus clientes.
A la hora de gastar:
- No lo compres si no lo necesitas realmente.
- Si te entra dinero: subcontrata lo que no sepas o no puedas hacer. Subcontratar es un coste y tu tiempo y el de tus empleados también. Valora cada situación y evalúa.
- Intenta tener lo que necesitas prestado, o alquilado, o gratis. Intenta no gastar.
- No seas cutre, compra aquello que necesites al 100% y te aporte valor.
Es un pequeño mantra que me llevo repitiendo un tiempo y quería plasmar para poder recordarlo de vez en cuando. Esto no significa que programes mal, es un recuerdo de que debes centrarte en la funcionalidad y dejar de lado detalles secundarios, pajas mentales y posibles. Desarrolla lo que te va a dar de comer, solo eso, nada más! Cualquier aportación será incluida :D
Muy buen post, crack, y gracias por la referencia :) Como bien comentas, los ingenieros tendemos a buscar la solución perfecta, y curiosamente la solución perfecta a veces no es la mejor solución ;)
ResponderSuprimirYo también creo que los ingenieros tenemos el problema de irnos por las ramas en temas que nos gustan: un código legible, limpio y hasta "bonito", una eficiencia cojonuda, un diseño genial y un montón de funcionalidades "extra" que nos molaría tener, hasta que alguien suelta un... "oye, ¿ésto qué leches tenía que hacer al final?"
ResponderSuprimirLo único con lo que no estoy de acuerdo, ni lo estaré nunca, intentando verlo como un emprendedor es lo de "subcontrata lo que no sepas". Para mi la subcontratación no debería ser legal (aunque eso es otro tema); Yo abogo más por tener una plantilla muy, muy corta, mixta y bien formada y aún por encima de eso, implicada con el proyecto y que aporte distintos puntos de vista.