Versión original en Eric Sink, aquí está la traducción realizada por Héctor García ;). Espero que os gusten mis cutre traducciones (me he tomado ciertas libertades para adaptarlo a nuestras costumbres) y disfrutéis de los artículos.
Me encanta jugar a las cartas. Paso muchas horas en la cocina jugando a pinochle, euchre o a las espadas.
Pero mi juego de cartas favorito es el bridge. Más específicamente, la variante del bridge que más me gusta es el «duplicado». La idea básica del bridge duplicado es que tu puntuación es una función de lo bien que juegues tus cartas en comparación con la forma de jugar que tengan los otros equipos jugando exactamente las mismas cartas.
Para ser claro, permitidme repetir: en un bridge duplicado, tu juegas las mismas cartas que tus oponentes. La suerte desaparece.
Tu tienes 13 cartas en las manos, por lo que hay 13 «tricks» para ganar. Si tienes muy buenas cartas no hay ninguna razón para ponerse contentos. Sí, tus cartas se podrán combinar para hacer muchos tricks, pero eso no es lo importante. Lo realmente importante es conseguir más tricks que los contrincantes que están jugando con las mismas cartas. Si consigues 9 tricks y otro consigue 10, tu pierdes.
Cada pequeño fallo que cometas jugando al bridge duplicado puede ser muy costoso. Yo voy a veces al club local de bridge, pero casi siempre pierdo. Al final de la tarde hago un repaso de las partidas he intento reflexionar sobre que lo que hice mal. Aunque soy muy malo jugando, disfruto porque en cada partida aprendo nuevas cosas.
Me suelo preguntar sobre otras situaciones de la vida donde se trabaje usando las mismas reglas: Los recursos y el contexto no varían — lo único que cambia es la habilidad de la persona para gestionar esos recursos.
Estas preguntas son realmente interesantes si nos las hacemos dentro del campo de la gestión de productos software. ¿Dada una pieza de tecnología o código, que pasaría si otra persona la estuviera gestionando?
- Que pasaría si yo estuviera gestionando Delphi en vez de Borland, ¿podría hacer un trabajo mejor?
- Si Joel Spolsky estuviera gestionando Vault por mi, ¿tendría el producto más usuarios?
- Si Sun pasara la gestión de Java a un comité de monos, ¿sería mejor? 🙂
Pero estás fantasías no van a ocurrir. Si los ISVs (Vendedor de software independiente) tuvieran que trabajar por duplicado, todos aprenderíamos muy rápido. Primero, aparecerían montones de errores estúpidos, y rápidamente veríamos lo mal que hemos sido gestionando nuestros productos. Después de esto, comenzaríamos a entender los puntos clave del marketing. En vez de achacar cada fallo a un «mal marketing», debemos revisar cada decisión que tomamos y buscar en que momento jugamos una mala carta.
No podemos jugar duplicado con nuestros productos shrinkwrap (Shrinkwrap es software que necesita ser probado en el exterior por mucha gente), pero podemos aprender los puntos clave del marketing. El marketing no es algo vago y difuso donde solo importa la suerte. Hay ciertos principios que se pueden aprender y aplicar.
Al Ries y Jack Trout llaman a estos principios como «leyes». Su libro, titulado «Las 22 leyes inmutables del marketing» es uno de mis favoritos. Y yo no podría ayudar pero me he dado cuenta de que hay exactamente 22 días de la semana (sin contar fines de semana) en el mes de Junio. Así que…
Durante el mes de Junio, escribiré un post cada día de la semana. Para cada una de las 22 leyes, resumiré el punto clave y luego haré una conexión con la industria del software. Los lectores interesados deberían leer el libro antes de seguir estos artículos:
Nota de traducción: he decidido no traducir los nombres de los juegos de cartas ni la jerga asociada. Espero que se haya entendido la idea general. Si alguien sabe jugar al bridge sería bueno que nos diera unas pequeñas nociones 😉
