Chess - antoniomartel.com

Archivos de Categoría: Blog

Mi libro de nuevo en la Kindle Flash

Hoy domingo estará mi libro Gestión práctica de proyectos con Scrum entre los promocionados hoy por Amazon en su selección Kindle Flash.

Junto a mi libro están también de promoción:

  • La nube en la que vivo. Calum (El libro oficial) de Calum Heaslip.
  • El secreto del alquimista de Scott Mariani.
También en Kindle Flash con otros precios promocionales podrás encontrar libros como Nunca dejes de bailar de Carmen Grau o una selección de libros de Julia Navarro como Dime quién soy o Dispara, yo ya estoy muerto.

Si aún no lo has leído, anímate a comprarlo. Con esta promoción estará durante todo el día con un descuento del 75%.

Haciendo clic en la portada tienes el enlace a la oferta de hoy en Kindle Flash de Amazon.com, Amazon.es y Amazon Méjico:

Amazon.com
Amazon.es
Amazon.com.mx

Las cosas se hacen bien pero no demasiado bien

Esa es una frase que escuche en una ocasión a un médico cuando la enfermera le preguntaba si debía usar un tipo u otro de catéter. Lo que quería decir el médico era que no había necesidad de usar el catéter más caro, complejo o difícil de poner si con el más sencillo lográbamos lo mismo.

Es una regla útil para aplicarla en nuestros proyectos de trabajo o personales. Nos pasa cuando vamos a entregar una propuesta o un presupuesto, cuando simplemente debemos enviar un email o un informe o cuando tenemos que entregar una nueva versión de nuestro producto.

A veces lo hacemos por un perfeccionismo excesivo que nos hace pensar que nuestro producto debe tener las mejores características del mercado en todas y cada una de las funcionalidades. Cuando acabemos habremos terminado orgullosos de él pero, qué coste tiene el producto si tiene el Wifi más avanzado, el Bluetooth de mejor rendimiento y el mayor número de puertos USB ¿te lo comprarán a ese precio?

Y cuando por fin hayas decidido poner el producto en el mercado después de tantos meses de trabajo puestos en él ¿se seguirá usando el Bluetooth? ¿el número de puertos USB seguirá siendo una decisión relevante en la compra? Probablemente no.

Quizás era mejor haber planificado una fecha de lanzamiento, el próximo Black Monday por ejemplo, y calcular qué opciones nos da tiempo de construir para entonces. Seguro que en el mercado habrá productos más completos pero ¿serán tan económicos como el tuyo? ¿son tan fáciles de usar o pesan tan poco como tu producto? ¿tus competidores estarán teniendo tanto margen comercial como tendrías tú?

Cuando Google lanzó su Google Docs en la nube, los periodistas especializados fueron corriendo a preguntar a Microsoft por esta nueva amenaza a su MS Word. Google Docs era gratis y podía usarse desde cualquier ordenador sin instalación o licencia alguna. Steve Ballmer contestó de manera un tanto despectiva que Google Docs nunca a sustituir su clásica suite Office. En la nueva aplicación de Google ni siquiera era posible imprimir los documentos que escribías.

La respuesta de Google fue rápida. Al día siguiente Google Docs tenía implementado un botón Imprimir en su barra de herramientas ¿Cómo pudo haber hecho esto Google tan rápido? Sencillo, Google Docs no tiene funcionalidades complejas. Sólo hay 5 ó 6 funcionalidades en un único menú. Son justo las funcionalidades que necesitan el 90% de los documentos que escribimos.

No había mucho que desarrollar tampoco había mucho que probar. Debieron usar una librería de exportación a PDF estándar que recoge las características básicas y listo. No hay complicadas opciones de numeración, viñetas, estilos, fuentes o formatos. Sería una librería muy probada para esas pocas opciones por lo que no había mucho donde fallar.

En tu trabajo diario te puede pasar lo mismo. Puedes estar días y días buscando una diferencia de 1 céntimo entre el Debe y el Haber, pero mientras, el informe de pérdidas y ganancias está sin hacer.

Puedes hacer un versión de tu software para iPad, para tablets, para smartphones, para Chrome, Firefox Internet Explorer y Safari. Mientras tanto alguien está ganando dinero ya con su app para el iPhone pero sobre todo sabrá ya a estas alturas si merece la pena sacar una versión para Android o si estará tirando su tiempo y su dinero si lo hace.

Evita la procastinación, el miedo a fallar o a las críticas si tu producto no es el mejor de todos los que hay en el mercado o no se vende bien. Si eso pasa, bueno, por lo menos no invertiste demasiado en ello. Ve a por el siguiente o trata de mejorarlo en una siguiente versión (Kaizen lo llamaría yo). Ahora ya sabes qué es lo que no funciona y podrás probar de nuevo.

Esfuerzo y práctica

Hace muchos años, cuando se comenzaba a conocer cosas sobre la plasticidad del cerebro humano, su capacidad para regenerarse o adaptarse y que con la práctica y la estimulación de ciertas zonas se podían mejorar sus resultados, se pidió a grandes genios de la época que, una vez fallecieran, donaran sus cerebros a la ciencia (curiosamente nadie quiso hacerlo antes).

Los científicos querían estudiar qué tenían estas personas de especiales y, una vez descubierto, su idea era que todos pudiéramos estimular y ejercitar estas zonas para convertirnos en genios de la humanidad.

Pero después de estudiar unos cuantos cerebros, no encontraron nada de especial. Ni las neuronas iban más rápido, ni tenían una cantidad especial de conexiones entre ellas, ni nada de nada. Lo único que encontraron es que tenían una zona del cerebro hiper-desarrollada, más grande de lo normal. Era una zona dedicada a la memoria y que el cerebro utiliza para recordar cosas, pero que los científicos ya habían visto desarrollada así en taxistas de Londres.

Londres es una ciudad gigantesca, con miles y miles de calles y los taxistas que llevan muchos años trabajando en ella son capaces de recordar de memoria un gran número de calles. Obviamente, los taxistas de Londres no son genios (al menos no todos ellos). Entonces ¿qué hacía tan especiales a esos premios Nobel que donaron su cerebro a la ciencia?

Fue unos años más tarde cuando surgió otra teoría que trataba de explicar este fenómeno. Era la llamada teoría de las 10.000 horas del libro Outliers. Esta teoría decía que la gente que destacaba en sus profesiones o deportes era debido a que había invertido a lo largo de su vida unas 10.000 horas en perfeccionar su técnica.

Se había visto que el primer violinista de una orquesta contaba con 10.000 horas de práctica, el segundo sólo 7.000 y así consecutivamente. Lo mismo para el cirujano principal de un hospital o el golfista que destaca ese año en el campo.

Macauley, una gran jugador de baloncesto en los años 50 que fue el primer MVP en un partido all-star, decía ‘Si no estás practicando, alguien, en algún lugar, lo está haciendo, y cuando te enfrentes a él, te va a ganar‘.

Pero (de nuevo hay un pero) esta teoría tampoco lo explica todo. Todos conocemos a balocentistas, golfistas o jugadores de fútbol que llevan más de 10.000 horas de práctica y nunca van a llegar ni a tercera regional (no quisiera vivir cerca del violinista que después de 2.000 horas de práctica aún está ensayando canciones de principiante).

Aquí es cuando llega una tercera teoría que explica que lo que tenían estas personas en sus cabezas no era más que curiosidad. Sí, simple curiosidad. Ganas de hacer, de saber, de comprender o como lo queramos llamar.

Esto es lo que hacía que esos genios que donaron sus cerebros tuviesen el suficiente entusiasmo como para dedicar 10.000, 20.000 o más horas de su tiempo a lo que les apasiona, probando cosas diferentes cuando algo no les funciona e intentando cosas nuevas que les lleve por caminos distintos.

Así que si quieres convertirte, por ejemplo, en un experto arquitecto Java, ya sabes más o menos el esfuerzo que tienes que ponerle. Por otro lado, asegúrate de que te gusta mucho a lo que te vas a dedicar. Vas a invertir ahí mucho tiempo y si no te apasiona lo que haces vas a ser difícil que llegues a un nivel avanzado. 1000 horas repitiendo lo mismo no suman más que las 50 primeras que fue lo que tardaste en aprenderlo.

Referencias:

  • Outliers, Malcom Gladwell.
  • Agile Innovation, Langdon Morris

Gestión práctica de proyectos de nuevo en la Kindle Flash de Amazon

Mi libro Gestión práctica de proyectos con Scrum ha sido seleccionado de nuevo para una promoción de Amazon: Kindle Flash

Estas promociones Kindle Flash son promociones en las que, durante 24 horas, 3 libros seleccionados por Amazon son destacados en una newsletter que Amazon envía a todos los suscritos. Desde ahí, los usuarios de Amazon pueden comprar alguno de los libros promocionados ese día con un descuento de hasta el 80%.

Puedes suscribirte a la newsletter en este enlace para Amazon.es si estás en España, o en Amazon.com para otros países. Ahí estará mi libro a menos de 1$ entre las 12:00 am hasta las 11:59 pm del 14 de febrero. Además, suscribiéndote a esa newsletter puedes descargarte un ebook gratuito.

En este otro enlace puedes ver también los libros Kindle que estarán de promoción hasta las doce de la noche de hoy en Amazon Kindle Flash.

Si quieres leer el libro y no tienes un lector Kindle o no quieres descargarte la aplicación para tu PC, móvil o tablet, siempre puedes leer el libro yendo a la página read.amazon.com. Allí, con la cuenta de correo con la que compraste el libro, podrás leer cualquier ebook que hayas comprado en Amazon, aunque no tengas un lector Kindle.

Aquí tienes también los accesos al libro en los tres Amazon donde puedes comprarlo (si no quieres esperar al descuento del 14 de febrero):

Amazon.com
Amazon.es
Amazon.com.mx

Requisitos que pueden cambiar

Hace ya unos cuantos años, antes de aplicar por completo todo esto de agile, trabajé en el desarrollo de una aplicación web que debía gestionar las fichas de trabajo del cliente mediante una serie de pasos o wizard que guiase al usuario sobre la fase en la que estaba.

Realizamos un análisis completo, recopilamos todas las necesidades que el cliente tenía y de ahí salieron una lista de funcionalidades a implementar. Todo normal. Funcionalidades correctas y coherentes que solucionaban problemas concretos. Con el grueso documento de requisitos y su correspondiente diseño nos pusimos a implementar, una tras otra, cada una de estas funcionalidades.

En aquel momento ya intentamos ser algo ágiles (some way) e íbamos enseñando en pre-producción cada dos semanas lo que íbamos haciendo. No tenía mala pinta. Era fácil de usar e incluso nos dieron la enhorabuena por el trabajo que iban viendo. Estábamos contentos por lo que continuamos así hasta desarrollar con no poco esfuerzo hasta la última de las funcionalidades que estaban en el documento de análisis aprobado. Y subimos a producción…

En cuanto los administrativos estuvieron unos días usando la aplicación se dieron cuenta que habrían venido bien algunos cambios: incluir una tabla en cada pantalla con los documentos originales para no perderlos de vista, evitar salir a otro menú cuando se quiere crear una entidad, añadir más controles para evitar errores al finalizar una ficha, etc. La mayoría eran pequeños cambios que no llevarían más de 2 o 3 días de desarrollo pero nosotros ya habíamos acabado el presupuesto (y más).

Entre las funcionalidades que habíamos desarrollado al principio, había algunas de bastante complejidad que te permitían complicados cambios entre procesos, y que costó bastante desarrollar (y testear para tener en cuenta todos los posibles casos). Pregunté por ellas meses después pero nadie sabía de su existencia ni en qué menú estaban. Tampoco le dieron importancia. Cuando habían necesitado algo parecido cancelaron el proceso y empezaron uno nuevo.

Cuando empezamos el proyecto, ni yo, ni el cliente, ni los usuarios teníamos una idea exacta de lo que iba a funcionar bien. Simplemente no podíamos saberlo a ciencia exacta. ¿Qué podíamos haber hecho para evitar esto? Pues subir a producción en cuanto tuviésemos las funcionalidades básicas para los primeros procesos. Ahí habríamos visto con facilidad todos estos pequeños cambios que habrían hecho la aplicación más práctica y fácil de usar.

Desde entonces, en nuevos proyectos, cuando los usuarios ven la necesidad de cambios como éstos, me preguntan por la posibilidad de incluirlos. No tienen ningún problema en descartar otras funcionalidades de las que ya ni se acuerdan porqué las pusieron en los pliegos de contratación o a las que ahora no le ven tanto sentido.

La lista de funcionalidades está estimada desde el inicio en el product backlog y el cliente conoce esta estimación. Simplemente nos dice ‘Quítame la funcionalidad número 18 que llevaría 8 días de trabajo y cámbiamelas por estas dos nuevas que suman 6. Guardamos estos dos días por si solicitásemos algún cambio más‘.

Éste es otro de los principios ágiles:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

En general supone una ventaja para el cliente que obtiene un producto que le funciona y que no queda cojo hasta que se realice una nueva contratación para un mantenimiento evolutivo (a pagar con dinero extra), pero también es una ventaja para nosotros como proveedores que sumamos un proyecto que nos sirve referencia, en el que controlamos bien cada hora invertida y evitamos entregar un producto, en el que gastamos todo el presupuesto y al que le faltan cosas importantes.